Agent infrastructure is four bolted-on layers. None of them enforce.

Ask a team how their AI agent is secured and you will hear a confident list of brand names: a sandbox product, a workflow engine, an observability platform, an MCP SDK. Then ask which of those can say no. Which one can stop an agent mid-run because the effect it was about to perform was never allowed? Notifying, visualizing, and alerting don’t count.

In most deployments the answer is none, and the cause is structural rather than a procurement mistake. Agent infrastructure today is four separate products, bolted on after the fact and owned by nobody, and every one of them is built on requests.

Layer one: the sandbox that used to work

vm2 used to be the default answer for running untrusted model-generated code. It was a good answer for years. It has been deprecated since 2023, after a long series of escapes that its maintainer could no longer keep patching.

The industry moved to isolated-vm, a harder target because it uses real V8 isolates. In August 2026 it shipped a critical escape of its own. Same story, later chapter: a library promises isolation, attackers treat the promise as a surface, and the maintainer loses the race.

Containers are the current fallback. Wrapping every agent step in a fresh container shrinks the blast radius, at the price of hundreds of milliseconds of cold start per step. So teams use containers for the demo and the security review, and the hot loop runs outside them, because the loop calls the model forty times and waiting four seconds per iteration is not viable. A sandbox that only protects the slow path is a checkbox.

Layer two: replay that isn’t

After the first “why did the agent do that?” incident, teams reach for workflow engines: event-sourced, durable, deterministic. The marketing says replay. The engineering is subtler. These engines replay control flow by recording outcomes. Every non-deterministic step, meaning every model call, is quarantined into an activity whose result is stored and re-read, never re-executed. That is the correct design, but it means the replay covers the schedule and not the system.

You can see the plan the agent followed. You can’t see the effect. What did the agent’s tool call actually write? Which credential did the fetch present? The journal and the transcript don’t know. The database audit log does, but it lives in a different product, on a different team, with no link back to the run. That is why agent postmortems read so strangely: everyone knows what the model said, and nobody can prove what the agent did.

Layer three: the gateway that counts

The spend story repeats every week now. The agent that spent $400 overnight. The loop that retried a failing job eight hours past the point of usefulness. The team that found out from the invoice.

The standard mitigation is an LLM gateway, with rate limits, cost tracking, and model routing. It is a useful product in the wrong position. A gateway sits on HTTP, so it can count requests, but it can’t see that request 3,912 is one of 4,000 identical requests queued by an agent loop that was told to try again if anything fails. The decision to spend happens below the HTTP layer, in the agent’s own composition, where the gateway has no authority. The alert fires when the money is gone.

Layer four: the SDK that hands out credentials

MCP is the best thing to happen to agents in years, and the most dangerous. It gives you one protocol and thousands of tools, and the developer experience ends with pasting an API key into a config file. Strangers write the tool code, the credentials are real, and nothing scopes one tool from another: any tool the agent can reach, it can reach with everything the config gave it. We have already watched an email tool silently BCC outbound mail to an attacker. The trace looked healthy because it records prompt in, tool call out, success. The exfiltration was a side effect the trace never captured.

An SDK distributes but can’t constrain. It runs inside the same trust domain as the agent code it serves, so it has no boundary to enforce anything at.

The pattern

Each of the four layers makes requests. The sandbox asks that code be submitted to it. The workflow engine asks that non-determinism be declared. The gateway asks that traffic route through it. The SDK asks that you read its docs. Meanwhile the component present at every effect boundary, the one that performs every write, send, and install, is the agent’s own code, the least trustworthy thing in the stack and the only one with a front-row seat to all of them.

Libraries request and runtimes enforce. That division of labor was settled years ago for memory safety, network policy, and budgets. Agents are the first mainstream workload to skip the enforcement layer, because the workload arrived wrapped in a framework before anyone asked what it would run on.

What enforcing would take

A better library won’t do it. It takes a different floor. Model-generated code should run default-deny, starting with nothing and receiving capabilities per run. An effect journal, hash-chained, should record which credential touched which resource, which makes the run replayable in a form worth the word. Budget should be reserved before dispatch, so a run stops when the reserve doesn’t fit instead of when the invoice arrives. And tool transport should belong to the layer that can see the effects, with scoping per tool and per run.

Each of those is unremarkable in a database or an OS kernel. None of them ships as a bolt-on, because a bolt-on is by definition on the wrong side of the boundary.

The cost of the fix is that it is runtime work. It changes where the stack lives and how fast it starts. QuickJS is an interpreter, and a runtime that enforces inside its own isolates will lose CPU benchmarks to Node and should say so loudly.

The next time an agent incident lands and the postmortem goes viral, read it with one question in mind: which of the four layers could have said no? I expect the answer to be the same every time.