An AI agent can authenticate correctly, present a validly signed token, call an approved tool, and still do something your business never asked for. The token checks out, the logs look ordinary, and the action is still illegitimate, because prompt injection can steer a validly authenticated agent toward work the user never requested.
When NIST IR 8587 landed in September 2026, co-developed with CISA, the natural assumption was that agents were now covered. It is narrower than that: it hardens identity tokens, access tokens, and assertions, and deliberately leaves AI agent actions and API keys untouched, a vacuum where agentic risk begins.
This article sits inside our wider AI agent identity and runtime authorisation guide. By the end you will know what IR 8587 secures, why the scope gap exists, and how to judge your own readiness.
What is NIST IR 8587, and what does it cover for token management?
NIST IR 8587 is an Internal Report issued in September 2026 and developed jointly with CISA. It gives implementation guidance for protecting identity tokens, access tokens, and assertions from forgery, theft, and misuse, and it explicitly leaves AI agent actions and API keys out of its scope.
The full title gives the game away: Protecting Tokens and Assertions from Forgery, Theft, and Misuse. It is a token-hardening document, not an agent-identity standard. That distinction is exactly the scope gap this wider guide is built around.
What it hardens is the substrate agents carry: it pushes short-lived tokens, audience restrictions, sender-constrained binding through DPoP or mutual TLS, and shared signals such as CAEP.
What it leaves out is equally important. API keys and systems that do not rely on asymmetric signed tokens are out of scope, as is what an agent does once it holds a valid token. Hardening the token shrinks the blast radius, but it cannot govern the action. That gap, and why a valid token can still authorise an invalid action, is the next section's subject.
Why does NIST and CISA's IR 8587 place AI agent actions out of scope?
IR 8587 secures the token. It does not secure the action. Authenticating a token is a different problem from authorising what the token holder does, and NIST and CISA deliberately bounded the report to the first. They recognise the gap and are developing practical guidelines.
The report states that it is "not a comprehensive guide to addressing AI and AI agent access risks", and that agentic AI creates challenges needing further guidelines.
Token hardening assumes the token holder is a known, bounded actor, and an agentic system breaks that assumption. Prompt injection works through a valid token: hostile content in a README, a web page, or a PDF steers the agent while the token stays technically legitimate. That is the confused deputy pattern.
The gap is not theoretical. Agents have acted outside their intended scope at 65% of surveyed enterprises, with 29% reporting measurable impact, and only a third checked whether an agent was authorised to act at execution time. A token that checks out is not an action your business approved, which is the heart of runtime oversight failure in practice.
Where can I find NIST/NCCoE official guidance on AI agent identity and authorisation?
IR 8587 is the anchor. NCCoE's February 2026 concept paper on Software and AI Agent Identity and Authorization is where practical agent-identity guidance is developing, and CISA's "Careful Adoption of Agentic AI Services" is the adoption pointer. For governance, choose between the voluntary NIST AI RMF and the certifiable ISO/IEC 42001, both resting on ISO 27001.
The fuller guidance is spread across a constellation of sources. The NCCoE concept paper plans practical guidelines built on OAuth 2.1, OpenID Connect, SPIFFE/SPIRE, SCIM, and NGAC. CISA, with NSA and international partners, published "Careful Adoption of Agentic AI Services", naming privilege risk as a headline concern: an over-privileged agent amplifies the impact of any compromise.
Then there is the framework choice. The NIST AI Risk Management Framework is voluntary and risk-based, built around Govern, Map, Measure, and Manage, while ISO/IEC 42001 is the first global standard for an AI management system, structured like ISO 27001 and certifiable. Neither is a legal prerequisite; the EU AI Act is the binding contrast. Both land on the same governance demands, the four questions set out in the next section.
One dependency runs beneath all of this: ephemeral, short-lived credentials, the credential-model shift this cluster covers elsewhere. That dependency is the technical floor. The governance floor is next.
How do I evaluate whether my organisation's IAM is ready for agentic AI?
Ask four questions of every agent: does it have a defined owner, a declared intent, a bounded scope, and a managed lifecycle including decommissioning? These sit on two preconditions: an agent inventory and immutable audit logging, anchored to SP 800-207 Zero Trust and SP 800-53 controls against an ISO 27001 baseline.
The owner is the control everything else attaches to. Every production agent needs a named human owner who approves its tools, reviews its permissions, and answers for what it does. If you cannot name that person, you have an ungoverned entity in your business. Intent, scope, and lifecycle follow: a stated purpose, least privilege, and a retirement plan.
An agent registry is how you know what agents exist at all, surfacing shadow agents, because you cannot govern what you do not know exists. Immutable, append-only logging gives you an evidence chain, a reconstructible path from intent to action, so agent behaviour is attributable after the fact.
Zero Trust already gives you the vocabulary. SP 800-207's "never trust, always verify" extends naturally to non-human actors: a named owner, a stated purpose, an expiration. SP 800-53 supplies the control families, and ISO 27001 gives you a baseline. What is realistically deployable is shaped by the vendor race over enforcement boundaries.
Ownership plus inventory plus logging plus lifecycle is the governance floor beneath which no agent should ship. If you cannot say what agents you have, who owns each one, what it is for, what it can touch, and when it retires, you have already answered your readiness question.
That opening paradox is why the standard stops where it does. A token can authenticate correctly while the action it authorises is illegitimate, and no amount of token hardening changes that. IR 8587 secures what agents carry. You secure what agents do.
A standard cannot make that decision for you. Readiness is a governance choice your business owns, made before any agent reaches production. The patterns for securing agent identities already exist. Agents need their own identity governance, distinct from human IAM. Recognising that is the starting point. For the broader picture, from the bounded-actor premise through to the vendor race over enforcement, the standards and readiness layer of the wider guide is the place to go next.
Frequently Asked Questions
Is NIST IR 8587 legally binding, or is it just guidance?
NIST IR 8587 is guidance, not regulation. It is an Internal Report, a NIST publication type that shares findings and implementation advice rather than imposing enforceable rules. Like most NIST output, it becomes binding only where a regulator, contract, or internal policy adopts it. The practical effect is that no organisation is fined for ignoring it, but those building agentic AI should treat its token-hardening controls as a de facto baseline.
Does NIST IR 8587 cover API keys as well as tokens?
No. NIST IR 8587 explicitly places API keys out of scope, alongside AI agent actions. The report concentrates on identity tokens, access tokens, and assertions, the credentials that carry an identity claim between systems. API keys are long-lived shared secrets with weaker binding, and the report leaves their governance to the organisation. That exclusion matters because API keys remain one of the most common ways agents and scripts authenticate.
What is the confused deputy problem, and why does it matter for AI agents?
The confused deputy problem describes a privileged system being tricked into misusing its authority on behalf of someone who should not have it. An AI agent holding a valid, correctly signed token can be steered by hostile content, such as a prompt injection, into acting on the attacker's behalf. The token remains legitimate; only the action is illegitimate. That is exactly why token verification alone cannot secure what an agent does.
Can stronger token security alone stop prompt injection attacks?
No. Token hardening shrinks the blast radius of a stolen or forged credential, but prompt injection does not need a stolen token. It works through a validly authenticated agent, manipulating the instructions the agent follows rather than the credential it presents. NIST IR 8587 protects the token substrate; defending against prompt injection requires runtime authorisation, intent checking, and scope limits that sit above the token layer.
What is a non-human identity, and how does it relate to AI agents?
A non-human identity (NHI) is any identity that authenticates without a human at the keyboard, such as a service account, workload, API client, or bot. AI agents are a fast-growing subset of NHIs, but they add a distinctive risk: they make decisions and chain actions, so an identity with a valid credential can pursue goals no human directly requested. NHI governance is therefore the wider discipline that agent identity sits within.
What is DPoP, and how does it protect against token theft?
DPoP, or Demonstrating Proof of Possession, is a mechanism that binds an access token to a specific client's cryptographic key. A stolen token is useless to an attacker who does not hold the matching private key, because the receiving system checks proof of possession on every request. IR 8587 recommends this sender-constrained binding as one of several controls that limit the value of a captured token.
Do I need ISO/IEC 42001 certification before deploying AI agents?
No, but you may want a recognised governance framework. ISO/IEC 42001 is a certifiable AI management-system standard, while the NIST AI Risk Management Framework is voluntary and risk-based. Neither is a legal prerequisite for agent deployment. The choice depends on your regulatory exposure and customer expectations, and both rest on ISO 27001 as the underlying security-management baseline. The EU AI Act is the binding contrast.
What is an AI agent registry, and why is it a precondition for governance?
An agent registry is a maintained inventory of every AI agent operating in your environment, recording each one's owner, purpose, and permissions. It is a precondition because you cannot govern, monitor, or retire what you do not know exists. A registry also surfaces shadow agents, the ones deployed outside central oversight. Without it, the four readiness questions of owner, intent, scope, and lifecycle cannot be answered reliably for any agent.
What makes audit logging "immutable," and why does it matter for AI agents?
Immutable audit logging means records are append-only and cryptographically tamper-evident, so entries cannot be quietly altered or deleted after the fact. For AI agents this matters because it establishes an evidence chain: when an agent acts, you can reconstruct what it did, under whose authority, and when. Raw application logs can be overwritten, but an immutable trail makes agent action genuinely attributable during incident response and audit.
Who is accountable when an AI agent takes an action outside its scope?
The organisation that deployed the agent remains accountable. An agent is not a legal person, so responsibility sits with the named human owner and, ultimately, the business that authorised it. This is why IR 8587's scope gap matters: the standard secures the token, but the consequences of a validly authenticated yet out-of-scope action fall on the organisation. Ownership, bounded scope, and logging turn that accountability into something enforceable.
How is NIST IR 8587 different from the NIST AI Risk Management Framework?
They address different layers. NIST IR 8587 is a technical report on token hardening: how to protect identity tokens, access tokens, and assertions from theft and forgery. The NIST AI Risk Management Framework is a governance framework for managing AI risk across an organisation, covering design, deployment, and oversight. One secures the credential substrate; the other structures how you govern AI, and agent programs typically need both.
How are AI agents different from service accounts or traditional bots?
Service accounts and bots execute predefined, deterministic tasks, while AI agents interpret goals and decide how to reach them, often chaining tools and API calls autonomously. That decision-making is what breaks the older assumption that a valid credential implies a predictable action. A compromised bot can only do what it was coded to do; a manipulated agent can improvise, which is why agent identity needs governance beyond static credential management.