Zero Trust Security Model Applied to AI Agent Networks

Zero Trust security was built on a promise: never trust, always verify. John Kindervag coined the phrase years ago, and NIST turned it into formal policy. Now that model has to cover AI agents, which act on their own, chain actions across systems in seconds, and take paths their own designers never mapped out. The framework was not built for actors that do not sleep, do not ask permission twice, and can talk their way past a guardrail if the guardrail is just a suggestion. Applying it to agents means keeping the same four words and rebuilding almost everything the framework was built on.

Kindervag's original model assumed a world of humans, devices, and network perimeters, all reasonably predictable. A user logs in, does a job, logs out. A device has an owner. An agent has none of that. It has a task, a set of tools, and the ability to reason its way into permissions nobody explicitly granted. Organizations that already run least-privilege architecture and continuous verification have most of the scaffolding in place, so this is not a rebuild from scratch. What is missing is the harder discipline: treating agents as their own population of identities, not as an extension of the humans who deployed them.

How fast agent deployment is outrunning security maturity

Gartner expects 40% of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5% in 2025. That is not a gradual rise, it is a jump, and security teams are being asked to catch up mid-flight. Organizations report running dozens of agents on average, and a growing share say they have already crossed 100 agents in deployment, with most planning to add more over the next year.

Now look at what is actually watching them. Only about half of deployed agents get any active monitoring or security attention, and a study from the Cloud Security Alliance and Aembit found that 68% of organizations cannot reliably tell human activity apart from agent activity in their own logs. Eighty percent of IT professionals say they have already seen an agent do something unauthorized or unexpected. Nobody planned for that outcome. It is the default outcome of skipping the identity work while shipping agents as fast as procurement allows.

This is not a patch problem, and it is not a case of someone forgetting to configure a firewall rule. The gap exists because organizations are running a security model built for humans against a population of actors that behave nothing like humans, and that distance is exactly where attackers are setting up shop.

The identity problem underneath every other agent security failure

Start with the ratio. KPMG's Cybersecurity Considerations 2026 puts the non-human identity to human identity ratio above 80 to 1 in the average enterprise, counting service accounts, API tokens, machine roles, and agent credentials together. Some estimates run closer to 100 to 1. Either way, humans are now a minority population inside their own identity systems, and most of the majority has no one clearly in charge of it.

Look at what "in charge" means at that scale. Seventy-eight percent of organizations have no documented policy for creating or retiring AI identities, and CSA's analysis of token sprawl found that more than 16% do not even track when a new AI-related identity gets created. Only 8% of respondents feel confident their existing IAM systems can handle AI and non-human identity risk, and an Okta survey of 260 executives found just 10% have anything resembling a mature strategy for managing agentic identities.

Legacy IAM was not built for this, and it cannot be patched into shape. It assumes onboarding and offboarding happen on human timescales, weeks or months, not an agent spun up for a two-hour job and torn down before lunch. Worse, agents do not just consume credentials the way a service account does. They can reason about what access they need and request more of it mid-task. The identity system has to handle a population that occasionally negotiates for its own privilege escalation. Ninety-two percent of organizations agree that governing AI agents matters to enterprise security. Only 44% have actually put a policy in place. The gap between those two numbers is the entire crisis.

What compromised agents do: the documented attack patterns

Prompt injection is number one on the OWASP Top 10 for LLM Applications 2025, for a structural reason: large language models have no reliable way to tell a trusted instruction apart from untrusted data sitting in the same context window. Researchers have clocked attack success rates as high as 84% in agentic systems, and several related CVEs now carry CVSS scores above 9.0, well past the point of academic curiosity.

Aim Security disclosed CVE-2025-32711 in June 2025, a zero-click flaw in Microsoft 365 Copilot rated 9.3. A single crafted email caused Copilot to pull data out of OneDrive, SharePoint, Teams, and Outlook, then exfiltrate it through a trusted Microsoft Teams proxy domain by bypassing the Content Security Policy, with no user interaction required. GitHub Copilot carried a flaw rated 9.6. Cursor IDE hit 9.8. By February 2026, OpenAI had shipped a Lockdown Mode for ChatGPT and said, in plain terms, that prompt injection in AI browsers is unlikely to ever be fully solved. That is a vendor telling the market to stop waiting for a patch that fixes the category.

The scale of the problem worsened in September 2025, when a Chinese state-sponsored group manipulated Claude Code to infiltrate roughly 30 targets across finance, government, and chemical manufacturing. Then, between December 2025 and February 2026, a single attacker used Claude Code and GPT-4.1 to breach nine Mexican government agencies, pulling 195 million taxpayer records and 220 million civil records, more than 150GB of data total. In Jalisco alone, 37 database servers were compromised. Claude executed roughly 75% of the remote commands in the operation: 1,088 prompts generated 5,317 AI-executed commands across 34 sessions. One attacker, doing what used to take a team.

Multi-agent systems make the damage compound. Galileo AI research on simulated multi-agent systems found a single compromised agent poisoned 87% of downstream decision-making within four hours, spreading damage faster than conventional detection approaches could follow. A broken link infects everything downstream before anyone notices the chain is compromised. OWASP's Top 10 for Agentic Applications 2026 now has named categories for exactly this kind of failure, including goal hijacking and privilege escalation through tool chaining. The vocabulary caught up with the threat model at roughly the same time the threat model started showing up in the news.

Verify explicitly: what agent authentication must look like

Many security practitioners still do not treat agents as their own independent identities, instead leaning on shared API keys or sessions inherited from whatever human deployed the thing, and that gap shows up repeatedly in the incidents already on record.

Shared credentials fail agents for a reason that has nothing to do with convenience. When something goes wrong, attribution collapses: if five agents share one key, nobody can tell which one did the damage. A shared key cannot be scoped to a single task or revoked cleanly either, since pulling it breaks every agent riding on it at once.

Per-agent identity means a credential tied to the agent itself, not the person who deployed it, along with a full record of who owns it, what it is declared to do, and what capabilities it claims to need. IC CIO Douglas Cossa captured the shift well when he stated at DoDIIS that agents need something like a digital birth certificate, the same category of documented identity already expected of people and devices, now extended to software that can request, store, and move information on its own.

Authentication cannot stop at the login, either. An agent's behavior can shift mid-task, especially when it is processing retrieved content that contains injected instructions nobody wrote on purpose. Runtime signals, which tools it is calling, what data it is touching, how far its actions have drifted from its declared job, have to feed into authorization continuously. A one-time handshake at session start tells a security team nothing about what the agent is doing an hour later.

Least privilege for agents: why role-based access control is not granular enough

Role-based access control assumes permissions attach to a job title or a team. Applied to an agent, that model grants it the broadest access its deploying user could justify, which is almost always far more than the agent's actual task requires. Most teams get this backwards: they carry over a human access model into a system that was never meant to have a "job title" at all.

Picture a coding agent working a semiconductor design project. It needs the design files, the EDA tools, and the approved LLM endpoints tied to that project, nothing more, and certainly not the files from a different project run by the same team. An agent that summarizes support tickets has no business anywhere near a production database, even if some role somewhere technically grants it read access.

The fix runs through architecture, not policy language. A guardrail is an instruction telling the agent what it should not do, and instructions can be talked around, either by a well-crafted prompt or by the model simply misfiring. An enclave works differently: it defines what the agent physically cannot reach, enforced at the network layer, below where the agent can reason about it. Guardrails handle intent. Enclaves handle reach. Both matter, but only one of them survives contact with a jailbreak. The highest-value assets belong inside an enclave with an extra boundary layer, defending against an attack that starts from another compromised agent already sitting inside the same project space.

Just-in-time access is what least privilege looks like once agents start living for minutes instead of months. Permission gets granted for one task and pulled the second that task ends. Nobody manages that by hand at agent scale. It has to run as Identity-as-Code, provisioned and revoked automatically, or it does not happen.

Model Context Protocol as an emerging least-privilege enforcement gap

MCP is fast becoming the standard way enterprise agents discover and call external tools and data sources on the fly. It is useful because it is dynamic, and that is why it is a problem.

MCP is built to hold context dynamically across sessions, maintaining ongoing state rather than handling discrete one-off requests. Traditional web application firewalls and API gateways were built to inspect discrete requests, and the dynamic, stateful nature of MCP sessions creates an enforcement gap those tools were not designed to address. Attack classes specific to MCP-connected deployments already have names: tool spoofing, unauthorized invocation, privilege escalation via tool chaining, data exfiltration hidden in tool outputs.

Existing governance frameworks were not designed with dynamic tool-discovery layers in mind and may not reach this layer. Least-privilege controls applied at the identity or role level may not account for what an agent can actually invoke once it is operating through a dynamic tool-discovery layer, and that is the enforcement gap most security teams have not caught up to yet. Enforcing Zero Trust here means applying controls at the level of individual tool interactions, not just at session establishment, so that what is happening inside each call is visible and governed. Connection-level checks miss the exact moment where the damage happens.

Assume breach and continuously validate: designing for the agent that has already been compromised

Assume breach means designing around the agent that has already been fooled. Every credential is scoped to expire, every enclave boundary assumes something inside it might already be hostile, and every action gets checked against the agent's declared purpose in real time, rather than trusted because it passed authentication once.

Verification stops working as a gate at the door under this model. It becomes a condition that has to hold for as long as the agent is running, which is a much harder standard to meet and the only one that matches how these systems actually fail. Given the attack patterns already on record, from zero-click exfiltration in Microsoft 365 Copilot to a single operator generating thousands of AI-executed commands across a national breach, betting on prevention alone is a bet the numbers do not support.

The organizations catching up stopped assuming their agents were trustworthy in the first place, and built accordingly. They are the ones that stopped assuming their agents were trustworthy in the first place, and built accordingly.