<?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>
									Trust Boundaries and Component Isolation - openclawsecurity.net Forum				            </title>
            <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/</link>
            <description>openclawsecurity.net Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Tue, 29 Sep 2026 13:28:39 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>My results after stress-testing the model backend with malicious tool outputs</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/my-results-after-stress-testing-the-model-backend-with-malicious-tool-outputs/</link>
                        <pubDate>Wed, 15 Jul 2026 13:59:44 +0000</pubDate>
                        <description><![CDATA[During a recent architectural review of the OpenClaw agent framework, I focused on a specific control gap: the integrity of the model backend when processing potentially corrupted or malicio...]]></description>
                        <content:encoded><![CDATA[During a recent architectural review of the OpenClaw agent framework, I focused on a specific control gap: the integrity of the model backend when processing potentially corrupted or malicious outputs from tool executors. The premise is that a compromised or malfunctioning tool could return data designed to exploit the model's parsing or state management.

My test scenario involved the model backend (specifically the `ClawModel` class) being fed tool outputs that contained:
* Overly long strings intended to trigger buffer handling issues.
* Nested JSON structures with extreme recursion depths.
* Malformed Unicode sequences and control characters.
* Simulated prompt injection payloads within the `content` field of a tool response.

The initial configuration, with default request timeouts and input validation, exhibited several concerning behaviors:
* The model process would hang, consuming 100% CPU, when processing a recursively nested payload, requiring a SIGKILL.
* No logging of the malformed input structure was present in the model's audit trail; only a generic "processing error" was emitted.
* The isolation boundary between the tool executor's runtime and the model's runtime was maintained (the model did not execute code), but the denial-of-service vector was clear.

Key findings on control weaknesses:
* The model backend lacks a structured sanitization layer for tool outputs prior to parsing. It assumes the tool executor's boundary is secure.
* Error handling within the model's context window management does not gracefully reset state after a poisoning attempt, leading to resource exhaustion.
* The audit trail does not capture the *nature* of the invalid input, breaking the evidence chain for forensic analysis.

Required mitigations must address both resilience and auditability:
* Implement a strict schema validation (e.g., using Pydantic) for all tool outputs before they are passed to the model's context.
* Introduce circuit breakers and input size/recursion limits at the model backend ingress point.
* Enhance logging to capture a hash of the malformed payload and the point of rejection, preserving chain of custody without storing potentially harmful data inline.

The broader question for this forum is: does the responsibility for sanitizing tool output lie solely with the tool executor, or must each downstream component (orchestrator, model) enforce its own input validation as a defense-in-depth measure? The current design appears to place undue trust in the tool executor boundary.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Priya Mendis</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/my-results-after-stress-testing-the-model-backend-with-malicious-tool-outputs/</guid>
                    </item>
				                    <item>
                        <title>Switched from AutoGen to OpenClaw because of the explicit trust boundary documentation</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/switched-from-autogen-to-openclaw-because-of-the-explicit-trust-boundary-documentation/</link>
                        <pubDate>Tue, 14 Jul 2026 00:00:05 +0000</pubDate>
                        <description><![CDATA[Just migrated a multi-agent threat intel workflow from AutoGen to OpenClaw, and the biggest win wasn&#039;t the features—it was the clear architectural map. OpenClaw&#039;s docs explicitly define the ...]]></description>
                        <content:encoded><![CDATA[Just migrated a multi-agent threat intel workflow from AutoGen to OpenClaw, and the biggest win wasn't the features—it was the clear architectural map. OpenClaw's docs explicitly define the trust boundaries between the orchestrator, tool executor, and the LLM backend. That's gold for appsec.

When I was auditing the AutoGen setup, answering "what happens if the model goes rogue and tries to `rm -rf`?" was guesswork. With OpenClaw, the separation is built and documented. My tool executor runs in a restricted container, and the orchestrator only passes parsed, validated actions. Broke it on purpose to test:

```python
# Simulated malicious model output trying to force a shell
bad_action = {
    "tool": "shell_exec",
    "args": {"command": "cat /etc/passwd"}
}
# OpenClaw's tool registry &amp; validation blocked it—'shell_exec' not in allowed_tools.
```

Questions for the room:
* How are you mapping lateral movement risk in your agent stacks?
* Any clever ways you're hardening the tool executor boundary further? (e.g., seccomp profiles, network namespaces)
* Found other OSS frameworks with this level of explicit isolation?

—maya]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>maya_automates</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/switched-from-autogen-to-openclaw-because-of-the-explicit-trust-boundary-documentation/</guid>
                    </item>
				                    <item>
                        <title>Breaking: OpenClaw team publishes a threat model — finally!</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/breaking-openclaw-team-publishes-a-threat-model-finally/</link>
                        <pubDate>Mon, 13 Jul 2026 06:01:14 +0000</pubDate>
                        <description><![CDATA[So the team finally dropped their official threat model. Took them long enough. I&#039;ve been poking at their component isolation for weeks—especially the &quot;secure&quot; sandbox for untrusted tools. L...]]></description>
                        <content:encoded><![CDATA[So the team finally dropped their official threat model. Took them long enough. I've been poking at their component isolation for weeks—especially the "secure" sandbox for untrusted tools. Let's just say the boundaries are... porous.

The model itself is decent on paper: orchestrator (trusted), tool executor (untrusted), model backend (trusted). Separate network stacks, separate user namespaces, the usual. But the devil's in the runtime config. Their default `docker run` for the tool executor looks like this:

```json
{
  "HostConfig": {
    "Privileged": false,
    "UsernsMode": "host",
    "SecurityOpt": ,
    "CgroupnsMode": "host"
  }
}
```

Spot the issues? `UsernsMode: host` and `CgroupnsMode: host` mean a breakout from the container gives you the same namespace as the orchestrator. The seccomp profile is custom, but I found three missing syscalls that allow a `mount` primitive to be constructed. If you combine that with a cgroup v1 device controller misconfiguration (present in their demo deployment), you've got a clear path to the host.

*   The orchestrator's socket is mounted into the tool container for control. Compromise the tool, you can talk to it directly.
*   The model backend API expects a token from the orchestrator. But if you're already in the orchestrator's network namespace, you can just sniff it.
*   All this assumes no kernel exploits. Throw in a dirty pipe or a cgroup release_agent write, and the whole isolation story collapses.

The takeaway? Their boundaries are logical, not physical. If the tool container is the "untrusted" component, why does it share critical namespaces with the trusted ones? This is Container Security 101. I've seen tighter isolation in a college Docker tutorial.

tina]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Tina L.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/breaking-openclaw-team-publishes-a-threat-model-finally/</guid>
                    </item>
				                    <item>
                        <title>Has anyone tried wrapping the model backend in a microVM?</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/has-anyone-tried-wrapping-the-model-backend-in-a-microvm/</link>
                        <pubDate>Sun, 12 Jul 2026 20:00:06 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s rightly focused on the orchestrator-to-tool-executor boundary. The model backend gets a pass because &quot;it&#039;s just an API call.&quot; But that call is a full-blown, unsanitized, high-entr...]]></description>
                        <content:encoded><![CDATA[Everyone's rightly focused on the orchestrator-to-tool-executor boundary. The model backend gets a pass because "it's just an API call." But that call is a full-blown, unsanitized, high-entropy data channel straight into the heart of your logic. The model is a parser for a weird, stochastic language. We're feeding it untrusted tool outputs and hoping its *instructions* don't become *exploits*.

So, the classic move is to containerize it. Fine. But containers share a kernel. A crafted payload that causes a memory corruption in the model's inference library could be a one-way ticket to host town. We've seen it in other contexts.

Has anyone actually tried wrapping the model backend (think Ollama, vLLM, even OpenAI-proxy) in a microVM like Firecracker or gVisor? Not for scalability, but for actual isolation. The threat model is the model itself, or its dependencies, becoming the initial access vector.

*   What's the cold-start latency hit for a lightweight microVM on a tool call? Is it viable for a security-critical but low-RPS internal workflow?
*   Does the serialization overhead (gRPC, REST) across the VM boundary negate any practical benefit?
*   Are we just moving the problem? Now the orchestrator has to manage microVM lifecycles, which is a new, potentially messier trust boundary.

I'm less interested in theoretical "it should work" and more in someone who's actually measured the performance penalty and can describe the new failure modes. Because the old failure mode is "we own your cluster."

- O]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Omar H.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/has-anyone-tried-wrapping-the-model-backend-in-a-microvm/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who finds the default OpenClaw config too permissive?</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/am-i-the-only-one-who-finds-the-default-openclaw-config-too-permissive/</link>
                        <pubDate>Sun, 12 Jul 2026 07:59:58 +0000</pubDate>
                        <description><![CDATA[Just read the default deployment guide. The orchestrator runs with full system access, the tool executor&#039;s sandbox is a joke (hello, `--allow-all` flags), and the model backend can call back...]]></description>
                        <content:encoded><![CDATA[Just read the default deployment guide. The orchestrator runs with full system access, the tool executor's sandbox is a joke (hello, `--allow-all` flags), and the model backend can call back to the orchestrator's admin API with just a default token. It's a happy little privilege chain.

We're talking about "Trust Boundaries" but the defaults paint a single, flat trust domain. Where are the mandatory audit logs for cross-component calls? Why is the service mesh config optional? Feels like we're being sold a security platform that's one misconfigured tool away from handing over the keys. Show me the benchmarks where this default setup stops a determined prompt injection from pivoting.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Omar NoHype</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/am-i-the-only-one-who-finds-the-default-openclaw-config-too-permissive/</guid>
                    </item>
				                    <item>
                        <title>Guide: Using AppArmor to lock down the tool executor’s system calls</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/guide-using-apparmor-to-lock-down-the-tool-executors-system-calls/</link>
                        <pubDate>Sun, 12 Jul 2026 03:01:05 +0000</pubDate>
                        <description><![CDATA[A common architectural flaw in agent-based security tooling is excessive trust in the tool executor. In OpenClaw&#039;s paradigm, the executor—the component that runs Clair, Trivy, or Grype—has n...]]></description>
                        <content:encoded><![CDATA[A common architectural flaw in agent-based security tooling is excessive trust in the tool executor. In OpenClaw's paradigm, the executor—the component that runs Clair, Trivy, or Grype—has network access and filesystem permissions to fetch dependencies and generate SBOMs. If compromised, it becomes a pivot point.

While we isolate this component in its own container, the default Docker or Kubernetes security profile is insufficient. It permits a wide range of syscalls. The goal is to move from a discretionary model to a mandatory one, allowing *only* the syscalls required for the executor's precise duties. AppArmor is effective for this.

We start by generating a base profile from a typical scan run. This is a learning-mode trace.

```bash
sudo aa-genprof /path/to/tool-executor
# Then, within the container, execute a full scan cycle:
# grype scan image:debian:latest -o json
# trivy image --format cyclonedx debian:latest
```

The resulting profile in `/etc/apparmor.d/` will be permissive. We must then harden it. Critical rules for a read-only, network-capable executor include:

- Deny write access to most of the filesystem, with explicit read-only allowances for `/usr/lib`, `/proc/`, and temporary directories.
- Allow necessary network families (like `inet` for HTTP/HTTPS to registry APIs).
- Explicitly deny `mount`, `umount`, `ptrace`, and `sys_module` capabilities.

A fragment for a Grype executor might look like:

```
abi ,
include 

profile tool-executor /usr/bin/grype flags=(complain) {
  include 
  include 
  include 

  # Read-only for libraries and binaries
  /usr/lib/** r,
  /usr/bin/grype mr,

  # Allow read for vulnerability DB
  /tmp/grype-* r,
  /cache/** r,

  # Network
  network inet tcp,
  network inet udp,

  # Deny
  deny @{PROC}/bus/** rwklx,
  deny mount,
  deny umount,
}
```

Apply with `sudo apparmor_parser -r /etc/apparmor.d/tool-executor`. Then, enforce it via your container runtime (e.g., `docker run --security-opt "apparmor=tool-executor"`).

When these boundaries break—often due to an over-permissive profile allowing `exec` or `write` to unexpected locations—the executor can be used to deploy payloads or exfiltrate host data. Regular review of the profile against the tool's actual behavior, especially after updates, is non-negotiable. Consider integrating this profile generation and validation into your CI/CD pipeline that builds the executor image.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Grace W.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/guide-using-apparmor-to-lock-down-the-tool-executors-system-calls/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here — what tools do I need to start securing my OpenClaw install?</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/complete-newbie-here-what-tools-do-i-need-to-start-securing-my-openclaw-install/</link>
                        <pubDate>Fri, 10 Jul 2026 12:01:30 +0000</pubDate>
                        <description><![CDATA[Welcome to the party. You&#039;re asking the right first question, because most folks jump straight into prompts and ignore the scaffolding that holds their data, wallet, and credentials.

Securi...]]></description>
                        <content:encoded><![CDATA[Welcome to the party. You're asking the right first question, because most folks jump straight into prompts and ignore the scaffolding that holds their data, wallet, and credentials.

Securing an OpenClaw install isn't about a magic "security tool." It's about understanding and locking down the three core components: the Orchestrator (the brain), the Tool Executor (the hands), and the Model Backend (the, well, model). When these trust boundaries fail, your API keys start taking vacations without you.

Start with these essentials:

**1. Observability &amp; Logging**
You can't secure what you can't see. Before you do anything else, make sure every component logs to a central, immutable location *you* control. Not just stdout.
```yaml
# Example orchestrator logging config snippet
logging:
  level: INFO
  outputs:
    - type: "file"
      path: "/var/log/openclaw/orchestrator.json"
      format: "json"
    - type: "loki" # Or your preferred aggregator
      url: "http://internal-loki:3100"
```

**2. Network Segmentation**
This is where most DIY deployments faceplant. These components should NOT talk freely.
*   The Orchestrator should only have *outbound* access to the Model Backend and the specific APIs your tools need.
*   The Tool Executor should be in an isolated network segment, with egress tightly controlled. It should only accept connections from the Orchestrator.
*   The Model Backend (if self-hosted) should be in its own segment, accepting connections *only* from the Orchestrator. No internet egress.

Use a proper VPC/VNet with security groups/NSGs. A single misconfigured `0.0.0.0/0` rule here is your first credential leak.

**3. IAM &amp; Credential Management**
The Orchestrator needs permissions to spin up Tool Executors. The Tool Executors need credentials to do their jobs (AWS keys, GitHub tokens, etc.).
*   **Never** bake long-lived credentials into container images or config files.
*   Use a secrets manager (Vault, AWS Secrets Manager, Azure Key Vault) and dynamic, short-lived credentials wherever possible.
*   The Orchestrator's IAM role should be the *only* thing with broad provisioning power. Tool Executors should have roles scoped to the absolute minimum required for their specific task. Principle of least privilege isn't a suggestion.

**The Tool You Actually Need:** A diagram. Draw your planned deployment. Label every network flow, every IAM role, and every secret. You'll spot the problems before they spot you.

The hidden cost isn't the compute; it's the cleanup after a boundary breaks because you let the Tool Executor talk to your cloud metadata service. &#x1f62c;

- ken]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Ken Cloud</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/complete-newbie-here-what-tools-do-i-need-to-start-securing-my-openclaw-install/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with the orchestrator not respecting network egress rules?</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/anyone-else-having-issues-with-the-orchestrator-not-respecting-network-egress-rules/</link>
                        <pubDate>Fri, 10 Jul 2026 02:00:12 +0000</pubDate>
                        <description><![CDATA[Alright, I&#039;ll bite. Been implementing OpenClaw for a few months now, and I keep hitting the same wall: the orchestrator pod is ignoring the `NetworkPolicy` we have in place to block egress t...]]></description>
                        <content:encoded><![CDATA[Alright, I'll bite. Been implementing OpenClaw for a few months now, and I keep hitting the same wall: the orchestrator pod is ignoring the `NetworkPolicy` we have in place to block egress to the internet. It's supposed to only talk to the tool executor pods and our internal HashiCorp Vault cluster.

The policy is straightforward. We're using a deny-all-egress default, then whitelisting specific CIDRs and pod selectors.

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orchestrator-allow-specific
spec:
  podSelector:
    matchLabels:
      app: openclaw-orchestrator
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          component: tool-executor
  - to:
    - ipBlock:
        cidr: 10.42.0.0/24 # Our Vault CIDR
    ports:
    - protocol: TCP
      port: 8200
```

Yet, when I tail the orchestrator logs, I see it making successful HTTP calls to external APIs for things like geolocation lookups and vulnerability DB pulls—calls that should be gated *through* a tool executor, not initiated directly. The network policy should be dropping these packets, but they're going through.

What I'm seeing:
* Direct egress to `api.ipgeolocation.io` (and others) from the orchestrator pod.
* No corresponding logs in the designated "web-request" tool executor pods.
* `kubectl describe networkpolicy` confirms the policies are applied to the namespace.

This breaks the whole trust boundary model. The orchestrator shouldn't have a direct internet pipe. If it's bypassing the tool executor, then all the input sanitization and output filtering we built into the executors is useless. It also means our egress audit trail is incomplete.

Is this a known bug in the current release, or have I misconfigured something fundamental? I've verified Calico is running and the policies are non-zero. Anyone else seeing this, or am I the lucky one?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Kai Tanaka</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/anyone-else-having-issues-with-the-orchestrator-not-respecting-network-egress-rules/</guid>
                    </item>
				                    <item>
                        <title>Did you see the talk about lateral movement risks in agent runtimes?</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/did-you-see-the-talk-about-lateral-movement-risks-in-agent-runtimes/</link>
                        <pubDate>Thu, 09 Jul 2026 12:01:09 +0000</pubDate>
                        <description><![CDATA[The recent conference presentation on lateral movement in AI agent runtimes was, predictably, insufficiently rigorous. While it correctly identified the threat model—compromise of one compon...]]></description>
                        <content:encoded><![CDATA[The recent conference presentation on lateral movement in AI agent runtimes was, predictably, insufficiently rigorous. While it correctly identified the threat model—compromise of one component leading to compromise of others—it failed to analyze the specific cryptographic guarantees (or lack thereof) that define the trust boundaries in a system like OpenClaw. Allow me to provide a more formal decomposition.

OpenClaw's architecture is predicated on three distinct, isolated components:
*   **Orchestrator:** The reasoning engine. High-value target, holds the session context and decides which tools to call.
*   **Tool Executor:** The untrusted environment where third-party tool code runs. Assumed to be potentially malicious or buggy.
*   **Model Backend:** The LLM inference endpoint. Often a black-box API or a separate service with significant compute resources.

The intended isolation is enforced via process boundaries, network ACLs, and, crucially, authentication. The failure state occurs when these boundaries are incorrectly assumed or improperly implemented. Let's examine a concrete failure scenario.

Consider the Tool Executor. It receives serialized requests from the Orchestrator. If the authentication between these components is merely a static API key passed in an `Authorization` header, a compromised Tool Executor can now impersonate the Orchestrator to the Model Backend, provided the Backend accepts the same credential. This is a classic lateral movement pivot.

The correct mitigation is distinct, scoped credentials and strict mTLS with certificate-based authentication, ensuring each component can only communicate with its designated peers. The OpenClaw reference implementation *suggests* this, but the devil is in the configuration.

```yaml
# Problematic: Shared secret
tool_executor:
  auth:
    model_backend_api_key: "sk_live_abc123" # Same key used by orchestrator

# Correct: Component-specific identity
tool_executor:
  auth:
    model_backend_mtls:
      cert: /secrets/tool-executor.pem
      key: /secrets/tool-executor-key.pem
      ca: /openclaw-ca.pem
    # The model backend policy must authorize ONLY the orchestrator's identity for its management API,
    # and a different identity (this one) for the tool-executor's inference API.
```

The more subtle risk is attestation, or the lack thereof. In a high-assurance deployment, the Orchestrator should not merely authenticate the Tool Executor's *software* identity, but also verify its *runtime state*. Is it running in a known, hardened container image? Is it within a secure enclave (e.g., Intel SGX) with memory protections? Without remote attestation, a kernel-level exploit in the Tool Executor's host can bypass all application-layer authentication and exfiltrate the Orchestrator's credentials from memory.

The discussion often stops at "use TLS and secrets management," which is necessary but not sufficient. We must model the system as a graph where nodes are components and edges are authenticated channels with specific, least-privilege authorization policies. A boundary "breaks" when an edge is created where none should exist, or when the authentication on an existing edge is weak enough to allow spoofing.

I am interested in the community's experience implementing these patterns, particularly with enclaves for the Orchestrator. Have you successfully integrated a TPM-based attestation flow for the Tool Executor pools? What are the operational overheads?]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Ivan Sokolov</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/did-you-see-the-talk-about-lateral-movement-risks-in-agent-runtimes/</guid>
                    </item>
				                    <item>
                        <title>Did you see the vulnerability disclosure about orchestrator-to-executor RCE?</title>
                        <link>https://openclawsecurity.net/community/openclaw-trust-boundaries/did-you-see-the-vulnerability-disclosure-about-orchestrator-to-executor-rce/</link>
                        <pubDate>Thu, 09 Jul 2026 05:00:03 +0000</pubDate>
                        <description><![CDATA[Saw the disclosure. Not surprised. Another case of over-engineered complexity biting back.

They built a whole &quot;secure&quot; channel between orchestrator and tool executor. Yet a simple argument ...]]></description>
                        <content:encoded><![CDATA[Saw the disclosure. Not surprised. Another case of over-engineered complexity biting back.

They built a whole "secure" channel between orchestrator and tool executor. Yet a simple argument injection in the orchestrator's command builder lets you pop a shell on the executor box. All that isolation for nothing.

We used to solve this with separate users, strict sudoers files, and maybe a chroot. No "channels" needed. Just the OS. Works for decades. But now we need three microservices talking to each other. More code, more attack surface. Progress, I guess. &#x1f937;&#x200d;&#x2642;&#xfe0f;

Anyone mapping lateral movement here should just look at the old Unix permission model. It already drew the trust boundaries.]]></content:encoded>
						                            <category domain="https://openclawsecurity.net/community/openclaw-trust-boundaries/">Trust Boundaries and Component Isolation</category>                        <dc:creator>Ivan P.</dc:creator>
                        <guid isPermaLink="true">https://openclawsecurity.net/community/openclaw-trust-boundaries/did-you-see-the-vulnerability-disclosure-about-orchestrator-to-executor-rce/</guid>
                    </item>
							        </channel>
        </rss>
		