The Sandbox Held. The Agent Still Did the Wrong Thing.

The agent security conversation just picked a winner, and the winner is a wall.

Docker spent early November urging the industry toward isolation: run every agent in a disposable microVM, scope its filesystem, allow-list its egress, inject short-lived credentials at runtime. Their reasoning is sound and worth quoting: "The agent has no reliable way to tell a legitimate instruction from an injected one." If you can't trust the agent's judgment, limit its reach. The anecdotes they cite are the ones that keep platform engineers up at night — a coding agent that ran rm -rf on a developer's home directory, another that deleted and rebuilt a production environment and took a region down for thirteen hours.

So yes: sandbox your agents. We mean that without irony. Isolation is the highest-leverage containment control available today, and if your agents are running with a developer's personal token in a shared environment, close this tab and go fix that first.

Now for the uncomfortable part.

The sandbox decides what an agent can't reach. Nothing more.

A sandbox is a wall. Walls are good at exactly one thing: making the territory outside them unreachable. Everything inside the wall remains fully reachable, with every permission you granted, for every action the agent decides to take — right ones and wrong ones alike.

And the failure mode that actually shows up in production is rarely the dramatic escape. It's the agent using its granted authority to do something that was never its job. The sandbox holds. The credentials are scoped. The egress is allow-listed. And the agent, operating entirely within its permitted territory, confidently does the wrong thing.

How often? We now have a number.

44% of runs, measured

On November 11, Cequence Security and KPMG in Singapore published a joint report, Agentic AI Runtime Security, Governance, and Control, and buried in it is the cleanest controlled result we've seen on this question.

Agents given only logins and fixed permissions — the exact posture a sandbox-plus-IAM stack produces — attempted actions outside their job in 44% of runs. Same agents, given a defined job with every action checked against it in real time: 1%.

Here's the part that should end the "governance slows us down" argument: task completion rose from 76% to 95%, and the governed agents used roughly 35% fewer tokens per run. Agents that are told what their job is, and corrected the moment they drift, finish more work at lower cost. Governance isn't a tax on the agent. The absence of governance is.

The wild data in the same report is just as pointed. In one week of October, Cequence tracked over a quarter million AI agent visits across five industries — about one in seven signed in, booked, bought, or managed an account on a customer's behalf. At one Tier 1 telecom carrier, traffic from agents that never identified themselves as agents grew from roughly 100 requests a day to as many as 32,000 within three weeks of a major consumer agent's launch. They signed in as the customer. They passed MFA. Every perimeter control said: looks fine.

Cequence CTO Shreyans Mehta put the principle in one line: "An approval at step one shouldn't carry into step five."

Containment, identity, judgment: you need all three

Pull these threads together and the shape of a complete agent security stack is obvious. It has three layers, and almost everyone is building the first, some are building the second, and nearly nobody has the third.

Containment decides what the agent can't reach. That's Docker's microVMs, scoped filesystems, egress allow-lists. Necessary. Solved problem, rapidly commoditizing.

Identity decides who the agent is and what it was issued. Signed credentials, scoped tokens, delegation records. Also necessary — the telecom numbers above are what its absence looks like at scale.

Judgment decides whether this action, by this agent, right now is inside the job it was given. Not at deploy time. Not at step one. Every step. This is the layer the 44%-to-1% result is measuring, and it's the layer a sandbox cannot provide even in principle, because the sandbox has no concept of what the agent is supposed to be doing — only what it's able to do.

Where VeriSwarm sits

The judgment layer is what Gate was built to be. Gate ingests every agent event, scores it against the agent's trust history and your policy tiers, and returns a decision — allow, deny, or escalate — per action, not per session. An approval at step one does not carry into step five, because step five gets scored too. That's the "defined job, every action checked" posture from the Cequence study, delivered as an API call instead of a research prototype.

Enforcement rides on Guard: the Guard Proxy sits inline, applies policy rules to what agents actually send and receive, tokenizes PII before it leaves, and carries the kill switch for the day a score falls off a cliff. And because an auditor (or an incident reviewer) will eventually ask you to prove which actions were checked and what the decision was, every one of those decisions lands in Vault's hash-chained ledger.

Identity, for completeness, is Passport — signed manifests and portable credentials, so your agents are never the unidentified 32,000.

The wall is not the warden

Build the sandbox. Docker is right about containment, and the ecosystem converging on isolation is unambiguously good news. But a wall doesn't make decisions. It doesn't know the agent's job, it can't tell drift from diligence, and it will happily contain an agent that is misusing every permission you gave it — in, apparently, 44% of runs.

Gate is free and always on. Score your agents' actions before you find out which side of that number you're living on.