NIST Published Ten Design Tenets for Agent Identity Management. Here's What Deployers of AI Agents Should Do With Them.

On October 27, 2026, NIST published “Design Tenets for Agent Identity Management Systems”, the second post in its Cybersecurity Insights series on agentic identity, authentication and authorization. Ten design tenets for IAM systems, offered as the target state for managing AI agents.

The subject is the layer of agent deployments nobody wants to own: which identity the agent acts under, what it is allowed to do, who can stop it mid-task, what evidence survives. Most agents in production run on one of three credential types. A human account. A service account. An API key that outlived its rotation date.

Call it what it is: a blog post in a voluntary series, closer to a target-state sketch than a standard. What earns it an hour of a security leader’s time is the source: more than 600 public comments on the National Cybersecurity Center of Excellence’s agent identity concept paper, distilled into ten moves deployers can start on.

What NIST actually published

The post states its role in the series: “This is blog #2 in our series on agentic identity, authentication and authorization.” The first post (Fisher and Galluzzo, Aug. 27, 2026) made the warning case; this one moves to design: ten tenets, each with what it means to meet it plus the primary risks it mitigates.

The tenets came from the comments. In February 2026, the NCCoE published the concept paper behind what is now the NCCoE Agentic SI Identity and Authorization Project Resource Hub. SI is NIST’s current federal term for artificial intelligence; this piece says AI agents, like the rest of the market. The project’s comment summary states it plainly: “The engagement was substantial, with over 600 responses received.” A summary of those comments went up Sept. 29, 2026, sketching what is next: the first implementation use case sits in the software development lifecycle with the NCCoE’s DevSecOps project, showing how AI agents are identified, authenticated and authorized while writing software.

NIST scopes application honestly. The tenets “should be applied and implemented by organizations based on the risk associated with the agentic transactions they intend to support,” alongside the environment and the data, tools and skills each agent touches. That is risk-based framing, not a compliance checklist, and the sentence to hold onto when someone asks whether tenet numbers map one-for-one onto control-framework rows. They do not.

Why identity is the front door for agent risk

The series’ first post inventoried the anti-patterns, and the list is recognizable: users handing personal and enterprise credentials to agents; long-lived bearer tokens and static API keys, which “do not prove identity”; broad role-based access; and agents running under local user accounts, which “undermines non-repudiation.” Their assessment of the moment: early agentic deployments are “prioritizing feature development and immediate value over security.”

Scale turns that debt into agent exposure. NIST’s comment summary observes that agents’ “ephemeral nature compounds the number of unique identities and credentials to be issued, managed, and audited.” An organization that recently matured managing people now holds a principal class that spawns faster than onboarding and dies faster than offboarding. This is what the tenets assume: you cannot govern what you cannot name.

The ten tenets, grouped for deployers

The ten fall into three lanes deployers build with: identity hygiene, authority control, oversight with evidence. Descriptions compress NIST’s language.

Identity hygiene (tenets 01 and 02)

Tenet 01, distinct agent identification: “unique, cryptographically verifiable identification” that is “distinguishable from other identities (e.g., human users, service accounts),” “tied to a specific workload, environment, and approved configuration,” with a “lifecycle distinct from human principals.”

Tenet 02, agent linking, delegation and attenuation: the agent stays cryptographically linked to its task originator for the whole run, and delegation only narrows: “downstream entities can never claim more authority than the parent.” The point: attribution to a responsible human or entity, not a browser tab.

Authority control (tenets 03, 04, 06, 07, 08)

Tenet 03, least and zero standing privilege: “Agents operate with zero standing privilege, holding no persistent rights when idle.” Task-scoped rights, plus separation of duties against combining privileges that sidestep governance.

Tenet 04, short-lived, dynamic and revocable authorization: grants are “Just-In-Time (JIT), time-bounded and audience-specific,” verified at runtime per call, with an explicit warning against “long-lived bearer tokens or static, reusable secrets.”

Tenet 06, mandates and constraints: the task originator creates “cryptographically signed mandate statements that define intended outcomes and constraints for agentic actions,” verifiable downstream for authorization, auditing and non-repudiation. Consumer-facing versions avoid leaking sensitive information about the user.

Tenet 07, architectural separation of policy from reasoning: “The logic that determines what an agent attempts to do is architecturally separated from the systems that determine what it is allowed to do.” NIST explains why: LLMs accept data and instructions as “a single stream of tokens through a single interface,” so the separation “must be enforced by architecture design” around the agent and every system, credential and environment it touches. Then the sentence worth framing: “Guardrails alone are insufficient.”

Tenet 08, deterministic access decisions: probabilistic signals may inform, but are “not used as the primary mechanism for making access determinations.” Permissions change because policy changed, not because a model reasoned its way into a loophole.

Oversight and evidence (tenets 05, 09, 10)

Tenet 05, human-in-the-loop triggers: risk thresholds pull a human in, with enough escalation context for a real review. NIST flags consent fatigue: escalations frequent enough that “agentic actions are approved habitually, rather than through careful risk consideration.”

Tenet 09, continuous monitoring: agent activity outpaces human review, so monitoring runs on “agent specific metrics, thresholds, and policies.”

Tenet 10, immutable evidence: the enterprise maintains “an unbroken, tamper-evident chain of custody and append-only body of evidence” spanning the agent’s identity, delegated intent and resulting actions, kept “independent of the agent” so a compromised agent cannot rewrite its own record.

One worked example ties it together, and it may be the most useful part of the post. NIST maps the “confused deputy” attack (a prompt injection pushing a broadly scoped agent beyond its mandate) onto four tenets at once: attenuation to limit delegation, least privilege to limit scope, policy separated from reasoning to blunt the injection, deterministic decisions to enforce the boundary. No tenet carries the load alone, the fair answer to anyone hoping one product settles agent identity.

A deployer’s checklist

The tenets are targets, not requirements, so the useful question is what moves are available now. A reasonable order:

• Inventory every agent, then give each one an identity lifecycle: purpose, owner, permitted tools and data, approved configuration, documented revocation path. The register most organizations started for shadow AI inventory is the same artifact; tenet 01 adds a lifecycle separate from the employee one agents now borrow.
• Take humans out of the credential path. Agents run under their own principal class, their own credentials, entitlements and lifecycle milestones, never a user’s account.
• Make token hygiene the floor. Reusable secrets come out of agent configurations, replaced with short-lived, audience-restricted grants, verified during the task, revocable mid-task without the agent’s cooperation. NIST’s first post points at draft NISTIR 8587 for credential detail.
• Keep the policy layer outside the model. Deterministic enforcement lives in the architecture around the agent, so prompt injection cannot expand what the agent may do. Guardrails supplement that layer; protocol-level tooling security is another, covered in our MCP security design considerations piece.
• Write mandates down, and let delegation only narrow: a signed task statement, even a lightweight one, beats reconstructing a vague prompt chain later.
• Set human-review thresholds deliberately: which actions always require a human, what context an escalation carries, and how noisy the channel gets before approvals turn into rubber stamps.
• Log where the agent cannot reach: append-only, tamper-evident, outside its platform. An agent that can edit its own log fails tenet 10, and incident response starts from worse ground.

For buyers, the tenets convert into platform questions: is the agent’s identity distinct from its operators? Can we verify mandates instead of taking the vendor’s word? Are grants just-in-time and audience-bound? Can we revoke mid-task and see evidence of it? Where does the log live relative to the agent? Vendors noticed the opening: Okta released a datasheet mapping its offering against the tenets in late October, and practitioner IAM blogs ran the translation days later. Self-assessments and commentary until independently verified, the same rule every security datasheet deserves.

What this means for SOC 2 and ISO 42001 evidence

The tenets will not appear in a SOC 2 report as numbered criteria, and ISO 42001 does not adopt them as controls. The overlap is still useful: auditors already test logical access, authorization granularity, monitoring and audit-trail integrity, and the agent layer adds the eventual questions. Which entity was the agent acting as? Under what mandate? Who approved the scope? Could the grant be stopped mid-task?

The mapping falls out without stretching: the agent register supports inventories and access listings; mandates and scope statements evidence intended use and least privilege; documented review thresholds show control over consequential actions; append-only, tamper-evident logging is the audit-trail proof tenet 10 states outright: evidence no agent can edit. Inside ISO 42001, the same logic sits in AIMS controls on access and monitoring. Our SOC 2 AI controls gap analysis and the ISO 42001 certification wave piece cover the framework side.

In practice the policy write-up is the easy half; the hard half is proving the control operates consistently: that the revocation actually fired, that the mandate constrained the task, that the log survived. Tenets 04 and 10 are written for that proof, and the accountability gap in agentic AI governance covered in September stays open until this evidence exists.

Is this a standard?

No. The ten design tenets are a blog post in NIST’s Cybersecurity Insights series proposing voluntary design targets for IAM systems that manage AI agents. Not a Special Publication, not a rule, no compliance obligations anywhere in it.

NIST is candid about how far reality lags the design: “not all of these design tenets will be immediately fulfilled by the current state of standards and technology,” particularly across the deployment models enterprise and public-facing services will use. The NCCoE’s stated end deliverable is an SP-1800 series practice guide with example implementations, released iteratively, with feedback accepted on a rolling basis. NIST calls the tenets “the guideposts for our agentic demonstrations,” meaning standards and technology move toward them in public, piece by piece.

Where this leaves deployers

Three moves, in rough order: run the agent inventory and give agents an identity lane of their own; put the deterministic policy boundary in place before agent counts scale; start the append-only evidence store while volumes are small enough to design rather than retrofit.

Identity is also where agent governance gets concrete for leadership: boards do not vote on tenet numbers, they weigh consequences, and identity converts “what could our agents do if compromised” into controls, revocation paths and evidence someone can answer for. NIST’s first post put the opening move in management-friendly terms: a “clear-eyed evaluation of its current IAM practices, systems, and capabilities against current standards and best practices” is among the most important actions to take before agents scale. The second gives the destination: the tenets “provide a substantial starting point to allow organizations to assess their current capabilities and establish a roadmap towards more mature agentic IAM capabilities.”