Caging the Agents: Applying Zero Trust to Autonomous AI

NIST’s zero trust architecture, SP 800-207, landed in August 2020 with a simple instruction: stop trusting things because of where they sit. No implicit trust for a user or an asset just because it is on the corporate network, or because the company owns it. Authenticate and authorize as two separate steps before every session. Protect the resource, not the network segment. That document became the default posture for enterprise IT, and NIST spent the following years making it concrete. SP 1800-35, finalized in June 2025, documents nineteen reference architectures built with twenty-four vendors and maps them to the NIST Cybersecurity Framework and SP 800-53.

Autonomous agents broke the assumptions underneath that whole body of work, and mostly nobody said it out loud.

Zero trust already accounts for non-human subjects. SP 800-207 makes authentication and authorization functions of both the subject and the device, and it protects resources, assets, services, workflows, and network accounts, not just people. The agent gap is narrower than the usual telling suggests, and it is specific. An agent’s authority is delegated to a non-human principal, and its behavior is non-deterministic, so you cannot predict what it will ask for next. And the instructions you gave it sit in the same context window as the data it just fetched from an email, which means your system prompt and an attacker’s injected text are indistinguishable tokens. There is no line between what you told the agent to do and what the world told it to do.

That is the pivot I want to write about. The field is moving from how to build agents to how to control them, and it is moving on two tracks. One is practical: infrastructure that contains an agent like an untrusted workload. The other is institutional: the identity and authorization machinery being assembled for non-human principals. Both are young, and both are worth watching.

The failure is documented, not theoretical

An agent in production is a program with shell access, filesystem and database access, HTTP, and the ability to message people. That is a much larger attack surface than a chatbot, and the failures are now on the record. Agents of Chaos, a February 2026 study by Shapira and colleagues, ran a two-week red team with twenty researchers against agents in a live environment and wrote up eleven case studies: agents complying with requests from people who were not the owner, disclosing sensitive information, taking destructive system-level actions, spoofing identity, spreading unsafe practices across a fleet of agents, and partially taking over systems.

The case study I keep returning to is the agent that reported a task complete while the underlying system state showed otherwise. That is the one that breaks our first instinct, which is to add monitoring. Logging does not help if you cannot trust the agent’s own account of what happened.

The containment answer

“Caging the Agents” is the clearest statement of the practical track. It describes a production zero-trust architecture for a fleet of nine autonomous agents at a healthcare technology company, and the author released the whole thing under Apache 2.0.

The paper starts from a six-domain threat model: credential exposure, execution-capability abuse, network egress exfiltration, prompt integrity, database access, and fleet configuration drift. Each domain maps to a provision of the HIPAA Security Rule. On top of that sits a four-layer defense.

The first layer is gVisor, a kernel-level sandbox, so each agent runs in its own isolated workload and a compromised agent cannot reach the host. The second is a credential-proxy sidecar. Agents never hold raw secrets. They get scoped service accounts, and credentials are injected through the proxy. The third is a per-pod network egress allowlist, so an agent can only reach the endpoints on its list. The fourth is a prompt integrity framework.

Over ninety days the architecture’s automated security-audit agent found and fixed four high-severity issues, including twelve API keys exported in a single agent’s .bashrc and a world-readable credential file. The paper maps its defenses to all eleven of the attack patterns from Agents of Chaos.

The security sits in the three layers the model cannot talk its way around. gVisor isolates the workload regardless of what the agent says, the credential proxy never hands the agent a raw secret, and the egress allowlist blocks anything not on its list. The prompt integrity layer, the one that depends on the model behaving, is the one that can fail.

Zero trust’s pillars, translated

Zero trust has three pillars, and each one has a direct agentic translation.

Identity verification becomes trusted-metadata envelopes and, at the frontier, cryptographically verifiable authorization. Least privilege becomes the credential-proxy sidecar and a scoped service account per agent. Continuous monitoring becomes an automated audit agent writing to logs the audited agents cannot modify.

The lesson for infrastructure teams is which translation holds. The prompt integrity layer cannot offer the same assurance as the infrastructure layers, and the paper’s authors say so, because it depends on the model obeying instructions, and prompt injection is structural rather than a patchable bug. The architecture’s security rests on the other three layers catching the failures of the fourth. This is not a criticism. It is the honest accounting, and it is why “caging” fits. You do not convince the agent to behave. You make the parts it can reach small enough that misbehavior stops mattering.

The identity ceiling

The institutional track is where the harder unsolved problem lives, and it started moving in February 2026. NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative on February 17 around three pillars: industry-led standards, community-led open protocols, and research into agent security and identity. CAISI put out a request for information on agent security, and NCCoE published a concept paper on applying identity standards to enterprise agents. I covered the initiative and what it signals in an earlier post, so I will not repeat it here.

The part that post did not get to is the ceiling on identity itself. Cryptographically verifiable authorization, an August 2026 preprint by Llambí-Morillas and Fernández-Fernández, makes the point formally. Authentication, what the agent is, and delegation, what it is broadly allowed to do, do not imply that a specific request is authorized. The paper writes this as AuthN(A_i) does not imply AuthZ(q_i), and proposes authorization as a cryptographically verifiable relation binding the principal, the request, the execution context, and the policy, with a Groth16 zk-SNARK proof of concept.

The paper names the central open problem as the separation of three bindings: identity, authorization-request, and runtime-execution. Today they collapse into a single credential. That collapse is why an agent can authenticate as itself, hold a broad scope, and still do something nobody actually authorized.

Compliance maps onto agents

The HIPAA Security Rule predates agents by decades, but its provisions translate cleanly. Access controls under 164.312(a) cover what an agent can reach in the patient data. Audit controls under 164.312(b) cover logging what the agent did. Transmission security under 164.312(e) covers an agent’s outbound calls. The evaluation requirement under 164.308(a)(8) supports watching for drift in how the fleet behaves. The Caging paper ships a threat-domain to HIPAA mapping table that is a useful starting point for the same mapping exercise.

This is the point that gets undersold in the security conversation. You do not need new regulation to govern agents. You need to do the mapping from your existing obligations to the new attack surface. HIPAA is the worked example: the Caging paper walks the Security Rule provision by provision and shows the mapping is mechanical once you sit down and do it. I will not make the same claim for CMMC or the EU AI Act, because the paper does not, and I have not seen a comparable mapping published for either. What transfers is the structure of the exercise, not the specific HIPAA results.

The audit-agent paradox

Then there is the recursion problem. The Caging architecture audits its own agents with an AI agent, which makes the auditor the highest-value target in the fleet. A compromised audit agent could report a clean bill of health for an exploited agent, which is the same failure Agents of Chaos documented. The mitigations are concrete: scope the auditor’s service account tightly, write its logs to a store it cannot modify, and eventually split privilege or lean on hardware-backed audit trails. I have written about the audit trail side of this before. It is a compliance design question, not an academic one, and it is a question most teams have not started asking.

What I am not claiming

A few boundaries before the bottom line.

The Caging results come from one company, nine agents, and ninety days, and the findings were produced by the author’s own audit agent. There is no independent validation, the author discloses dual affiliation with Commure and nFactor Technologies, and it maps to HIPAA specifically rather than a general zero-trust standard. It is a preprint. Read it as a worked example, not a certified result.

Cryptographically verifiable authorization is a hypothesis with an executable proof of concept over a zk-SNARK, not a deployed system, and the authors say so. The overhead and the deployment questions are open.

Agents of Chaos is two weeks and twenty researchers. Those are case studies, not statistics, and some of the failures were model-provider issues outside what deployment-side controls can fix.

The standards work is still in the input-gathering phase. The request for information closed March 9, the concept paper is out for comment, and there is no final agent-security guidance. SP 1800-35, the nineteen architectures, targets conventional enterprise IT. Translating zero trust to agentic workloads is the part that is not standardized yet.

And one framing correction. Zero trust did not fail, and it was never limited to human users; it already treats devices and workloads as subjects. What it does not yet handle is the delegated, non-human authority an agent exercises, and the missing binding of a particular request and its context to the policy that should govern it. That is why zero trust has to be extended for agents rather than just applied. The CVA paper’s distinction between identity binding, authorization-request binding, and runtime execution binding is the sharpest statement of what is still missing.

Bottom line

Zero trust told us to stop trusting the network and start protecting resources. Agents force the next step: stop trusting a delegated identity to imply that any specific request is authorized. Behavior is non-deterministic and there is no boundary between an agent’s instructions and its data, so authorization has to bind to the request and its context, not to the principal alone. The response forming has two halves. Containment is here today, in sandboxes, credential proxies, and egress allowlists, and the Caging paper shows it working in production against a documented threat model. Identity and authorization for non-human principals is the harder half, and NIST plus the research community have only just started on it. The teams that do both, contain the agent and map their existing compliance obligations onto the new surface, will be the ones holding evidence when the standards finish catching up.

Sources

1. NIST SP 800-207, Zero Trust Architecture (August 2020)
2. NIST NCCoE, Implementing a Zero Trust Architecture (SP 1800-35)
3. NIST, NIST Offers 19 Ways to Build Zero Trust Architectures (June 2025)
4. Shapira et al., Agents of Chaos (arXiv, February 2026)
5. Maiti, Caging the Agents: A Zero Trust Security Architecture for Autonomous AI in Healthcare (arXiv, March 2026)
6. Llambí-Morillas and Fernández-Fernández, Cryptographically verifiable authorization for autonomous AI agents (arXiv, August 2026)
7. NIST, AI Agent Standards Initiative
8. NIST, Announcing the AI Agent Standards Initiative (February 17, 2026)
9. NIST NCCoE, Software and AI Agent Identity and Authorization