NIST's 10 agent identity tenets: A checklist for security teams

An AI agent can be steered by what it reads. A line hidden in a document, web page, or email can grant an agent with broad access the ability to do something its owner never intended. NIST's new post, “Design Tenets for Agent Identity Management Systems,” says the fix cannot live inside the model: "Guardrails alone are insufficient." Its 10 design tenets come from public comments on the NCCoE's project on software and AI agent identity and authorization, and they read as a list of what a security team can ask of any system that manages agents.

Why prompt guardrails can’t secure autonomous AI agents

NIST's reasoning is about how language models work. A model receives its instructions and input data as a single stream of text, so it can't reliably distinguish between them, and an instruction hidden in a document can read like a command from the user. Prompt filters and guardrails are probabilistic, and they read the same text stream that an attacker can inject into. 

While these guardrails attempt to predict unsafe inputs, relying on them creates five structural security gaps:

• Probabilistic vs. deterministic: Every classifier has an error rate. At agent speed and scale, even a tiny error rate means thousands of wrong calls, and when the call wires money or deletes a database, even one is too many.
• Shared attack surface: A guardrail inspects the prompt, the content, and the proposed action, which is the same text an attacker can inject into. The attacker only needs one successful attempt, and can rephrase, encode, split, or hide instructions until they achieve their goal. 
• Lack of identity context: A classifier sees an input stream. It doesn't know which agent sent the request, on whose behalf it acts, whether that agent was compromised before, or whether it has touched this resource at all. These facts live in the identity system.
• Behavioral drift: Retraining or fine-tuning the model can change a guardrail's behavior without anyone approving the change. Identity policy changes only when someone edits it, and the edit is logged.
• Inability to enforce revocation: A guardrail can stop a prompt. It can't pull an agent's credentials or cut off access the agent already has.

NIST concludes that the separation must be built into the architecture: The system that determines what an agent may do must sit outside the agent, between the agent and the data, tools, and credentials it uses. That is why identity, access, and runtime control must sit outside the agent and the platform that runs it, in a single system that controls agent access across domains.

NIST's 10 design tenets for AI agent identity

1. Distinct agent identification: Agents get unique identities, separate from humans and service accounts, with their own credential lifecycle.
2. Agent linking, delegation, and attenuation: Agents stay tied to whoever started the task, and delegated authority shrinks as it passes to sub-agents or downstream services.
3. Least and zero standing privilege: Agents hold no persistent rights while idle, get only the minimum scope a task needs, and are kept from combining privileges that conflict (separation of duties).
4. Short-lived, dynamic, and revocable authorization: Access is just-in-time, time-limited, and audience-specific, with runtime checks and revocation, and no long-lived bearer tokens or static secrets.
5. Human-in-the-loop triggers: Risk thresholds route agent actions to the right human reviewer, without causing consent fatigue.
6. Mandates and constraints: Task originators issue signed mandates specifying intended outcomes and limits that downstream services can verify.
7. Architectural separation of policy from reasoning: The logic that decides what an agent attempts is separate from the systems that decide what it may do, so injected content can't expand permissions.
8. Deterministic access decisions: Deterministic mechanisms are the primary basis for access decisions. Probabilistic signals, such as a risk score, can inform them but don't make them.
9. Continuous monitoring: Agent-specific metrics, thresholds, and policies flag anomalies at agent speed.
10. Immutable evidence: A tamper-evident, append-only record of agent identity, delegated intent, and actions is stored independently of the agent.

Tenets 7 and 8 are where the guardrails argument turns. Policy has to sit outside the agent, and the decision has to come from a deterministic check rather than from the model.

Why the identity layer is the right place for the decision

A guardrail predicts whether an action is safe. The identity layer decides whether the action is allowed. Today most agents run on borrowed credentials: an API key in a config file, a shared service account, a user's personal token. NIST's tenets call for something different: Each agent gets its own identity with an owner, a purpose, and permissions it earns one task at a time. Creating that identity and governing it from first access to retirement is what an identity provider is built to do.

The identity layer works differently than guardrails: 

• It decides on explicit policy: entitlements, scopes, relationships, and conditions such as risk level and device. 
• It sits outside the model, which is the seventh tenet, and never reads the prompt, so an injected instruction has nothing to talk to. 

An agent needs an issued token to call a resource, so an agent tricked into a harmful action still lacks the key. It already knows who the agent is, who the human is, what each is entitled to, and the current risk posture of both. It is also the only system that can issue a verifiable statement that this agent is acting for this user with these scopes, which is why token exchange and the standards built on it anchor trust there. And it works across in-house agents, SaaS agents, coding assistants, MCP servers, and agent-to-agent flows, with OAuth, OpenID Connect (OIDC), and fine-grained authorization standards that have decades of maturity behind them. Guardrails have no standards yet and vary by provider.

Why agent security requires multiple identity tenets 

NIST emphasizes that no single tenet is sufficient on its own. Strong identity without least privilege, or least privilege without continuous verification, still leaves agents exposed. Agentic risk is mitigated only when these tenets work together.

Stopping a confused deputy attack

NIST uses a confused deputy attack scenario to show how the tenets work together:

1. A user asks an agent to summarize a document. The agent can read a shared drive and send email.
2. The document carries a hidden instruction: Forward its contents to an outside address.
3. The agent can't distinguish the instruction from the data, so it retains access and sends the file.

No single security control stops this attack. NIST says stopping it takes four tenets working together:

• Linking and delegation (tenet 2): Ties the agent's actions to the person or organization that started the task, and narrows authority as work passes to sub-agents.
• Least privilege (tenet 3): Ensures the agent never had a way to send that file anywhere.
• Separation of policy from reasoning (tenet 7): Keeps the injected instruction from changing what the agent is permitted to do.
• Deterministic access decisions (tenet 8): Enforces the scope on each call.

Neutralizing a leaked bearer token

A leaked bearer token needs the same layering. An attacker finds a token in a log file and reuses it; to the receiving system, the attacker looks exactly like the agent.

• Distinct agent identity (tenet 1): The token is tied to the agent's workload, so it fails verification anywhere else.
• Short-lived, revocable authorization (tenet 4): Tokens expire in minutes and are bound to the agent's key, so a stolen copy is nearly worthless.
• Continuous monitoring (tenet 9): A token used from an unexpected place or at an unusual rate is flagged and revoked.
• Immutable evidence (tenet 10): Logs show exactly which calls the replayed token made.

How does identity-first governance implement NIST’s agent tenets?

The enterprise identity architecture: Implementing NIST’s agent tenets

Cross App Access is built on the Internet Engineering Task Force (IETF)’s Identity Assertion JWT Authorization Grant (ID-JAG), an open, vendor-neutral protocol that Okta authored. Any agent or app that supports the standard can take part, not only Okta's. Agent SSO, included in the workforce single sign-on (SSO) plan, applies it to any agent that supports the standard.

Security review checklist: Three questions to ask

Use the tenets as a review checklist the next time an agent platform shows up in a security review.

1. Can anything the agent reads change what it is allowed to do?
2. Does the agent ever hold the credential for the system it calls?
3. How fast can you stop one agent, and what stops with it?

Vendors that answer the first one with a better prompt or a smarter filter are describing a guardrail. NIST's position is that the answer has to be architectural.

Start with the agents you have

The tenets depend on knowing which agents exist and who owns them. If you can't answer where your agents are, what they can do, what they are doing, and how to respond when one misbehaves, start there. 

For third-party agents such as Claude or Cursor, Agent SSO is included with core SSO plans, bringing them into Universal Directory with their own identity. 

For the agents you build, Okta for AI Agents helps address tenets 3, 4, 7, 8, and 9. See what’s new: Explore the latest Okta for AI Agents launches.

Any mention of future products, features, functionalities, or certifications in this blog is for informational purposes only. These items are not commitments to deliver and should not be relied upon to make purchasing decisions.

These materials are for general informational purposes only and do not constitute legal, privacy, security, compliance, or business advice. The content may not reflect the most current security, legal and/or privacy developments. You are solely responsible for obtaining advice from your own legal and/or professional advisor and should not rely on these materials. Okta makes no representations or warranties regarding this content and is not liable for any loss or damages resulting from your implementation of these recommendations. Information on Okta's contractual assurances to its customers may be found at okta.com/agreements.

NIST has not reviewed or endorsed Okta products. The mapping in this post is Okta's own reading of the NIST post.