Security boundaries in agentic architectures

Source: Vercel Blog

Overview

Most agents today run generated code with full access to your secrets.
As more agents adopt coding‑agent patterns—reading filesystems, running shell commands, and generating code—they become multi‑component systems that each need a different level of trust.

While many teams run all of these components in a single security context (because that’s how the default tooling works), we recommend thinking about security boundaries differently.

Below we walk through:

1. The rise of coding‑agent architecture
2. The core risk of prompt injection + code execution
3. Four distinct actors and their trust levels
4. Design principles
5. Common architectures (from least to most secure)

1. Coding‑Agent Architecture Is Becoming the Norm

• Agents read and write to a filesystem.
• They run Bash, Python, or similar programs to explore their environment.
• They generate code to solve particular problems.

Even agents that aren’t marketed as “coding agents” use code generation as their most flexible tool.

Example: a customer‑support agent that generates and runs SQL to look up account data is using the same pattern—just pointed at a database instead of a filesystem. An agent that can write and execute a script can solve a broader class of problems than one limited to a fixed set of tool calls.

2. Core Risk: Prompt Injection + Code Execution

Consider an agent debugging a production issue:

1. The agent reads a log file that contains a crafted prompt injection.
2. The injection tells the agent to write a script that sends the contents of ~/.ssh and ~/.aws/credentials to an external server.
3. The agent generates the script, executes it, and the credentials are exfiltrated.

Key point: Prompt injection gives attackers influence over the agent, and code execution turns that influence into arbitrary actions on your infrastructure.
The agent can be tricked into:

• Exfiltrating data from its own context
• Generating malicious software (which can steal credentials, delete data, or compromise any reachable service)

The attack works because the agent, the code it generates, and the underlying infrastructure all share the same level of access.

3. Four Distinct Actors & Their Trust Levels

These four actors exist in every agentic system. The central architectural question is whether you draw security boundaries between them or let them all run in the same trust domain.

4. Design Principles

1. Least‑Privilege Access – Give each actor only the permissions it truly needs.
2. Isolation of Generated Code – Run generated programs in a sandbox or separate execution environment.
3. Secret Management – Keep secrets out of the agent’s direct view; inject them only where required.
4. Boundary Enforcement – Explicitly define and enforce security boundaries between the four actors.

5. Architectures in Practice (Least → Most Secure)

5.1 No Boundaries (Baseline)

• Description: All four actors share a single security context.
• Implications:
  • On a developer’s laptop, the agent can read ~/.ssh files and SSH keys.
  • On a server, it can access environment variables, DB credentials, and API tokens.
  • Generated code can steal any of these, delete data, and reach any service the environment can reach.
• Mitigation: The harness may prompt the user for confirmation before certain actions, but there is no enforced boundary once a tool runs.

5.2 Secret‑Injection Proxy

[Agent] → [Proxy] → [External Service]

• How it works: A proxy sits outside the main security boundary and intercepts outbound network traffic, injecting credentials only as requests travel to their intended endpoint.
• Configuration: The harness configures the proxy with the credentials and domain‑allowlist rules; the generated code never sees raw secret values.
• Benefits:
  • Prevents exfiltration of secrets (they can’t be copied out of the execution context).
• Limitations:
  • Does not prevent misuse during active runtime; generated software can still make unexpected API calls using the injected credentials.
• Trade‑off: A backward‑compatible upgrade from a zero‑boundary architecture—no major restructuring, but the agent and generated code still share the same security context for everything except the secrets themselves.

5.3 Shared Sandbox

• Concept: Wrap both the agent harness and the generated code inside a shared VM or sandbox.
• Advantages:
  • Isolates both from the broader environment.
  • Generated programs cannot infiltrate the wider infrastructure.
• Considerations:
  • The agent and generated program still share the same sandboxed environment, so any compromise inside the sandbox can affect both.
  • Additional controls (e.g., network egress filtering, read‑only filesystem mounts) may be needed to tighten security further.

5.4 Fully Isolated Execution (Most Secure)

1. Agent Harness runs in a trusted, privileged environment.
2. Generated Code executes in a separate, highly restricted sandbox (e.g., container with limited capabilities, seccomp profile, read‑only filesystem).
3. Secret Injection occurs via a dedicated secret‑injection service that supplies short‑lived, scoped credentials only to the sandboxed process.
4. Network Egress is controlled by a zero‑trust proxy that enforces allow‑lists per request.

• Result: Even if prompt injection leads to malicious generated code, the code cannot:
  • Access raw secrets (they never leave the injection service).
  • Reach unauthorized services (proxy blocks unexpected outbound traffic).
  • Affect the host environment (sandbox prevents filesystem or process‑level attacks).

6. Takeaways

• Identify the four actors in your agentic system and assign appropriate trust levels.
• Introduce boundaries—starting with a secret‑injection proxy is a low‑friction improvement; moving to shared or fully isolated sandboxes provides stronger guarantees.
• Apply least‑privilege principles to both the agent and any generated code.
• Continuously monitor for prompt‑injection attempts and anomalous code execution patterns.

By re‑thinking where you place security boundaries, you can keep the flexibility of coding agents while dramatically reducing the risk of credential theft, data exfiltration, and broader infrastructure compromise.

Overview

Agents and the code they generate must run in separate security contexts.
If they share the same context, generated code can:

• Steal the harness’s credentials.
• Misuse credentials via a secret‑injection proxy.

The sandbox protects the environment from the agent, but it does not protect the agent from its own generated code.

The Missing Piece

Run the agent harness and the programs the agent generates on independent compute (separate VMs or sandboxes) with distinct security contexts:

Current Landscape

• Claude Code and Cursor already offer sandboxed execution modes, but desktop adoption is low because sandboxing can cause compatibility issues.
• In the cloud, separation is far more practical: you can give generated code a VM that matches the software it needs to run, often improving compatibility.

Why This Separation Is Straightforward

1. Tool‑invocation abstraction – Agents already call tools through an abstraction layer.
2. Routing – That abstraction makes it natural to route code execution to a separate environment without rewriting the agent.

Compute Profiles

The sandbox works both ways:

• It shields the agent’s secrets from generated code.
• It shields the broader environment from whatever the generated code does.

Strongest Architecture: Application Sandbox + Secret Injection

Recommendation for production agentic systems

1. Run the agent harness as trusted software on standard compute.
2. Run generated code in an isolated sandbox.
3. Inject secrets only at the network layer; never expose them to the sandboxed process.

This separation will become the standard architecture for agentic systems. Teams that adopt it now will gain a meaningful security advantage as agents handle more sensitive workloads.

Safe secret injection is now available on Vercel Sandbox.

Read more →

Actors in Agentic Systems & Desired Security Boundaries

Agent
│
├─ Agent secrets
│
└─ Generated‑code execution
    └─ Filesystem (isolated)

Key Principles

1. Never expose harness credentials directly to the agent.
2. Tool invocations must be scoped narrowly.
   • Example: An agent supporting a specific customer should receive a tool scoped to that customer’s data, not a generic tool that accepts a customer‑ID parameter (which is vulnerable to prompt injection).
3. Generated programs that need credentials are handled via secret‑injection proxies, not by giving the code direct access.

Desired Isolation

• Full isolation between the agent harness and generated programs – each runs in its own security context.
• No direct credential access for generated code; it can only use secrets through the injection proxy.
• Injected headers overwrite any headers the sandbox code sets with the same name, preventing credential‑substitution attacks.

What Goes Wrong Without Boundaries

Four Actors in an Agentic System

1. Agent – the LLM‑driven orchestrator.
2. Agent secrets – API keys, tokens, etc.
3. Generated code execution – the programs the agent creates.
4. Filesystem – storage used by both harness and generated code.

Zero Boundaries (Today’s Default)

• All actors share the same process and filesystem.
• Generated code can read or exfiltrate secrets.

Secret Injection Without Sandboxing

• Secrets are passed, but the code still runs in the same environment → still vulnerable to exfiltration or misuse.

Separating Agent Compute from Sandbox Compute

• Agent runs on trusted compute.
• Generated code runs in an isolated sandbox.

Application Sandbox with Secret Injection

• Combines the benefits of both approaches: isolation + controlled secret access.

Summary

• Separate compute for the agent harness and generated code.
• Use ephemeral sandboxes (e.g., Vercel Sandbox) for generated programs.
• Inject secrets at the network layer, never expose them directly.
• Scope tools narrowly to avoid prompt‑injection attacks.

Adopting this architecture now positions teams for secure, scalable, and cost‑effective agentic systems as the technology matures.