An agent system fails its security review in three ways: data exfiltration when a scoped identity does not propagate, prompt injection when context is not sanitized, and inaccurate access control when the agent acts under a shared system identity. Those failures do not happen in the model. They happen one layer down, in the infrastructure around it.
Read together, those three failure modes are symptoms of three questions current stacks struggle to answer at the architecture level. Whose authority backed a given action? What proof exists, after the fact, that it happened the way the logs claim? And what blast radius contained the damage when the agent’s assumptions turned out to be wrong? Model-level defenses answer none of the three, because all three live one layer down, in the harness — the code and runtime around the model, made of six components: state and persistence, security and governance, orchestration and tool use, memory, observability, and evals. This post goes deep on the second of those. (Pt 1: The Agent Harness covers all six.)
Forrester named the “Agent Control Plane” as a market category in December 2025 (Joseph), and the category has cohered exactly around these concerns. The OWASP Top 10 for Agentic Applications, released the same month, organizes its risk hierarchy around autonomy rather than the model: its top three categories — agent goal hijack, tool misuse, and identity and privilege abuse — describe what a manipulated model does once it can act, hold memory, and carry credentials. In February 2026, NIST’s Center for AI Standards and Innovation launched a federal AI Agent Standards Initiative anchored on agent identity and authorization.
Prompt injection is real, but it is not the subject of this post; it is a model-layer problem, addressed by the people building the models. The questions here assume injection will sometimes succeed and ask a different one: when a model is talked into something it should not do, what stops that action from carrying authority it was never granted, from going unrecorded, or from reaching past a single execution? Those answers are architectural, and they hold up even as the models, prompts, and tools underneath an agent keep changing — the gradual divergence between what a system was configured to do and what it actually does, which practitioners call drift.
The three questions map onto a small catalog of architectural patterns — four, once agents start calling other agents. They are complementary, not alternatives. The first three are essential for any production agent platform today; the fourth, A2A authority chaining, is where the requirements are heading as multi-agent systems. Each names a failure mode in the harness, a recommended primitive that addresses it, and the point where it still breaks even when implemented correctly.
Identity propagation is the problem of keeping a request bound to the human who originated it as it travels through the agent and out to every tool and downstream API. Most stacks lose that binding at the first boundary: the user authenticates to the agent, the agent calls its tools under a shared service account, and the database records the action as “the agent” rather than as the user. Role-based access control at the model API does not propagate through the tool calls. Propagation matters because the check at the point of access is a conjunction: an action should proceed only when the requester’s permissions, the agent’s permissions, and the tool’s permissions all allow it, and that conjunction has to be available where the call is actually made. Lose the originating identity at the first hop, and the downstream system can no longer evaluate it.
The recommended primitive is to mint a new, audience-bound token at every hop instead of forwarding the user’s original one. The mechanism is OAuth 2.0 Token Exchange (RFC 8693), with audience binding via Resource Indicators (RFC 8707); the MCP Authorization specification forbids token passthrough for exactly this reason — a forwarded bearer token lets a compromised server replay it against anything the user can reach. It still breaks at MCP servers configured without protected-resource metadata, at handoffs where the token’s scope does not narrow, and at downstream APIs that accept any signed token without checking its audience. Permit.io, Pomerium, Auth0, and AWS AgentCore Identity all ship a version of this. Token exchange is past the aspirational stage: a meaningful share of services already implement it, some through a functionally equivalent exchange that they migrate toward full RFC 8693 conformance over time. The open question for any given stack is less whether the primitive exists than whether it has been adopted end-to-end.
A decision log records not just that an action happened but on whose authority, against which policy, with what reasoning, and what alternatives were weighed. A request log — endpoint, method, status, duration — captures that something happened and none of the rest. Most stacks produce the request log and discover the gap only when a regulator or an incident review asks a question the request log cannot answer.
The recommended primitive is total interception: every tool call, model call, and policy decision passes through one enforcement point that writes a structured, identity-bound, tamper-evident record. Galileo’s Agent Control hooks are the cleanest current articulation of it; Temporal’s deterministic replay reconstructs the same trail from a different angle. For high-risk systems deployed in the EU, EU AI Act Articles 12 and 14 make this non-optional. It breaks when interception is sampled rather than total, when the reasoning behind a decision is not captured, and when the audit store is mutable. No industry-standard schema for these records exists yet, so each regulated customer tends to specify its own. Across those specifications the field that carries the most weight is identity binding — being able to chain a single access, this tool read this record, back through every agent and tool hop to the user who originated the request — with tamper-evidence a close second.
Isolation determines how far damage spreads when a single agent execution is compromised. The architectural claim is that the boundary has to live below the layer the agent can reason about — enforced in hardware, not in application logic, an agent can be talked around. A shared-kernel container is the default and is not enough. The recommended threshold is a hardware-virtualized microVM per execution, each with its own kernel, so a compromised step cannot reach the host’s credentials or a neighboring agent’s context. The threshold applies to the workload that cannot be trusted — the agent itself, which runs on model output and attacker-shaped input. The first-party services it drives, orchestration and memory, are trusted code; they run safely in a hardened container with no added capabilities, a read-only root filesystem, no service-account token, and a default-deny network. A userspace kernel, such as gVisor is the software-enforced fallback where a full microVM is impractical. The reason the boundary has to sit in hardware rather than in that container is behavioral. In a controlled red-team exercise, an agent given a shell reasoned straight from one blocked escape to the next — capabilities, then seccomp, then namespaces, then a kernel CVE — and was stopped only by the one layer it could not reason its way to, the hardware boundary.
Firecracker is the reference implementation; AWS AgentCore Runtime, E2B, Vercel Sandbox, and Cloudflare Sandboxes all ship comparable primitives, which makes this a procurement decision rather than an engineering one. Marc Brooker (AWS) frames the shift plainly: the security-critical boundary moved off the operating system and onto one supported in hardware. The argument that a container is not a sandbox is the same point from the other direction. It breaks when the boundary is a user-space sandbox that intercepts syscalls but still shares a kernel; the cost is cold-start latency and per-VM memory overhead, plus coordination complexity for multi-step workflows. Compute isolation is necessary, but it is not the whole boundary. Network egress and how the harness scopes credentials are separate axes a microVM does nothing for: an agent isolated at the compute layer, behind a default-deny network, with one permitted datastore can still exfiltrate through that one permitted path using the valid credentials it was handed. The blast radius that remains once the runtime is sealed lives at the data and query tier, which is why scoped tokens (Pattern 1) and execution isolation (Pattern 3) are complementary rather than redundant: one binds authority, the other contains compute, and the data tier needs both.
Once agents call other agents, each of the first three questions gets harder. Identity that survived one hop now has to survive a chain. A single compromised agent’s blast radius cascades down the chain rather than staying local. And audit attribution blurs into “the agent did it,” with no record of which agent, or on whose ultimate authority.
The recommended primitive is a cryptographic delegation chain: each handoff produces a signed token that records the full chain back to the originating user, narrows the scope at every hop so each downstream agent can do strictly less than the one before, and lets every recipient verify the chain rather than trust it. MIT’s Authenticated Delegation work (South et al., ICML 2025) formalizes the pattern; Stytch’s A2A OAuth implements a version in production. This is the pattern with the lowest vendor density — the standards are still forming — which is why, of the four, it is the one most teams will build rather than buy. Even implemented correctly, the chain breaks at the two points it exists to protect. A hop that does not actually narrow scope re-broadens authority instead of reducing it, and a recipient that trusts the chain’s claims rather than verifying its signatures defeats the purpose of signing them. In current enterprise conversations, this pattern runs ahead of demand. Teams are deploying multi-agent systems and standardizing on A2A, but mostly to make agents in different environments interoperate, not yet to ask for cryptographic delegation chains or per-hop scope narrowing. Pattern 4 is the anticipatory one: the place to design for a question most customers have not raised yet, rather than retrofit once they do.
When a team cannot ship all four at once, a triage matrix sequences them by cost and by how the failure shows up. Infrastructure isolation is a high-cost adoption decision with many vendors to choose from. Scoped token propagation is also high-cost — it touches every component — but well-supported, so the work is evaluating vendors quickly rather than building. Decision-level audit is the one most often deferred, because its failure is silent until the moment proof is demanded, and most expensive to retrofit then. A2A chaining is catastrophic when it fails and has no mature vendor to buy from yet, so it is the one teams build.
The strongest evidence is what the people building agent infrastructure are shipping and writing. The MCP Authorization specification forbids token passthrough and mandates audience-bound tokens. Permit.io’s MCP auth taxonomy and Pomerium’s per-request authorization model both implement scoped propagation. Galileo shipped decision-level control hooks under an open-source license. On isolation, Firecracker’s design, Brooker’s retrospective on seven years of running it, and the “your container is not a sandbox” argument all make the hardware-boundary case concretely.
Frontier labs and academia point in the same direction. Anthropic’s Responsible Scaling Policy and Google DeepMind’s Frontier Safety Framework both treat autonomy and isolation as first-class; the UK AI Safety Institute ships an open sandboxing toolkit. On the academic side, Chan et al. on visibility into AI agents, South et al. on authenticated delegation, and Wu et al. on IsolateGPT each formalize one of the three questions, and Agache et al. (NSDI ’20) is the original Firecracker paper underneath Pattern 3.
Field engagements add a pattern that the published sources do not capture. Across recent enterprise conversations — regulated and not — the same shape recurs: prompt injection is the threat teams name first, but the controls they actually ask for sit below the model. The most-named production blocker is giving an agent an identity and propagating the user’s identity through tool chains and shared memory; more than one team acknowledges running on shared, tenant-level tokens and being unable to guarantee that one user’s request never crosses into another’s. On isolation, teams arrive at the same realization on their own — that, as built, the agent needs access to everything it might touch, so a single compromised step inherits the reach of the whole system. What reassures these teams, consistently, is not an assurance that the agent is trustworthy but a platform that evaluates the conjunction of permissions — requester, agent, and tool — at the point of access, so authority is checked at every hop rather than assumed.
Platform teams describe the same concern in their own terms. Their internal systems already enforce RBAC at every layer, so once agents sit in front of those systems, carrying each user’s real authority through every step becomes the hard part, and one they expect to grow as agents reach more of the stack.
The structural backdrop is consistent with all of this. Among organizations that suffered an AI-related breach in 2025, 97% lacked proper AI access controls (IBM, Cost of a Data Breach 2025). The access-control layer is not a tail risk; it is the layer most teams have not built.
The questions are being named in the field faster than the primitives that answer them are being assembled. Forrester has a category, OWASP has a ranking, NIST has an initiative, and the token-exchange, decision-audit, and isolation primitives all exist — in pieces, spread across a dozen vendors. Few stacks today assemble all of them into one platform.
A well-designed agent platform implements all four patterns as structural properties rather than configuration the user has to remember to set. Scoped token propagation so every action carries the originating user’s authority. Decision-level interception so every action produces an identity-bound, tamper-evident record. Infrastructure-layer isolation so a compromised execution cannot exceed its blast radius. And A2A authority chaining so delegation across agents narrows scope instead of dissolving it. A platform that provides three of the four has a known gap, not a complete answer.
Feature lists do not reveal which of the four patterns a stack actually implements. Three traces do. First, pick one user request and follow the originating identity through every tool call and downstream API — does it survive every hop, or collapse into a service account at some boundary? Second, generate one audit query: what did agent X do for user Y between time A and time B, and on whose authority? See whether the stack answers cleanly or whether it requires joining six systems after the fact. Third, pick one execution-failure scenario and find the blast radius — single execution, single tenant, or the whole platform — and whether that boundary is enforced in hardware, in the kernel, or in application logic the agent could reason its way around.
What is still hard is that no industry-standard set of controls for autonomous systems exists yet, so each organization ends up building its own, usually late in the project and under deadline. Closing that gap is the next two years of work, and NIST CAISI, OWASP, and the Forrester ACP category are all converging on it. Part 4 takes up orchestration — the loop where these primitives get stress-tested under real tool use.
Run the three traces against the stack already in production. The hop where identity collapses is the place to start.
Series: Designing An Agentic Platform
References
Authors
Mikiko Bazeley**, Staff Developer Advocate, MongoDB**. Mikiko focuses on agentic AI systems and enterprise agent infrastructure, writing about agent memory engineering, context engineering, and the POC-to-production gap in AI systems.
Ashish Kumar**, Technical Fellow, MongoDB**. Ashish joined MongoDB two years ago through the acquisition of Grainite, a database startup he co-founded. Before that, he spent many years at Google, most recently responsible for Google’s native database suite — Bigtable, Spanner, Datastore, and Firestore — across Google’s own products and Google Cloud. His passion is large-scale distributed systems, and at MongoDB he focuses on architectural improvements across the product stack.
Max Marcon**, Director of Product Management, MongoDB**. Max leads product for agentic AI initiatives at MongoDB. His mission is to ensure customers are successful with running agents at enterprise scale.
Srinidhi Kaushik**, Staff Site Reliability Engineer, MongoDB. **Srinidhi works on sandboxing, network isolation, and infrastructure reliability.
Simon Zhu**, Staff Engineer, MongoDB. **Simon works on security, agent identity, and infrastructure reliability.
The Three Questions Agent Security Has to Answer was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.