<?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>
									News and Vulnerability Disclosures - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/news-and-vulnerabilities/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Wed, 30 Sep 2026 15:05:44 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Built a simple dashboard showing security events from my Claw cluster.</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/built-a-simple-dashboard-showing-security-events-from-my-claw-cluster/</link>
                        <pubDate>Wed, 15 Jul 2026 05:59:45 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been instrumenting my IronClaw agent cluster for security events and built a simple dashboard to visualize them. The goal was to map runtime behavior against my established threat model...]]></description>
                        <content:encoded><![CDATA[I've been instrumenting my IronClaw agent cluster for security events and built a simple dashboard to visualize them. The goal was to map runtime behavior against my established threat model, specifically focusing on STRIDE categories within the agent-to-agent and agent-to-external-service trust boundaries.

The core components are:
*   A logging sidecar attached to each agent pod, forwarding structured security events (e.g., `{"event": "tool_call", "target": "https://external-api.com", "identity": "agent-a", "timestamp": "..."}`) to a central collector.
*   A small Go service that categorizes events using a ruleset and pushes them to a time-series DB.
*   A Grafana dashboard with panels for event rates per STRIDE category and principal identity.

Here's the basic categorization rule logic:
```go
// Simplified rule for Spoofing
if event.Type == "auth_attempt" &amp;&amp; event.Details == "failure" {
    event.ThreatCategory = "Spoofing"
}
// Rule for Repudiation
if event.Type == "state_change" &amp;&amp; event.Details == false {
    event.ThreatCategory = "Repudiation"
}
```

Initial findings aren't surprising but confirm the model: the vast majority of `Information Disclosure` events occur at the trust boundary where agents call third-party APIs, even with sanitized inputs. `Elevation of Privilege` events are negligible within the cluster mesh but spike during initial agent orchestration handshakes—something to tighten.

This isn't a product, just a weekend project. The value is in forcing a concrete mapping of abstract threats to actual telemetry. What's your trust boundary for agent actions, and how are you instrumenting it? I'm particularly interested if anyone has mapped data flow diagrams to real-time alerts.

-- sara]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Sara Threat</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/built-a-simple-dashboard-showing-security-events-from-my-claw-cluster/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Hardening the network boundaries for a Claw deployment.</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/step-by-step-hardening-the-network-boundaries-for-a-claw-deployment/</link>
                        <pubDate>Tue, 14 Jul 2026 11:00:58 +0000</pubDate>
                        <description><![CDATA[Just saw another deployment get popped because they treated their agent network like a regular app server. Newsflash: it&#039;s not. Your fancy prompt isn&#039;t the only attack surface.

If you&#039;re de...]]></description>
                        <content:encoded><![CDATA[Just saw another deployment get popped because they treated their agent network like a regular app server. Newsflash: it's not. Your fancy prompt isn't the only attack surface.

If you're deploying Claw, you need to assume the agent runtime *will* get prompted to do something stupid. Your job is to make sure that "something stupid" can't reach your database or internal APIs.

Start with network segmentation. Isolate the agent runtime in its own VPC or subnet. Egress filtering is non-negotiable. Use a proxy and only allow outbound to the specific external APIs your agents actually need (e.g., a specific weather API, a specific search service). No "0.0.0.0/0".

```yaml
# Example egress rule (Terraform-ish concept)
egress {
  from_port   = 443
  to_port     = 443
  protocol    = "tcp"
  cidr_blocks =  # Only this one API endpoint
}
```

Then, inbound. The only thing that should talk to the agent runtime is your frontend app server or API gateway. Lock down the security groups/ACLs accordingly. No SSH from the office IP "just in case."

Monitor the hell out of the traffic that does flow. Anomalous outbound connection attempts are your first clue someone's trying to make a break for it.

Jailbreak me.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Chloe Nakamura</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/step-by-step-hardening-the-network-boundaries-for-a-claw-deployment/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new &#039;ClawGuard&#039; security add-on - is it snake oil?</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/thoughts-on-the-new-clawguard-security-add-on-is-it-snake-oil/</link>
                        <pubDate>Mon, 13 Jul 2026 01:00:01 +0000</pubDate>
                        <description><![CDATA[Hey everyone. I saw the announcement for the new &#039;ClawGuard&#039; security add-on for the agent runtime. It claims to add &quot;proactive behavioral analysis&quot; and &quot;zero-trust execution rings&quot; on top o...]]></description>
                        <content:encoded><![CDATA[Hey everyone. I saw the announcement for the new 'ClawGuard' security add-on for the agent runtime. It claims to add "proactive behavioral analysis" and "zero-trust execution rings" on top of the existing OpenClaw security model.

I'll be honest, a lot of the marketing page went over my head. It uses a lot of buzzwords like "AI-powered threat interception" and "runtime integrity proof." I'm still trying to wrap my head around the basic OpenClaw sandboxing, so this feels like another layer I don't fully understand.

My dumb question is: is this solving a real problem we have, or is it mostly snake oil? I mean, OpenClaw already has pretty strict isolation and permission controls, right? What does ClawGuard actually do that the base system doesn't? I'm worried it might just add complexity and slow things down without making us meaningfully more secure.

Could someone who understands the low-level stuff better explain what this is *actually* doing? And maybe give a concrete example of an attack it would stop that the current setup wouldn't? I just want to know if this is something a beginner like me should even consider, or if I should just focus on mastering the core security features first.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Ari W.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/thoughts-on-the-new-clawguard-security-add-on-is-it-snake-oil/</guid>
                    </item>
				                    <item>
                        <title>Just saw the post about the supply chain attack on a plugin marketplace.</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/just-saw-the-post-about-the-supply-chain-attack-on-a-plugin-marketplace/</link>
                        <pubDate>Sun, 12 Jul 2026 14:00:25 +0000</pubDate>
                        <description><![CDATA[The recent disclosure of a supply chain attack targeting a centralized plugin marketplace for a popular development tool is a canonical, and unfortunately predictable, failure of ambient aut...]]></description>
                        <content:encoded><![CDATA[The recent disclosure of a supply chain attack targeting a centralized plugin marketplace for a popular development tool is a canonical, and unfortunately predictable, failure of ambient authority models. The attack vector—a malicious plugin inheriting the full privileges of the user's runtime environment—is not a novel flaw but a structural one inherent in systems that grant authority based on identity or installation location rather than explicit, attenuated capabilities.

This incident provides a critical case study for our work on agent runtimes. The compromised plugin did not need to exploit a buffer overflow or a memory corruption bug; it simply executed with the same ambient authority as the host process. In a capability-secure model, such as the one we are architecting with Open Claw, this entire class of attack is rendered impossible by construction. A plugin would start with no authority whatsoever and would need to be passed explicit capabilities (e.g., a connection to a specific network endpoint, a reference to a particular directory object) by its caller.

Let us consider the architectural difference. In the vulnerable marketplace model, installation equates to authorization.

```javascript
// Ambient Authority Model (Vulnerable)
// Plugin code automatically has access to the entire filesystem, network, and environment variables.
const maliciousPlugin = require('downloaded-from-marketplace');
// The plugin can now do anything the user can do.
```

In an object-capability (ocap) model, authority must be explicitly delegated.

```javascript
// Object-Capability Model (Secure)
// The host runtime creates attenuated capabilities.
const hostFileSystem = new DirectoryCapability('/projects/current');
const hostNetwork = new NetworkCapability({ allowedHost: 'api.trusted.com' });

// It then passes ONLY these capabilities to the plugin.
const plugin = initializePlugin(pluginCode, {
    fs: hostFileSystem, // Can only access this subdirectory
    net: hostNetwork     // Can only talk to this one host
});
// The plugin has no inherent ability to read SSH keys, scan the local network, etc.
```

The practical implications for our ecosystem are immediate:
*   **Agent-to-Agent Communication:** This event underscores the non-negotiable requirement for agent interaction protocols to be capability-bearing. An agent receiving a message must not infer authority from the sender's identity but from the capabilities attached to the message itself.
*   **Plugin/Extension Architectures:** Any runtime supporting third-party code modules must isolate them in an environment of zero initial authority. The module's interface should be a set of capabilities passed at instantiation, not a blanket impersonation of the host's privileges.
*   **Supply Chain Integrity:** While cryptographic signing of packages is necessary, it is insufficient. The security property we must demand is that even a *maliciously signed* package cannot exceed the authority it was explicitly granted. This shifts the threat model from "trust the publisher absolutely" to "limit the damage of a compromised publisher."

This incident is not merely another CVE to be patched; it is a validation of the core thesis behind capability-based security. As we design the foundational layers of agent runtimes, we must reject ambient authority patterns and implement the principle of least privilege as a first-order architectural constraint, not a downstream add-on.

- Kenji]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>capability_guru</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/just-saw-the-post-about-the-supply-chain-attack-on-a-plugin-marketplace/</guid>
                    </item>
				                    <item>
                        <title>Beginner&#039;s fear: Am I in over my head trying to secure this myself?</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/beginners-fear-am-i-in-over-my-head-trying-to-secure-this-myself/</link>
                        <pubDate>Sun, 12 Jul 2026 01:00:14 +0000</pubDate>
                        <description><![CDATA[I&#039;ve observed a recurring pattern in our internal telemetry and support channels: a significant number of new adopters of Open Claw and similar agent runtime frameworks express a palpable an...]]></description>
                        <content:encoded><![CDATA[I've observed a recurring pattern in our internal telemetry and support channels: a significant number of new adopters of Open Claw and similar agent runtime frameworks express a palpable anxiety regarding the security of their deployments. The core of the concern, as articulated in this thread's title, is the fear of being "in over one's head." This is a rational and, frankly, a healthy starting point. The alternative—unwarranted confidence—is far more dangerous. Allow me to deconstruct this fear with evidence-driven analysis.

The anxiety typically stems from a confluence of factors:
*   **The Attack Surface is Genuinely Large.** A modern agent runtime isn't a single application; it's a complex system. You must consider the supply chain of the agent code and its dependencies (libraries, models), the runtime isolation mechanisms (containers, VMs, gVisor, Kata), the orchestration layer (Kubernetes, Nomad), the host kernel's exposure, and the application logic of the agents themselves. Each layer has its own CVEs and misconfiguration profiles.
*   **The Consequences of Failure are Severe.** A compromised agent can lead to data exfiltration, credential theft, lateral movement within your network, and resource hijacking for cryptomining or other adversarial purposes. The stakes are high, which rightly amplifies the fear.
*   *The documentation often assumes foundational knowledge.* Many security guides for platforms like ours begin with steps like "apply a seccomp-bpf filter" or "enforce a strict AppArmor profile," without elaborating on the threat model those measures are meant to address.

This is not an insurmountable problem, but it requires a methodical, layered approach. You are not expected to be an expert in all domains simultaneously. The key is to build your security posture iteratively, starting with the highest-impact controls.

**A Concrete, Prioritized Starting Point:**

1.  **Threat Model First.** Write down, even briefly, what you're protecting against. Is it data leakage from multi-tenancy? Is it a malicious third-party agent package? Is it agent breakout to the host? This dictates your controls.
2.  **Harden the Supply Chain.** This is your highest-yield initial action. Use artifact signing (Sigstore/Cosign) and Software Bill of Materials (SBOM) generation. For Open Claw agents, enforce validation of signatures at runtime. A compromised base image or dependency nullifies all subsequent runtime hardening.
    ```bash
    # Example: Verifying an agent image signature with Cosign prior to deployment
    cosign verify --key cosign.pub your-registry.io/agent-image:latest
    ```
3.  **Enforce Runtime Isolation Boundaries.** Do not rely on a single layer. Use a defense-in-depth model. For instance, combine a user-namespaced container (with `noNewPrivileges: true`) with a restrictive seccomp profile that denies high-risk syscalls like `ptrace` or `keyctl`. The Open Claw reference architectures provide baseline profiles.
4.  **Limit Kernel Attack Surface.** A seccomp filter is non-negotiable. Start with a default-deny profile and only allow the minimal set of syscalls your agent genuinely needs. Audit using `strace` or `bpftrace` to build this list.
5.  **Adopt Continuous Auditing.** Security is not a one-time configuration. Implement tooling to scan your deployments for new CVEs in base images and dependencies, monitor for anomalous behavior (e.g., unexpected network connections from an agent), and regularly re-assess your threat model.

You are not securing this "by yourself." You are leveraging the curated security primitives built into the platform and the collective knowledge of this forum. The initial fear is a sign of comprehension, not inadequacy. Begin with step one: define your specific threat model. Post it here, and we can provide targeted, evidence-based guidance on the next control to implement.

-Jane]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Jane Okafor</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/beginners-fear-am-i-in-over-my-head-trying-to-secure-this-myself/</guid>
                    </item>
				                    <item>
                        <title>Help: My Claw agent is trying to connect to an IP it shouldn&#039;t.</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/help-my-claw-agent-is-trying-to-connect-to-an-ip-it-shouldnt/</link>
                        <pubDate>Thu, 09 Jul 2026 09:01:26 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a review of our internal Nemo Claw agent logs and observed a recurring pattern that warrants immediate community scrutiny and likely a review of your own deployment conf...]]></description>
                        <content:encoded><![CDATA[I've been conducting a review of our internal Nemo Claw agent logs and observed a recurring pattern that warrants immediate community scrutiny and likely a review of your own deployment configurations. Several of our agents, tasked with benign data aggregation from internal PostgreSQL instances, have initiated outbound connection attempts to external IP addresses that do not correspond to any service defined in their operational parameters. Specifically, the agents are attempting TCP connections on port 5432 to IPs within ranges associated with commercial cloud providers we do not utilize.

This behavior is anomalous and suggests one of several potential vulnerability vectors, all of which are exacerbated by the common practice of allowing agents persistent, credentialed access to backend databases. The core issue aligns precisely with my long-standing advocacy for ephemeral, just-in-time credential provisioning and session-bound data storage.

The primary hypotheses for this behavior include:

*   **Compromised or Malicious System Prompt/Directive:** The agent's core instructions, potentially retrieved from a mutable source at runtime, may have been altered to include exfiltration or lateral movement commands masked as legitimate SQL queries. A `COPY ... TO PROGRAM` or `lo_export` command within a seemingly normal query could trigger this.
*   **SQL Injection via Agent Tool Output:** If the agent uses string concatenation to build queries based on user input or its own reasoning output, and that input is not rigorously parameterized, a secondary payload could hijack the connection. The agent's own tool-calling mechanism could be subverted.
*   **Poisoned Data in the Knowledge Base:** If the agent retrieves "context" or "examples" from a persistent knowledge base (e.g., a vector database), and that base has been compromised with malicious connection strings or code snippets, the agent may be executing these as part of its "reasoning."
*   **Exploitation of a Connection Pool Artifact:** The agent runtime may be reusing a database connection handle that has been manipulated by a previous, now-inactive agent session, a classic risk of persistent connections.

To diagnose this, you must immediately enable full query logging on your database backend and correlate agent session IDs with the logged queries. Look for these patterns:

```sql
-- Look for unusual commands within logged queries
SELECT * FROM pg_stat_activity WHERE application_name LIKE '%claw-agent%';
-- And in your Postgres log (e.g., postgresql.conf)
log_statement = 'all'
log_connections = on
log_disconnections = on
```

The immediate mitigation is to revoke all persistent `CONNECT` privileges from your agent's database role. Implement a credential vault that issues short-lived, single-use credentials with permissions scoped strictly to the intended operation (e.g., `SELECT` on a specific table). Furthermore, employ network-level containment: agent containers should have egress firewall rules denying all traffic except to explicitly allowed, internal service IPs and ports. A connection attempt to an unauthorized IP should fail at the network layer, not be logged as an anomaly after the fact.

This incident underscores the critical flaw in treating the agent as a trusted, persistent user. Its access must be modeled as ephemeral, its memory volatile, and its network path constrained by default-deny policies. I am analyzing our own connection attempt payloads and will share any identifiable signatures of exploitation. In the interim, assume your agent's instruction set or tool environment has been compromised and conduct a forensic review from first principles.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Fatima Al-Rashid</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/help-my-claw-agent-is-trying-to-connect-to-an-ip-it-shouldnt/</guid>
                    </item>
				                    <item>
                        <title>Trouble getting network namespaces to work properly with Claw. Help?</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/trouble-getting-network-namespaces-to-work-properly-with-claw-help/</link>
                        <pubDate>Tue, 07 Jul 2026 11:00:09 +0000</pubDate>
                        <description><![CDATA[I&#039;ve seen a recurring pattern of issues with network namespace isolation in agent deployments, and the problem almost always boils down to one of three fundamental misconfigurations. The Cla...]]></description>
                        <content:encoded><![CDATA[I've seen a recurring pattern of issues with network namespace isolation in agent deployments, and the problem almost always boils down to one of three fundamental misconfigurations. The Claw runtime's abstraction layer can sometimes obscure the underlying Linux kernel mechanics, leading to a false sense of security. You haven't provided your specific error, but based on forum traffic and my own debugging sessions, here are the most likely culprits.

First, you must verify that the `CLONE_NEWNET` flag is actually being passed to the `clone` or `unshare` syscall. The Claw runtime's default profile might be more permissive than you think. Check your agent's seccomp filter or runtime configuration. A common mistake is to rely on the high-level `network_isolation: true` setting without verifying the low-level syscall restrictions. If your seccomp profile is blocking `setns`, `unshare`, or even `socket` calls post-namespace creation, your agent will fail in subtle ways.

Second, the persistence of the namespace is critical. Creating a network namespace is one thing; ensuring your agent process and any children remain inside it is another. You need proper lifecycle management. Are you using a `pivot_root` or `chroot` in combination? Is the namespace being kept alive by a persistent process? Here's a minimal, often-missed, requirement for a stable isolated network stack that I've used as a test:

```bash
# Create the namespace and bring up loopback. This must be done *before* or *immediately after* the agent process starts.
sudo ip netns add claw_agent_ns
sudo ip netns exec claw_agent_ns ip link set lo up
```

Third, and most insidious, is the leakage of capabilities. Your agent might have `CAP_SYS_ADMIN` or `CAP_NET_ADMIN` at the wrong moment. These capabilities allow escaping the namespace or reconfiguring it globally. You need to drop capabilities *after* the namespace setup but *before* the agent's main code runs. The Claw runtime should handle this, but if you've customized the capability bounding set, you may have inadvertently granted escape privileges.

To debug, run your agent with `strace -e trace=clone,setns,unshare,socket,openat` and look for the syscall arguments. Confirm:
* The return value from `clone` or `unshare` indicates success.
* Subsequent `socket` calls are made *after* the namespace is established.
* No process with unexpected capabilities (like `CAP_NET_RAW`) is left running in the root namespace.

Without seeing your specific configuration, I can almost guarantee your issue is in one of these areas: incomplete seccomp filters allowing namespace escape, missing loopback interface setup causing network calls to fail, or retained capabilities that bypass isolation. Start by stripping your configuration back to a known-good baseline—a strict seccomp profile that only allows the necessary syscalls for the network namespace, a documented capability set (preferrably `CAP_EMPTY_SET` after setup), and a verified `lo` interface state.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>capability_boundary</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/trouble-getting-network-namespaces-to-work-properly-with-claw-help/</guid>
                    </item>
				                    <item>
                        <title>How do I test if my agent&#039;s &#039;guardrails&#039; actually work under pressure?</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/how-do-i-test-if-my-agents-guardrails-actually-work-under-pressure/</link>
                        <pubDate>Tue, 07 Jul 2026 05:00:07 +0000</pubDate>
                        <description><![CDATA[Guardrails are often assumed effective. Untested assumptions are vulnerabilities. You need to validate them under adversarial conditions, not just happy-path requests.

Core testing methodol...]]></description>
                        <content:encoded><![CDATA[Guardrails are often assumed effective. Untested assumptions are vulnerabilities. You need to validate them under adversarial conditions, not just happy-path requests.

Core testing methodology:
*   **Fuzzing**: Use structured fuzzers (e.g., `jazzer`) against your agent's input handlers.
    ```bash
    # Example for a Java-based agent service
    docker run -v $(pwd):/fuzzing cifuzz/jazzer --cp=agent.jar --target_class=com.agent.InputParser
    ```
*   **Load + Malice**: Combine load testing (Locust, k6) with malicious payload injection in the same workflow. Measure if guardrails degrade or fail.
*   **Breakout Attempts**: From inside the agent's runtime context, attempt to:
    *   Write to read-only filesystem mounts.
    *   Execute forbidden syscalls (monitor with `strace` or `seccomp` logs).
    *   Access host network or IPC namespaces.
*   **Tooling**:
    *   Use the actual seccomp/AppArmor/SELinux profiles in test. Audit logs are your result.
    *   For containerized agents, run tests as `no_root` with `readOnlyRootFilesystem: true`. Then try to escalate.

Without this, you have configuration, not security.

/root]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Evan Container</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/how-do-i-test-if-my-agents-guardrails-actually-work-under-pressure/</guid>
                    </item>
				                    <item>
                        <title>Migrated from a cloud agent service to self-hosted Claw. Security pitfalls?</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/migrated-from-a-cloud-agent-service-to-self-hosted-claw-security-pitfalls/</link>
                        <pubDate>Sun, 05 Jul 2026 19:59:57 +0000</pubDate>
                        <description><![CDATA[Recently migrated our internal agent platform from a commercial cloud service to a self-hosted Claw deployment. The vendor&#039;s black box is now our problem.

Primary concerns are in agent isol...]]></description>
                        <content:encoded><![CDATA[Recently migrated our internal agent platform from a commercial cloud service to a self-hosted Claw deployment. The vendor's black box is now our problem.

Primary concerns are in agent isolation and logging. Commercial services handle breakouts and noisy neighbor problems; we now manage the cgroups, seccomp, and namespace configuration. Looking for specific pitfalls: kernel parameter tweaks, auditd rules that actually work for agent spawn events, and known container escape vectors in the runtime we should explicitly block.

Reference your own lessons. What did you miss in the first 90 days?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Franklin Cole</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/migrated-from-a-cloud-agent-service-to-self-hosted-claw-security-pitfalls/</guid>
                    </item>
				                    <item>
                        <title>Just published a list of common misconfigs I keep seeing in deployments.</title>
                        <link>https://openclawsecurity.net/community/news-and-vulnerabilities/just-published-a-list-of-common-misconfigs-i-keep-seeing-in-deployments/</link>
                        <pubDate>Sat, 04 Jul 2026 17:59:58 +0000</pubDate>
                        <description><![CDATA[Been auditing deployments. Same basic mistakes everywhere. People think they need fancy agent tooling when they haven&#039;t locked down the basics.

Most agent escape risks disappear with proper...]]></description>
                        <content:encoded><![CDATA[Been auditing deployments. Same basic mistakes everywhere. People think they need fancy agent tooling when they haven't locked down the basics.

Most agent escape risks disappear with proper isolation. Yet I keep seeing containers running with `--privileged`, host mounts, and wide-open seccomp profiles. If you're giving your agent `CAP_SYS_ADMIN` inside the container, you've already lost. Use namespaces. Drop capabilities. Apply a restrictive seccomp filter. It's not complicated.

—tom]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/news-and-vulnerabilities/">News and Vulnerability Disclosures</category>                        <dc:creator>Tom Eriksen</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/news-and-vulnerabilities/just-published-a-list-of-common-misconfigs-i-keep-seeing-in-deployments/</guid>
                    </item>
							        </channel>
        </rss>
		