Zero Trust Applied to AI Systems: NIST SP 800-207 maps onto agentic security if you squint right

Two communities talking past each other

In Christopher Nolan’s The Prestige, two rival magicians spend the whole film inventing identical tricks from opposite directions, each convinced the other stole his secrets. Neither realizes they built the same thing independently. That is the current state of AI security and network security.

The AI security community is building agent authorization from scratch. They are inventing concepts like “tool permissions,” “action scoping,” “context-aware access control,” and “runtime policy evaluation.” They are publishing papers, building frameworks, and holding conferences about how to control what autonomous agents can do.

Meanwhile, the network and identity security community has been solving this exact problem for a decade under a different name: Zero Trust Architecture (the security model that treats every request as untrusted regardless of where it originates).

Nobody in AI security has read NIST SP 800-207 (the federal Zero Trust architecture blueprint). Nobody in network security thinks it applies to AI. Both are wrong.

The mapping: ZTA concepts to agentic systems

NIST SP 800-207 (the federal Zero Trust architecture blueprint) defines Zero Trust Architecture (the security model that verifies every request regardless of network location) around a set of core concepts.¹ Every one of them has a direct analog in agentic AI systems.

Here is the full mapping:

Tenet 1: Never trust, always verify

The foundational Zero Trust Architecture (ZTA) principle: no entity gets implicit trust based on network location, prior authentication, or organizational membership. Every access request is evaluated independently.

Applied to agents:

No agent gets implicit trust based on who deployed it, what model powers it, or what it did last time. Every tool call is evaluated. Every action is authorized at the moment of execution, not at the start of the session.

flowchart LR
    subgraph perimeter["Perimeter Model"]
        A1([Session Start]) -->|Auth once| A2[/Agent Gets Tool Set/]
        A2 --> A3[Runs for hours]
        A3 --> A4{{No re-evaluation}}
    end
    subgraph zt["Zero Trust Model"]
        B1([Every Tool Call]) -->|Evaluate| B2{PDP: Check policy + context}
        B2 -->|Authorize| B3[PEP: Allow / Deny / Escalate]
        B3 --> B4[Execute or Block]
        B4 -->|Next call| B1
    end

Tenet 2: Least privilege for every action

Zero Trust Architecture (ZTA) requires that access is granted with the minimum privileges needed, for the minimum time required, to accomplish the specific task.

Applied to agents, this means:

• An agent authorized to “read customer records” does not automatically get “write customer records”
• An agent authorized to “send internal notifications” does not automatically get “send external emails”
• An agent authorized to “query the database” does not get persistent database credentials; it gets a scoped, time-limited token for each query
• An agent that needs elevated privileges for a specific action requests them at the moment of need, and those privileges expire when the action completes

Most agent frameworks today grant tools like permanent building access badges. Zero Trust Architecture (ZTA) says: give the agent a visitor pass for one room, one hour, one purpose. Every time.

The practical implication: tool access for agents should not be a static list in a configuration file. It should be a dynamic evaluation at every call. What is the agent trying to do? What does the user’s intent authorize? What does the agent’s role permit? What does the current context allow? The intersection of those answers is the authorized action set.

This is where DIRA (Dual-Intent Runtime Authorization – the framework that evaluates user intent and agent role together at every tool call) provides the concrete mechanism: authorized_action_set = f(user_intent) ∩ f(agent_role), evaluated at every tool call.²

Tenet 3: Continuous verification

Zero Trust Architecture (ZTA) does not end at the authentication event. It monitors continuously: is this session still legitimate? Has the context changed? Has the risk profile shifted?

In network Zero Trust Architecture (ZTA), this looks like:

• Device posture checks during the session
• Behavioral analytics on network activity
• Step-up authentication when risk signals change
• Session termination when anomalies exceed thresholds

In agentic AI, this maps to:

flowchart TB
    SESSION([Agent Session Active]) --> MONITOR[Behavioral Monitor]
    MONITOR -->|Check| BASELINE[(Behavioral Baseline)]
    MONITOR -->|Check| INTENT[/User Intent Alignment/]
    MONITOR -->|Check| CONTEXT[Context Signals]
    BASELINE -->|Drift detected| RESPONSE{Adaptive Response}
    INTENT -->|Misalignment| RESPONSE
    CONTEXT -->|Risk change| RESPONSE
    RESPONSE -->|Minor| RESTRICT[Reduce Privileges]
    RESPONSE -->|Moderate| ESCALATE[Escalate to Human]
    RESPONSE -->|Severe| TERMINATE[[Terminate Session]]

Behavioral drift detection: track the embedding distance between the agent’s recent actions and its established baseline. Agents accumulate subtle instruction drift across long sessions. The system prompt fades. Context injections shift the agent’s behavior incrementally. Each individual action looks authorized; the aggregate pattern deviates from what was intended.

Continuous verification catches this. Not by evaluating each action in isolation (that is the PDP’s job – the policy decision point that checks each request against current policy), but by evaluating the pattern of actions over time.

Tenet 4: Micro-segmentation as agent sandboxing

In network security, micro-segmentation means breaking the network into small, isolated zones with independent access controls. A compromised workstation in Zone A cannot reach the database server in Zone B, even though both are “inside the network.”

Applied to agents: each agent operates in a sandbox with access only to its authorized tools and data. Agents cannot reach tools outside their sandbox. A compromised or misbehaving agent cannot pivot to tools authorized for a different agent.

flowchart TB
    PDP{{Policy Decision Point}} --> AGENT_A & AGENT_B & AGENT_C

    subgraph sandA["Sandbox A"]
        AGENT_A([Research Agent]) --> TOOL_A1[Web Search]
        AGENT_A --> TOOL_A2[Document Reader]
    end
    subgraph sandB["Sandbox B"]
        AGENT_B([Action Agent]) --> TOOL_B1[Email API]
        AGENT_B --> TOOL_B2[Database Write]
    end
    subgraph sandC["Sandbox C"]
        AGENT_C([Admin Agent]) --> TOOL_C1[User Management]
        AGENT_C --> TOOL_C2[Config Editor]
    end
    AGENT_A -.->|Blocked| TOOL_B1
    AGENT_B -.->|Blocked| TOOL_C1

The research agent can search the web and read documents. It cannot send emails. The action agent can send emails and write to the database. It cannot manage users. The admin agent can manage users and configuration. It cannot search the web. Each sandbox is a micro-segment with an independently enforced boundary.

This is not optional. Multi-agent architectures without sandbox isolation are flat networks. And flat networks are the reason Zero Trust Architecture (ZTA) exists in the first place.

The identity problem: agents are not humans

Here is where the Zero Trust Architecture (ZTA) mapping gets interesting, and where most current thinking breaks down.

Zero Trust assumes subjects have identities that can be verified. In network security, subjects are users, devices, and workloads. They authenticate. They have credentials. They have attributes (role, department, clearance level) that inform authorization decisions.

Agents break this model in a specific way: an agent is not the same principal as the human who deployed it, even when it acts on that human’s behalf.

The human delegates intent to the agent. The agent executes within its role. But the agent is not the human. It has:

• A different context than the human (the agent has the conversation history; the human has organizational knowledge)
• A different capability set (the agent can call APIs at speed; the human can exercise judgment)
• A different failure mode (the agent hallucinates; the human gets fatigued)
• A different trust profile (the agent is a non-human identity that should be governed as such)

The AI agent authorization problem is an identity problem, not a prompting problem. The industry is trying to solve agent security through prompt engineering and output filtering. The real control point is authorization at action time, and that requires a new principal model.

This is the NHI (Non-Human Identity – the class of machine credentials, service accounts, and automated actors that operate without human users behind them) problem applied to AI. Most organizations already have 10 to 50 times more service accounts than human accounts, and no inventory, no lifecycle management, no governance.³ AI agents are the next NHI wave, and they arrive with the same gap: no identity model, no lifecycle, no governance framework that treats them as what they are.

The trust algorithm for agent authorization

NIST SP 800-207 (the federal Zero Trust architecture blueprint) defines a trust algorithm that the PDP (policy decision point – the component that evaluates each access request against current policy) uses to evaluate access requests. The algorithm considers multiple signals: identity, device posture, behavior history, request context, threat intelligence.

For agentic systems, the trust algorithm evaluates:

flowchart LR
    REQ([Agent Action Request]) --> TA[[Trust Algorithm]]
    ID[/Agent Identity + Delegation/] --> TA
    POSTURE[Model + Prompt Integrity] --> TA
    BEHAVIOR[(Behavioral Baseline Check)] --> TA
    CTX[/Intent + Context Signals/] --> TA
    THREAT{{Adversarial Input Detection}} --> TA
    TA -->|Score| DECISION{Authorize?}
    DECISION -->|High trust| ALLOW([Allow Action])
    DECISION -->|Medium trust| STEP_UP[Restrict Scope or Step-Up]
    DECISION -->|Low trust| DENY[Deny + Escalate]

No single signal is sufficient. Identity alone does not tell you whether the action is appropriate. Behavior alone does not tell you whether the intent is legitimate. Context alone does not tell you whether the agent has been compromised. The trust algorithm combines all signals into an authorization decision.

This is the same multi-signal, continuous evaluation model that modern ZTNA (Zero Trust Network Access – platforms that enforce Zero Trust policies at the network access layer, replacing VPN perimeter models) platforms implement for network access. The signals change. The architecture does not.

What the AI security community is missing

Three specific gaps:

1. No PDP/PEP separation

Most agent frameworks embed authorization logic in the orchestration layer. The thing deciding whether an action is authorized (the PDP – policy decision point) is the same thing executing the action (the PEP – policy enforcement point). That violates the most basic Zero Trust Architecture (ZTA) principle. Separate the decision from the enforcement.

2. No continuous verification

Agent sessions get authorized once and run until they end. No behavioral monitoring. No drift detection. No re-evaluation. This is session-based trust, the thing Zero Trust Architecture (ZTA) was designed to eliminate.

3. No identity model for delegation

There is no standard for expressing: “This agent is acting on behalf of this human, with this delegated authority, under these constraints, for this purpose.” OAuth 2.0 (the authorization delegation standard that lets a service act on a user’s behalf) does not model this. SAML (the XML-based federated identity standard used for single sign-on between organizations) does not model this. The emerging A-JWT (Agentic JWT – a proposed extension of JSON Web Tokens that carries agent identity and delegation chain) and A2A (Agent-to-Agent – an emerging protocol for agent identity and inter-agent delegation) work is starting to address it, but it is early.⁴

What the network security community is missing

The mapping goes both ways. Network security practitioners dismiss AI security as “not their problem” because it does not involve packets and firewalls. They are wrong, and here is why:

Zero Trust was never about networks. NIST SP 800-207 (the federal Zero Trust architecture blueprint) is an architecture standard, not a network standard. It defines subjects, resources, policy decision points (PDPs – the components that evaluate each access request), and enforcement points (PEPs – the components that act on those decisions). It never says the subject must be a human or the resource must be a server. The principles are substrate-independent.

Zero Trust Architecture (ZTA) was designed to be substrate-independent. The network security community constrained it to networks. The AI security community ignored it entirely. Neither response is correct.

If you are a security architect who understands Zero Trust Architecture (ZTA), you already understand 80% of what agentic AI security requires. The remaining 20% is specific to the AI substrate: injected instructions as an attack vector, hallucination as a failure mode, context window manipulation as a persistence technique.

But the architecture? You already know the architecture. You have been building it for years.

Putting it together: a ZTA-native agent architecture

flowchart TB
    USER([Human Policy Author]) -->|Writes policy| POLICY[(Policy Store)]
    USER -->|Reviews| AUDIT[(Audit + Analytics)]

    subgraph runtime["Agent Runtime"]
        AGENT([Agent]) -->|Action request| PEP[Policy Enforcement Point]
        PEP -->|Evaluate| PDP{{Policy Decision Point}}
        PDP -->|Consult| POLICY
        PDP -->|Check| TRUST[[Trust Algorithm]]
        TRUST -->|Identity| ID_SVC[/Identity Service/]
        TRUST -->|Behavior| BDD[(Behavioral Drift Detection)]
        TRUST -->|Context| CTX_SVC[Context Evaluator]
        PDP -->|Decision| PEP
        PEP -->|Allow| TOOL[Tool / Resource]
        PEP -->|Deny| BLOCK[Block + Log]
        PEP -->|Escalate| ESC[Human Exception Handler]
    end

    TOOL -->|Action log| AUDIT
    BLOCK -->|Denial log| AUDIT
    ESC -->|Resolution| USER
    BDD -->|Drift alert| ESC
    AUDIT -->|Findings| USER

This is not speculative architecture. Every component in this diagram has a proven analog in existing Zero Trust Architecture (ZTA) implementations. The PDP/PEP (policy decision point / policy enforcement point) split is NIST-defined. The trust algorithm is standard. Behavioral monitoring is deployed in every major ZTNA (Zero Trust Network Access) platform. The identity service is what every IGA (Identity Governance and Administration – the systems that manage identities, entitlements, and access lifecycle across an organization) platform provides.

The work is not inventing new principles. The work is implementing proven principles on a new substrate.

Where this goes

The convergence of Zero Trust Architecture (ZTA) and agentic AI security is inevitable. The question is whether it happens by design or by accident.

By design means: security architects who understand both domains build the bridge. They apply Zero Trust Architecture (ZTA) principles to agent authorization, implement PDP/PEP (policy decision point / policy enforcement point) separation in agent frameworks, build continuous verification into agent runtimes, and treat agent identities as the NHI (Non-Human Identity) class they belong to.

By accident means: someone builds an agent framework with perimeter-based authorization, it gets compromised through an injected instruction that pivots across an unsegmented multi-agent system, and the postmortem eventually discovers that the security community solved this problem years ago for a different substrate.

Read NIST SP 800-207 (the federal Zero Trust architecture blueprint). Then look at your agent framework. The gaps will be obvious.

See also

Security architecture chain : these articles form a connected sequence on authorization for agentic AI:

• Dual-Intent Runtime Authorization (DIRA) : the framework that operationalizes Zero Trust Architecture’s per-request authorization for agents. DIRA (Dual-Intent Runtime Authorization) is what “never trust, always verify” looks like when the actor is an LLM.
• Non-Human Identity for Agentic Systems : the identity layer underneath authorization. Agents are NHIs (Non-Human Identities); most governance frameworks do not know what to do with them.
• Human Above the Loop : where the human fits in a Zero Trust Architecture (ZTA)-compliant agentic system. Policy authoring and exception handling, not click-to-approve.
• CB4A: content-based 4-tier authorization for AI tool calls : a production implementation of the PEP (policy enforcement point) described in this article.
• The tool permissions your agent does not need : least privilege in practice: an audit of unused permissions and what they cost you.