Zero Trust for AI Agents

Zero trust for AI agents means no agent, session, tool call, data request, or handoff receives access because it came from a trusted network, approved application, known user, or previously authenticated session. Trusted systems verify the request against current identity, task, policy, resource, data, runtime posture, and risk, then enforce the decision before access.

This fits agents because their behavior can change during a run. An agent may read an untrusted document, choose a new tool, receive broader data, write Memory, start a subagent, or continue after the user’s original intent is no longer clear. A valid login at the start does not settle whether the fifth tool call is allowed.

Zero trust turns every material step into a resource access decision. The model may propose an action and explain why, but it does not approve its own access.

TL;DR

A practical zero trust program for AI agents should:

• Inventory every agent, owner, user, workload, tool, data source, destination, and persistent store.
• Define protected resources at the API, action, field, file, context, Skill, Memory, and output level.
• Give each agent and workload a distinct identity.
• Preserve the identity of the user or workflow that delegated the task.
• Treat the user’s authority as a ceiling, not an automatic grant.
• Issue short-lived, task-bound access for one action, resource, tenant, and environment.
• Remove trust based only on network location, device ownership, agent approval, or session age.
• Check context source, authority, freshness, integrity, and sensitivity before it shapes a decision.
• Treat retrieved text, web pages, email, tool results, and Memory as data, not permission.
• Enforce decisions outside the model at boundaries it cannot bypass.
• Keep raw credentials out of prompts, model context, generated code, and logs.
• Recheck access when tools, data, destination, risk, posture, or delegated authority changes.
• Narrow authority at every agent-to-agent handoff.
• Monitor sequences and cumulative effects, not only isolated calls.
• Revoke credentials, routes, sessions, and tool access when trust signals fail.
• Record the decision, enforcement, effect, and exact policy context for each material action.
• Test bypass, stale policy, prompt injection, confused delegation, and failure modes.

The operating test is direct: if the agent follows a harmful instruction while holding a valid session, can trusted infrastructure still stop the harmful effect?

What Zero Trust for AI Agents Means

Zero trust is a resource-centered security model. It does not grant broad confidence to a subject because that subject is inside a network, runs on a managed device, belongs to the company, or passed one authentication check.

NIST SP 800-207 describes zero trust as a shift from static network perimeters toward users, assets, and resources. Its tenets include protecting resources individually, securing all communication, granting access per session, using dynamic policy, monitoring asset posture, enforcing authentication and authorization before access, and collecting telemetry to improve policy.

For AI agents, the subject is rarely one identity. A request can involve:

• The human or workflow that started the task
• The agent definition and version
• The workload or runtime executing the agent
• The model and tool client
• A service account or delegated credential
• A parent agent and one or more subagents

The resource is also more specific than a system name. It can be one API action, database field, file path, browser profile, credential reference, Skill package, Memory version, message recipient, deployment environment, or amount of money.

A zero trust decision evaluates that full relationship at the time of access.

Why Agents Need More Than Session-Start Trust

Traditional applications often follow a predictable path after login. Agents can choose their next step based on natural-language input and tool results, so their effective risk changes as they work.

Untrusted content can change the plan

An agent may read a web page, issue, document, email, log, image, or tool result that contains instructions. The text can steer the agent toward another resource while looking like task data.

Prompt guidance can tell the agent to ignore untrusted instructions, but a zero trust design assumes the model may still propose a bad request. The resource boundary checks the action independently.

Valid tools can create invalid effects

An approved email tool does not make every recipient safe. A production deployment tool does not make every change authorized. A database tool can return the wrong tenant even when the query is syntactically valid.

Tool approval is one policy input. The exact action, resource, parameters, purpose, data, destination, and current conditions still need a decision.

Authority can grow through composition

One agent may have file access, another may have network access, and a third may have a messaging tool. Passing full context among them can create an exfiltration path that no single agent has alone.

Zero trust checks every handoff and prevents the workflow from silently combining authority.

Persistent state changes later sessions

Memory, caches, workspaces, browser profiles, logs, and generated artifacts can survive a task. A later session may inherit data or instructions from a different user, tenant, purpose, or trust level.

Persistence is a resource boundary. Reads and writes need identity, scope, version, retention, and integrity checks.

Long runs outlive their original conditions

A user may lose access, a deploy freeze may begin, an incident may raise the risk level, a tool version may change, or a destination may become blocked while an agent is still working.

An access token issued at session start cannot account for every later change. Long-running work needs reauthorization and revocation.

Map the NIST Tenets to Agent Work

The zero trust tenets translate cleanly when resources and requests are defined at agent granularity.

Zero trust tenet	Agent implementation
Treat data and services as resources	Protect tools, actions, fields, files, context, Skills, Memory, credentials, outputs, and destinations
Secure communication	Authenticate and encrypt user-to-agent, agent-to-tool, agent-to-agent, and policy traffic
Grant access per session	Issue narrow grants for one task, action, resource, tenant, and time window
Use dynamic policy	Check identity, purpose, data, context, posture, approvals, prior actions, and current risk
Monitor asset integrity	Measure agent version, tool schema, runtime image, sandbox, device, dependency, and policy state
Authenticate and authorize before access	Verify every material tool call, data request, Memory operation, and handoff
Collect telemetry	Record requests, decisions, enforcement, effects, context versions, and changing risk signals

The table is a starting point, not a product checklist. Each workflow still needs a threat model and resource map because a coding agent, support agent, finance agent, and browser agent cross different boundaries.

Define the Protected Resources

Zero trust programs fail when the resource is defined too broadly. “Database access” or “use the support system” leaves most of the decision unstated.

For one workflow, inventory resources at the level policy can enforce:

• Agent invocation and configuration
• Model endpoint and processing region
• Context Alignment and version
• Skill package and version
• Memory and exact version
• Tool and tool action
• MCP server, method, and schema
• API resource, tenant, row, and field
• File path and operation
• Network destination, protocol, method, and payload
• Credential reference and allowed use
• Browser profile, site, account, and action
• Message recipient, channel, and attachment
• Deployment target and environment
• Transaction account, amount, and approval
• Logs, traces, and evaluation records

Then classify each resource by owner, sensitivity, business purpose, permitted subjects, required posture, approval rule, retention, and audit need.

The NIST zero trust implementation guidance starts with discovery and inventory, then recommends resource-specific policies based on mission, least privilege, and separation of duties. The same order prevents teams from writing generic “agent access” rules before they know what agents can reach.

Build a Verifiable Identity Chain

An agent request should carry more than a user token.

A useful identity chain includes:

1. Human, service, or workflow principal
2. Agent ID and approved version
3. Session and task ID
4. Workload and runtime identity
5. Tool client and tool server identity
6. Credential or authorization artifact
7. Parent agent when delegation occurred

Each link answers a different question. The user identity says whose authority sets the ceiling. The agent identity says which governed actor is working. The workload identity says which runtime is making the connection. The session and task bind the request to one purpose.

AI agent identity management should give every active agent a human Owner, a defined purpose, a lifecycle state, and an audit trail. Do not use one shared service account as the only identity for a fleet.

Separate identity from credentials

An API key or token proves possession of a secret. It does not explain the agent, task, user, purpose, or permitted effect.

Keep raw credentials in trusted brokers. The agent requests a capability by reference, and the broker checks current policy before applying or issuing a short-lived credential outside model context.

This lets credentials rotate without changing agent identity and lets a security team revoke one agent or task without breaking every workflow that uses the integration.

Bind Access to One Task

The effective grant should be the intersection of several limits:

• What the delegated user may do
• What the agent is approved to do
• What the workflow permits
• What the current task needs
• What the resource owner allows
• What the data classification allows
• What the environment permits
• What the approval covers
• What current risk and posture allow

If any required condition denies access, the request stops or narrows.

A task-bound grant should name the agent, user, workload, action, resource, tenant, purpose, environment, limits, expiry, and policy version. For a high-impact action, bind any human approval to the same normalized request.

Avoid ambient authority. A coding agent working on one repository does not need a home-directory credential store, every organization repository, or standing production access. A support agent answering one ticket does not need a full customer export.

AI agent authorization turns these attributes into a runtime decision. Zero trust adds the operating discipline of making that decision continuously, feeding it current signals, and enforcing it near the resource.

Treat Context as a Trust Signal, Not Authority

Context shapes what an agent requests. It can include system instructions, AGENTS.md guidance, Skills, retrieved documents, tool results, user messages, conversation history, and Memory.

Zero trust asks four questions about each context item:

1. Where did it come from?
2. Who controls it?
3. How current and intact is it?
4. What authority should it have?

Published company policy may carry high authority. A web page or issue description may provide task data but no authority. A Memory entry may contain useful working recall, but it cannot grant a permission or override current policy.

Separate instructions from data

Mark source and trust level when content enters the session. Keep trusted policy separate from retrieved or user-controlled text. Reject tool requests that rely on an untrusted instruction to expand access.

The OWASP AI Agent Security Cheat Sheet recommends treating external data as untrusted, scoping tools by least privilege, validating Memory before persistence, filtering outputs, and testing prompt override, tool misuse, privilege escalation, data exfiltration, and multi-agent chains.

Recheck after context changes

New context can change the risk of the next action. Reevaluate after retrieval, a tool result, an agent handoff, a Memory read, or a long-session compaction when the next step affects a protected resource.

Do not trust a policy summary when the complete required policy was dropped during compaction. Protected guidance should have an independent version and delivery record so the runtime can check that the session still has the required input.

Govern context delivery independently

Repository permission and route are different controls. Permission governs who may discover, read, or change an Alignment, Skill, or Memory. Independent Included and Required routes govern which Resources enter an agent’s bundle.

A route does not grant repository access, and repository access does not create a route. A zero trust decision should evaluate both the management rights around a Resource and the delivery state that shaped the session.

Enforce Policy Outside the Model

The model may suggest an action. A trusted policy decision point evaluates it, and a policy enforcement point applies the result.

NIST’s zero trust reference architecture separates the policy engine, policy administrator, and policy enforcement point. The policy engine decides whether to grant, deny, or revoke access. The policy administrator carries out that decision, while the enforcement point guards the resource and enables, monitors, or terminates the connection.

For agents, the flow can be:

1. The model proposes a typed tool request.
2. A trusted interceptor validates the schema and normalizes the action.
3. Identity services verify the user, agent, workload, session, and delegation chain.
4. Policy loads trusted facts about the task, resource, data, context, posture, approval, and risk.
5. The decision point returns allow, deny, narrow, transform, require approval, quarantine, or terminate.
6. The enforcement point applies the decision at the resource boundary.
7. A brokered executor performs only the allowed operation.
8. The result is checked before it returns to the model or another system.
9. Audit records connect the request, decision, enforcement, effect, and policy context.

Natural language alone is not a policy request. Convert proposed effects into typed fields such as action, resource, tenant, data class, recipient, environment, amount, purpose, and limits.

Put Enforcement at Every Relevant Boundary

No single gateway sees every agent effect. Use several enforcement points with a shared decision model and consistent identities.

Tool and MCP gateways

Validate tool source, identity, version, schema, action, parameters, caller, and result. Prefer narrow tools with structured parameters over unrestricted shell, SQL, browser, or HTTP access.

Pin tool definitions when a schema change could add authority. Reauthorize when a tool or MCP server changes, even if its name stays the same.

APIs and data services

Enforce tenant, resource, row, field, purpose, and rate limits in the protected service. A central policy layer can advise, but the data service should reject an out-of-scope request itself.

File and code brokers

Control path, repository, operation, branch, remote, data class, and export. Prevent symlink and path traversal bypasses. Scan generated artifacts and diffs before they leave a task workspace.

Network proxies

Control destination, port, protocol, DNS, redirects, method, headers, and payload. Re-resolve and recheck after redirects. Block internal metadata services and arbitrary outbound access unless the task needs them.

Sandbox supervisors

Verify the runtime image, operating-system identity, mounts, process rights, resource limits, installed packages, and network policy. A managed laptop does not make generated code trustworthy.

AI agent sandboxing contains mistakes and attacks after the access decision. Zero trust determines which connections and resources the sandbox may receive.

Credential brokers

Check the exact action before resolving a secret reference or issuing a token. Bind the credential to agent, task, tool, resource, action, tenant, and short time window. Keep the raw value away from the model.

Messaging and browser services

Validate recipient, account, channel, destination, attachment, data class, and approval immediately before an external effect. Treat drafts and queued actions as effects when another system can already read or execute them.

Context and Memory services

Check Resource identity, version, permission, route, tenant, data class, retention, and integrity. Require Editor access and the exact latest version for a Memory write. Prevent remembered text from changing its own role, route, or authority.

Measure Runtime Posture

Zero trust evaluates the subject and the asset, not only the account. For agents, posture spans several layers:

• Agent definition and approved version
• Model and model endpoint
• Tool and MCP schema versions
• Workload identity and attestation
• Runtime image and patch state
• Sandbox policy and isolation state
• Device or host posture
• Dependency and plugin integrity
• Active credentials and token age
• Context, Skill, Memory, and policy versions
• Logging and enforcement health
• Current incident and threat signals

Define which posture signals are required for each resource. A low-risk internal search may tolerate a reduced signal set. A production deployment, customer export, or payment should require a verified runtime, current policy, complete audit path, and healthy enforcement points.

When posture degrades, narrow or end access. Do not merely alert after the action. A changed tool schema may disable that tool, an expired policy may block the workflow, and a compromised runtime may terminate its credentials and sessions.

NIST SP 800-207A extends zero trust to cloud-native applications through application and service identities, API gateways, proxies, and identity infrastructure. That model fits agents because tool and service identity matters alongside user and network identity.

Reauthorize During the Session

Continuous verification does not mean asking a person to log in before every token. It means the system keeps checking the conditions that made access valid.

Reauthorize when:

• The agent requests a new resource or action
• The task purpose or scope changes
• A tool or schema changes
• Sensitive data enters the session
• The destination changes
• A human approval expires or parameters change
• The agent delegates work
• A Memory read or write occurs
• The runtime, device, or sandbox posture changes
• Risk signals cross a threshold
• The user, agent, or Resource role changes
• A long session reaches a time or action limit

Use short-lived authorization artifacts so stale decisions expire. Add replay protection for approvals and high-impact actions.

Session monitoring should track cumulative effects. Ten allowed reads followed by one upload can be more dangerous than any call alone. Rate, amount, row, destination, and spend limits should apply across the task.

Narrow Trust Across Agent Handoffs

Every agent-to-agent message crosses a trust boundary, even when both agents belong to the same team.

The parent should pass:

• A narrow task statement
• The minimum data needed
• Source and trust metadata
• Allowed tools and resources
• Prohibited effects
• Data handling and retention rules
• Approval requirements
• Time and resource limits
• Correlation and audit IDs

The child agent gets a new identity and grant. It should not inherit the parent’s full context, credentials, tools, or authority.

Authenticate both sides and bind the response to the task. Treat the child output as untrusted input until the parent or a trusted service validates its source, schema, data class, and permitted use.

Limit delegation depth, fan-out, retries, tokens, time, and spend. Terminate descendants when the parent task is revoked.

Protect Data With Zero Trust

Zero trust applies to data access and movement, not only connections.

Classify data before it enters context. Filter rows and fields at the source. Carry classification and lineage through summaries, files, Memory, tool calls, and handoffs.

An outbound decision should check:

• Data source and classification
• Agent, user, task, and purpose
• Transformation and derived sensitivity
• Destination and recipient
• Channel and retention
• Approval and policy version
• Prior reads and cumulative transfers

AI agent data loss prevention adds content, transformation, sequence, and destination controls to the zero trust request. It also covers encoded, split, summarized, and low-volume data movement that a connection-level rule can miss.

Minimize logs and traces. Telemetry is required for zero trust, but copying full prompts and tool results into a broad monitoring system creates another protected data store. Record structured decision metadata and redact sensitive payloads before logging.

Treat Memory as a Protected Resource

Memory carries working recall across sessions, which means its trust cannot come from the fact that an agent wrote it earlier.

For each Memory read, check:

• Agent and user identity
• Repository permission when the agent is discovering or reading it directly
• Included or Required route when it is delivered in the current bundle
• Company, tenant, project, and task scope
• Source, writer, and version
• Integrity, freshness, and expiry
• Data class and permitted purpose

For each write, also check Editor access, the exact latest version, source provenance, retention, and content policy. Keep credentials, raw source documents, full transcripts, and published instructions out of working Memory.

Retrieved Memory may inform the task, but it cannot authorize access, change a Required route, grant a Resource role, or override current policy. AI agent Memory governance covers poisoning, correction, deletion, and point-in-time evidence in more detail.

Design the Audit Record

A useful zero trust audit connects four layers:

1. Request
2. Decision
3. Enforcement
4. Effect

Record:

• User, agent, workload, session, task, and delegation chain
• Resource, action, tool, tenant, environment, and destination
• Data class, purpose, limits, and approval
• Context, Skill, Memory, and policy versions
• Runtime, tool, and device posture
• Risk signals and prior relevant actions
• Decision and required obligations
• Enforcement point and execution identity
• External effect and protected-system response
• Revocation, denial, quarantine, or recovery event
• Timestamp and correlation ID

An allow decision without proof of enforcement is incomplete. A tool log without the policy inputs cannot explain why the action was permitted. A transcript without the external effect cannot prove what changed.

Point-in-time agent audit should reconstruct the complete state, including what governed context reached the agent and which exact policy the enforcement point used.

Test Zero Trust as a Security Boundary

Test the architecture by trying to obtain an effect the agent should not have. Check the external system, not only the model response.

A practical test set includes:

• Use a valid session after the user loses access.
• Ask an approved agent to use a tool outside its purpose.
• Inject instructions through web content, email, documents, images, and tool results.
• Change a tool schema while keeping the same tool name.
• Reuse an expired credential or approval.
• Change action parameters after approval.
• Request another tenant’s row through a valid data tool.
• Escape a file path or task workspace.
• Follow DNS and redirect paths to a blocked destination.
• Write malicious or sensitive content into Memory, then retrieve it later.
• Pass full authority to a subagent.
• Combine several low-risk actions into a high-risk sequence.
• Disable a policy, logging, identity, or posture service.
• Continue a long session after policy, posture, or incident state changes.
• Replay a previously allowed request.
• Verify revocation reaches credentials, sessions, routes, tools, and descendants.

Expected outcomes should name the exact response: deny, narrow, redact, require approval, quarantine, revoke, or terminate. Save the fixture, policy, agent, tool, and context versions so failures can be reproduced.

Common Zero Trust Mistakes

Trusting an approved agent

Approval means the agent may operate under defined conditions. It does not make every future action trustworthy.

Checking only the user

The user sets an authority ceiling. The agent, workload, task, resource, and current conditions narrow it.

Making the network the boundary

An internal network can carry a compromised agent, poisoned tool, stale credential, or wrong-tenant request. Protect resources through identity and policy regardless of location.

Writing policy only in the prompt

Instructions help the model propose better actions. They do not stop a valid credential or tool from carrying out a bad request.

Issuing broad session tokens

Long-lived, multi-resource credentials preserve authority after the task, user, posture, or policy changes. Use short-lived, audience-bound, task-bound grants.

Treating telemetry as enforcement

Detection after the action is useful for response, but it is not an access decision. High-risk resources need a policy enforcement point that can block or terminate.

Ignoring context and Memory

An agent can stay inside its tool allowlist and still act from poisoned, stale, over-shared, or wrong-tenant context. Context and persistent state belong in the trust model.

Roll Out Zero Trust for AI Agents in Stages

Start with agents that can both reach sensitive resources and create external or durable effects.

Stage 1: Discover

1. Inventory agents, owners, users, workloads, tools, Resources, data, credentials, destinations, and persistent stores.
2. Map the identity and delegation chain for each high-risk workflow.
3. Find shared accounts, standing credentials, unrestricted tools, and arbitrary egress.
4. Record current policy, enforcement, and audit gaps.

Stage 2: Contain

1. Give agents and workloads distinct identities.
2. Remove unused tools and broad credentials.
3. Isolate task runtimes and block unneeded network access.
4. Put approvals before irreversible and externally visible actions.
5. Add emergency revocation and termination.

Stage 3: Verify

1. Turn proposed effects into typed resource requests.
2. Evaluate agent, user, task, data, context, posture, approval, and risk.
3. Issue short-lived grants and enforce them near the resource.
4. Reauthorize when material conditions change.
5. Correlate sequences and cumulative effects.

Stage 4: Prove

1. Connect requests, decisions, enforcement, effects, and point-in-time context.
2. Run repeatable bypass and failure tests.
3. Measure unprotected resources, stale grants, missing identity chains, and revocation time.
4. Fix source policy or architecture after every finding.

CISA’s Zero Trust Maturity Model organizes progress across identity, devices, networks, applications and workloads, and data, with visibility, analytics, automation, orchestration, and governance across the pillars. Agent programs can use the same structure while adding agent context, tools, Memory, delegation, and model-driven action to each pillar.

How Alignbase Fits

Alignbase is an AI context control plane. It governs the organizational context, Skills, and short-term working Memory that form part of an agent’s policy and operating state.

Teams can use Alignbase to:

• Publish reviewed AGENTS.md guidance and security policy.
• Govern Skill packages that define approved workflows.
• Control repository access to Alignments, Skills, and Memories through Resource roles.
• Route each Resource independently as Included or Required for agents and Groups.
• Keep version history and ownership for governed inputs.
• Require exact-version writes to Memory.
• Record which Alignment, Skill, and Memory versions reached an agent at a point in time.
• Replace stale policy or working recall without editing every agent setup.

Alignbase does not authenticate workloads, attest runtimes, issue resource tokens, enforce API permissions, inspect network traffic, broker credentials, classify tool payloads, or terminate a process. Identity, authorization, runtime, data, network, and credential systems still protect those resources.

The connection is the policy context. A runtime decision can reference the exact governed inputs the agent received, while Alignbase can prove their versions and delivery. That evidence helps teams answer both what the agent was told and what protected systems allowed.

Zero trust for AI agents works when every material action reaches an enforcement point that knows the actor, task, resource, context, posture, and current risk. Start with one high-risk workflow, remove ambient authority, and make each grant narrow enough to explain and revoke.