Security boundaries in agentic architectures
By Steven Van ·
Vercel outlines four trust levels in agentic systems and compares proxy-based secret injection against shared sandboxing.
Vercel published a guide on securing agentic systems, arguing that most agents today run generated code with the same access to secrets and infrastructure as everything else in the system. The post walks through an example: an agent debugging a production issue reads a log file containing a prompt injection instructing it to write a script that exfiltrates SSH keys and AWS credentials. Because the agent, its generated code, and the environment share one security context, the agent complies and the credentials are stolen.
The post identifies four actors in an agentic system, each needing a different trust level: the agent itself (subject to prompt injection), agent secrets (API tokens, database credentials, SSH keys), generated code execution (the least predictable actor, since it can do anything the language runtime allows), and the filesystem/environment. From this it draws a few design principles: the harness should never expose its own credentials directly to the agent, agents should get narrowly scoped tools rather than parameters like a customer ID that an injection could manipulate, and generated code that needs credentials should be treated as a separate concern.
It then compares architectures teams use today, in order of increasing security:
- Zero boundaries: the default for most setups, where the agent, its secrets, the filesystem, and generated code all share one security context. Coding agents like Claude Code and Cursor ship with sandboxes, but they're often off by default.
- Secret injection without sandboxing: a proxy sits outside the main security boundary and injects credentials into outbound requests, so generated code never sees raw secret values. This blocks exfiltration but not misuse of the credentials while a request is in flight, and it's a backward-compatible add-on to a zero-boundaries setup.
- Shared sandboxing: wrapping the harness and generated code together in one VM or sandbox keeps both isolated from the wider environment, but the post notes this still leaves the agent and generated code in the same security context as each other.
The full post continues toward an architecture that runs agent and generated code in separate contexts, for teams building agents on Vercel.
