Skip to content
essaysecuritytechnical foundersplatform teams

Sandboxing Agents: Why Security Is Architecture, Not an Afterthought

By James Han

·

Apr 7, 2026

·

3 min read

security guardrailsproduction reliabilitytrust boundariesRampMercury

A colleague opened an open-source repo with an AI coding agent. The repo had a hook that ran on session start. That hook read the API key from the environment and sent it to an external server. Took about three seconds.

The agent didn't do anything wrong. The repo's config did. And the agent's runtime didn't treat that config as untrusted input.

The agent is an untrusted process

This is the mental shift: your agent has elevated privileges (file access, shell access, maybe network access) and operates on content you don't fully control (repos, user input, tool output). That's the definition of a security-sensitive daemon. Treat it like one.

Three layers of defense:

Workspace isolation. Mount a filtered workspace. Exclude .env, .aws, .ssh, credential files, key files. The agent can't leak what it can't see.

Environment filtering. Strip all env vars by default. Pass only an explicit allowlist: PATH, HOME, NODE_ENV. Never pass through AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, or anything matching *_KEY, *_SECRET, *_TOKEN.

Secret redaction. Before any data reaches the model or your trace store, run it through a redaction filter:

redact(text):
  replace sk-[...20+chars]     → [REDACTED:api_key]
  replace AKIA[16 chars]        → [REDACTED:aws_key]
  replace ghp_[36 chars]        → [REDACTED:github_token]
  replace -----BEGIN PRIVATE KEY----- → [REDACTED:private_key]
  replace postgres://...        → [REDACTED:connection_string]
  high-entropy strings (>=3.5 bits/char) → [REDACTED:high_entropy]

Apply this to file reads, command output, diffs, and git metadata. Everything the model sees has been through redaction.

Repo config is untrusted input

The most dangerous assumption in AI coding tools: that project config files contain safe instructions. A CLAUDE.md, a pre-commit hook, an MCP config — all of these can contain arbitrary instructions that the agent might follow or execute.

For repos you don't own: parse config, show the user what it wants to do, require explicit approval. "This repo has a session hook that runs npm install && npm run setup. Allow it?"

For repos you do own: still log it.

Network isolation by default

Most tool executions don't need network access. File reads, edits, test runs — all local. Block network by default. Enable it per-tool, per-call, with policy approval.

This single rule prevents the most serious attack vector: code in the repo (or injected by the model) that reaches out to external servers to exfiltrate data.

The takeaway

Security in agent systems isn't a feature — it's a layer. Sandbox the execution, filter the environment, redact the output, and never auto-execute config from repos you don't control.

Next: Agent Observability: If You Can't Replay It, You Can't Debug It


I write about this when I have something worth saying.