AI Agent Sandboxing and Credential Scoping:The 2026 Guide to Blast-Radius Reduction

An AI agent with tool access is only as safe as the worst thing it can be tricked, coaxed, or hallucinated into doing — and that ceiling is set by exactly two things: where its tool calls actually execute, and what credential they execute with. Everything else in this guide is detail underneath those two questions.

Teams tend to treat "sandboxing" and "credential scoping" as separate line items — a DevOps concern and a security-team concern, handled by different people on different timelines. In practice they are the same control viewed from two angles. Sandboxing constrains where an agent's actions can physically reach: the filesystem, the network, the host kernel. Credential scoping constrains what an agent's actions are authorized to do once they reach a system: which records it can read, which it can write, which it can delete. An agent that is perfectly sandboxed but holds an unscoped admin credential can still do unlimited damage to every system that credential touches, network path or no. An agent that holds a perfectly scoped credential but runs unsandboxed can still be used to pivot against the host machine itself. Neither control substitutes for the other.

This is blast-radius engineering, a discipline borrowed directly from infrastructure security, applied to a new kind of actor: one that reads untrusted, attacker-influenceable content as part of its normal operation — an email, a support ticket, a scraped web page, a tool description written by someone you have never met — and decides what to do next based on it. We wrote this guide because most of what circulates about "secure AI agents" is either a framework's marketing page or a single-technique blog post (just sandbox it, just add OAuth), and neither answers the operator's actual question: what does a complete, current architecture look like, in what order do you build it, and what does the current threat and standards landscape actually say as of today.

If you are earlier in the decision — whether to build an agent at all, or which framework to build it on — our build-vs-buy guide for AI agents covers that decision separately. This guide assumes you have tool-calling agents in production or in active development and starts from there.

The confused deputy problem is not new — Norm Hardy described it in 1988, decades before language models existed — but AI agents reproduce the exact structural pattern at a new scale. A deputy is any program with more privilege than the party asking it to act. When that deputy performs an action on the requester's behalf, a downstream system sees the deputy's privilege, not the requester's. AI agents are built this way by default: an agent is authenticated once, typically by whoever configured it, and then invoked by many different users through a chat interface, a Slack integration, or an API. Every tool call the agent subsequently makes presents the agent's own credential, not the invoking user's — unless something specifically intervenes to fix that, which most agent deployments do not.

The practical consequence is that a low-privileged user can weaponize a higher-privileged agent to reach data or take actions they could never reach directly, and the downstream system — a database, an internal API, an email service — has no way to distinguish that from a legitimate request, because it only ever sees one identity: the deputy's.

It is worth being precise about what this incident does and does not demonstrate. It is not primarily evidence that a model "went rogue" in some abstract sense — instruction-following failures happen, and always will to some degree. It is evidence of an architecture with no hard technical backstop behind a soft, natural-language instruction: an agent with standing, unscoped write access to a live production database, running in an environment with a direct path from that agent to that database, where the only thing standing between a bad decision and an unrecoverable outcome was the model choosing correctly. Sandboxing and credential scoping are exactly the two controls that change this picture — an isolated working environment with no live path to production data, and a credential that is scoped to the current task and never includes the ability to drop tables, regardless of what the agent is told or decides to do.

The fix that actually addresses the confused-deputy shape of this failure, rather than just the specific database-deletion instance of it, is identity propagation: instead of an agent presenting its own static credential to every downstream system, it exchanges the invoking user's identity for a token scoped to the specific action, at every hop. We cover the mechanics of that — OAuth token exchange under RFC 8693 — later in this guide.

The OWASP Top 10 for LLM Applications gives this failure family a name — Excessive Agency, LLM06:2025 — and, in its 2025 revision, broke it into three distinct root causes worth treating as three separate checklist items rather than one vague concern.

• Excessive functionality: The agent can reach tools or capabilities beyond what its actual task requires. If a workflow never needs to fetch an arbitrary URL or execute an arbitrary shell command, that capability should not be offered to the agent at all — not gated, not warned-about, simply absent from its tool list.
• Excessive permissions: The tools the agent can reach operate with broader access than the task needs. A tool that only ever needs to read a customer's own order history should not be backed by a database credential that can read every customer's records or write to any table.
• Excessive autonomy: High-impact, hard-to-reverse actions proceed without a human checkpoint. OWASP's own mitigation guidance is specific here: human-in-the-loop belongs on high-impact operations specifically — deletes, payments, external sends — not sprinkled indiscriminately across every action, which trains users to click through it without reading.

It is also worth noting what dropped out of the framework: Insecure Plugin Design, a standalone category in OWASP's earlier v1.1 list, is no longer separate in the 2025 revision — its concerns were folded into Supply Chain and Excessive Agency. That consolidation reflects a real shift in how the security community now thinks about this problem: not as a plugin-implementation-quality issue, but as a permissions-and-autonomy issue that happens to be exercised through plugins, tools, and MCP servers.

OWASP's concrete mitigations translate directly into engineering decisions: prefer narrow, purpose-built tools over open-ended ones (a tool that looks up an order by ID, not a tool that runs arbitrary SQL); log and monitor every tool invocation, with rate limiting and alerting on abnormal patterns, so that even a successful excessive-agency exploit gets caught quickly rather than running unnoticed; and treat human-in-the-loop as a designed control on specific high-impact actions, not a generic disclaimer.

"Sandboxed" is not one thing, and the differences between the common isolation tiers are not cosmetic — they represent genuinely different threat models and genuinely different costs, and conflating them is how a team ends up with weaker isolation than they believe they have.

Firecracker specifically is worth understanding because it underpins most of the microVM-based sandbox vendors in the table below: originally built by AWS and used in production for Lambda and Fargate since 2018, it creates minimal-overhead virtual machines with a stripped-down device model, giving each sandboxed run its own real kernel rather than sharing the host's. The reason companies running large volumes of agent-generated code — Manus and Perplexity among the vendors' own cited customers — choose microVMs over containers for this specific workload comes down to threat model: agent-generated code is, definitionally, code nobody has reviewed before it runs, and a shared-kernel container is the wrong isolation boundary for code in that category.

A parallel, complementary approach worth naming separately is OS-level sandboxing for developer-facing coding agents, rather than full virtualization: Anthropic's own Claude Code ships a local Bash sandbox that uses Apple's Seatbelt framework on macOS and bubblewrap (an unprivileged Linux containerization tool) on Linux and WSL2, restricting filesystem writes to the current working directory and routing network access through a local proxy that enforces a domain allowlist. Anthropic has reported this cut permission prompts by roughly 84% in internal usage while keeping a prompt-injected agent inside boundaries the operating system itself enforces — a meaningfully different guarantee than a boundary the application layer merely intends to enforce. The runtime is published as an open-source package a team can adopt independently of Claude Code itself.

The Model Context Protocol has become the dominant way agents discover and call tools, and it introduced its own attack surface along with that convenience — one that sandboxing alone does not close, because the attack targets what the agent is instructed to do, not where the code runs.

Tool poisoning embeds adversarial instructions inside a tool's description, its parameter schema, or the content it returns — text the model reads as trusted operational context but that a human reviewing the tool list may never see, because tool descriptions are rarely surfaced in full in a typical chat UI. Security researcher Simon Willison documented this class of problem publicly in April 2025, and security firm Invariant Labs published a proof of concept the same month showing that an innocuous-looking "fact of the day" tool could be used to exfiltrate an entire chat history, purely through instructions hidden in the tool's own description field — no vulnerability in the model itself, just a description the model had no reason to distrust.

A rug pull is the same idea applied after the fact: a tool passes review and is approved once, and its definition later changes — silently, on the server side — to something malicious, exploiting the reality that many MCP clients historically did not require a fresh approval when a previously-approved tool's description changed underneath it.

Neither MCP's OAuth-based authorization model (covered next) nor a well-built sandbox directly prevents tool poisoning or a rug pull — both operate at the layer of what the agent is authenticated and isolated to do, not at the layer of what it is told to do. The defenses that actually address this attack class are different and complementary: hash-pinning a tool's definition so any change requires explicit re-approval, scanning tool descriptions for injected instructions before they are added to an agent's available tool set, and — this is where sandboxing and scoping earn their keep even against an attack they don't directly stop — making sure that even a successfully poisoned tool call executes inside an isolated environment with a narrowly scoped credential, so the damage a successful poisoning attack can do is bounded by the same architecture the rest of this guide describes.

Separate from the tool-poisoning problem above, MCP does specify a real authorization model, and it changed meaningfully in 2026 in ways worth understanding before you build against it.

The foundational model, formalized in MCP's authorization specification, is built on OAuth 2.1: an MCP server acts strictly as an OAuth 2.1 resource server, validating tokens issued by a separate, dedicated authorization server, and never itself acting as the identity provider. An MCP client, correspondingly, acts as an OAuth 2.1 client making protected resource requests on behalf of a resource owner — the human or system the request is ultimately for.

The specification published on July 28, 2026, described by its maintainers as the largest revision since the protocol's launch, hardened this model on several specific points that matter for anyone running MCP servers in production:

• RFC 9207 issuer validation: Authorization servers must now return an iss parameter, and clients must validate it before redeeming an authorization code — closing a mix-up hole where a malicious authorization server could impersonate a legitimate one during the auth flow.
• Client credentials bound to their issuing server: No reuse across authorization servers, closing off a class of credential-confusion attack between environments.
• Dynamic Client Registration formally deprecated: MCP is moving to Client ID Metadata Documents (CIMD) as the standard registration approach, with a minimum twelve-month deprecation window before the older DCR mechanism is removed.
• Stateless protocol core: The initialize/initialized handshake and session IDs are eliminated, letting requests land on any server instance behind a load balancer without shared session storage — an operational change more than a security one, but relevant to how you scale an MCP deployment safely.

None of this addresses tool poisoning or rug pulls, which live at the application layer — what a tool claims to do and whether that claim can change post-approval — rather than the authentication layer this spec update hardens. A team that reads "MCP uses OAuth 2.1" as a blanket security assurance is answering a different question than the one that actually determines their exposure.

The mechanical fix to the confused-deputy problem described earlier has a name and a standard: OAuth 2.0 Token Exchange, defined in RFC 8693. A client presents a subject_token — representing the party an action is being performed for — and optionally an actor_token — representing the party actually making the call — and receives back a new token scoped to a specific target audience and permission set. The standard supports two distinct semantics worth distinguishing: impersonation, where the new token fully assumes the subject's identity with no record of the acting party, and delegation, where the token retains the acting party's identity alongside the subject's.

Applied to an agent, this is the pattern known as on-behalf-of (OBO): instead of an agent presenting one static credential to every downstream system regardless of who invoked it, the agent exchanges the invoking user's identity token for a new token scoped narrowly to the specific downstream call, at every hop in the chain — a user's request, an orchestrating agent, a sub-agent, the tool call itself. Each actor in that chain receives only the token it needs for its next specific action, and a downstream system sees who the action is actually for, not merely which agent made the call. A related, simpler pattern for user-facing agents is per-user OAuth: rather than the agent holding one shared master credential for an entire third-party integration, each user individually grants the agent a scoped, revocable token tied to their own account — so revoking one user's access does not require rotating a credential shared across every other user.

Underneath token exchange sits a second, complementary shift: workload identity federation, which replaces the practice of generating a long-lived static credential — a service account key, an API key beginning with something like sk-... — and distributing it to a workload at deployment time. Workload identity federation instead lets the workload present a short-lived OIDC token it already has (issued by its own runtime: AWS, GCP, Azure, GitHub Actions, Kubernetes, or a SPIFFE identity) and exchange that, via the same RFC 8693 flow, for a short-lived, narrowly-scoped access token. The SPIFFE and SPIRE projects, both graduated projects of the Cloud Native Computing Foundation, are the open standard most commonly cited for this: a SPIRE server acts as the central authority for a trust domain, issuing cryptographic identity documents (SVIDs) to workloads — including agents and MCP servers — that let each one prove who it is via mutual TLS with no pre-shared secret at all.

The net effect of combining these two mechanisms is that a static, long-lived, broadly-scoped credential — the artifact an attacker actually wants, and the single point of failure the Replit incident and the general confused-deputy pattern both trace back to — simply does not exist anywhere in the chain. What exists instead is a sequence of short-lived, narrowly-scoped tokens, each one an independent enforcement point rather than a single point of failure.

One caution worth stating plainly for the row above: the incumbent name in this table changed hands in 2025. IBM closed its $6.4 billion acquisition of HashiCorp on February 27, 2025, meaning HashiCorp Vault — still the default answer many engineers give when asked how their organization manages secrets — is no longer an independent company. Corporate-status drift like this is exactly the kind of fact worth re-verifying at the moment you scope a project, not assuming from memory.

Two current government references are worth reading directly rather than secondhand, because both are recent enough that most existing internal security policy predates them.

On May 1, 2026, CISA and five allied cybersecurity agencies— the NSA, and the national cyber authorities of Australia, Canada, New Zealand, and the United Kingdom — jointly published "Careful Adoption of Agentic AI Services," among the first coordinated Five Eyes advisories aimed specifically at autonomous AI agent deployments rather than generative AI broadly. The guidance organizes agentic AI risk into five categories: privilege compromise (overly broad permissions letting a single compromised agent reach across many systems), design and configuration flaws (integrating third-party components with excessive permissions, or relying on static access controls that don't account for dynamic agent workflows), behavioral misalignment (agents acting unpredictably or being manipulated via prompt injection or data poisoning), structural cascading failures, and supply chain vulnerabilities. Its central, practical recommendation is blunt: current agentic deployments should be limited to low-risk, non-sensitive tasks, with that threshold expected to rise only as the security community's controls mature — not a permanent ceiling, but a present-tense one.

Separately, NIST's Center for AI Standards and Innovation announced its AI Agent Standards Initiative on February 17, 2026— the first US government program dedicated specifically to interoperability and security standards for autonomous agents, distinct from NIST's earlier AI Risk Management Framework (January 2023) and its Generative AI Profile (July 2024), neither of which was designed for systems that autonomously execute multi-step actions, call external tools, or spawn sub-agents. The initiative is organized around three pillars — industry-led standards development, community-led open-source protocol work, and research into agent security and identity — and NIST has indicated a formal AI Agent Interoperability Profile is targeted for release in the fourth quarter of 2026.

Neither document is a certification regime, and neither substitutes for your own counsel's review of applicable regulation in your specific industry — healthcare and financial-services deployments in particular carry obligations (HIPAA and equivalent frameworks among them) well beyond what either document covers on its own. What both documents are useful for is exactly what we've used them for here: a current, checkable reference for what "reasonable" looks like as of today, from bodies with no vendor product to sell.

The order matters as much as the individual pieces, because several of these steps quietly depend on the one before them and fail invisibly, rather than loudly, if built out of sequence.

A note on ownership, since this is the part most teams leave implicit: tool-call monitoring, credential rotation, and periodic re-review of any MCP server's tool definitions all need a named owner and a recurring cadence, not a one-time build task closed out at launch. An agent architecture that is correctly scoped and sandboxed on day one degrades quietly over the following months if nobody is assigned to watch it — a new tool added to unblock one workflow, a permission widened "just for now," an MCP server update approved without re-reading its tool descriptions. None of these individually looks like a security regression. Collectively, six months later, they can be exactly that.

If your agent needs to reach older, internal systems that were never designed with OAuth or workload identity in mind — a mainframe, an on-premises ERP, a system of record with only a service-account login — our legacy system modernization guide for AI agents covers the specific pattern of building a scoped credential broker in front of a system that cannot natively support one.

The following is an illustrative scenario, not a real client engagement — we are naming it as a worked example because we do not have a Frenchy Digital case study specific to agent tool-sandboxing and credential-scoping architecture to draw on honestly, and we would rather work an example transparently than imply one that doesn't exist.

Consider a 60-person operations team at a mid-market logistics company deploying an agent that reads a shared support inbox, looks up shipment status in an internal API, and — for a narrow set of clearly-defined cases — issues refunds under $250 without a human review. Built the naive way, this agent runs on one service account with read/write access to the entire order-management system (because that was the credential already available, and scoping a new one felt like extra work), and executes its refund logic directly in the same backend process that reads the inbox — meaning any content in an incoming email is one hop away from code that can move money.

Applying the architecture above changes three concrete things, in order. First, the inbox-reading and refund-issuing logic move into an isolated execution environment — reading untrusted email content and having a live path to a payments API are exactly the combination sandboxing exists to separate. Second, the shared service-account credential is replaced with two narrowly scoped tokens: one read-only token for looking up shipment status, and one write-scoped token, valid only for issuing a refund under the $250 threshold, that expires within minutes of issuance rather than sitting active indefinitely. Third, any refund at or above the $250 threshold — the genuinely high-impact, less-reversible case OWASP's Excessive Agency guidance specifically calls out — routes to a human queue instead of executing autonomously, while refunds under the threshold still execute agent-side, now bounded by a credential that, even if fully compromised, cannot authorize a refund above the amount it was scoped for.

Worked honestly: if this team processes roughly 40 refund-eligible tickets a day and the agent's scoped token is capped at $250 per action with a five-minute lifetime, the maximum possible loss from a single fully-compromised token — the worst case the architecture is actually designed to bound — is $250, not the full balance of whatever account the old shared service credential could reach. That is the entire point of scoping: not that a compromise becomes impossible, but that its cost becomes a known, small, designed-in number instead of an open question.

One scoping note specific to this domain: the discovery phase should always include a direct read of every MCP server or third-party tool integration your agent currently trusts, checked specifically for tool descriptions that request unusually broad permissions relative to their stated purpose, and for whether your client re-prompts on a tool-definition change or silently accepts it. Both are quick to check and expensive to discover only after an incident.

Two adjacent pieces worth reading next: if your agent operates a browser or a desktop directly rather than calling discrete APIs, our computer-use and browser automation guide covers the specific isolation challenges of that pattern, and our LLM cost optimization guide covers the economics of running scoped, monitored agent workflows at volume.