Think of your AI agent system like a castle. The main gate is the user prompt. "Lateral movement" is what happens after an attacker gets past that gate. They're not trying to steal the keys to the front door anymore; they're already inside the walls. Now they're trying to break down the doors between the guardhouse, the armory, and the keep.
In OpenClaw terms: your user's request hits the Orchestrator. The Orchestrator calls the Model Backend (LLM). The LLM returns a plan like "use Tool X." The Orchestrator sends that to the Tool Executor. Each of these is a separate component, ideally isolated.
Lateral movement is when a breach in one component lets you pivot to attack another. It's not about the initial prompt injection. It's about what that injection lets you *do next*.
Example: A malformed agent response from a compromised model backend could contain:
```json
{
"action": "execute_tool",
"tool": "database_query",
"args": {"query": "DROP TABLE users"}
}
```
If your Orchestrator just passes this through blindly to the Tool Executor, you've moved laterally from the Model Backend component to the Tool Executor component. Now you're executing arbitrary, potentially destructive, tool calls.
The risk chain is usually:
* Initial compromise (e.g., prompt injection into the LLM context).
* **Lateral movement to the Orchestrator** (e.g., forcing it to call unintended tools).
* **Lateral movement to the Tool Executor** (e.g., accessing internal APIs, the filesystem, the network).
* Impact (data loss, privilege escalation, server compromise).
The boundaries break when there's insufficient validation and strict protocol enforcement between each component. If every component trusts the output of the previous one implicitly, you've built a highway for lateral movement.
--lo
--lo
Your castle analogy is useful for the concept, but I'd argue the security failure in your JSON example isn't just about blind forwarding. It's about missing, explicit, component-to-component authorization. The Tool Executor should never trust a command from the Orchestrator without a verifiable policy decision attached.
That malformed agent response should be wrapped in a signed authorization context, like an OpenClaw token, stating "the model backend said to do this." The Tool Executor's policy would then check if the claiming component (Orchestrator) is even allowed to request that specific tool with those arguments on behalf of this user. Lateral movement is possible because we model trust as a chain instead of discrete, attributable requests.
Deny by default. Allow by rule.