AI Agents Are Identities: NIST's Ten Tenets, Sorted for Your IAM Team

What NIST proposed, and what it did not

On October 27, 2026, NIST published "Design Tenets for Agent Identity Management Systems" on its Cybersecurity Insights blog. The authors "proposed an initial set of ten design tenets" for identity and access management systems that manage AI agents, to be applied based on the risk of the agentic transactions an organization supports.

NIST is candid that "not all of these design tenets will be immediately fulfilled by the current state of standards and technology". NIST calls this an initial set and a starting point; it is not a standard or an audit criterion. NIST also runs an AI Agent Standards Initiative, which lists the NCCoE agent identity concept paper among its related activities; this article covers only the tenets post.

The sort below is mine: GCA's practice opinion as of October 29, 2026, not NIST's classification. Other practitioners may sort the tenets differently, and where we differ, NIST's text controls.

The premise: an agent is an identity with rights

My starting point is simple. An AI agent does not need a new kind of identity system. To reach your data it needs an account, and that account holds rights. Many IAM programs already treat identities such as employees, contractors, service accounts, built-in accounts and API identities, among others, as distinct types with their own policies. An agent is one more type.

In my view, most enterprises are keeping the IAM fundamentals working with the frameworks they have while this field moves fast. NIST's proposal shows where it sees agent identity heading, which helps you decide what to do now and what to watch.

The sort at a glance

The tenets fall into three groups, and the sections below follow them. Group A (tenets 1, 3, 4 and 8) is what your IAM program already does. Group B (tenets 2 and 6) is the two real gaps. Group C (tenets 5, 7, 9 and 10) sits outside the IAM team or is shared. The table lists the tenets in NIST's order; the sections group them, so you read tenets 1, 3, 4 and 8 first and then the rest.

Group A: what your IAM program already does

Tenet 1: Distinct agent identification

NIST proposes agents "distinguishable from other identities (e.g., human users, service accounts)", with "an identity, credential, and access management lifecycle distinct from human principals."

Should AI agents have their own identity? Under NIST's proposal, yes, for traceability: a distinct identity helps prevent an agent from impersonating a person or a service account, and it traces an autonomous action to a specific software component.

How are AI agents identified? The way any account is: an identity record with a type, a named human owner, a purpose and a lifecycle, and a credential that belongs to it alone. NIST also asks for a cryptographically verifiable identity, meaning one the agent can prove with cryptography, such as a signed token or certificate, and not just by presenting a name or a shared secret. NIST adds that it should ideally be tied to a workload, environment and approved configuration. That is the small gap. The work is an attribute and a policy, not a platform: an identity type, type-specific policy, access reviews that separate agents from people, and named owners who attest to least privilege and necessity. Which group owns an agent differs by organization; a platform engineering team is one example of an ownership party. How each agent's access is controlled depends on what each application or repository can authenticate, so you apply the mechanisms you already have as the application allows: policy at the identity provider for one account, just-in-time access for another, a vaulted credential for a third. Those are examples of existing capabilities, not a list of three options.

Tenet 3: Least and zero standing privilege

NIST asks that agents operate with "zero standing privilege, holding no persistent rights when idle", with access limited to what a task needs and separation of duties preventing conflicting privileges. This is core IAM: least privilege, just-in-time elevation and privileged access management. In my view none of it needs a new product.

In IAM, least privilege is our fundamentals, and sports offer a good comparison. The more talented team can still lose if it slips on the basics. Granting more rights than are necessary adds risk the way throwing into double coverage does: you may complete the pass, but you have significantly raised the odds of a turnover.

We already have programs that handle least privilege, revalidation of those rights and just-in-time provisioning of them. A good example is Microsoft Entra Privileged Identity Management, which organizations with the right Entra licensing already have. It lets an account be eligible for rights but requires an activation step, which can include MFA, justification or approval, before the rights apply. For workload identities such as service principals, Microsoft supports only time-limited active assignments, not eligible ones, so check what your agent identity type supports. Identity providers can also send attribute claims in OpenID Connect or SAML sign-ins to drive just-in-time provisioning of the account, and other tools exist to revoke standing privileges and grant access temporarily, for the duration of the task, with a simple step. These capabilities exist; they need to be used. While the rest of the agentic AI world matures, we can stick to our fundamentals: the blocking and tackling of IAM.

Tenet 4: Short-lived, dynamic and revocable authorization

NIST proposes that "All access grants are Just-In-Time (JIT), time-bounded and audience-specific", verified at runtime for each call, avoiding "long-lived bearer tokens or static, reusable secrets". Identification gets an agent in the door; authorization decides what it can do inside, and NIST asks that it be decided again for each call.

This is zero trust for a new identity type: never trust, always verify, as I argued in an earlier article on the OSI model. Keep policy central at the identity provider and apply it at each authentication. The purpose of classification is to tie the authentication duration and re-authentication requirements to the sensitivity of the agent, the task or the data. An entitlement that grants access to data you already classify as sensitive can pull in the policies you have defined for that data: a shorter session, a fresh authentication, or even a human-in-the-loop pause and approval. Exceptions go to just-in-time elevation or an added step-up control. Vaulted credentials that rotate after use are the catch-all when you do not have more mature capabilities: a compensating control, not the tenet itself.

Know the limits. Microsoft documents Conditional Access for workload identities for single-tenant service principals, where "Block access is the only available option" as a grant control. That policy does not cover managed identities and requires Workload Identities Premium licenses. It also documents Conditional Access for agents, which targets agent identities, agent identity blueprints and agent users and requires specific licenses. Microsoft documents that Conditional Access is evaluated when a token is issued or refreshed, with continuous evaluation only for some resources, so per-call checking, which NIST asks for, is the part of tenet 4 to press vendors on. Okta and Ping Identity each document comparable controls under the name authentication policies (Okta and Ping), and both now document AI agent identity features (Okta and Ping). Vendors are still adding agent capabilities, so during planning, understand exactly what your own platform supports today, press your vendors on what comes next, and keep following as it changes.

Tenet 8: Deterministic access decisions

NIST proposes "deterministic capabilities as the primary mechanism for making access decisions", with probabilistic information as an input only.

Entitlements are facts: to reach this data you hold this authorization, enforced at this decision point. The agent does not get broad access and then reason about whether to use it. Each agent has a specific purpose and specific rights; if it needs more, it asks, and a person or a policy outside the agent approves, so the agent never activates its own elevation. Eligible assignments in Microsoft Entra Privileged Identity Management are a useful analogy for that step: the member must act, such as requesting approval, before a role becomes active, and the assignment can be time-bound.

This ties back to tenets 3 and 4: apply least privilege at each turn where you can, instead of granting far too much and leaving the AI to sort out whether a given use is appropriate. The decision is not the model's to make. When enforcement sits outside the model, and neither the agent nor any tool acting for it was granted the rights, no amount of arguing, prompt poisoning or verbal acrobatics changes the outcome for that resource, because the agent simply does not have the rights.

Group B: the two real gaps

Tenet 2: Linking, delegation and attenuation

NIST proposes that agents and the entities that initiate their tasks are "cryptographically linked throughout the agent execution", and that "scopes attenuate so that downstream entities can never claim more authority than the parent."

In plain terms: linking means every action an agent takes can be traced back to the person or organization that started the task. Delegation means an agent can hand part of the work, and some of its authority, to a sub-agent or another service. Attenuation means that authority shrinks at each handoff, so whoever receives it can never hold more than the party that passed it on.

Today many agents inherit the permissions of whoever runs them, the opposite of attenuation. Bob Giguere wrote about that in Humans and Agents: Should Access Follow the Job, Not the Person? I call this a gap because, in my view, identity teams lack the tooling and visibility to do it alone, and the work will land on IAM. The design question is how to keep a signed link between whoever started a task and every step after it, however the chain is built. OAuth token exchange (RFC 8693) can record who is acting on whose behalf, but narrowing authority at every hop is the part to press vendors on, because NIST says current standards and technology will not immediately fulfill every tenet.

NIST's stated purpose is attribution. It warns that without a definite link to whoever initiated them, high-impact transactions and unauthorized actions "cannot be technically attributed to the responsible party." In practice that means being able to find which agent, at which turn, did something. That matters because AI systems have long been described as black boxes. Dario Amodei of Anthropic put it plainly in The Urgency of Interpretability: "we do not understand how our own AI creations work." When the people who build a system cannot always explain how it produced an output, break complex work into digestible steps and keep a trail of which agent did each one, so a problem can be pinpointed.

Tenet 6: Mandates and constraints

NIST says a task originator "can create cryptographically signed mandate statements that define intended outcomes and constraints for agentic actions." Downstream services can verify the signature and use the mandate in authorization and audit, and consumer-facing mandates should avoid unnecessary disclosure of a user's sensitive information.

This is where the earlier tenets converge: originator, delegation, identity type, entitlements and consent.

It also harks back to a fundamental that I rarely see used now: directory rights. Directories are only an example, but they let you set very specifically who can read and write each attribute. That can let a person see and change things on their own account that, by default, even highly privileged administrators are not granted, while a controlled group, or everyone, can see other attributes. Administrators who control the directory can usually change those permissions, so pair this with monitoring of permission changes. Add consent through OAuth, and someone dealing with a service provider can authenticate themselves and give an agent a scoped access token, ideally short-lived, that allows it to read a subset of their data. In my experience this is rare today, because the application layer often enforces those controls.

This is where AI agents change the paradigm. The agent becomes the application, and as in tenet 8, the agent does not get to decide what it is appropriate for it to read; that decision must be deterministic. Short-lived consent to specific attributes is my extension, not NIST's.

Group C: outside the IAM team, or shared

Tenet 5: Human-in-the-loop triggers

NIST says "Every organization defines risk thresholds and tolerances that, when reached, initiate human review of agentic actions." Deciding when a human must look is a business and risk decision. IAM's part is enforcement: the identity provider can hold an action until a named stakeholder approves it. Many DevOps teams already work this way: they require approval of a pull request before a change is merged and before deployment pipelines release it to production, so a human signs off before anything reaches production. The same gating can apply to AI actions and tie back to other tenets, such as the classification and sensitivity from tenet 4. It also resembles the step-up authentication used for sensitive transactions such as e-prescribing of controlled substances or wire transfers above a set threshold, where the person must re-confirm before the action completes; for an agent, that person is the human in the middle. Because those capabilities exist today, I expect them to be reused for this purpose, driven by business rules. In my view, that routing will land on IAM. NIST warns of consent fatigue, where escalations are so frequent that actions are approved habitually.

Tenet 7: Separation of policy from reasoning

NIST says the logic that decides what an agent attempts is "architecturally separated from the systems that determine what it is allowed to do", and that "Guardrails alone are insufficient." Language models take data and instructions as a single stream, so a prompt-injected agent must not be able to widen its own permissions.

This is an architecture decision for whoever builds the agent, and it ties back to least privilege and deterministic rights; IAM enforces policy around it. The agent has one or more accounts with authorizations associated, and the authentication and authorization components decide whether it can reach the data. That is the opposite of the monolithic client and server pattern in which a single all-powerful service account is used and the application, here the agentic AI, determines what access should be. The entitlements assigned grant the authorizations, and the authorizations dictate the rights.

One architecture an organization can build routes an agent's data requests through a policy layer, so authentication and authorization apply to every call. The Model Context Protocol is a useful way to separate authentication and authorization from the prompts themselves: its specification describes authorization for HTTP-based servers on OAuth 2.1 and says it is optional, so an organization that needs it must implement and enforce it, and local (STDIO) servers fall outside it. In my view, all of these are future considerations: such a layer could become a logical place for monitoring, policy enforcement and data masking, and probably for other controls we have not thought of yet.

Tenet 9: Continuous monitoring

NIST says agents operate at "a scale and velocity that is not achievable for humans", so monitoring needs "agent specific metrics, thresholds, and policies". Detection belongs to security operations; identity supplies authentications, privilege changes and approvals. Complement your SIEM; do not replace it. Baseline agents separately from people. Where authentication is centralized at an identity provider, monitoring is easier, because the provider is probably already integrated with your monitoring and audit logging, though per-call actions still need to be visible at the resource or policy layer.

Tenet 10: Immutable evidence

Much of this is audit logging you already have: authentication events, privilege escalations and approvals. The open question is central storage, typically a SIEM and security operations. NIST adds an "unbroken, tamper-evident chain of custody" that is independent of the agent and tied to delegated intent and actions. If an agent can modify its own logs, a compromised one can hide what it did. Centralized authentication at an identity provider helps here too: it is probably already integrated into the environment for audit logging, though per-call actions still need logging at the resource or policy layer.

What to do first

1. Inventory agents the way you inventory non-human identities, including any teams set up on their own.
2. Classify each agent's identity type and name a human owner.
3. Remove standing access from inventoried agent accounts, test in non-production first, and put a just-in-time path in place before you cut access (tenet 3).
4. Enforce policy at the identity provider for the agent type, using what your platform documents today (tenets 4 and 8), and plan a fallback for applications that cannot support it.
5. Split access reviews by identity type and have the named owners attest to necessity and least privilege, keeping reviews light enough that agent work is not pushed into workarounds.
6. Name an owner now for the tenets outside IAM (5, 7, 9 and 10), because "not IAM" can easily become nobody's job.

Not every application will support every modern capability, so plan a cascade of techniques. Your first choice may be just-in-time access integrated with your identity provider, using short-duration tokens, perhaps through an MCP layer. Some applications will offer only a legacy service account with a username and password that is not integrated with your identity provider. Be ready to fall back, all the way if you must, to automatically rotated credentials stored in a password vault for the agent to retrieve. Keep that credential out of the model's prompts and logs: have a tool or broker layer retrieve and inject it, scope the vault access to that one account, and keep the legacy account least-privileged. Where that is not possible, weigh whether the agent should connect to that application at all.

If you can only get funding for one tenet, make it tenet 3, least and zero standing privilege, once you have inventoried your agents.

How to read this

The tenets are an initial NIST proposal. The sort is my view, and it describes where the work usually sits, not whether any organization is aligned with anything. IAM work like this contributes to the outcomes NIST describes; it does not deliver them by itself.