NIST IR 8587 Hardens Your Tokens and Names the AI Agent Gap

On September 15, 2026, NIST published NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, written with CISA. Its value is that it is executable: it turns token security into a set of numbers and MUST/SHOULD clauses that can be diffed in a config file. The second reason to read it matters more for anyone shipping agents - the report explicitly puts AI and AI agent access risks out of scope and says the gap is recognised and under development. For teams moving agents into production, that sentence is the headline.

A token is a credential with a clock attached

1. What the Report Is

IR 8587 was written by Ryan Galluzzo and Andrew Regenscheid of NIST, Stephanie Nelson of Accenture Federal supporting CISA, and Christine Lazcano of CISA. It was approved by the NIST Editorial Review Board on August 27, 2026, published on September 15, 2026 per the CSRC document history, and carries DOI 10.6028/NIST.IR.8587. It builds on updates to NIST SP 800-53, Release 5.1.1, and it is aimed at federal agencies and cloud service providers across three scenarios: single sign-on, identity federation, and API access. The report's own framing is that identity tokens, access tokens, and assertions need protection from forgery, theft, and misuse, and that the recommendations respond to threats demonstrated in recent high-profile attacks.

-- 1. Audit token lifetimes first: this is the cheapest control in the report
SELECT issuer,
       token_type,
       MIN(lifetime_minutes) AS shortest,
       MAX(lifetime_minutes) AS longest,
       COUNT(*) FILTER (WHERE lifetime_minutes > 60) AS over_one_hour,
       COUNT(*) FILTER (WHERE revoked_check_supported = false) AS no_revocation_check
FROM   token_issuance_policy
GROUP  BY 1, 2
ORDER  BY over_one_hour DESC;

-- NIST IR 8587: access tokens and identity tokens SHOULD be valid for no more
-- than one hour, and expired tokens MUST be rejected by authorization services
-- and policy enforcement points.

2. Four Rules You Can Implement This Quarter

The easiest control in the report is also the one most often skipped: token lifetime. IR 8587 recommends that access tokens and identity tokens be valid for no more than one hour, requires CSPs to make validity length configurable by consumers with baseline periods tied to FISMA system categorisation and authentication assurance level, and states that expired tokens must be rejected by authorization services and policy enforcement points. The second rule is key discipline: signing keys must not be used for any other purpose and must not be usable outside their defined scope - the report even specifies that keys for non-FedRAMP or non-federally-authorised environments must not sign identity tokens in FedRAMP environments except under appropriate trust agreements. The third is verification duty: relying parties and resource servers must confirm scope, validity, source, and integrity before granting access. The fourth is refresh hygiene: refresh tokens used for API access, workloads, and non-human interactions should be as short as possible and accompanied by additional controls such as compromise detection and device registration.

# 2. Four checks before you trust a token (resource server side)
def verify(token, request, config):
    claims = decode_and_verify_signature(token, config.jwks)

    assert claims["exp"] > now(),                  "expired tokens MUST be rejected"
    assert claims["aud"] in config.allowed_audiences
    assert claims["scope"] in config.allowed_scopes
    assert claims["iss"] in config.trusted_issuers
    assert signing_key_scope(claims) == "token-signing"

    # IR 8587: the scope, validity, source, and integrity of all identity
    # assertions and tokens MUST be confirmed by the relying party or resource
    # server before access is granted.

Sender constraining turns a stolen token into a useless one

3. Revocation Is a Signal Chain, Not a Switch

The report is candid about a hard constraint: immediate and global revocation is not always possible in stateless token implementations before a token expires. Its strategy is therefore twofold - compress the window with short lifetimes and refresh or reauthentication, and require token and assertion revocation capabilities wherever possible, with revocation status propagated to connected relying parties through mechanisms such as a token introspection endpoint, token status list, or shared signalling. Relying parties that receive the signal must reject revoked tokens and terminate the sessions attached to them. Two named standards carry this: the Open Identity Foundation's Shared Signals Framework and the Continuous Access Evaluation Profile, both of which include a session revocation signal. The engineering translation is blunt: revocation has to move from an administrator pressing a button to an event stream your services subscribe to.

# 3. Sender constraining: bind the token to the client, not just the user
#    Order of preference is a judgement call; the report lists the options.
oidc_clients:
  agent-worker:
    token_ttl_seconds: 900            # 15 minutes, well under the 1-hour ceiling
    sender_constraining: dpop         # or mtls; channel binding via TLS is the fallback
    audience_restriction: [inventory-api, ticket-api]
    device_registration: required
    compromise_detection:
      signals: [geolocation, velocity]
      action_on_risk: revoke_session

refresh_tokens:
  non_human_interactions: "as short as possible"   # API access and workloads
  interactive_human_sessions: "not beyond reauthentication time frames"

4. Turning a Stolen Token Into a Useless One

The risk-mitigation capability table in the report reads like a procurement checklist: revocation; advanced authorization that pushes updates to policy enforcement points quickly; compromise detection and session analysis using signals such as geolocation and velocity; device or IP registration; and proof of possession with sender constraining. That last capability is the most direct. By binding a token to a device-specific public-private key pair (DPoP) or to mutual TLS, the relying party verifies the endpoint presenting the token, so a stolen token cannot be replayed elsewhere. Where strong sender binding is not achievable, channel binding using TLS properties is the fallback. The report adds an obligation on providers: the availability and effectiveness of these capabilities must be documented and presented to consumers, precisely so consumers can decide how long a token may live. Better capability, longer lifetime; missing capability, shortest lifetime.

# 4. Revocation has to travel: plan for signals, not for a global switch
signals_to_propagate = [
    "session_revoked",       # Shared Signals Framework (SSF)
    "credential_change",     # Continuous Access Evaluation Profile (CAEP)
    "risk_level_change",
]

subscribers = [idp, resource_server, policy_enforcement_point]

# IR 8587: immediate and global revocation is not always possible before a
# stateless token expires. Short lifetimes plus refresh or reauthentication
# limit the window; connected relying parties MUST reject revoked tokens and
# terminate the sessions attached to them.

The report draws its own boundary around agent access risks

5. The Sentence Agent Builders Should Read Twice

Section 1.1.1 of the report states that AI systems - especially agentic AI systems - use signed tokens or assertions in many emerging IAM schemes, that organisations should apply these guidelines when agents use signed tokens to access systems, data, tools, or APIs, and then sets a boundary: this document is not a comprehensive guide to addressing AI and AI agent access risks, those risks create additional IAM challenges that require further guidelines and in some cases new or expanded standards and protocols, and those topics are excluded from scope. NIST and CISA, the report says, recognise this gap and continue to develop practical guidelines, pointing to the CAISI AI Agent Standards Initiative and a possible NCCoE AI Agent Identity project. The message to engineering teams is plain: tightening the token layer per IR 8587 is necessary work, but do not mistake it for the answer to who authorised an agent to do what. Delegation, intent, and least-privilege semantics for agents remain yours to design.

{
  "agent_identity_checklist": {
    "distinct_identity_per_agent": true,
    "no_shared_or_human_credentials": true,
    "token_ttl_minutes": 15,
    "just_in_time_issuance": true,
    "zero_standing_privilege": true,
    "audience_restricted": true,
    "sender_constrained": "dpop",
    "revocation_signal_subscriber": ["SSF", "CAEP"],
    "logs": { "retain_days": 400, "fields": ["token_id", "agent_id", "tool", "decision"] },
    "note": "IR 8587 applies when agents use signed tokens; agent-specific access risks are explicitly out of its scope."
  }
}