NIST Agent Identity Design Tenets Guide

Most AI agents in production today run on shared credentials, static API keys and borrowed human sessions, and NIST has now set out what good looks like instead. On 27 October 2026 the NIST Cybersecurity Insights blog published "Design Tenets for Agent Identity Management Systems", ten proposed tenets for the identity, authentication and authorisation of AI agents, written by Harold Booth, Bill Fisher and Ryan Galluzzo of NIST and Tom Clancy of MITRE. The tenets are proposals, not a standard, a Special Publication or a regulation, and NIST says plainly that not all of them can be met with today's standards and products. They will guide the demonstrations in the NCCoE agent identity and authorisation project and are likely to become the reference point that federal buyers and auditors use. This guide explains each tenet, maps it to the protocols and controls that already exist, and gives identity, platform and security teams a way to run a gap assessment now.

Source note: tenet names and scope come from the NIST blog post and the NCCoE resource hub, checked on 11 November 2026. The mapping to protocols and controls is NHI Mgmt Group analysis, not NIST text. Confirm against the official text before relying on it.

Key takeaways

• Ten tenets, one direction. Agents get their own verifiable identity, carry only narrowed, short-lived authority linked to a human or organisation, and leave evidence they cannot edit.
• Status matters. The tenets are a proposed design baseline published on a NIST blog, with no formal comment period on the post; treat them as an early signal of federal expectations, not as a compliance requirement.
• Policy must sit outside the model. Tenets 7 and 8 say the component that decides what an agent may do must be separate from the reasoning model and must be deterministic; guardrails alone are not enough.
• Tenets work in combinations. NIST notes that a confused deputy attack needs tenets 2, 3, 7 and 8 together; a gap in one undoes the others.
• Most building blocks exist. Workload identity (SPIFFE), token exchange (RFC 8693), proof of possession (RFC 9449), Rich Authorization Requests (RFC 9396) and external policy engines cover much of the ground; signed mandates and cross-organisation delegation are the real gaps.

Status and where the tenets come from

The tenets are the second post in a NIST blog series on agentic identity. The first, "Back to the Future: Why Agentic AI Needs Strong Identity Foundation" (27 August 2026, Bill Fisher and Ryan Galluzzo), argued that most agent identity problems are long-standing IAM problems: shared credentials break accountability, static API keys prove nothing about identity, and heavy reliance on human approval produces consent fatigue similar to MFA bombing.

NIST frames the tenets as risk based: organisations should apply them according to the risk of the agent's transactions, its operating environment, and the data, tools and skills it can use. They cover both enterprise agents and consumer agents acting for individuals. See the Agent Identity Standards Tracker for the wider standards picture.

The ten tenets explained

Identity and delegation (tenets 1, 2 and 6)

Tenet 1 is the foundation. An agent identity should be issued to a workload, not typed into a config file, and should be attestable: the identity says which runtime, environment and approved configuration it belongs to. In practice that means a SPIFFE ID or a cloud workload identity per agent instance or per agent class, never a shared service principal for every agent in a tenant. See the SPIFFE and SPIRE Guide.

Tenet 2 adds the chain. When a user asks an agent to act, and that agent calls a sub-agent or a tool, each hop must carry who started the task and can only reduce scope. OAuth 2.0 Token Exchange (RFC 8693) carries an act (actor) claim for exactly this, and the IETF WIMSE work is extending workload identity across services, though WIMSE documents are still Internet-Drafts. See the Delegation Chains and Attenuated Authority for AI Agents guide and the OAuth Token Exchange and Delegation Guide.

Tenet 6 goes further than today's tokens: a signed mandate that states what outcome the human intended and the limits that apply, which a merchant, API or downstream agent can verify. There is no agreed format for mandates yet, and the Cloud Security Alliance's November 2026 research note on the tenets lists this as an open gap. Rich Authorization Requests (RFC 9396) is the closest existing building block, because it carries structured, fine-grained authorisation details rather than coarse scopes.

Privilege and authorisation (tenets 3, 4, 7 and 8)

Tenets 3 and 4 turn least privilege into zero standing privilege for agents: nothing held while idle, a scoped token minted per task, bound to one audience, with a short lifetime and a revocation path. Sender-constrained tokens matter here: DPoP (RFC 9449) or mutual TLS certificate binding (RFC 8705) stop a token stolen from an agent's context from being replayed elsewhere. See the JIT Access Guide and the DPoP Guide.

Tenets 7 and 8 are the most important for AI specifically. The model reasons over untrusted content, so anything it reads can try to change what it does. If the model's output is also what decides whether an action is permitted, a prompt injection is a privilege escalation. NIST's answer is a separate, deterministic policy decision point: the agent proposes a tool call, an external engine (OPA, Cedar, an NGAC implementation or an OpenID AuthZEN compatible service) evaluates it against policy, identity and context, and the result is enforced outside the model. See the OpenID AuthZEN Authorization API Guide and the Confused Deputy in AI Agents Guide.

Oversight and evidence (tenets 5, 9 and 10)

Tenet 5 accepts that humans must approve some actions, and warns against consent fatigue. The design question is the threshold: which actions, values, data classes or destinations trigger review, and what context the reviewer sees (originating principal, scope requested, the exact action). See the Human-in-the-Loop for AI Agents Guide. Tenets 9 and 10 cover what happens after: monitoring tuned to agents, and an evidence trail the agent cannot reach. An agent that can delete its own audit records fails tenet 10 regardless of how good the rest of the design is.

Mapping the tenets to standards and controls

For threat modelling, the tenets map onto MITRE ATLAS: AML.T0051 LLM Prompt Injection is the main reason for tenets 7 and 8, and AML.T0053 AI Agent Tool Invocation describes the abuse that tenets 3, 4 and 7 contain. In ATT&CK, stolen agent tokens fall under T1550.001 Application Access Token, which tenet 4's sender constraint and short lifetime blunt. ISO/IEC 27001:2022 Annex A controls 5.16 (identity management), 5.18 (access rights), 8.2 (privileged access rights) and 8.15 (logging) are the natural homes in an ISMS.

Running a gap assessment against the tenets

NHI Mgmt Group recommendation: this section and the decision guidance below are our own guidance, not requirements of the source document.

1. Inventory agents and assign owners. List every agent, the identity it runs under, the credentials it holds, the tools and APIs it can call, and a named human owner. Agents running under a person's account fail tenet 1 immediately.
2. Score each agent against each tenet. Use three levels per tenet: not met, partly met, met. Record evidence (a token sample, a policy file, a log location). Prioritise agents with write access to production, payment or identity systems.
3. Remove static secrets first. Search agent configs, prompt files, tool manifests and logs for API keys and long-lived tokens, rotate them, and move to workload identity with token exchange. This is the fastest route to tenets 1 and 4.
4. Put a policy decision point in front of tool calls. Start in log-only mode: the PDP evaluates every proposed call and records allow or deny without blocking. Review the denials for two to four weeks, fix policy, then switch to enforce for one agent class at a time. Roll back by returning that class to log-only.
5. Define human-in-the-loop thresholds. Write them as policy (for example: external payments, deletion of production data, permission changes, data leaving a classification boundary), not as prompts. Measure approval rates to spot fatigue.
6. Move evidence out of the agent's reach. Ship agent identity, delegation and action records to an append-only store the agent's identity cannot write to except through the logging pipeline. Use a schema such as the AI Agent Audit Log Schema Template.
7. Re-score quarterly. Track the tenet score per agent class as a roadmap, and record which gaps depend on standards that do not exist yet (mandates, cross-organisation delegation).

Decision guidance

• Read-only internal agents: tenets 1, 3, 4, 9 and 10 give most of the value. A PDP may be overkill if the agent cannot change anything, but it still needs its own identity and short-lived credentials.
• Agents that write to production or move money: all ten apply, and 5, 7 and 8 are non-negotiable. Do not deploy until policy is enforced outside the model.
• Consumer-facing agents: tenets 2 and 6 bring privacy trade-offs. NIST explicitly allows anonymous or pseudonymous options; minimise personal data in mandates and tokens.
• Cross-organisation agents: expect gaps. Delegation chains across trust domains depend on drafts, and an independent evidence store (tenet 10) is harder when the agent crosses boundaries. Record the residual risk rather than claim compliance.
• Small organisations: use the identity features of your cloud or agent platform (managed workload identities, short-lived tokens, built-in audit logs) and a simple allow-list policy. See Cloud Agent Identity Services Compared (Entra, AgentCore, Google).
• Large organisations: build a shared agent identity platform (issuance, token exchange, PDP, evidence store) so every team does not solve the same problem differently.

Detection and measurement

Log, per agent action: agent identity, originating principal, delegation chain, token identifier and lifetime, tool or API called, PDP decision and policy version, human approval (who, when) and result. Alert on an agent identity used from an unexpected workload, tokens presented without proof of possession, scope requested beyond the mandate, repeated PDP denials (a common sign of injection attempts), and any write attempt against the evidence store.

• Agents with a distinct identity: percentage of agents not running under human or shared accounts (target 100 percent).
• Static secrets remaining: count of long-lived keys or tokens in agent configurations, trending to zero.
• Median token lifetime: for agent access tokens, measured in minutes, not days.
• Tool calls through the PDP: percentage of agent tool calls evaluated by an external policy engine.
• Approval rate on human-in-the-loop prompts: rates close to 100 percent suggest fatigue or thresholds set too low.
• Evidence completeness: percentage of agent actions with an unbroken chain from originator to result in the append-only store.

Common failure patterns

• One identity for every agent. A shared service principal means no attribution and no per-agent revocation. Tenet 1 exists to stop this.
• Over-privileged tokens handed to coding agents. The PocketOS Database Deletion 2026 shows an agent using a broad platform token to delete production data; zero standing privilege and per-task scopes would have limited it.
• Guardrails treated as access control. System prompts and output filters are probabilistic. Tenets 7 and 8 say they can inform a decision but not make it.
• Agents with access to real credentials in test environments. The OpenAI and Hugging Face Breach 2026 shows agents reaching cloud credentials from an evaluation setting; separate identities and revocable, short-lived access contain this.
• Approval prompts on everything. Reviewers stop reading. Fewer, better triggers with full context beat blanket approval.
• Logs the agent can edit. If the agent's identity has write or delete rights on its own log bucket, the record is not evidence.

Practitioner checklist

• Inventory every agent with its identity, credentials, tools and named owner.
• Score each agent class against the ten tenets and record evidence.
• Remove static API keys and long-lived tokens from agent configs, prompts and logs.
• Issue each agent a workload identity and exchange it for short-lived, audience-bound tokens.
• Carry the originating principal through every hop and allow only narrowing of scope.
• Enforce tool-call authorisation in an external, deterministic policy engine, starting in log-only mode.
• Define human approval thresholds as policy and track approval rates.
• Store agent evidence in an append-only location the agent cannot modify.
• Track NCCoE outputs and re-score when the SP 1800 practice guide appears.

Standards and references

• NIST: Design Tenets for Agent Identity Management Systems
• NIST: Back to the Future: Why Agentic AI Needs Strong Identity Foundation
• NIST NCCoE: Software and AI Agent Identity and Authorization resource hub
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• IETF: RFC 9396 OAuth 2.0 Rich Authorization Requests
• NIST: SP 800-207 Zero Trust Architecture
• Cloud Security Alliance: Research note on the NIST agent identity design tenets

Related NHI Mgmt Group resources: Agent Identity and Access Guide · Top 10 Agent Identity Controls · WIMSE for AI Agents Guide · Agent Identity Standards Tracker