How does NIST SP 800-207 zero trust apply to AI agents?

NIST Special Publication 800-207 is the document most security teams mean when they say “zero trust”. It came out in August 2020, before AI agents were reading logs and drafting changes to production. It already names the problem, though. Section 5.7 notes that “artificial intelligence and other software-based agents are being deployed to manage security issues on enterprise networks”, and warns that an attacker may “induce or coerce” such an agent “to perform some task that the attacker is not privileged to perform”.

That is a good place to start if you want an AI near your infrastructure. Below we take the seven tenets in section 2.1 one at a time and ask what each means when the subject making the request is an AI agent. Then we look at where the mapping gets hard. This is the thinking behind zero-trust AI operations, an open specification that maps each of its five rules to a tenet.

What does NIST SP 800-207 actually say?

NIST defines zero trust as “a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.” Every request passes a policy decision point and a policy enforcement point. The aim is to shrink the “implicit trust zone”, the area where anything is trusted just because of where it sits, until almost nothing is in it.

Two terms matter here. A subject is whoever or whatever asks for access. A resource is what it asks for. NIST says subjects “could encompass both human and possible NPEs”, non-person entities, “such as service accounts that interact with resources”. An AI agent is a non-person entity. The framework applies to it as written.

How do the seven tenets map to an AI agent?

1. All data sources and computing services are resources. Every system the agent can reach is a resource: the hypervisor, the load balancer, the identity provider, the cloud account. So is every tool you hand the agent. If a tool can delete something, it needs a policy, whatever its description says.
2. All communication is secured regardless of network location. An agent that runs inside your network earns no trust for being there. Its calls to your systems should be authenticated and encrypted like any outside caller’s, and they should pass a point that can refuse them.
3. Access is granted per session, with least privilege. The agent should get access for one task, not a standing account. Permission to read a VM’s configuration should not include permission to change it. Access to one system should not carry over to the next.
4. Access is decided by dynamic policy. The decision should use the current state: who asked, what the agent is working on, which system and which operation. If a person’s role changes, the agent working for that person should lose the access on its next call.
5. The enterprise monitors the integrity and posture of all assets. For hosts and appliances this is familiar ground: patch level, configuration, signed workloads. For the agent itself it is much harder, as we explain below.
6. Authentication and authorization are dynamic and strictly enforced before access. Every request is checked before it runs, including the hundredth one in a session. NIST names multifactor authentication here. For an agent, the strong version is that a sensitive action needs a person to authenticate, not the agent.
7. The enterprise collects as much information as possible and uses it. Every request, proposal, approval and result should be recorded. That is how policy improves, and how you rebuild what happened after an incident.

Where does the mapping break down?

The tenets assume that once you know who the subject is, you can judge its request. For people and service accounts that mostly holds. A service account runs fixed code. A person can be phished, but their intent does not shift each time they read a log line.

An AI agent is different. Its next request depends on everything it has read, and some of that text may carry instructions aimed at it: a ticket, a commit message, a web page, an error string. Authenticating the agent proves which agent is asking. It does not prove whose instructions the agent is following.

NIST saw part of this coming. Section 5.7 says a software agent “may have a lower bar for authentication (e.g., API key versus MFA)” than a human user, and that “an attacker could gain access to a software agent’s credentials and impersonate the agent”. Both risks grow when the agent is a language model that reads untrusted text all day. We go deeper on the injection side in prompt injection and infrastructure.

Tenet 5 is the other weak point. You can measure a server’s posture. You cannot measure the posture of a model’s reasoning halfway through a task. There is no patch level for a prompt.

What does a sound mapping look like?

If you cannot trust the agent’s intent, design so that its intent does not decide anything that matters. In practice that comes down to four rules.

• Keep credentials away from the agent. An agent that never holds a key has nothing to leak and nothing to reuse. That answers the credential risk in section 5.7 directly.
• Let the agent read inside a person’s scope. Reads can run with the permissions of the person who asked, checked again on every call.
• Make every change a request that a person decides. The agent can propose. The decision on a write belongs to a human subject, authenticated as a human, ideally with a second factor.
• Fingerprint what was approved. The change that runs must be exactly the change the person saw, so nothing can be swapped between approval and execution.

The result is an agent with a deliberately low ceiling. It can investigate freely inside your scope, and it is never the final authority on a write. For the credential side in more depth, see should AI agents hold production credentials?

How GAEZLA does it

We built GAEZLA on this mapping.

• The AI never holds a credential. Integration credentials stay inside GAEZLA. A secret a job needs is released only after approval and sealed to the one enrolled Linux host that runs the job.
• The code the AI writes runs in a sandbox with no network. Calls to your systems run inside GAEZLA with the permissions of the operator who asked, checked again on every call.
• Every change the AI asks for is drafted as a proposal. It is fingerprinted at approval and checked again when it runs. The approve and execute calls accept only an operator, so agents, routines and machine tokens are refused. Nothing in GAEZLA can approve.
• Each decision records who approved it, over which channel, whether multi-factor authentication was used, and what ran. A push on every approval is available on the Complete plan, and it is off by default.

Two limits, stated plainly. An approval accepted inside an MCP client proves the client accepted it, not that a person pressed the key, unless multi-factor authentication is on. And zero trust here applies to the AI. You still choose which systems to connect, and with how much privilege.

Sources

• NIST SP 800-207, Zero Trust Architecture (August 2020): section 2 (definition and tenets), section 5.7 (non-person entities), section 7.3.1 (subjects).