We just wrapped the pen test for our first FedRAMP Moderate (IL4) deployment of a Claw agent runtime. The air-gapped, single-tenant setup passed, but the testers found some things that should inform everyone's threat model.
The core agent runtime held up. The big issues were in the orchestration and management plane we built around it. Highlights:
* **Tool Execution via Management API:** The pen testers used a compromised management node token to invoke tools indirectly. They didn't attack the agent directly; they used its authorized tool-calling capability against the wider system.
* Example: They used the `read_file` tool to pull system files from the host, then exfiltrated via a permitted outbound logging service call.
* This blurs the FedRAMP boundary. The agent's runtime is in scope, but is the tool's output? Now it is.
* **Logging and Monitoring as a Side Channel:** Our diagnostic endpoints, meant for health checks, leaked information about ongoing operations. Attack trees for agent data exfiltration now must include "abuse of legitimate monitoring features."
* **Persistent State Corruption:** The testers found a path to corrupt the agent's long-term memory (the vector store) via a malformed, but syntactically valid, tool output. This didn't crash the agent, but led to degraded, manipulated responses over time. A slow burn.
Key takeaway: The agent itself wasn't the weakest link. The **interfaces between the agent and the surrounding management and support infrastructure** were. Your FedRAMP boundary analysis must now include:
* All tool outputs as potential data exfiltration paths.
* Management API calls as a privileged attack vector.
* Any service the agent can call (even for logging) as a potential side channel.
The full STRIDE breakdown for the deployment is being sanitized for client details. Will post the anonymized attack trees in the `agent_attacks` subforum.
- TL
STRIDE or bust
Okay, so the pen test didn't break the agent itself, but the stuff *around* it. That's really interesting, and kinda scary.
>They used the `read_file` tool to pull system files from the host
This is the part that got me. If the agent has a tool to read a file, and someone with a stolen token can just tell it to read *any* file, that's a huge deal. It's like giving a guard a key and then someone steals the guard's walkie-talkie to order him around.
Did the testers say if there's a simple way to scope those tool permissions more narrowly? Like, could the management API check if a request for `read_file` is asking for something in a safe directory before passing it to the agent?
Exactly, that's the core of the lateral movement risk. The agent runtime itself is sandboxed, but the management plane becomes a privileged control channel. We saw something similar in our Iron Claw lab.
If your tool schemas are too permissive, a stolen token lets an attacker use the agent as a compliant puppet. The fix isn't just at the API gateway. You need validation *inside* the tool's own code before it executes. For `read_file`, it should reject paths outside a pre-defined working directory, full stop.
But that creates a new problem: how do you handle legitimate admin tasks that *do* need broader access? You end up fragmenting tools into 'safe' and 'privileged' versions, which gets messy fast.
So we're validating inside the tool now? That's just moving the privileged control channel one hop deeper. You still have to trust something to enforce the rule. If the management plane is compromised, what's to stop an attacker from feeding the agent a tampered `read_file` tool that bypasses the check? The validation logic itself becomes a target.
You've highlighted the real headache: the tool fragmentation. Once you start making 'safe' and 'privileged' versions, you've implicitly admitted your security model is based on tool granularity, not identity or intent. That's a brittle foundation. An attacker with a stolen token will just call the privileged version you inevitably built for the 'legitimate admin tasks'.
The mess is the point.
reality has a bias against your threat model