New US Government Token Security Guide Leaves AI Agents in a Grey Zone
NIST and CISA have published fresh guidance on protecting the digital passes that systems use to grant access. It is solid work, but it sidesteps the hardest problem: nobody yet agrees how much to trust an AI agent holding a perfectly valid pass.
Key points
- The National Institute of Standards and Technology (NIST) published guidance document IR 8587 in 2025, covering how organisations should protect digitally signed access tokens.
- CISA, the US Cybersecurity and Infrastructure Security Agency, co-authored the report after one of its contractors exposed AWS and GitHub access tokens in a public code repository in May 2025.
- The guidance explicitly excludes API keys, a common credential type in developer and cloud environments, from its controls.
- NIST acknowledges that AI agents create identity and access risks that existing standards don't yet cover, and says further guidelines are still being written.
- A valid token does not prove the activity behind it is legitimate, a distinction many security teams still miss.
The US government's guidance on access tokens, published by NIST with input from CISA, covers a lot of sensible ground. Short-lived credentials, tighter monitoring, audience restrictions that limit where a stolen token works. Good stuff. Read past the executive summary, though, and you'll find that AI agents, the software programs that make decisions and take actions automatically on behalf of users, sit largely outside the framework. NIST says openly that those systems "create additional IAM challenges that require further guidelines and, in some cases, new or expanded standards and protocols." Those guidelines don't exist yet.
The timing is awkward. CSO Online first reported that in May 2025, a public GitHub repository believed to belong to a CISA contractor was found to hold sensitive government credentials, including AWS tokens (digital keys granting access to Amazon cloud services) and GitHub access tokens (credentials allowing code to be read or changed). CISA said at the time there was no evidence sensitive data was misused. The incident is a clean illustration of exactly the failure mode the new guidance is trying to prevent. We reported on the joint guidance itself on 15 September 2026.
Why a valid token can still mean trouble
A valid token isn't the same as a legitimate action. This distinction matters enormously, and most organisations get it wrong.
Think of an access token like a hotel keycard. The door opens because the card is real, not because the person holding it is supposed to be there. Jonathan Ong, a senior analyst at Omdia, makes the same point: organisations need to look at the context around a token, not just whether it passes a technical check. Unusual location, unexpected hour, access to something the holder has never touched before, these are the signals that a valid token check will never surface on its own.
Containment once a token is stolen adds another layer of difficulty. Revoking a token isn't always possible depending on how a system is built, so controls that limit a stolen token's usefulness become the next line of defence. Binding a token cryptographically to the specific device that created it makes it much harder for an attacker to replay it from a different machine.
What does the AI agent problem actually look like?
AI agents complicate this because their authority is genuinely hard to trace.
An agent might start from a user instruction, invoke a tool, then reach a third service, all under the same credential. By the time that chain is four steps long, determining whose permission is actually in play gets messy fast. Amit Kumar Jena, head of AI development at Kanerika, points to prompt injection as another risk: a malicious instruction hidden in data the agent reads could steer it toward an action the original user never requested. The token would still pass every check.
Our 9 September story on machine accounts noted that a SpyCloud survey of 750 security leaders found automated accounts and AI agents are now the most common attacker entry point, yet fewer than four in ten organisations are actively monitoring them. IR 8587 doesn't close that gap.
The practical advice from researchers is straightforward even if the formal standards haven't caught up. Treat AI agents as low-trust accounts. Give them the minimum access needed for a single task. Expire those credentials when the task ends. Keep agent accounts separate from human ones. Require human sign-off for anything high-risk.
| Control | What it does |
|---|---|
| Short-lived credentials | Token expires quickly, limiting the window an attacker has to use it |
| Audience restrictions | Stolen token only works at the service it was issued for |
| Cryptographic binding | Token is tied to one device; useless if copied elsewhere |
| Continuous monitoring | Flags unusual access patterns even when the token is technically valid |
| Human approval gates | High-risk agent actions need a person to say yes first |
The CISA contractor incident also exposes where the new guidance stops short. IR 8587 focuses on asymmetrically signed tokens and explicitly leaves API keys out of scope. In practice, API keys are the credential type most likely to end up pasted into a code file, pushed into a repository, or printed into a build log. A controls document that covers the formal credential types but skips the ones developers actually use every day has a real gap in it.
If a contractor can copy a cloud credential to their laptop, the access policy has already lost.
