The New Token Guidance Names AI Agents, Then Scopes Their Hardest Problem Out

NIST finalised Interagency Report 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, on 15 September 2026. It was written by Ryan Galluzzo and Andrew Regenscheid at NIST with Stephanie Nelson of Accenture Federal Services and Christine Lazcano of CISA, developed in coordination with the CISA Joint Cyber Defense Collaborative, and issued in support of Executive Order 14306. The audience named on the cover is federal agencies and the cloud service providers they buy from. The reason it matters to everyone else is that it is the clearest statement yet of what good token hygiene looks like, arriving at a moment when the fastest growing population of token holders in most environments is not people.

The control set is worth reading even if you will never sell to a federal agency, because none of it is exotic. Protect signing keys and restrict what is allowed to use them. Validate the issuer and the audience strictly, so that a token accepted by one service is refused by the next. Keep lifetimes short. Bind tokens cryptographically to a client held private key, so that possession of the token alone is not enough to use it. Run revocation that actually works, and log enough to reconstruct an incident afterwards. The report points to two OpenID Foundation specifications by name, the Shared Signals Framework and the Continuous Access Evaluation Profile, along with RISC, so that systems can react when the conditions behind a token change rather than waiting for it to expire. It also tells you to keep covered tokens out of logs and out of CI/CD pipelines, and it places API keys outside its scope, which is its own quiet comment on how much of the AI tooling estate is authenticated.

Then comes the passage that makes this a story for this site. The report acknowledges that AI agents use the same kind of signed tokens to reach email, files, APIs, tools and other services, and it tells you to apply the same protections to them. Having said that, it also records that AI and AI agents create additional identity and access management challenges that will require further guidelines and, in some cases, new or expanded standards and protocols. That sentence is the scope boundary, and it is an honest one. Token integrity is handled. Agent authorisation is named, acknowledged and deferred. Yih Khai Wong of IDC gave CSO Online the cleanest summary of why the two had to be split: token hardening assumes the holder is a known and bounded actor, and an agentic system breaks that assumption.

The distinction the report is drawing, without quite using these words, is between authentication and authorisation. Everything in IR 8587 makes it harder to obtain a token you were never issued, and harder to use one you stole. None of it addresses the case where the token is entirely legitimate, was issued correctly to an identity that genuinely holds those permissions, and is then used by a process acting on instructions nobody at your organisation wrote. That is the shape of very nearly every agent incident we have covered this year. A browser agent inheriting a signed in session is not a forged token. An assistant that signs in as you and posts under your name is not a stolen token. The accounting agent in the Mandiant report that made more than 15,000 high cost API calls in under an hour held valid credentials for every single one of them. Prompt injection does not break the cryptography. It redirects a correctly issued credential, which is exactly the case this guidance leaves open.

It would be a mistake to read that scope note as meaning the document has nothing to offer agent deployments, because two of its controls bound agent blast radius better than anything most teams run today. Audience restriction is the one to implement first. If the token an agent carries is accepted only by the three services it genuinely needs, then a compromised or merely confused agent cannot pivot to the other forty, and the limit is enforced by the resource server rather than by an instruction sitting in a prompt the agent can read and talk its way past. Sender constrained tokens remove the copy and replay path, which matters a great deal when agents hand context between components and leave traces in logs. Short lifetimes shrink the window. And the shared signal mechanisms are the part almost nobody has wired up, because they give you a way to revoke at machine speed, which is the only speed that helps when the thing being revoked can make thousands of calls before a human finishes reading the alert.

One further item in the report belongs on a roadmap rather than a checklist. It asks organisations to understand where public key cryptography sits inside their identity systems and to plan the move to post quantum algorithms, and it flags a practical consequence that identity teams tend to meet late. Quantum resistant keys and signatures are larger, and that extra size lands on JWTs, browser cookies and HTTP headers, all of which have real limits. If your architecture already passes bulky tokens between an agent, a gateway and half a dozen tool endpoints, that is the design most likely to hit a header limit on the day you migrate. Working out where your signing algorithms live is a cheap inventory exercise this quarter and an expensive archaeology exercise in two years.

The framework mapping is unusually clean here, because the controls involved are old ones. ISO 27001 carries nearly all of it already, across identity and access management, cryptographic key management, secure authentication, and the logging and monitoring family. The honest question for most statements of applicability is not whether the control exists but whether anyone ever applied it to a non human identity that can invoke a paid API in a loop. ISO 42001 is where the missing half belongs, because a management system for AI is the right place to define what an agent is authorised to do, on whose behalf, and inside what boundary, and that is precisely the artefact IR 8587 declines to specify. SOC 2 asks the period question about logical access, which is the hard one: not whether audience restriction was configured on the day of the walkthrough, but whether it held for every token issued across twelve months. PCI DSS enters the moment any of these tokens can reach cardholder scope, and a sender constrained, audience restricted token with a short life is a materially easier scoping conversation than a long lived bearer token. The EU AI Act angle is Article 12, since automatically generated logs are a legal duty for high risk systems, and a token trail that cannot attribute an action to one specific agent identity will not satisfy it. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will all hold the policy and collect evidence that you have one, and not one of them inspects your identity provider token configuration, so this is a control you build and then evidence rather than one you buy.

The work itself is short and most of it is configuration rather than code. Give every agent its own identity, because an audience restriction means nothing if six agents share one service account. Set the audience on each token to the smallest set of services that agent actually calls, then verify the rejection by pointing it at a fourth service and watching it fail. Move to sender constrained tokens wherever the platform supports them, and cut lifetimes to the shortest value that does not break long running tasks, which is usually far shorter than the default nobody has revisited. Wire up a shared signal path so revocation reaches the resource servers in seconds rather than at the next refresh. Then record the delegation separately, on the understanding that no standard is going to do it for you yet: which human or which system authorised this agent, to act on whose behalf, with what scope, and until when. That record is what turns an audit question into a lookup, and it is the artefact the next generation of guidance will eventually standardise. The ISO 27001 and ISO 42001 guides on this site cover the identity, cryptography and lifecycle control families this work belongs in, the compliance readiness assessment will show you which of them you can currently evidence, and the policy templates library has the access control, acceptable use and AI governance clauses to hang it on.