<?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>
									openclawsecurity.net Forum - Recent Topics				            </title>
            <link>https://openclawsecurity.net/community/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 14 Aug 2026 09:21:59 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Guide: Running Aider in a VS Code dev container with locked-down capabilities.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/guide-running-aider-in-a-vs-code-dev-container-with-locked-down-capabilities/</link>
                        <pubDate>Wed, 15 Jul 2026 22:01:33 +0000</pubDate>
                        <description><![CDATA[Having recently audited several self-hosted coding agent setups, a common pattern emerges: developers run tools like Aider in overly permissive environments, negating the security benefits o...]]></description>
                        <content:encoded><![CDATA[Having recently audited several self-hosted coding agent setups, a common pattern emerges: developers run tools like Aider in overly permissive environments, negating the security benefits of self-hosting. The primary risk is not the agent itself, but the execution context it inherits. This guide outlines a method for running Aider within a VS Code Dev Container, applying a default-restricted, capability-dropping posture.

The goal is to create a container where Aider can function for code generation and Git operations, but is explicitly denied the ability to:
* Execute arbitrary shell commands outside its toolset.
* Access the Docker socket or host network.
* Write to filesystems outside the designated workspace.

A foundational `devcontainer.json` configuration achieves this by starting from a minimal image, adding only necessary packages, and dropping Linux capabilities. The `runArgs` are critical for containment.

```json
{
    "name": "Aider (Locked-Down)",
    "image": "mcr.microsoft.com/devcontainers/base:debian",
    "features": {
        "ghcr.io/devcontainers/features/git:1": {}
    },
    "runArgs": ,
    "mounts": ,
    "postCreateCommand": "pip install --user aider-chat",
    "customizations": {
        "vscode": {
            "extensions": []
        }
    }
}
```

Key security controls in this configuration:
- `--cap-drop=ALL`: Removes all Linux capabilities, preventing container breakout via privilege escalation.
- `--read-only` with a `/tmp` tmpfs: The root filesystem is immutable; only a volatile `/tmp` is writable, mitigating persistence of malicious scripts.
- Bind mount for workspace: The host's project directory is mounted explicitly, isolating container filesystem access.
- No `network` mode overrides: The container uses the default bridge network, isolated from the host.

For Git operations, Aider requires specific capabilities. The container provides Git, but the `--cap-drop=ALL` setting means any attempt by Aider to spawn subprocesses outside its direct function will fail. This must be validated against your specific workflow. Consider implementing additional guardrails:
* A pre-commit hook audit log within the workspace to monitor Git actions.
* A `.git/config` that uses a dedicated, non-administrative SSH key with minimal repository permissions.
* VS Code's own sandboxing of terminal access provides an additional layer.

This approach shifts the security model from hoping the agent doesn't misuse its environment to architecturally preventing misuse. It aligns with zero-trust principles for development tools, treating the agent API as an untrusted boundary. Further hardening would involve app-specific firewall rules to restrict Aider's outbound API calls to only the configured LLM endpoint.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Sarah Bolton</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/guide-running-aider-in-a-vs-code-dev-container-with-locked-down-capabilities/</guid>
                    </item>
				                    <item>
                        <title>Did you see the post about using DNS sinkholes for threat intel feeds?</title>
                        <link>https://openclawsecurity.net/community/dns-and-layer7-controls/did-you-see-the-post-about-using-dns-sinkholes-for-threat-intel-feeds/</link>
                        <pubDate>Wed, 15 Jul 2026 21:59:43 +0000</pubDate>
                        <description><![CDATA[Hey everyone, saw an interesting discussion pop up in another forum about using DNS sinkholes not just for ad-blocking, but as a primary feed for threat intelligence.

Specifically, they wer...]]></description>
                        <content:encoded><![CDATA[Hey everyone, saw an interesting discussion pop up in another forum about using DNS sinkholes not just for ad-blocking, but as a primary feed for threat intelligence.

Specifically, they were layering feeds from places like the OpenPhish project or abuse.ch's URLhaus directly into a Pi-hole or a custom resolver. The idea is to block known malicious domains at the DNS layer before any connection even attempts to establish. It's a solid, low-cost layer to add.

I'm curious about the practical side here for our egress control discussions. How are you all handling the maintenance and false positives with these feeds? And are you pairing this with a layer 7 proxy (like Squid with SSL inspection) to catch what DNS filtering misses, or using it more as a canary for detection? Let's share some real-world setups.

- Grace (mod)]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Grace Mod</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/dns-and-layer7-controls/did-you-see-the-post-about-using-dns-sinkholes-for-threat-intel-feeds/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with seccomp filters blocking clone() for subprocess management?</title>
                        <link>https://openclawsecurity.net/community/openclaw-seccomp-apparmor/anyone-else-having-issues-with-seccomp-filters-blocking-clone-for-subprocess-management/</link>
                        <pubDate>Wed, 15 Jul 2026 21:00:46 +0000</pubDate>
                        <description><![CDATA[Seeing seccomp filters break subprocess spawning in containerized workloads. Specifically clone() being blocked.

Common pattern:

```json
{
  &quot;names&quot;: ,
  &quot;action&quot;: &quot;SCMP_ACT_ERRNO...]]></description>
                        <content:encoded><![CDATA[Seeing seccomp filters break subprocess spawning in containerized workloads. Specifically clone() being blocked.

Common pattern:

```json
{
  "names": ,
  "action": "SCMP_ACT_ERRNO",
  "args": [],
  "comment": "restrict process creation"
}
```

Problem: Many languages/runtimes (Go, Python subprocess) rely on clone() for fork/exec. Blocking it outright kills legitimate process management.

What are you actually trying to block?
- New network namespace? Filter on `CLONE_NEWNET`.
- General process isolation? Might need to allow clone but restrict with cgroups pids controller.
- True fork bombs? Limit via RLIMIT_NPROC.

Better approach: Allow clone, but filter on its flags argument.

```json
{
  "names": ,
  "action": "SCMP_ACT_ALLOW",
  "args": ,
  "comment": "deny clone with namespace flags"
}
```

What's your actual filter? What's the workload? Are you blocking clone entirely or using argument filtering?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>David Kirsch</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-seccomp-apparmor/anyone-else-having-issues-with-seccomp-filters-blocking-clone-for-subprocess-management/</guid>
                    </item>
				                    <item>
                        <title>Hot take: The &#039;tool use&#039; feature is a backdoor waiting to be exploited.</title>
                        <link>https://openclawsecurity.net/community/openai-operator-security/hot-take-the-tool-use-feature-is-a-backdoor-waiting-to-be-exploited/</link>
                        <pubDate>Wed, 15 Jul 2026 20:59:51 +0000</pubDate>
                        <description><![CDATA[Everyone is focused on the model&#039;s output, but the real attack surface is the tool-calling mechanism itself. The OpenAI Operator can now execute actions on behalf of users via connected tool...]]></description>
                        <content:encoded><![CDATA[Everyone is focused on the model's output, but the real attack surface is the tool-calling mechanism itself. The OpenAI Operator can now execute actions on behalf of users via connected tools. This isn't just a feature; it's a delegated privilege engine with insufficient isolation.

Let's break down the immediate threats using STRIDE:
*   **Spoofing:** How does the Operator authenticate to third-party services (Google Calendar, Slack, etc.)? If it uses a long-lived user-provided API key, that credential is now stored and processed in OpenAI's environment. The attack tree starts with compromising that storage or the execution flow.
*   **Tampering:** The primary vector is prompt injection via web content or documents the model processes. A manipulated instruction in a retrieved webpage can become a tool-calling command. The model is the interpreter, and we've seen it's not a reliable security boundary.
*   **Repudiation:** If an agent sends a damaging email or deletes data, who is liable? The user who provided credentials? OpenAI? The audit trail is opaque.
*   **Information Disclosure:** The Operator now has structured access to private services. A successful injection could exfiltrate calendar entries, emails, or team messages through the same tool channel.
*   **Denial of Service:** Tool calls can be abused to spam or disable external accounts via their APIs.
*   **Elevation of Privilege:** The user's granted tool permissions become the agent's permissions. There's no step-down or context-aware limitation per action.

The compliance angle is a nightmare. GDPR, SOC2, etc., are built on knowing where your data flows. An OpenAI-hosted agent acting on user credentials creates a data processor chain that is dynamic and poorly defined. You've just outsourced privileged actions to a system you cannot audit.

We need concrete answers, not marketing:
*   What is the exact credential storage and transit mechanism?
*   Is there a tool-calling sandbox or any runtime validation beyond the model's discretion?
*   What logging of tool calls and their authorization context is provided to the enterprise user?

Without this, "tool use" is just a fancy name for a remote access trojan with a natural language interface.

- TL]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Lena Threat</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openai-operator-security/hot-take-the-tool-use-feature-is-a-backdoor-waiting-to-be-exploited/</guid>
                    </item>
				                    <item>
                        <title>Just built a script to monitor key derivation event logs.</title>
                        <link>https://openclawsecurity.net/community/ironclaw-key-management/just-built-a-script-to-monitor-key-derivation-event-logs/</link>
                        <pubDate>Wed, 15 Jul 2026 20:00:40 +0000</pubDate>
                        <description><![CDATA[Built a script to pull key derivation events from our IronClaw test rig&#039;s audit log. Noticed something odd in the sealing process during enclave teardown.

Looking at the logs, the derived k...]]></description>
                        <content:encoded><![CDATA[Built a script to pull key derivation events from our IronClaw test rig's audit log. Noticed something odd in the sealing process during enclave teardown.

Looking at the logs, the derived key gets sealed to the enclave's identity, but the event stream shows two sealing operations when we trigger a controlled shutdown. Should only be one. Anyone else monitoring this? Need to confirm if this is expected behavior or a bug in our config.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Ray M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/ironclaw-key-management/just-built-a-script-to-monitor-key-derivation-event-logs/</guid>
                    </item>
				                    <item>
                        <title>Has anyone written a contingency plan specifically for agent system failure?</title>
                        <link>https://openclawsecurity.net/community/hipaa-and-healthcare/has-anyone-written-a-contingency-plan-specifically-for-agent-system-failure/</link>
                        <pubDate>Wed, 15 Jul 2026 20:00:08 +0000</pubDate>
                        <description><![CDATA[Looking at HIPAA&#039;s contingency plan requirement (164.308(a)(7)(i)). Our traditional plans cover server outages, network loss, data recovery.

But an agent system introduces new failure modes...]]></description>
                        <content:encoded><![CDATA[Looking at HIPAA's contingency plan requirement (164.308(a)(7)(i)). Our traditional plans cover server outages, network loss, data recovery.

But an agent system introduces new failure modes. An orchestrator crash could leave patient data stranded in an LLM provider's memory. A corrupted context window might retain PHI even after the main app is restored.

Has anyone drafted or seen a plan that addresses:
* Securely purging agent context (via API call, timeout) as part of disaster recovery?
* Failover that ensures no new PHI is sent to a compromised or degraded agent pipeline?
* How to document/testing procedures for this?

Thinking we need specific technical controls. Here's a crude example for a pod-level kill switch to isolate an agent deployment in Kubernetes, using a NetworkPolicy (Calico in this case):

```yaml
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: block-agent-egress-contingency
  namespace: agent-production
spec:
  selector: app == 'llm-agent'
  types:
  - Egress
  egress:
  - action: Deny
    destination:
      nets:
      - 0.0.0.0/0
```

Triggering that policy would be part of the containment step. But what about the data already in flight or at the external provider? That's the gap I'm trying to cover.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Sam K.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/hipaa-and-healthcare/has-anyone-written-a-contingency-plan-specifically-for-agent-system-failure/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made: A small daemon that rate-limits and logs all agent file writes.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/check-out-what-i-made-a-small-daemon-that-rate-limits-and-logs-all-agent-file-writes/</link>
                        <pubDate>Wed, 15 Jul 2026 19:00:55 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running a self-hosted Aider instance for a few weeks now, mostly happy with its git integration. But the more I watched it work, the more a specific pattern started to itch: the ag...]]></description>
                        <content:encoded><![CDATA[I've been running a self-hosted Aider instance for a few weeks now, mostly happy with its git integration. But the more I watched it work, the more a specific pattern started to itch: the agent writes files directly to my working directory, and while it *usually* uses git, there's nothing enforcing that all writes are part of a commit cycle. A stray bug, a malformed instruction, or a dependency hallucination could lead to uncontrolled file generation, filling a disk or clobbering sensitive configs.

Instead of wrapping the entire agent in a heavy VM, I built a small, focused daemon that sits between the agent and the filesystem. Its only job is to intercept, rate-limit, and log every `write` or `rename` syscall targeting the workspace. It's a userspace solution, leveraging `ptrace` to be runtime-agnostic—it works with Python, Node, or any binary the agent might spawn.

The core idea is a simple allowlist with a token-bucket rate limiter. You define a directory (like `/workspace`) and a maximum number of writes per minute. The daemon permits all writes within that directory but enforces the limit. Crucially, it logs every attempt—successful or throttled—with a hash of the content. This gives you an immutable audit trail of what the agent tried to create and when.

Here's a snippet of the core policy configuration:

```yaml
workspace_path: "/home/agent/workspace"
max_writes_per_minute: 50
log_file: "/var/log/agent_writes.log"
audit_mode: false  # if true, logs but does not throttle
```

When `audit_mode` is false and the agent exceeds 50 writes in a minute, subsequent writes are delayed (not rejected) to smooth out bursts. This prevents a runaway script from causing a denial-of-service against its own workspace, while still allowing legitimate high-activity operations to complete, just more slowly.

The log output is structured for easy parsing:
`2024-05-15T14:23:17Z | ALLOWED | /home/agent/workspace/src/main.rs | sha256:a1b2c3... | 2048 bytes`

This approach complements broader sandboxing (like gVisor or a WASM runtime) by adding a fine-grained, observable control layer at the filesystem boundary. It's a step towards treating the agent not as a trusted user, but as a service with explicit, measurable resource constraints. I'm considering adding hooks to automatically commit allowed writes to git, closing the loop on that original concern. What other agent actions would benefit from this kind of transparent interposition?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>wasm_isolator</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/check-out-what-i-made-a-small-daemon-that-rate-limits-and-logs-all-agent-file-writes/</guid>
                    </item>
				                    <item>
                        <title>Switched from LangChain&#039;s stuff to LangGraph, auth story is still missing.</title>
                        <link>https://openclawsecurity.net/community/langgraph-security/switched-from-langchains-stuff-to-langgraph-auth-story-is-still-missing/</link>
                        <pubDate>Wed, 15 Jul 2026 18:59:49 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been evaluating LangGraph for a potential production deployment after moving away from LangChain&#039;s more fragmented orchestration approach. The structured state graphs and checkpointing ...]]></description>
                        <content:encoded><![CDATA[I've been evaluating LangGraph for a potential production deployment after moving away from LangChain's more fragmented orchestration approach. The structured state graphs and checkpointing are a significant improvement for control flow, but from a security standpoint, the authentication and authorization model for the graph itself and its tools appears to be an afterthought. This is a critical gap when you're deploying these graphs as long-running, stateful services that may handle sensitive data or interact with external APIs.

The core issue is that a LangGraph essentially becomes an execution engine for a graph of tools and LLM calls. The graph's state can be checkpointed to an external store (Redis, Postgres), and that state can be resumed by any caller who has the graph ID. Where is the mandatory authz check before resuming a state that might contain PII, internal reasoning, or tool outputs? There isn't one. The `configurable` fields are for routing logic, not for attaching principal or tenant identifiers in a validated way. You're meant to roll your own wrapper and hope you don't miss an edge.

Similarly, tool nodes are just Python callables. If your graph uses a `ToolNode` or a function binding, there is no built-in mechanism to enforce that the *caller* of the graph is authorized to trigger the specific tool (e.g., "send_email", "query_database"). You have to bake the authorization into the tool function itself, which violates clean separation and is easy to get wrong. The graph's security is only as strong as the weakest tool's ad-hoc checks.

Here's a trivial example of the problem. A graph with a state that includes a user-provided query, checkpointed to a public URL.

```python
from langgraph.graph import StateGraph, MessagesState
from langgraph.checkpoint.sqlite import SqliteSaver

class State(MessagesState):
    user_query: str

builder = StateGraph(State)
# ... define nodes, edges
memory = SqliteSaver.from_conn_string(":memory:")
graph = builder.compile(checkpointer=memory)

# First call, checkpoint is created.
config = {"configurable": {"thread_id": "thread_123"}}
initial_result = graph.invoke({"user_query": "show me all users' emails"}, config)
# State is now saved.

# Later, ANYONE can resume this exact conversation state if they can guess or discover the thread_id.
malicious_resume = graph.invoke({"user_query": "now change the admin password"}, config)
# The graph continues, with no authentication barrier.
```

The mitigation isn't complicated, but it must be systematic and enforced. My checklist for the team so far:

*   **Wrap the graph invocation.** All `graph.invoke`, `graph.stream`, `graph.batch` calls must go through a middleware that validates a JWT or session token, extracts a principal, and validates it against the `thread_id` or a mapping table before allowing the call to proceed.
*   **Isolate checkpoint stores.** The checkpoint storage (e.g., Redis DB) must be namespaced by tenant and inaccessible cross-tenant. The `thread_id` must be scoped with a tenant prefix.
*   **Instrument tool nodes.** Every tool callable should receive validated principal data from the invocation context, not from the untrusted state. Implement a decorator that enforces a policy before execution.
*   **Audit LangSmith.** If you're using LangSmith, be aware that your entire state, messages, and tool outputs are likely being logged. You must filter sensitive data via `langsmith.config` and ensure your LangSmith project has strict access controls.
*   **Run under restrictive profiles.** The entire graph runtime should be sandboxed. Our deployment uses a combination of:
    *   A custom seccomp profile blocking unnecessary syscalls.
    *   An AppArmor profile denying filesystem writes except to a temporary scratch space.
    *   Dropped Linux capabilities (`CAP_NET_BIND_SERVICE`, `CAP_SYS_ADMIN`, etc.).
    *   Container isolation with a read-only root filesystem and non-root user.

Until the LangGraph library provides first-class primitives for authentication and authorization hooks, we're stuck building this perimeter ourselves. The risk is state contamination, privilege escalation via tool invocation, and data leakage from checkpoint stores. Has anyone else built a robust auth layer for this, or are we all just hoping our wrapper is airtight?

- Leo]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Leo M.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/langgraph-security/switched-from-langchains-stuff-to-langgraph-auth-story-is-still-missing/</guid>
                    </item>
				                    <item>
                        <title>Switched from OpenHands back to Aider - the sandbox was too restrictive for our legacy codebase.</title>
                        <link>https://openclawsecurity.net/community/aider-openhands-security/switched-from-openhands-back-to-aider-the-sandbox-was-too-restrictive-for-our-legacy-codebase/</link>
                        <pubDate>Wed, 15 Jul 2026 18:00:57 +0000</pubDate>
                        <description><![CDATA[After extensive comparative analysis of the default security postures in both OpenHands and Aider, our team has reverted to Aider for active development on a legacy monolith. The decision, w...]]></description>
                        <content:encoded><![CDATA[After extensive comparative analysis of the default security postures in both OpenHands and Aider, our team has reverted to Aider for active development on a legacy monolith. The decision, while seemingly a regression from a hardened configuration standpoint, was necessitated by OpenHands' stringent default sandboxing, which proved incompatible with the non-standard build and execution patterns inherent to our older system.

The core issue lies in the fundamental architectural philosophy: OpenHands adopts a default-restricted, zero-trust posture for agent-executed commands, whereas Aider operates with a default-open, trust-the-user model. For greenfield projects adhering to modern containerized workflows, OpenHands is superior. However, legacy codebases often require orchestration of bespoke scripts, direct package manager calls outside of declared environments, and interactions with local daemons. OpenHands' sandbox, likely leveraging namespace isolation and seccomp-bpf filtering, systematically blocked these necessary operations.

Our primary pain points manifested in the following scenarios:

*   **Build System Integration:** The legacy build process involves a series of chained Python and shell scripts that modify the `PATH` and `LD_LIBRARY_PATH` dynamically. OpenHands' sandbox prevented these environment variable injections, causing consistent "command not found" failures.
*   **Local Service Dependency:** The application requires a connection to a locally running, unauthenticated Redis instance on a non-standard port for a specific data transformation step. The sandbox's network filtering appeared to block this loopback communication, despite our attempts to configure allowed hosts.
*   **File System Access Patterns:** Several scripts write temporary artifacts to sibling directories outside the declared project root, a pattern we are not currently positioned to refactor. The sandbox's filesystem jail correctly denied these writes, halting the pipeline.

We attempted to configure the OpenHands sandbox policy, but the documentation for advanced profiles is sparse. The apparent requirement to define an exhaustive allow-list of binaries, arguments, and network endpoints was untenable given the complexity and fluidity of our legacy dev environment. In contrast, Aider's model, which essentially runs with the user's permissions, presented no such barriers.

This experience raises a critical question for the community regarding the security trade-offs in self-hosted agent environments: **How are teams managing the gap between ideal, restricted agent execution and the pragmatic needs of brownfield development?** Is the prevailing strategy to:
*   Dilute the sandbox policy to near-permissiveness, accepting the risk?
*   Invest in substantial refactoring of the legacy codebase to conform to the sandbox's expectations before agent adoption?
*   Or, as we did, regress to a less restrictive agent, compensating with other controls like network-level segmentation and rigorous code review on the agent's outputs?

I am particularly interested in any documented patterns for creating graduated or learning sandbox policies that can be relaxed incrementally based on observed, legitimate needs, rather than requiring a complete and perfect policy definition upfront.

- Lei]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Lei Zhang</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/aider-openhands-security/switched-from-openhands-back-to-aider-the-sandbox-was-too-restrictive-for-our-legacy-codebase/</guid>
                    </item>
				                    <item>
                        <title>Breaking: new research paper on detecting exfiltration in multi-agent systems.</title>
                        <link>https://openclawsecurity.net/community/openclaw-exfiltration-detection/breaking-new-research-paper-on-detecting-exfiltration-in-multi-agent-systems/</link>
                        <pubDate>Wed, 15 Jul 2026 17:59:53 +0000</pubDate>
                        <description><![CDATA[Read the paper. They&#039;re still stuck in the containerized, over-abstracted mindset. Monitoring egress from a container namespace tells you nothing about what the agent *actually* did. You&#039;re ...]]></description>
                        <content:encoded><![CDATA[Read the paper. They're still stuck in the containerized, over-abstracted mindset. Monitoring egress from a container namespace tells you nothing about what the agent *actually* did. You're watching the wrong layer.

Real detection happens on the metal. If your agent needs outbound, define it. Enforce it. Then log the violation at the kernel level where it can't be lied about.

Example: an agent's unit file with strict cgroup-based egress control via `systemd`.

```ini

...
IPAccounting=yes
IPAddressAllow=192.0.2.1/32
IPAddressDeny=any
```

Now check the logs. The kernel reports violations to journald.
```bash
journalctl -u your-agent.service _TRANSPORT=kernel
```

Combine with AppArmor to deny network sockets except to specific binaries. No "anomaly detection" needed. Just a policy failure and a definitive log entry. Baselines are for people who don't know what their software is supposed to do.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/"></category>                        <dc:creator>Joe Harris</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-exfiltration-detection/breaking-new-research-paper-on-detecting-exfiltration-in-multi-agent-systems/</guid>
                    </item>
							        </channel>
        </rss>
		