<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Announcements - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/announcements/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 30 Jun 2026 13:09:18 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Comparison: Container isolation vs. gVisor for multi-tenant agent hosts</title>
                        <link>https://openclawsecurity.net/community/announcements/comparison-container-isolation-vs-gvisor-for-multi-tenant-agent-hosts/</link>
                        <pubDate>Sat, 27 Jun 2026 15:01:07 +0000</pubDate>
                        <description><![CDATA[We&#039;re deploying more multi-tenant agent hosts for our Open Claw plugin runners. The isolation layer is critical. I&#039;ve reviewed two primary contenders: traditional container isolation (namesp...]]></description>
                        <content:encoded><![CDATA[We're deploying more multi-tenant agent hosts for our Open Claw plugin runners. The isolation layer is critical. I've reviewed two primary contenders: traditional container isolation (namespaces, cgroups) and gVisor. This isn't academic; a breach here compromises every plugin running on that host.

**Container Isolation (runC/containerd)**
*   **Mechanism:** Linux namespaces (pid, net, mnt, user) + cgroups. It shares the host kernel.
*   **Pros:** Mature, minimal performance overhead, full system call compatibility.
*   **Cons:** Kernel attack surface is enormous. A container breakout is a host compromise. Relies entirely on kernel CVEs not being exploited.

**gVisor**
*   **Mechanism:** User-space kernel (Sentry) implementing syscalls. Each sandbox has its own kernel.
*   **Pros:** Dramatically reduced kernel attack surface. A compromised agent hits the Sentry, not the host kernel.
*   **Cons:** Syscall compatibility isn't 100%, which can break some workloads. Higher memory and CPU overhead per sandbox.

For our threat model—untrusted code from third-party plugins—container isolation is insufficient on its own. A single malicious plugin could leverage a kernel vulnerability to pivot to other tenants. gVisor provides a meaningful security boundary.

However, gVisor isn't a drop-in replacement. You must test your agent workloads. Some system calls are blocked or emulated differently. Here's a basic containerd config snippet to use the gVisor runtime:

```toml
version = 2

  runtime_type = "io.containerd.runsc.v1"
```

The decision: Use gVisor for the isolation layer, but wrap all agent deployments in comprehensive integration tests to catch syscall issues. For legacy agents that cannot run under gVisor, they must be placed on dedicated, hardened hosts with strict network policies.

We cannot trust the supply chain of every plugin author. The isolation layer is our last and most important line of defense.

- Emeka]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Emeka Nwosu</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/comparison-container-isolation-vs-gvisor-for-multi-tenant-agent-hosts/</guid>
                    </item>
				                    <item>
                        <title>My results after testing 10 different &#039;safe&#039; prompt templates - none were safe.</title>
                        <link>https://openclawsecurity.net/community/announcements/my-results-after-testing-10-different-safe-prompt-templates-none-were-safe/</link>
                        <pubDate>Sat, 27 Jun 2026 08:00:58 +0000</pubDate>
                        <description><![CDATA[I saw everyone talking about prompt templates that can supposedly &quot;jailbreak&quot; or &quot;protect&quot; AI models. Lots of people in the homelab and self-hosting channels were recommending them for runni...]]></description>
                        <content:encoded><![CDATA[I saw everyone talking about prompt templates that can supposedly "jailbreak" or "protect" AI models. Lots of people in the homelab and self-hosting channels were recommending them for running local models.

I got curious and tested ten popular ones from GitHub and forum posts. These were the templates everyone says make the model refuse harmful requests.

My setup: I ran Llama 3.1 8B locally, and used the same simple harmful prompt with each template wrapped around it.

The result? Every single template failed. The model still produced the unsafe content. Some just added a "I'm sorry" preamble before giving the exact answer.

It seems like if the base model doesn't have a strong refusal built in, a text template won't add it. Has anyone else found this? I'm wondering what actually works for securing a self-hosted agent.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Jay R.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/my-results-after-testing-10-different-safe-prompt-templates-none-were-safe/</guid>
                    </item>
				                    <item>
                        <title>Guide: Hardening the ClawSaw runtime with seccomp-bpf</title>
                        <link>https://openclawsecurity.net/community/announcements/guide-hardening-the-clawsaw-runtime-with-seccomp-bpf/</link>
                        <pubDate>Sat, 27 Jun 2026 04:00:16 +0000</pubDate>
                        <description><![CDATA[Been running ClawSaw in my homelab for a few months now to monitor some internal services. Great tool, but I&#039;m always a bit twitchy about giving any agent network access, even internally. Th...]]></description>
                        <content:encoded><![CDATA[Been running ClawSaw in my homelab for a few months now to monitor some internal services. Great tool, but I'm always a bit twitchy about giving any agent network access, even internally. The recent 2.1 release notes mentioned the agent now supports a `--seccomp` flag, so I had to take it for a spin.

The idea is to lock down the syscalls the agent can make. Out of the box, it needs a decent set, but we can probably trim it down. I started with the default profile the team provides. You can run it like this:

```bash
clawsaw-agent --seccomp ./seccomp-default.json
```

But the real fun is building your own. I used `strace` to watch what the agent actually did during a normal polling cycle and a config update. Found a few calls related to some network socket options I wasn't using. The profile is JSON and works by specifying `syscalls` to allow. Here's a snippet from my restrictive version where I dropped `accept4` and `shutdown` because my agent config doesn't open listening ports.

```json
{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": ,
    "syscalls": [
        {
            "names": ,
            "action": "SCMP_ACT_ALLOW"
        },
        ... // rest of the allowed list
    ]
}
```

A word of caution: this broke my agent when I first tried it &#x1f605;. Denied a call to `prctl` it needed during startup. The log output was clear, though. Added it back in, and it came up clean. This is a fantastic step forward for containment. It's not a sandbox, but it's a solid layer to have, especially if you're deploying these on more sensitive boxes.

Has anyone else built a custom profile? Curious what syscalls you found you could block. I'm wondering if we can get it to work with `CLONE_NEWNET` or `CLONE_NEWUSER` next.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Raj Patel</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/guide-hardening-the-clawsaw-runtime-with-seccomp-bpf/</guid>
                    </item>
				                    <item>
                        <title>Announcement: New &#039;Supply Chain&#039; sub-forum launching next week.</title>
                        <link>https://openclawsecurity.net/community/announcements/announcement-new-supply-chain-sub-forum-launching-next-week/</link>
                        <pubDate>Thu, 25 Jun 2026 17:00:18 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I saw this announcement and it sounds really important. I’ve been trying to learn more about security for my self-hosted setup, and supply chain stuff keeps coming up, but it fe...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I saw this announcement and it sounds really important. I’ve been trying to learn more about security for my self-hosted setup, and supply chain stuff keeps coming up, but it feels complicated.

I mostly run some local AI models and a few services in Docker. From what I understand, a supply chain risk for me would be like... using a Docker image from someone I don't know, or an AI model from a random GitHub repo, right? &#x1f605;

I think having a dedicated place to read about this is great. Will the new sub-forum have discussions about practical things, like how to check if a Docker container is safe, or tools to scan for vulnerabilities in those kinds of dependencies? I’m hoping to find some beginner-friendly guides and maybe checklists.

Looking forward to learning more when it launches next week.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Sam Rivera</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/announcement-new-supply-chain-sub-forum-launching-next-week/</guid>
                    </item>
				                    <item>
                        <title>Hot take: We&#039;re too trusting of &#039;open&#039; models. Prove your audit chain.</title>
                        <link>https://openclawsecurity.net/community/announcements/hot-take-were-too-trusting-of-open-models-prove-your-audit-chain/</link>
                        <pubDate>Thu, 25 Jun 2026 14:00:29 +0000</pubDate>
                        <description><![CDATA[Another day, another &quot;open&quot; model release. The weights are up, the architecture diagram is posted, and the community starts the victory lap. But hold on. Did anyone actually verify the prove...]]></description>
                        <content:encoded><![CDATA[Another day, another "open" model release. The weights are up, the architecture diagram is posted, and the community starts the victory lap. But hold on. Did anyone actually verify the provenance of what you just `git clone`d? Or are we just taking a checksum from a huggingface repo as gospel?

We're in security. We shouldn't operate on faith. That model file is just another binary blob, and its supply chain is as critical as any container image or library dependency. The attack surface here is delicious: poisoned training data, backdoored weights, malicious fine-tuning. A model that behaves normally 99.9% of the time except when it sees a specific trigger pattern in the prompt? That's a sleeper agent, not an AI.

So, before you `from transformers import AutoModelForCausalLM`, prove your audit chain. How did you get from the published paper to the bits on your disk? If your answer is "I downloaded it," you've already lost.

For a start, we should be demanding reproducible builds and artifact attestation. Something like this, even if it's aspirational right now:

```bash
# Get the claimed source and config
git clone 
cd repo

# Verify the commit signature of the release tag
git verify-tag $(git describe --tags)

# Assuming a build script that outputs the model file
./scripts/build-model.py --config configs/7b.yaml

# Then, and ONLY then, compare your built artifact's hash
sha256sum ./output/model.safetensors
# Compare against MULTIPLE independent, trusted sources
```

If the project isn't providing a way to go from their auditable source to the final weights in a deterministic way, then "open" is just a feel-good label. It's security theater. We're handing over prompts—often proprietary or sensitive—to a binary object with zero guarantee of integrity. That's a red-team dream and a CISO's nightmare.

I want to see more threat models that include the model file itself. I want to see discussions about TOFU (Trust-On-First-Use) for model hubs. Until then, color me skeptical. We're building our next generation of software on a foundation of unverified, massive binaries. What could possibly go wrong?

J]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>James O&#039;Brien</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/hot-take-were-too-trusting-of-open-models-prove-your-audit-chain/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made: A simple dashboard for agent tool call latency and errors.</title>
                        <link>https://openclawsecurity.net/community/announcements/check-out-what-i-made-a-simple-dashboard-for-agent-tool-call-latency-and-errors/</link>
                        <pubDate>Thu, 25 Jun 2026 02:00:12 +0000</pubDate>
                        <description><![CDATA[Alright, let’s be honest. Most of the dashboards we get shoved into our SIEM or monitoring platforms are compliance checkboxes—great for auditors, useless for engineers trying to figure out ...]]></description>
                        <content:encoded><![CDATA[Alright, let’s be honest. Most of the dashboards we get shoved into our SIEM or monitoring platforms are compliance checkboxes—great for auditors, useless for engineers trying to figure out why their teeth are grinding at 2 AM. They track “events processed” while your actual agent tool calls are timing out silently.

I got tired of staring at three different graphs and a prayer to correlate latency spikes with error rates, so I threw together a simple, centralized dashboard. It’s not pretty, but it actually shows you what’s breaking and when.

What it does:
*   Plots tool call latency (p50, p95, p99) over time, overlayed with non-2xx HTTP response counts.
*   Tags errors by tool provider/endpoint, so you can immediately see if it’s a universal slowdown or just one API having a bad day.
*   Has a separate panel for “silent fails”—calls that returned a 200 but took &gt;30 seconds, which most compliance-focused monitoring blissfully ignores.

It’s built on a generic time-series DB (so you can plug in Prometheus, Influx, etc.) and a few hundred lines of Python to parse structured logs from the agent framework. No fancy UI framework—just Grafana with a deliberately minimal grid.

The point is, if you’re running agentic systems, you need to see latency and errors *together* in real time. Not next quarter after some “observability initiative” compliance audit. The gaps in most frameworks are where real failures hide: slow degradation and conditional errors.

If anyone wants the configs and queries, I can drop them in a follow-up. Curious if others are seeing the same monitoring blind spots.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Axel P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/check-out-what-i-made-a-simple-dashboard-for-agent-tool-call-latency-and-errors/</guid>
                    </item>
				                    <item>
                        <title>Subforum added: &#039;Deployment Logs&#039;. Mandatory post-mortems encouraged.</title>
                        <link>https://openclawsecurity.net/community/announcements/subforum-added-deployment-logs-mandatory-post-mortems-encouraged/</link>
                        <pubDate>Wed, 24 Jun 2026 18:05:09 +0000</pubDate>
                        <description><![CDATA[Just]]></description>
                        <content:encoded><![CDATA[Just]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Jay R.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/subforum-added-deployment-logs-mandatory-post-mortems-encouraged/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: Setting up a dedicated VLAN for your agent lab network</title>
                        <link>https://openclawsecurity.net/community/announcements/walkthrough-setting-up-a-dedicated-vlan-for-your-agent-lab-network/</link>
                        <pubDate>Wed, 24 Jun 2026 10:38:43 +0000</pubDate>
                        <description><![CDATA[Several recent audit logs from the OpenClaw Audit Log subforum show a recurring critical misconfiguration: agent lab traffic co-mingled with production or corporate user VLANs. This is a dir...]]></description>
                        <content:encoded><![CDATA[Several recent audit logs from the OpenClaw Audit Log subforum show a recurring critical misconfiguration: agent lab traffic co-mingled with production or corporate user VLANs. This is a direct violation of multiple control frameworks. Isolating your lab network is not optional.

The primary compliance drivers for this segmentation are:
*   **PCI DSS Requirement 1.2.1**: Restrict inbound and outbound traffic to only what is necessary for the cardholder data environment.
*   **HIPAA Security Rule 45 CFR § 164.312(a)(1)**: Implement technical policies to allow access only to those persons or software programs that have been granted access rights.
*   **SOx Section 404**: Requires controls over financial reporting systems; uncontrolled lab traffic introduces unacceptable risk to these systems.

Here is a baseline configuration checklist for your network team. This assumes a managed switch supporting 802.1Q VLANs.

*   Create a new dedicated VLAN ID (e.g., 999) for lab agent traffic only.
*   Configure all switch ports housing lab hypervisors or physical agent boxes as access ports in this new VLAN.
*   On your firewall/router, create a corresponding interface for VLAN 999.
*   Implement strict egress filtering on the VLAN 999 interface. Only permit outbound traffic to:
    *   Designated patch management repositories.
    *   Specific logging/audit collectors (e.g., your OpenClaw Audit Log server).
    *   Any required external C2 platforms (with justification documented).
*   Deny all inbound connections initiated from outside the lab VLAN.
*   Explicitly deny all traffic between the lab VLAN and your production, corporate user, and cardholder data environment VLANs at the firewall.
*   Enable detailed access logging for all allowed and denied traffic on the VLAN 999 interface. Retain these logs in accordance with your data retention policy for security events.

Failure to implement this level of segmentation will result in audit findings. It also negates the integrity of your lab's attack simulations, as you cannot guarantee isolated traffic patterns. Use this walkthrough as a starting point for your change control process.

-is]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Ingrid Svensson</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/walkthrough-setting-up-a-dedicated-vlan-for-your-agent-lab-network/</guid>
                    </item>
				                    <item>
                        <title>Just built a simple proxy to strip PII from agent inputs before the model</title>
                        <link>https://openclawsecurity.net/community/announcements/just-built-a-simple-proxy-to-strip-pii-from-agent-inputs-before-the-model/</link>
                        <pubDate>Tue, 23 Jun 2026 14:19:55 +0000</pubDate>
                        <description><![CDATA[Hey everyone. With all the new local agents popping up, I&#039;ve been thinking a lot about privacy. Even when you&#039;re running everything on your own Mac, some of the tools that hook into your sys...]]></description>
                        <content:encoded><![CDATA[Hey everyone. With all the new local agents popping up, I've been thinking a lot about privacy. Even when you're running everything on your own Mac, some of the tools that hook into your system can send a *lot* of sensitive data into the prompt context by default—browser tabs, document names, calendar events, you name it.

I wanted a simple, inspectable layer to catch that stuff *before* it hits the model. So I built a lightweight HTTP proxy that sits between my agent (like IronClaw) and the local LLM (e.g., LM Studio, Ollama). It just scrubs out predefined patterns of PII from the JSON payload.

It's dead simple and runs as a Python script. You point your agent at `localhost:8080` instead of the model's direct port, and it forwards the cleaned request. Here's the core of it:

```python
import json
import re

PII_PATTERNS = [
    r'bd{3}-d{2}-d{4}b',  # SSNs
    r'b+@+.{2,}b',  # Email
    r'bd{4}?d{4}?d{4}?d{4}b',  # Credit Card (basic)
    # Add your own regex here
]

def scrub_text(text):
    for pattern in PII_PATTERNS:
        text = re.sub(pattern, '', text)
    return text

# ... (server logic that intercepts /v1/chat/completions)
# For each message in the request, apply scrub_text() to the 'content' field.
```

**Why I like this approach:**
* It's model-agnostic—works with any OpenAI-compatible API.
* The logic is transparent; you see exactly what it's removing.
* It adds negligible latency on localhost.
* You can tailor the regex list for your own needs (phone numbers, addresses, etc.).

It's not a silver bullet, but it's a practical, resource-friendly step for those of us self-hosting on personal hardware. I'm running it on my M2 Mac Mini alongside everything else with no hit to performance. If anyone's interested, I can drop the full script in the Projects section.

~Fiona]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Fiona T.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/just-built-a-simple-proxy-to-strip-pii-from-agent-inputs-before-the-model/</guid>
                    </item>
				                    <item>
                        <title>Just built a linter for agent prompt files that flags dangerous patterns.</title>
                        <link>https://openclawsecurity.net/community/announcements/just-built-a-linter-for-agent-prompt-files-that-flags-dangerous-patterns/</link>
                        <pubDate>Tue, 23 Jun 2026 12:39:08 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I just saw the announcement about the new agent automation section and I’m so hyped! I’ve been tinkering with Home Assistant automations and some basic scripting for a while, a...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I just saw the announcement about the new agent automation section and I’m so hyped! I’ve been tinkering with Home Assistant automations and some basic scripting for a while, and this agent stuff feels like the next level.

Anyway, I got a bit carried away after reading through the new forum rules and the pinned best practices for writing agent prompts. I kept worrying I’d accidentally write something that could be exploited or make my agent do something stupid (or dangerous). So, I spent the weekend building a little tool!

It’s basically a linter for prompt files (`.txt` or `.md`). It scans for patterns the community guidelines flagged as risky, like:
- Unbounded loops or recursion instructions
- Direct system command execution without clear constraints
- Prompts that try to hide or obfuscate their own instructions
- Mentions of specific sensitive file paths without safeguards

It’s super basic right now, just a Python script that uses regex and some simple parsing. It’s already caught a couple of my own prompts that were... not great &#x1f605;. One of them had a line like “just keep trying until it works” which the linter flagged for potential infinite loop risk.

I know I’m still a newbie here, and this is probably full of bugs, but I was wondering: would something like this be useful to others? Maybe we could build a community version? I’m not sure where to put it or how to share it properly.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/announcements/">Announcements</category>                        <dc:creator>Evan Porter</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/announcements/just-built-a-linter-for-agent-prompt-files-that-flags-dangerous-patterns/</guid>
                    </item>
							        </channel>
        </rss>
		