Blast Radius: Sandboxing and Permissions for AI Agents

Give an AI agent a Slack token, a database credential, and a tool that can run Python, and you have handed it 3 different ways to cause damage at 3 different scales. Most teams write a system prompt that says "be careful with production data" and call the job done. AI agent security sandboxing and permissions means capping what an agent can physically reach: a scoped credential for every tool it calls, and an isolated runtime for anything that executes code, so a wrong action stays small no matter why it happened.

Why is this different from stopping prompt injection?#

Prompt injection defense stops bad instructions before the model ever sees them. Containment assumes that defense will sometimes fail anyway, and asks a different question: once an agent decides to call a tool or run code, correctly instructed or fooled, how much can it actually reach? Scoped permissions and sandboxing answer that question.

This post stays on the containment side of that line. For the defense against an agent being tricked into acting at all, prompt injection defense in n8n covers fencing untrusted text, validating structured output, and treating retrieved content as data instead of instructions, a different and well-documented fight. Here, the question is narrower: given that an agent will sometimes act on a bad decision anyway, what keeps that action from reaching everything you own?

OWASP's Top 10 for Agentic Applications, published in December 2025, keeps these problems in separate categories too. Goal hijacking and prompt injection get their own slots; the ground this post covers falls mostly under ASI03, Identity and Privilege Abuse, and ASI05, Unexpected Code Execution. Both describe the same shape of failure: an agent holding more reach than the task in front of it actually needs.

Every number here is sourced to a named, dated source, not a house estimate.

Why does a shared credential turn a small mistake into a disaster?#

A single API key or OAuth token covering every tool an agent might call means every mistake inherits that credential's full reach. Scope each tool its own narrow grant instead, so a wrong call or a hijacked session touches only the system it was actually authorized for.

MCP's own OAuth layer illustrates the gap. The 2025 spec update added audience-bound tokens, so a server can reject a token minted for somewhere else, a real improvement. But most production MCP deployments still hand out 1 bearer token that grants everything on that server, because the spec has no standard capability token scoped to a single tool call. Every tool the agent calls runs on the same broad authority as every other tool, whether it needed it or not. A capability token scoped to a single calendar-read call cannot also delete a repository on the same MCP server, even though a shared bearer token covering the whole server could.

The cost of that gap is not hypothetical. In July 2025, an AI coding agent deleted a live production database mid-way through a 12-day test, during an active code freeze it had been explicitly told to respect, a documented incident that is now a standard cautionary case. The team's own retrospective was blunt: the freeze lived only in the instructions, and nothing in the execution path enforced it, so the agent could agree with the rule and break it in the same session. The fix that followed was not a better prompt. It was splitting development and production into separate credentials the agent could not cross on its own.

Least privilege means one narrow credential per tool, never a shared master key.

What does least-privilege permissioning actually look like in practice?#

Least privilege means giving each tool the agent calls its own credential, scoped to only the action that tool performs, never a shared master key with broader reach. A read-only database user instead of the app's owner role. A post-only Slack token instead of a workspace admin key.

n8n builders already have a node-level version of this discipline: connect only the tools the task needs, give each credential the narrowest scope that still works, and use a sandbox or test account before go-live. n8n's guardrail nodes implement this same idea as iteration caps and per-credential scoping, so if you are already building in n8n, that is the concrete node-by-node version of the principle here.

The practical test is simple: if this exact credential leaked today, what could someone reach with it? If the honest answer is more than the single call it exists for, the scope is too wide. Rotate long-lived static keys into short-lived tokens wherever the provider supports it, and treat a broad, rarely-used permission as a liability sitting idle, not a convenience you might need later.

Each step narrows what a leaked credential could actually reach.

Why does an agent that runs code need more than a scoped API key?#

A scoped credential caps which named tools an agent can call, but code execution is not a named tool. It is an open door: whatever a generated script contains, the process running it can attempt. Permission scoping stops there, so a code-running agent needs a runtime boundary instead, something that contains the process itself.

This is exactly the ASI05 category from OWASP's list: natural-language input reaching a subprocess call or an interpreter, with remote code execution as the result. A computer-use agent makes the stakes concrete: once an agent can click, type, and run commands on a real desktop, "which tools does it have" stops being the right question, because the desktop itself is the tool.

Anthropic's own Claude Code is a useful worked example, because the fix shipped as an actual product change, not just advice. Claude Code's sandboxed Bash tool now enforces filesystem and network isolation at the OS level, using Seatbelt on macOS and bubblewrap on Linux, so a compromised or mistaken command cannot reach files or domains outside an approved boundary regardless of what the model decided to do. Anthropic reports that this cut permission prompts by 84%, evidence that a boundary enforced by the operating system needs fewer interruptions than a boundary enforced by asking a person to approve every step. Vercel formalized a version of this same pairing in 2026, running Claude's own Agent SDK inside Vercel Sandbox's microVMs directly, so a solo builder already on that stack does not have to wire the sandbox and the agent runtime together by hand.

The gap between these 2 rows is the entire argument for sandboxing code execution.

Containers, microVMs, or a hosted sandbox: which fits your stack?#

3 isolation tiers cover most cases. OS-level controls (seccomp, namespaces, or Claude Code's own Seatbelt and bubblewrap setup) restrict a process on the same machine. Containers add a lighter filesystem and process boundary that still shares the host kernel. MicroVMs and hosted sandbox platforms give each run its own kernel at the cost of a small startup delay.

For a solo builder, the honest default is a hosted sandbox rather than rolling your own container policy, because the vendor's whole job is keeping that boundary correct. The table below compares 3 that are current as of mid-2026.

Pricing across all 3 runs per-second rather than per-hour, with E2B's smallest tier starting around $0.05 an hour of active compute. The Daytona row is worth reading carefully: its default is a Docker container, which is fast but shares your host's kernel, and the microVM-grade isolation is an opt-in, not the default. Check which tier you are actually running before you assume a hosted sandbox means full kernel isolation. None of this means Docker containers are unsafe by default, only that "sandboxed" is not a single fixed guarantee across providers, so the same due diligence you would apply to a cloud IAM policy belongs here too.

How do permission scoping and sandboxing work together?#

The 2 controls are not interchangeable. A sandbox without scoped credentials is a locked room holding a live master key: the code cannot escape the box, but it can still use whatever broad access lives inside it. Decide both together for every new tool, not as alternatives to pick between.

Walk through it for any new tool or credential you are about to grant. Does the tool execute arbitrary code at all? If so, that code runs in an isolated sandbox first, before it gets a credential to anything else. Does the call write or delete data? If so, that credential is scoped to just that action, nothing broader. Is the resulting action easy to undo? If not, it waits for a person to approve it, the same gate an n8n Human Review node enforces on irreversible tool calls. Everything else gets the narrowest read-only grant and ships. That ordering is deliberate: sandbox first because it bounds the code itself, scope the credential second because it bounds what the code can reach even inside the box, and the human gate last because it is the most expensive check to run on every call.

Three questions decide how much containment a new tool or credential actually needs.

What should you check before you grant an agent a new tool?#

Before a new tool or sandbox goes live, confirm 3 things: the credential behind it is scoped to a single action, anything running generated code sits inside an isolated runtime rather than the host machine, and irreversible actions still route through a person. Skipping this quietly regrows a god-credential.

Once you have scoped what a tool can touch, a related question follows close behind: how does the system downstream know the agent calling it is the agent you actually authorized, and not a session that inherited its token by accident? Delegated identity for agents is the next layer once permission scoping is in place, proving who is acting, not just what they are allowed to do.

Before you trust a new grant in production, run it past a short list.

What should you set up this week?#

Pick the single credential in your stack with the broadest reach today, probably an API key shared across several tools, and split it into narrower grants this week. If any tool executes generated code on your host machine or a general VM, move that tool into a sandboxed runtime first.

Neither move requires new infrastructure. Scoping a credential is usually a settings change with the provider you already use; a hosted sandbox account (E2B, Daytona, and Vercel Sandbox all have free tiers) gets a code-execution tool off your machine in under an hour. Do both before you connect the next tool, not after.

The 2 controls in this post cap what an agent can do once it has already decided to act. Pair them with the defense that stops an agent from being tricked into that decision in the first place, and you have covered both halves of the same problem: what an agent is fooled into attempting, and what it can actually reach when it tries. Neither half is optional once an agent can touch a real system, and the cheaper fix today is almost always the credential, not the runtime.