Zero Trust for AI agents is not “put the chatbot behind SSO.”

That is the login layer. It proves that a user reached the application. It does not prove that the agent should retrieve a specific source, call a specific tool, write a specific field, reuse a memory, send an external message, or act through a particular service account.

The hard enterprise question is narrower and more important:

How should an AI agent receive just enough delegated authority to complete one task, through one governed tool path, with evidence that can be audited later?

My answer: treat the agent as a separate workload identity acting under a session-bound delegation from a human, then force every retrieval, tool call, memory write, and workflow action through a policy enforcement point. The model can propose. The orchestrator can prepare context. The broker can execute. Authorization must remain outside the model.

This extends the broader control-plane model in AI governance architecture, the runtime authorization pattern in policy-as-code for enterprise AI agents, the execution catalog in safe tool registries for enterprise AI agents, the abuse-case workflow in threat modeling enterprise AI agents, and the evidence model in audit logs for enterprise AI agents. This article is specifically about identity and delegation. It is where Zero Trust becomes an AI agent runtime design, not a slogan.

Key takeaways

• AI agents should not inherit broad human OAuth tokens or run under shared service accounts with more authority than the task requires.
• A production agent needs at least four identities in the decision path: human user, AI application, agent workload, and downstream tool or resource.
• Zero Trust for AI agents means continuous, per-action authorization across retrieval, tool execution, output release, memory writes, approvals, and incident modes.
• The model should never decide whether it is authorized. Model output is a request for authorization, not authorization itself.
• The most useful artifact is an agent delegation envelope: who delegated authority, to which agent, for which task, tool, resource, data class, workflow state, risk tier, time window, and audit trace.
• Least privilege has to be narrower than “the user can do it.” The AI agent may be allowed to draft, propose, or read a filtered subset even when the human has broader rights.

Citation-ready answer

Zero Trust for enterprise AI agents is an architecture where each agent action is authorized explicitly using human identity, agent identity, workload identity, resource attributes, tool risk, data classification, workflow state, approval status, and audit requirements. The agent should receive short-lived, scoped, session-bound delegation through a broker or policy enforcement point, not a broad user token or shared service account. The model may propose actions, but deterministic identity, policy, tool registry, approval, and audit layers decide what can execute.

Start with the identity chain

Traditional application access usually asks:

1

Can this user access this application?

AI agents require a longer chain:

1
2
3
4
5
6
7

human user
  -> AI application
  -> agent workload
  -> policy enforcement point
  -> tool broker
  -> downstream resource
  -> audit trail

Each element has a different security meaning.

NIST SP 800-207 on Zero Trust Architecture is useful because it moves the trust decision away from network location and toward subjects, assets, resources, and explicit authorization. For AI agents, the same idea has to move one level deeper: do not trust a tool call because it came from an authenticated chat session.

The wrong pattern: user token passthrough

The fastest prototype often uses the user’s token directly:

1
2
3

user signs in
  -> agent receives user's OAuth token
  -> agent calls search, CRM, ticketing, email, file storage, code, or cloud APIs

That pattern is convenient and dangerous.

It creates four problems:

1. The agent can silently exercise more authority than the task needs.
2. Downstream systems may see only the human user, not the AI agent that chose the action.
3. Audit logs cannot cleanly distinguish human intent, model proposal, policy decision, and tool execution.
4. Prompt injection can become a confused deputy problem: hostile content manipulates the agent into using a valid user credential for the wrong purpose.

The safer pattern is brokered delegation:

1
2
3
4
5
6

user session
  -> agent request envelope
  -> policy decision
  -> short-lived scoped delegation
  -> brokered tool execution
  -> structured audit event

The agent should receive a task-scoped authorization, not a reusable master key.

A practical delegation envelope

The core artifact is a delegation envelope. It is the structured request the agent runtime sends before the tool broker executes anything privileged.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

{
  "trace_id": "trace_2026_08_21_001",
  "human": {
    "user_id": "alice@example.com",
    "roles": ["support_manager"],
    "auth_strength": "mfa",
    "department": "customer_ops"
  },
  "agent": {
    "app_id": "support_copilot",
    "agent_id": "support_resolution_agent",
    "version": "2026.08.21",
    "risk_tier": "tier_3_customer_visible"
  },
  "task": {
    "purpose": "resolve_support_case",
    "case_id": "case_123",
    "workflow_state": "pending_customer_reply"
  },
  "action": {
    "type": "tool_call",
    "tool_id": "crm.update_case_status",
    "operation": "write",
    "arguments_hash": "sha256:..."
  },
  "resource": {
    "system": "crm",
    "record_id": "crm_case_123",
    "tenant": "eu",
    "data_classes": ["customer_pii", "commercial_confidential"],
    "owner_team": "customer_ops"
  },
  "constraints": {
    "expires_in_seconds": 300,
    "max_invocations": 1,
    "requires_approval": true,
    "approval_id": "appr_456",
    "external_send_allowed": false
  }
}

This envelope is not a log-only object. It should be the input to policy. If the policy engine cannot evaluate a field, either the field is useless or the enforcement architecture is incomplete.

Token design for agents

There is no single universal token pattern for every enterprise stack. The design principle is stable: separate human authentication from agent delegation and downstream execution.

RFC 8693 on OAuth 2.0 Token Exchange is relevant because it defines a standard way for a security token service to exchange tokens and express delegation or impersonation semantics. SPIFFE is relevant on the workload side because it gives distributed systems a way to assign cryptographic identity to software workloads rather than relying on location or static secrets.

Use the standards and identity platform that fit your environment, but keep the semantics explicit.

Do not let the model see bearer tokens. Do not put credentials in prompts, retrieved context, tool descriptions, or agent memory. The agent can request an action. The broker owns credentials.

Where Zero Trust enforcement belongs

One policy check at chat startup is not enough. Agent authority changes as the task moves from text to retrieval to action.

The OWASP AI Agent Security Cheat Sheet calls out least privilege, tool authorization, input validation, memory isolation, human oversight, monitoring, and adversarial testing. The engineering translation is direct: every one of those controls needs a runtime boundary where it can stop an action.

Least privilege for AI agents is not human least privilege

The common mistake is to ask, “Can the user do this?”

For AI agents, ask four questions instead:

1. Can the human do this?
2. Can this agent do this?
3. Can this agent do it for this task, state, data class, and resource?
4. Can it execute, or may it only propose?

That last question matters. A senior employee may be allowed to send customer emails. The AI assistant may be allowed to draft one, attach evidence, and request approval. It does not follow that the assistant should be allowed to send it directly.

This matrix complements human-in-the-loop approval patterns for high-risk AI workflows: approval should not be a generic “are you sure?” popup. It should be bound to identity, action, resource, evidence, and expiry.

The reference architecture

A practical Zero Trust agent architecture looks like this:

1
2
3
4
5
6
7
8
9
10

1. User authenticates through enterprise IdP.
2. AI application creates a session with user attributes and purpose.
3. Agent runtime runs under its own workload identity.
4. Agent produces a structured action proposal.
5. Policy enforcement point intercepts retrieval, memory, tool, and output requests.
6. Policy decision point evaluates the delegation envelope.
7. Approval workflow supplies bounded approval when risk requires it.
8. Tool broker executes with scoped credentials.
9. Audit logger records the full decision chain.
10. Incident mode can reduce or revoke agent authority centrally.

Notice what is missing: no direct model-to-API credential path.

The broker pattern can feel slower than giving the agent a broad connector. In practice, it is what lets an enterprise scale agent use beyond demos. It gives IAM, security, platform, and business owners a place to enforce decisions without rewriting every agent.

Failure modes to design out

Zero Trust is useful only if it changes failure behavior.

The NCSC Guidelines for secure AI system development are useful here because they place secure design, deployment, operation, logging, monitoring, and incident management across the AI system lifecycle. Zero Trust for agents should be part of that lifecycle, not a last-minute gateway.

What to log

Agent identity architecture is incomplete without audit evidence.

A high-risk tool call should produce one correlated trace:

Do not log raw sensitive data by default. Log enough structured metadata to reconstruct authority, not enough secrets to create a second breach.

The NIST AI Risk Management Framework is helpful as a governance reference, but the practical implementation question is simple: can your team reconstruct who delegated what to which agent, under which policy, against which resource, with which approval, and what happened afterward?

Production checklist

Before an enterprise AI agent receives tool authority, require this checklist:

• The AI application is registered with an owner, risk tier, supported workflows, and approved model routes.
• The agent workload has its own identity, version, deployment environment, and registry entry.
• Human identity and agent identity are both present in every authorization decision.
• The agent cannot receive or store broad user tokens, service-account keys, API keys, or refresh tokens.
• Tool execution goes through a broker or policy enforcement point.
• Delegation tokens are short-lived, scoped to a task, and bound to a resource or operation where possible.
• High-risk actions are proposal-only unless an approval artifact is present and valid.
• Retrieval uses ACLs, data classification, source authority, and purpose constraints.
• Memory writes are scoped, classified, and denied for restricted data classes.
• Audit logs capture policy decisions, denied attempts, approvals, and execution results.
• Incident mode can centrally revoke or reduce high-risk agent authority.
• Adversarial tests include prompt injection, unauthorized retrieval, tool overreach, approval bypass, token replay, and audit completeness.

If any item is missing, the agent may still be useful as a draft assistant. It should not be treated as a trusted business-process actor.

Common design mistakes

Treating SSO as Zero Trust

SSO answers who reached the app. It does not answer whether this agent, task, data class, tool, resource, and approval state are allowed now.

Using one service account per agent platform

That hides which agent acted and makes least privilege nearly impossible. Use workload identity, agent registry metadata, and scoped downstream credentials.

Letting prompts describe permissions

Prompt instructions are useful for behavior. They are not authorization controls. Permissions must be evaluated by code that can deny execution.

Logging only successful tool calls

Denied retrieval and denied tool calls are security evidence. If you only log successful actions, you lose the signal that tells you whether controls are working.

Confusing proposal with execution

The best pattern for high-risk workflows is not “the agent cannot help.” It is “the agent can propose, prepare evidence, and route approval, but cannot execute directly.”

FAQ

Is Zero Trust for AI agents different from normal Zero Trust?

The principles are the same, but the enforcement points are different. AI agents add retrieval, prompt assembly, model output, tool selection, memory, approval, and output-release boundaries. Each boundary needs explicit authorization because language can influence access and action.

Should an AI agent use the user’s permissions?

It should use the user’s identity as one input, not blindly inherit all user permissions. The authorization decision should also include agent identity, task purpose, data classification, resource owner, workflow state, risk tier, approval state, and audit requirements.

Can a service account be safe for AI agents?

Yes, if it is scoped, brokered, short-lived where possible, mapped to a registered agent workload, and constrained by policy. A shared long-lived service account with broad access is not a safe agent identity model.

What is the first control to implement?

Put a policy enforcement point between the agent and every privileged tool. Even a simple broker that validates agent ID, user context, tool ID, risk tier, approval state, and resource scope is better than direct model-to-API execution.

Should agents ever execute high-risk actions automatically?

Only when the workflow is narrow, reversible or compensated, heavily tested, explicitly approved by owners, and covered by strong audit and incident controls. For IAM, payments, legal commitments, production changes, and customer-visible actions, proposal-first is usually the right default.

How does this connect to AI governance?

Governance becomes real when identity, ownership, policy, approval, and audit requirements are enforced in the runtime. Zero Trust is the identity and access architecture that prevents agent governance from staying trapped in documents and review meetings.

References

• NIST SP 800-207: Zero Trust Architecture
• OWASP AI Agent Security Cheat Sheet
• RFC 8693: OAuth 2.0 Token Exchange
• SPIFFE Overview
• NCSC Guidelines for secure AI system development
• NIST AI Risk Management Framework