Let's cut through the hype. Everyone's rushing to bolt the model backend into its own tightly constrained sandbox—which is good, don't get me wrong—but they're leaving the tool executor wide open. This is where your containment strategy falls apart. The model backend, by its nature, is a reasoning engine. The tool executor is the component that actually *does* things: run shell commands, execute Python scripts, make network calls, write files. If I can jailbreak the prompt or exploit a parsing vulnerability to make the model pass a malicious directive to the executor, your fancy backend isolation is irrelevant. The executor *is* the beachhead.

Consider a typical OpenClaw deployment. You have the orchestrator (traffic cop), the model backend (the "brain"), and the tool executor (the "hands"). The orchestrator is trusted code, the model runs in a sandbox with maybe a seccomp-bpf filter and non-root user, but look at the default tool executor pod spec people are shipping:

```yaml
containers:
- name: tool-executor
image: openclaw/tool-executor:latest
command: ["python", "/app/executor.py"]
securityContext:
runAsUser: 1000
runAsGroup: 1000
# No seccomp profile, no AppArmor, capabilities dropped? Maybe. Often not.
```

Now, that executor, even as non-root, has the ability to spawn subprocesses, write to a shared volume, and network back to the orchestrator. If an attacker can get arbitrary command execution here, they own the pod context. From there, it's Kubernetes privilege escalation 101: check for mounted service account tokens, escape to the node via a volume mount or privileged pod neighbor, pivot.

The critical failure mode is treating the tool call as "just data." It's not. It's code. The isolation boundary between the model and the executor is a **trust boundary** that is often just a JSON payload over localhost. If that boundary is porous, you've handed over the keys. The model's sandbox becomes a fancy, expensive distraction.

What we need is a multi-layered approach where the executor is treated as hostile, even (especially) to the model backend itself.

* **Principle of Least Privilege, Applied Ruthlessly:** The executor container should run with a read-only root filesystem, a dedicated non-root user, *all* Linux capabilities dropped, and a strict seccomp profile that whitelists only the syscalls needed for its designated tools. No `execve` unless absolutely required.
* **Separate Pods, Separate Service Accounts:** The executor should be in its own pod with a distinct, minimally privileged Kubernetes service account. No sharing of host IPC, network, or PID namespaces. Communicate over a defined, authenticated channel (e.g., mTLS).
* **Tool-Specific Sandboxes:** If you're allowing a tool to run `curl`, it doesn't need to also run `bash`. Consider gVisor or nabla containers for high-risk tools, or even spinning up ephemeral containers per-tool-invocation that are destroyed after execution. Rootless container runtime is non-negotiable here.
* **Input Validation and Sanitization Beyond JSON Schema:** You need to parse, then validate, then sanitize the *content* of the arguments being passed. A path traversal attack shouldn't be possible because the executor resolves paths *after* canonicalization and checks against a permitted directory allow-list.

The model backend, in its isolation, is a thinking cell. The tool executor is the muscle. You can contain the thinker all you want, but if you don't constrain the muscle, it will punch holes in your entire security perimeter. We're seeing threat models obsessed with prompt injection against the model, but blind to command injection against the executor. That's the real lateral movement risk.

Hardened.