A Practical Zero Trust Architecture for AI Agents

An AI agent that can search records, change cloud configuration, send email or trigger a payment is a security principal, not merely a language-model interface. It should not inherit broad user or service-account privileges simply because it can call useful tools. A practical Zero Trust architecture gives each agent run a workload identity, preserves the identity of the delegator, issues narrowly scoped and short-lived authority, evaluates policy before consequential tool calls, and records the context and approvals behind every action.

That is the case for Zero Trust AI agents. It isn’t a product category or a prompt filter in front of a language model. It’s an architecture in which an agent receives no standing trust because it sits on an internal network, runs in a trusted cluster, was launched by a known employee or has used a tool safely before. Each meaningful access request is authenticated, authorised in context and recorded.

The UK Government’s implementation guide for its AI cyber-security code is admirably direct: agentic systems can take actions that aren’t fully predictable and may be coerced by an attacker, so accounts and permissions assigned to them need exceptional care. (assets.publishing.service.gov.uk)

What happened: the familiar failure is excessive agency

There is no single incident being reconstructed here. This is a design postmortem of a common failure pattern.

An organisation deploys an operations agent to investigate service tickets. It can read monitoring data, inspect cloud resources and update tickets. To avoid integration friction, the agent receives a long-lived API key or broad cloud role. It can also call a general-purpose shell, automation platform or Model Context Protocol (MCP) server. A ticket, document or tool response contains hostile instructions disguised as operational context. The model follows them, or is persuaded to retrieve more information than the task requires. The tools do exactly what their credentials allow.

The language model has not “broken” access control. The surrounding system has granted authority without enough boundaries. OWASP’s agentic-application guidance separates related risks including goal hijack, tool misuse, identity and privilege abuse, memory/context poisoning and insecure inter-agent protocols. That is more useful than treating prompt injection as the whole problem. (genai.owasp.org)

A representative timeline of how an agent failure unfolds

1. Delegation: a user asks the agent to resolve an operational problem, but the request isn’t converted into a clear, constrained job definition.
2. Context ingestion: the agent reads tickets, files, webpages or tool output. Some of that content is untrusted, even when it comes from an internal system.
3. Authority expansion: a broad token, service role or inherited user session gives the agent options well beyond the immediate task.
4. Tool execution: the agent selects an action. The receiving API confirms that a token exists, but not whether this particular agent run should perform this exact operation now.
5. Late detection: logs show API calls, perhaps, but can’t reliably connect an action to the initiating user, agent version, prompt/context, policy decision and approval state.

Zero Trust changes the third and fourth steps. It doesn’t require perfect model reasoning. It assumes model reasoning can be wrong, manipulated or simply too eager to receive unconstrained access.

Root cause: an agent is not one identity

Early designs often collapse several identities into one. “The agent” becomes a single application registration with broad permissions. That hides the question a resource server actually needs answered: which running workload, acting for whom, under which approved task, is requesting which action on which resource?

A workable identity record should carry at least these separate facts:

• Agent workload identity: the deployed service, environment, version and runtime instance making the request.
• Delegator identity: the employee, customer, scheduled process or upstream service that initiated the work.
• Task identity: a short-lived job or case reference with a defined purpose, expiry and risk classification.
• Authority identity: the policy or approval that permits the requested action.
• Resource identity: the named system, tenant, dataset, mailbox, subscription or other target.

This isn’t pedantry. OAuth token exchange distinguishes delegation, where an actor retains its own identity while acting for another principal, from impersonation, where it becomes indistinguishable from that principal in the authorised context. For agent systems, delegation is usually the safer and more auditable default. (datatracker.ietf.org)

Authenticate the workload, not just the human

A human sign-in is not proof that a particular production workload is entitled to act. The agent runtime should obtain a cryptographic workload identity after the platform has attested what it is: for example, its Kubernetes service account, workload image, deployment namespace and environment. NIST’s cloud-native Zero Trust guidance specifically points to application identities, API gateways and service proxies as ways to enforce granular policy independently of location. (csrc.nist.gov)

SPIFFE/SPIRE is one established implementation pattern, not a compulsory choice. Its workload identities can be represented by short-lived X.509 certificates or JWT-based identity documents, allowing services to authenticate one another without embedding a shared secret in every deployment. (spiffe.io)

Whatever technology is chosen, don’t leave a permanent API key in an environment variable. Use short-lived credentials, rotate them automatically and bind them to the recipient where possible. The IETF’s current OAuth security best practice recommends sender-constrained tokens, such as mutual TLS or DPoP, to reduce the usefulness of a stolen bearer token. (datatracker.ietf.org)

The practical architecture: enforce at the tool boundary

The model should decide what it wants to attempt. It should not have the final say on whether the action is allowed. Put a policy enforcement point between the orchestration layer and every consequential tool: an API gateway, service-mesh proxy, broker, dedicated tool gateway or equivalent control point.

Before a tool call proceeds, that enforcement point should obtain or evaluate a decision against a policy engine. The decision needs more than an allow/deny rule based on an agent name. At minimum, evaluate:

• The authenticated workload and deployed version;
• The delegating user or originating service;
• The task’s stated purpose and expiry;
• The tool, operation and specific resource requested;
• Data classification and destination, including egress risk;
• The requested parameters, especially destructive or externally visible ones;
• Approval state, change window and relevant operational context.

This is where least privilege becomes real. “The support agent may use Salesforce” is not a permission model. A useful rule is closer to: “this production support-agent workload may read the minimum customer fields required for ticket INC-4821; it may add an internal note; it may not export lists, alter account ownership, disclose payment data or contact a customer without an approved template and human confirmation.”

Use a tool catalogue instead of allowing arbitrary URLs, plugins or command strings. Each approved tool should have an owner, data classification, explicit input and output schemas, an allowed network destination, a risk tier and a list of allowed operations. Where a tool can execute code or administer infrastructure, separate harmless inspection from mutation. Read-only access isn’t risk-free, but it is far easier to introduce and govern than write access.

MCP deserves the same caution as any integration layer. Its current authorisation specification supports OAuth-based access for HTTP transports and says clients should request only necessary scopes; it also requires resource indicators so tokens are issued for a specific target server. (modelcontextprotocol.io) Useful plumbing, but not an automatic security outcome. The organisation still has to decide what the MCP server exposes, which scopes are genuinely minimal, and whether an agent should invoke a particular tool at all.

Impact: constrain actions, not only data

Security teams often start with data access. Sensible, but incomplete. An agent’s operational impact may come from its ability to create objects, change settings, initiate communications or trigger downstream workflows. A read-only cloud inventory agent can expose sensitive architecture; a write-enabled agent can switch off logging, alter routing or create persistence. They need different controls.

A useful division is:

• Low impact: bounded retrieval from approved sources, with rate limits and output controls.
• Medium impact: creating draft records or internal tickets, subject to schema validation and clear provenance.
• High impact: changing production infrastructure, moving money, changing identities or permissions, sending external communications, deleting data, or running arbitrary code.

High-impact actions should require step-up controls: separate human approval, a change record, a second policy check immediately before execution, or a purpose-built workflow that limits possible parameters. A chatbot-style “Are you sure?” generated in the same conversation is not independent approval. Use a trusted user interface that shows the actual target, intended change, affected scope and consequence.

Detection and response: build the evidence before the incident

An agent audit trail needs to explain a chain of authority, not merely list API calls. Record the agent and workload identity, software version, delegator, task ID, policy version, tool selected, requested and final parameters, decision outcome, approval reference, resource identifiers, data classification and result. Protect those records from alteration and make sure they can be joined through a correlation ID.

Don’t reflexively log full prompts, retrieved documents or model outputs. They may contain customer data, credentials or sensitive business material. Capture cryptographic references, classifications and carefully designed redacted excerpts where that is enough for investigation. Retain more detailed evidence only where there is a defensible need and suitable protection.

Detection should watch for shifts in authority as well as familiar security signals: an agent calling a new tool, requesting a new scope, making unusual cross-tenant queries, generating unexpected egress volume, repeatedly failing policy checks, or acting outside its usual time and change window. NCSC guidance for secure AI deployment calls for access controls around APIs, models and data, incident procedures, testing before release and high-quality audit logs. (ncsc.gov.uk)

Response must be able to stop a live agent run. Provide a kill switch that revokes task tokens, blocks the workload identity at the gateway and pauses queued work. Disabling the user account alone may not halt a process holding a separate service credential. Test this under pressure, including whether queued jobs, delegated tokens and third-party tool sessions actually terminate.

Lessons learned: treat agent-to-agent traffic as an external boundary

Multi-agent designs can be useful, but they multiply trust edges. A planner agent handing work to a specialist agent is no reason to relax access controls; it is a reason to preserve the delegation chain. Each receiving agent should authenticate the caller, validate the task and audience, apply its own policy and receive only the authority it needs for its own step.

Set limits on delegation depth and prohibit silent privilege escalation. A research agent may ask a finance agent for a cost estimate; it should not be able to make the finance agent approve a purchase merely because both belong to the same orchestration. Don’t allow one agent’s free-form output to become another agent’s executable instruction, either. Pass structured fields, provenance labels and bounded schemas wherever possible.

All content that can influence an agent is untrusted input until it has been handled according to its origin and purpose. That includes documents retrieved from internal stores, issue descriptions, email attachments, tool error messages and other agents’ summaries. Internal provenance may increase confidence in authenticity; it doesn’t turn data into policy.

What organisations should change first

Don’t begin by attempting an enterprise-wide agent platform. Start with one narrow workflow that has a clear owner, a limited dataset and an obvious safe fallback to a person.

1. Inventory the existing authority. List every agent, model host, orchestrator, tool, MCP server, service account, API key, data source and external destination. Broad inherited permissions are the first things to remove.
2. Build a read-only pilot. Give the agent a single task, named data sources and no general shell or administrative capability. Prove that workload identity, task identity and audit correlation work before adding write operations.
3. Introduce a central tool gateway. Run it initially in observation mode if necessary, then deny undeclared tools and actions. This is usually more valuable than spending months tuning a model-side guardrail.
4. Issue just-in-time authority. Tie short-lived credentials to a single tool, resource audience, task and operation. Expiry should match the useful life of the job, not the convenience of the platform team.
5. Test hostile context and bad outcomes. Red-team prompt injection through documents and tool responses; try stolen tokens, replay, confused-deputy paths, unsafe parameter changes, cross-tenant access and approval bypasses.
6. Make rollback routine. Rehearse revocation, queued-job cancellation, evidence collection and recovery from an agent that has made a valid but damaging authorised change.

Zero Trust doesn’t make autonomous systems safe by decree. It makes their authority explicit, narrow and reviewable. That turns an agent from a vaguely trusted operator into what it should be: a constrained software workload whose actions are permitted only when the surrounding system can justify them.