AI agent authorization risks remain a gap in new NIST-CISA token security guidance

AI agents’ actions are out of scope for new guidance from US authorities on securing identity and access tokens, but there is still plenty enterprises can do to protect their systems from rogue humans and AI agents alike.

“Protecting Tokens and Assertions from Forgery, Theft, and Misuse,” a new report from the National Institute of Standards and Technology (NIST) with help from the Cybersecurity and Infrastructure Security Agency (CISA), offers guidance for operators of systems that use digitally signed tokens to make access decisions, including single sign-on and API access.

The guidelines, also known as NIST IR 8587, address what happens after authentication: Tokens and assertions can carry proof of authentication or authorization between systems, allowing an attacker who compromises them to exploit access that has already been granted. NIST recommends continuous monitoring, along with tighter controls throughout the token lifecycle.

The issue is of particular significance for CISA. In May, a public GitHub repository believed to have been maintained by a CISA contractor was found to contain sensitive government credentials, including AWS tokens and GitHub access tokens. CISA said at the time there was no indication that sensitive data had been compromised.

The unresolved question of agent authority

NIST recommends applying the same guidelines for securing signed tokens used by AI agents as for securing those used by humans, but notes that the access risks posed by AI and AI agents “create additional IAM challenges that require further guidelines and, in some cases, new or expanded standards and protocols.”

NIST and CISA are still working on those, but there are things that IT teams can do meanwhile to secure agentic systems.

Managing the lifecycle of an agent’s identity is part of the challenge, said Yih Khai Wong, senior research manager for security services at IDC Asia/Pacific.

Enterprises need visibility into who provisioned an agent’s credentials and what those credentials allow, Wong said. Access should also be withdrawn when the agent’s task ends.

“Token hardening assumes the token holder is a known, bounded actor,” Wong said. “An agentic system breaks that assumption.”

Delegation can make that boundary harder to establish, said Amit Kumar Jena, head of AI development at Kanerika. An agent may act on behalf of a user, invoke a tool and then reach another service, making it increasingly difficult to determine whose authority is being exercised as the chain grows.

Jena said prompt injection could also steer an agent holding a valid token toward an action the user never requested. Token verification would not necessarily detect that misuse because the token itself could still be legitimate.

Jain argued that CISOs should treat AI agents as low-trust non-human identities, granting only the access required for a task. Higher-risk actions should require human approval, he added.

Wong also recommended maintaining an agent inventory and keeping those identities separate from human accounts. Credentials should expire when the task is complete, he said.

Why valid tokens can still be dangerous

A common weakness is assuming that because a token is valid, the activity associated with it is legitimate, according to Jonathan Ong, senior analyst for managed security services at Omdia.

Organizations should consider the context in which a token is presented, including whether a user is accessing sensitive systems from an unusual location or at an unexpected time, Ong said. Detection should also correlate activity across security domains to identify behavior that may appear benign in isolation.

Containment presents another challenge once a token has been compromised. “Token revocation may not always be possible due to architectural limitations,” Ong said.

Other controls can limit the usefulness of a compromised token. Neil Shah, vice president for research and partner at Counterpoint Research, said that NIST’s recommendations can reduce both the duration and reach of a token compromise.

Audience restrictions can limit where a stolen token is accepted, while cryptographically binding a token to the client holding the corresponding private key makes replay by an attacker more difficult.

The report also points organizations toward shared-signal mechanisms such as the Continuous Access Evaluation Profile (CAEP) and Risk Incident Sharing and Coordination (RISC), which can help connected systems respond when token-related security conditions change, Shah said.

Token security extends beyond IAM

The CISA credential exposure also highlights how token security can break down outside traditional IAM controls, Jain said. Credentials can surface in source code, CI/CD pipelines, logs and contractor environments even when access policies themselves are sound.

“If a contractor can copy a cloud credential to their local machine, the identity governance has already failed,” Shah said.

Managing that risk through policy alone can be difficult in DevOps environments, where credentials can be copied onto developer machines or exposed through automated pipelines, Shah said. He argued that enterprises should eliminate static tokens wherever possible and replace them with short-lived credentials.

The CISA incident also exposes a boundary in the NIST guidance, Jena said. IR 8587 focuses on asymmetrically signed tokens and explicitly places mechanisms such as API keys outside the scope of its controls. NIST nevertheless requires covered tokens to be kept out of logs, CI/CD pipelines, and build artifacts.