NIST and CISA finalized IR 8587 on September 15, and its subject is the credential your AI agents already carry. The report does not tell you how to govern an agent. It tells you how to protect the token the agent presents, and that is the part you can act on this quarter.
The guidance protects the token, and the token is an agent’s whole identity
According to NIST’s announcement, IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, gives implementation guidance for keeping identity tokens secure. It is written mainly for federal agencies and the cloud providers they use, and NIST says any organization that manages tokens can benefit. It responds to Executive Order 14306 and builds on recent updates to SP 800-53.
The same announcement explains why the report exists: attackers forged tokens from a single stolen signing key and took more than 60,000 emails from one agency. A forged token that verifies correctly is trusted by every system downstream, so the defense has to sit around the token and its keys, not inside the application that receives it.
The final text changed from the December 2025 draft. NIST says its guidance on protecting cryptographic keys is now less prescriptive and more outcome-based, and that more options exist for revoking tokens and sharing signals about them. Outcome-based guidance asks whether a stolen token can be stopped, not which product you bought.
The Cloud Security Alliance’s research note on the final report summarizes the controls in concrete terms: access and identity tokens that expire within one hour, signing keys on documented rotation schedules, an intended audience on every token, and logs detailed enough to reconstruct which keys signed which tokens and when they were revoked. Those figures are CSA’s reading of the report. Check each one against the report itself before you write it into policy.
The report stops where agent identity starts, and that gap is yours to close
IR 8587 is not an agent standard. NIST says the publication offers high-level considerations for AI, not a comprehensive toolset, and points to a separate concept paper from its National Cybersecurity Center of Excellence on applying identity standards to AI agents. CSA’s analysis of the report reads it as acknowledging that agents and other automated workloads rely on the same token mechanisms, while the wider problem of agent identity needs guidance the report does not supply.
That split is useful to a security leader. Token mechanics are settled enough to implement today: the same lifetimes, audiences and revocation paths apply whether the bearer is an employee or a script. What remains open is who the agent is, whose authority it carries and how far it may act. According to CSA, the concept paper proposes distinct, attestable identities for agents rather than treating them as generic service accounts.
A shared service account is the opposite design. One credential serves many workloads, so the logs cannot say which agent used it, and revoking it cuts off every workload that shares it. CSA also observes that agent identities are frequently created dynamically, accumulate more privilege than the job needs, and can obscure delegation chains in multi-agent workflows. When one agent is hijacked, a shared long-lived credential turns a contained incident into a platform-wide one, and the team that must revoke it is the same team that must keep production running.
Three questions test where you stand. Which agents run in production? Which credential does each one hold? How long would it take to cancel it? If the honest answer is a search through a shared vault, you have found the control to build.
Per-agent credentials turn revocation into a routine action
Give every agent its own short-lived, narrowly scoped token, and rehearse revoking it before you need to.
Give every agent its own short-lived, narrowly scoped token, and rehearse revoking it before you need to.
The reasoning is simple. A hijacked agent still presents a valid token, so verification alone will not flag it. The control that works is the ability to cancel that one credential fast, without touching anything else. CSA’s September 19 analysis recommends a revocation path that works in minutes rather than hours. That recommendation is CSA’s, not a requirement of the report, but it sets a sensible target for a first test.
Start with five steps, in this order:
- Inventory. List every credential an agent uses: service accounts, API keys and OAuth grants. Name an owner for each, and mark which ones several agents share.
- Split. Give each agent its own identity, named for the agent and its accountable owner. Retire the shared account once nothing depends on it.
- Shorten and scope. Replace long-lived secrets with tokens that expire within an hour, the ceiling CSA reads from the report, limited to one task and one intended audience. Put signing keys on a documented rotation schedule, which CSA also lists among the report’s controls.
- Rehearse. Revoke the credential of a non-production agent and time the result. Fix whatever made it slower than your target, then repeat on a production agent that carries low risk.
- Log. Record which credential each agent used, when it was issued and when it was revoked, so an incident review can reconstruct what the agent did and under whose authority.
Assign the first step to the team that owns identity and the fourth to the team that owns incident response. Both belong on the same page of the board report, because the outcome the board cares about is a single number: the minutes it takes to stop an agent that is misbehaving.
NIST and CISA have settled how to protect a token, and the standard for who an agent is remains a concept paper. Give each agent its own credential now, and you can stop one misbehaving agent without stopping the rest.