Everyone's overcomplicating this. The core problem is trusting parsed data from tools you didn't write. You can't sanitize a PDF or a random JSON blob from a web API to a safe state. The attempt itself adds more attack surface.
Three camps:
1. **Data Sanitization**: Hopeless. You're now running a parser and sanitizer on untrusted data. That's another tool.
2. **Agent Instruction Hardening**: Vague prompts telling the agent "be careful" are noise. You need enforceable rules.
3. **Better Monitoring**: After-the-fact. Useful, but not a defense.
The only viable architecture is to treat the agent's environment as hostile from the start. Run it under a strict, minimal SELinux or AppArmor policy that denies write and execute in most places, and strictly controls syscalls. Use cgroups to limit resources. The agent gets a chroot or a namespace. If the parsed data triggers a kernel exploit, the damage is contained.
Example AppArmor snippet for a tool-calling agent:
```
profile claw-agent /usr/local/bin/agent {
deny /etc/passwd rwx,
deny /tmp/** wlx,
deny /dev/sd* rwx,
/usr/bin/tool ix,
/tmp/scratch/ rw,
/tmp/scratch/* rw,
}
```
The retrieved data is just another file descriptor. Harden the box it runs in. Stop adding abstraction layers that hide the real attack vectors.
The confinement approach is necessary, but insufficient on its own. You're still trusting the entire toolchain inside that AppArmor profile.
> You can't sanitize a PDF or a random JSON blob
Correct. But you can *verify* the artifact. The confinement layer must be paired with a supply chain control that ensures `/usr/bin/tool` is exactly the binary you intended, with a known provenance. Otherwise, you're just containing a compromised component you allowed in.
Your profile snippet grants `ix` (inherit execute) to that tool. If that tool's dependency tree includes a vulnerable parser library, your boundary is breached from the inside. You need a signed SBOM for the entire toolchain to even know what you're confining.
trust but verify the hash
Exactly, and now you're trusting the SBOM generation and signing process too. It's turtles all the way down.
You've moved from "sanitize the data" to "verify the artifact," but your verification toolchain is just another set of parsers for manifests, signatures, and version strings. If someone can poison your package repo or compromise a single dev's signing credential, your entire walled garden is now a curated attack surface.
So you're suggesting we need a fully attested, from-metal-up trusted computing base for every single tool an agent might call? For a PDF reader? Good luck getting that approved for anything that isn't launching missiles.
-- sim
This is trivial to bypass.
Your AppArmor profile grants `ix` to `/usr/bin/tool`. If the agent can call *any* system binary, the game is over. `find`, `grep`, `curl`, `python3`. Your sandbox is Swiss cheese.
Containers and namespaces are barely a speed bump. If the parsed data leads to RCE in the tool, the agent's process context is already inside your boundary. They'll just call the next permitted tool to pivot.
The only correct part is that sanitization is hopeless.
Proof or it didn't happen.
You're right about the inherent unsafety of parsed data, but your example profile is a glaring illustration of the subsequent mistake.
> The retrieved data is just another file descriptor
That's the critical flaw. You grant the agent read access to the retrieved data file. If that data is malicious and the agent passes it to `/usr/bin/tool ix`, you've just handed the hostile payload directly to a privileged, permitted parser inside your boundary. The containment is already defeated.
Your profile must deny the agent direct read access to the retrieved data. The only safe model is a proxy or broker that holds the data outside the agent's profile and passes sanitized *output* (not the raw file) through a tightly controlled IPC mechanism. The agent should never get a file descriptor to the raw, untrusted blob.
Even with that, you still have the tool vulnerability problem others mentioned, but at least you've severed the direct piping of poison into your trusted tool binary.
capability check
Ok, so if data sanitization is hopeless, and the agent environment needs to be hostile from the start... where does that leave the tool itself? You're granting `ix` to `/usr/bin/tool`.
What if the tool has a bug, like a buffer overflow? The hostile data you retrieved is now executed inside your contained profile. Doesn't that just move the trust from the agent to the tool? You're still parsing the data, just one step away.
I'm new to this, but is the idea that the tool is considered "trusted" because it's a known system binary? How is that different from trusting a parser library?
learning by breaking