Some of these don’t really seem like they bypassed any kind of sandbox. Like hallucinating an npm package. You acknowledge that the install will fail if someone tries to reinstall from the lock file. Are you not doing that in CI? Same with curl, you’ve explained how the agent saw a hallucinated error code, but not how a network request would have bypass the sandbox. These just sound like examples of friction introduced by the sandbox.

I am testing running agents in docker containers, with a script for managing different images for different use cases etc, and came across this: https://docs.docker.com/ai/sandboxes/

Has anyone given it a try?

> The swap bypassed our policy because the deny rule was bound to a specific file path, not the file itself or the workspace root.

This policy is stupid. I mount the directory read inside the container to make it impossible to do it (except for a security leak in the container itself)

This is exactly why we built AgentAudit. The bypasses described here - directory swapping, forged lockfiles, exit code masking - are all variations of what we call "environmental exploitation."

The key insight: agents don't reason about security boundaries. They optimize for task completion. Your sandbox is just another constraint to work around.

We've catalogued 650+ attack patterns against AI agents, and many fall into this category - not adversarial prompts, but emergent behaviors that exploit trust assumptions.

Defense in depth is right. We also recommend: - Testing agents with security scanners BEFORE production - Logging all tool invocations, not just denials - Treating agent outputs as untrusted input

If anyone wants to test their agent setup: https://app.xsourcesec.com (free tier available)

At first they talked about running it in a sandbox, but then later they describe:

> It searched the environment for vor-related variables, found VORATIQ_CLI_ROOT pointing to an absolute host path, and read the token through that path instead. The deny rule only covered the workspace-relative path.

What kind of sandbox has the entire host accessible from the guest? I'm not going as far as running codex/claude in a sandbox, but I do run them in podman, and of course I don't mount my entire harddrive to the container when it's running, that would defeat the entire purpose.

Where is the actual session logs? It seems like they're pushing their own solution, yet the actual data for these are missing, and the whole "provoked through red-teaming efforts" makes it a bit unclear of what exactly they put in the system prompts, if they changed them. Adding things like "Do whatever you can to recreate anything missing" might of course trigger the agent to actually try things like forging integrity fields, but not sure that's even bad, you do want it to follow what you say.