Zero trust has been the governing security architecture principle for enterprise IT for the better part of a decade. Never trust, always verify. No user or system is trusted by default, regardless of network location. Every access request is authenticated, authorised, and continuously validated. For human users, this model is mature, well-tooled, and increasingly well-understood by the organisations deploying it.

AI agents expose a fundamental limitation in how the model has been applied. Zero trust for humans centres on identity: authenticate the user, verify the device, enforce least-privilege access to resources. For AI agents, identity is necessary but insufficient. An agent that correctly authenticates and holds valid credentials can still cause significant harm through ordinary operation if it can reach resources that have nothing to do with its assigned task, or if it receives malicious instructions embedded in data it processes as part of its normal workflow.

The architecture that governs human users does not transfer cleanly to systems that interpret goals, chain actions autonomously, delegate sub-tasks to other agents, and make decisions that were not explicitly programmed. This article examines what zero trust for AI agents actually requires, why it is different from zero trust for humans, and how organisations can extend their existing security architecture to cover the agent class of non-human actor.

The Scale of the Governance Gap

The deployment of AI agents has significantly outpaced the governance and security infrastructure designed to manage them. Gravitee's 2026 State of AI Agent Security report found that only 47 per cent of deployed AI agents are actively monitored or secured. A separate Cloud Security Alliance study found that 68 per cent of organisations cannot clearly distinguish human activity from AI agent activity in their logs. For security teams, this means that a significant proportion of the activity in their environment is being performed by systems they cannot see, cannot audit, and cannot contain if something goes wrong.

The non-human identity problem underlies this gap. Entro Security research found that non-human identities outnumber human identities at a ratio of 144 to 1 in cloud-native environments. Every AI agent adds to this count. Traditional identity and access management frameworks were not designed for actors that interpret instructions, chain multi-step actions, and operate at machine speed. The blast radius of a compromised or misconfigured AI agent extends considerably further than a compromised service account precisely because agents are not constrained to a fixed set of operations.

The attack velocity problem

Average attacker breakout time in enterprise environments dropped to under 30 minutes in 2025, with the fastest observed at 27 seconds, according to CrowdStrike's 2026 Global Threat Report. AI-powered attacks operate at the same speed as AI-powered defences. A misconfigured agent with broad permissions that is compromised or manipulated can traverse systems, exfiltrate data, and escalate privileges faster than a human analyst can respond. The architectural controls that matter are the ones that prevent the blast radius, not the ones that detect it after the fact.

Why Traditional Zero Trust Falls Short for Agents

The original zero trust model, codified in NIST 800-207, was designed around sessions. A user authenticates at the start of a session, the device is verified, access to specific resources is granted based on identity and context, and the session ends. The trust evaluation happens at the boundary.

AI agents do not operate in sessions in this sense. An agent receives a goal and determines the intermediate steps itself. It may call dozens of APIs, access multiple data sources, spawn sub-agents, and chain together operations that span hours or days. The execution path is partially non-deterministic: the agent may access resources its designer did not anticipate, depending on how it interprets the goal it was given. A boundary-based trust evaluation that happens once at authentication cannot govern behaviour that unfolds across an extended, unpredictable action sequence.

Microsoft's Zero Trust for AI reference architecture, released in March 2026, extends the existing zero trust model with three additional principles specific to AI systems. Govern AI actions as well as access: traditional zero trust governs what a principal can access. For AI agents, this must be extended to govern what actions the agent is permitted to take, not just what data it can reach. Monitor AI behaviour continuously, not just at authentication: the pattern of an agent's actions over time is as important a security signal as its initial authentication. Protect AI models and data pipelines: the model itself and the data it is trained on and operates against are attack surfaces that human-centric security models do not address.

The Five Principles of Zero Trust Applied to AI Agents

Applying zero trust to AI agents requires translating each of the model's core principles into the specific architectural requirements of autonomous systems.

Explicit verification for non-human identities. Every AI agent must be provisioned as a distinct identity with verifiable credentials. The Agent 365 registry, now generally available in Microsoft environments, provides the system of record for non-human identities at the enterprise level. Each agent's identity should include not only authentication credentials but metadata covering the agent's purpose, the resources it is permitted to access, the actions it is permitted to take, and the human or team accountable for its operation. Agents without registered identities are ungovernable regardless of what other controls are in place.

Least privilege access scoped to task, not user. The most common failure mode in early agent deployments is inheriting the sponsoring user's permissions as the agent's access scope. A user with broad SharePoint access creates an agent that inherits that access, and the agent can read, surface, or act on anything the user could reach. Least privilege for agents means defining the minimum data access and minimum action set required for the specific task the agent performs, and granting nothing beyond that. This requires per-agent permission design, not a permission inheritance model.

Assume breach and contain the blast radius. The assume breach principle, which has always been part of the zero trust model, takes on additional importance for agents because the blast radius of agent compromise or manipulation is wider than human account compromise. The architectural mechanism that limits blast radius for agents is the enclave: a trust boundary that contains the agent, the specific data sources it is permitted to access, and the specific tools it is permitted to call. Actions outside the enclave boundary are blocked at the architecture level, not controlled by the agent's instructions.

Continuous verification of behaviour, not just identity. Once an agent has authenticated and begun operating, zero trust principles require that its behaviour be continuously evaluated against expected patterns. Anomalous behaviour, such as an agent attempting to access data sources outside its defined scope, calling APIs it has not previously used, or generating outputs that differ materially from historical patterns, is a security signal that should trigger review rather than being treated as normal operation. Microsoft Defender's runtime blocking capability, entering preview in June 2026, provides the mechanism for this at the infrastructure level.

Tamper-evident logging of every action. The audit trail for agents must cover every action the agent attempted, every tool it called, every data source it accessed, and every output it produced. This is a different logging requirement from the session-level logging that suffices for human users. The EU AI Act's Article 12 requirement for automatic event logging at appropriate granularity for high-risk AI systems makes this a regulatory obligation as well as a security requirement in many contexts.

Prompt Injection as the Agent-Specific Attack Vector

Traditional zero trust addresses the threat of credentials being stolen and used by malicious actors. For AI agents, there is an additional attack vector that has no equivalent in human identity security: prompt injection.

Prompt injection exploits the AI model itself rather than its credentials. An attacker embeds malicious instructions in data that the agent will process as part of its normal operation, causing the agent to take unintended actions that appear legitimate from an authentication and authorisation perspective. The agent has valid credentials. It is accessing permitted resources. But it has been induced to use those credentials and permissions in ways the organisation did not authorise.

The mitigation for prompt injection is architectural rather than instructional. Adding safety guidelines to the agent's system prompt reduces the risk at the margins but does not eliminate it. The controls that actually work are deterministic: policy engines that intercept every tool call and action request, evaluate it against a defined rule set in application code, and permit or deny it before the model's intent reaches the wire. Actions that are structurally prevented cannot be induced through prompt manipulation, regardless of what instructions the agent receives.

Microsoft Purview's runtime data loss prevention for agent prompts, now in preview with Agent 365, provides the data layer of this control. It detects and blocks sensitive data before it is processed by an agent, ensuring that an agent induced to seek sensitive information cannot access it even if the instruction to seek it was successfully injected.

The supply chain dimension

CrowdStrike's 2026 Global Threat Report highlighted a supply chain attack targeting an enterprise agentic framework, in which 1,184 malicious agent skills were distributed through 12 publisher accounts. Snyk's analysis of agent skills found that over 36 per cent contained security flaws at some severity level. The security of AI agent deployments depends on the integrity of the ecosystems from which agents and their tools are sourced, not just the governance of agents after deployment.

The Microsoft Zero Trust for AI Architecture in Practice

For organisations operating in Microsoft environments, the zero trust for AI architecture is built on the same infrastructure as the broader Microsoft zero trust model, extended with the agent-specific capabilities that have been added in 2025 and 2026.

Microsoft Entra provides the identity foundation. Every agent is assigned a workload identity in Entra, governed by the same conditional access policies, continuous access evaluation, and lifecycle management that apply to human identities. The difference is that agent identities are scoped to specific tasks and reviewed on a defined schedule, rather than being tied to employment status.

Microsoft Defender provides behavioural monitoring and runtime blocking. Its existing classification capabilities, which detect anomalous behaviour regardless of which application is performing it, extend directly to AI agents. Asset context mapping, entering preview in June 2026, builds a relationship graph for each agent showing the devices it runs on, the MCP servers it connects to, the identities associated with it, and the cloud resources those identities can reach. This is the blast radius visibility that security teams need to make containment decisions quickly when an anomaly is detected.

Microsoft Purview provides the data governance layer. Sensitivity labels applied at the item level govern what an agent can access and under what conditions. Runtime DLP for agent prompts prevents sensitive data from reaching AI models without appropriate controls. The data governance framework that an organisation establishes for Copilot compliance extends to agents with additional item-level specificity.

Agent 365 provides the control plane that connects all of these components into a unified governance architecture. The registry gives security and IT teams visibility of the complete agent fleet. The policy engine defines what agents are permitted to do. The monitoring infrastructure provides the continuous behavioural visibility that zero trust principles require.

What Needs to Change in the Security Architecture

For security teams that have built mature zero trust capabilities for human users and are now extending them to AI agents, the architectural changes required are specific and tractable. They are not a replacement for existing controls. They are extensions of the same principles into a new class of actor.

• Extend identity governance to cover non-human identities explicitly: if the current identity governance programme does not include a defined process for provisioning, scoping, reviewing, and deprovisioning AI agent identities, this is the first gap to close. The identity layer is the foundation that everything else depends on.

• Add action governance alongside access governance: define, for each agent or category of agent, not just what data it can access but what actions it is permitted to take. This requires a different kind of policy design from access control lists and requires input from the operational teams that understand what each agent is supposed to do.

• Implement architectural controls against prompt injection: system-prompt safety guidelines are insufficient. The controls that matter are at the application layer, in the policy engine that governs every tool call before it executes. Review whether current agent deployments have this layer in place.

• Build logging for agent actions, not just agent sessions: the audit trail for agents needs to cover the action level. Review whether current logging architecture captures the event types that would allow post-hoc reconstruction of an agent's operation, and whether those logs are retained for the duration required by applicable regulatory obligations.

• Include the agent supply chain in security review: the security of agent deployments depends on the integrity of the frameworks, skills, and tools from which agents are built. Apply the same supply chain security scrutiny to AI agent components that is applied to software dependencies.

How VE3 Supports Zero Trust for AI

VE3 works with organisations extending their security architecture to cover the governance and security requirements of AI agents at scale. Our work in this area covers the identity governance design that provides the foundation for agent security, the policy architecture that governs agent actions rather than just agent access, and the integration of agent-specific controls into existing zero trust and SIEM infrastructure.

As a Microsoft-aligned partner with deep expertise in Entra, Defender, Purview, and Agent 365, we design zero trust for AI architectures that extend existing investment rather than introducing parallel tooling. For organisations in regulated sectors where security architecture decisions need to satisfy both internal governance standards and external regulatory requirements including the EU AI Act's Article 15 cybersecurity obligations, we bring specific understanding of how the technical architecture and the compliance evidence requirement connect.

The transition from zero trust for humans to zero trust for AI agents is the architectural challenge that defines enterprise security in 2026. Getting it right means extending proven principles into new territory with the same discipline that made zero trust work for human identity. That is the work we help organisations do.