NIST just locked down identity tokens — but explicitly admitted AI agent authorization is still a gap

NIST finalized Interagency Report 8587 on September 15, 2026: "Protecting Tokens and Assertions from Forgery, Theft, and Misuse."

Authors include Ryan Galluzzo (NIST), Andrew Regenscheid (NIST), Stephanie Nelson (Accenture Federal Services), Christine Lazcano (CISA).

The document delivers outcome-based guidance for protecting signed identity tokens, access tokens, and assertions used in SSO, federation, API access, and workload authentication. It builds on NIST SP 800-53 Release 5.1.1 and Executive Order 14306.

Core topics include:

• Key protection — safeguarding private keys used to sign tokens.
• Token verification — ensuring relying parties validate signatures and claims correctly.
• Lifecycle controls — issuance, rotation, revocation, expiration.
• Short-lived credentials — preferring ephemeral tokens over static secrets for workload access.
• Continuous monitoring — detecting token misuse, stolen credentials, anomalous patterns.

But here's the critical admission buried in Section 1.1.1 (AI/AI Agents):

> Organizations SHOULD apply these guidelines when agents use signed tokens — BUT this document is NOT a comprehensive guide to AI/agent access risks; those risks need further guidelines/standards. NIST and CISA recognize the gap and continue work.

NIST news (Sep 15, 2026) called out what changed from draft to final:

• More outcome-based key protection — less prescriptive "how," more "what outcomes."
• Workload considerations — short-lived tokens instead of static secrets for machine identities.
• High-level AI + PQC notes without claiming full coverage.

CSO Online (around Sep 16, 2026) summarized the industry framing: agent authorization remains a gap. IR 8587 focuses on asymmetrically signed tokens; API keys often fall outside scope — yet stolen or standing machine credentials are exactly how agents get abused.

For enterprises deploying AI agents (commercial, marketing, support, coding), this document telegraphs what's coming:

• Token controls are getting mandatory (federal procurement lever pending).
• But agent-specific authorization frameworks — inventory, identity, gates, kill switches — still aren't standardized.

The question: Your agents might use NIST-compliant tokens, but who approved the agent, what can it access, and how do you revoke it when it goes rogue?

This is where yesterday's News comes in: Stop Rogue AI Act directs NIST to develop agent-specific governance standards (inventory, cryptographic identity, monitoring, revocation, tamper-evident logs). IR 8587 handles token security; Stop Rogue AI Act will handle agent authorization.

Context: Why IR 8587 matters now (tokens + agents intersection)

In September 2026, Google Mandiant documented a case of autonomous AI agents harvesting credentials in six hours — multi-agent coordination, automated exfiltration, lateral pivoting with no human intervention.

The threat model shifted:

• Old model: humans steal tokens, humans abuse access.
• New model: agents steal tokens, agents abuse access autonomously.

IR 8587 protects tokens themselves — but doesn't govern who or what is allowed to use those tokens.

Translation for enterprises:

1. Your workforce tokens (employee SSO) might be NIST-compliant.
2. Your workload tokens (service-to-service API access) might follow short-lived best practices.
3. But if an AI agent gets hold of a valid token (via prompt injection, exfiltration, or borrowed credentials), IR 8587 alone won't stop it.

That's the gap NIST and CISA admitted exists.

What NIST IR 8587 covers (token security baseline)

The document is comprehensive for tokens — here's what it standardizes:

1. Signed identity tokens and assertions

Scope: Tokens that prove "who you are" — SAML assertions, OpenID Connect ID tokens, OAuth access tokens with identity claims.

Key requirements:

• Asymmetric signing — private key signs, public key verifies (no shared secrets for identity).
• Key protection — private keys stored in HSM, TPM, or equivalent; never logged or exposed.
• Signature validation — relying parties MUST verify signature before trusting claims.
• Claim validation — check issuer, audience, expiration, not-before, subject.

Why this matters for agents:

If your AI agent impersonates a user (borrows their SSO token), IR 8587 says the token itself should be signed and validated — but it doesn't say "agents shouldn't borrow user tokens."

2. Access tokens for API and workload access

Scope: Tokens that grant "what you can do" — OAuth bearer tokens, API keys, service account tokens.

Key guidance:

• Short-lived credentials — prefer tokens that expire in minutes/hours, not days/months.
• Scoped permissions — token should carry minimal claims (least privilege).
• Rotation — refresh tokens regularly; revoke on suspicious activity.
• Avoid static secrets — no hardcoded API keys in code; prefer ephemeral workload identity.

Where agents fall short:

Many enterprises give agents long-lived API keys (developer's personal OpenAI key, standing service account token) — IR 8587 says "use short-lived," but who's monitoring agent key usage?

3. Token lifecycle: issuance, rotation, revocation, expiration

IR 8587 mandates:

• Issuance controls — only authorized identity providers (IdP) can issue tokens.
• Rotation — tokens should rotate on schedule (e.g., refresh every 15 minutes).
• Revocation — if token compromised, revoke immediately (no waiting for expiration).
• Expiration enforcement — relying parties MUST reject expired tokens.

Agent gap:

If an agent's token is revoked (e.g., model version deprecated), does the agent stop immediately or keep running until next rotation?

IR 8587 doesn't specify — that's an agent kill switch problem, not a token problem.

4. Key protection (outcome-based, not prescriptive)

Final IR 8587 moved toward "outcome-based" key protection — instead of saying "you MUST use HSM," it says:

• Outcome: Private keys used to sign tokens must be protected from unauthorized access, theft, and misuse.
• How: Organizations choose controls appropriate to risk — HSM, TPM, cloud KMS, secure enclave, etc.

What this means for agents:

If your agent signs tokens on behalf of a workload, the key must be protected — but who approved the agent to use that key?

Token security ≠ agent authorization.

5. Continuous monitoring and anomaly detection

IR 8587 calls for:

• Logging — all token issuance, usage, validation failures.
• Anomaly detection — volume spikes, geo-impossible logins, unusual access patterns.
• Incident response — automated revocation triggers when anomaly detected.

Where agents break the model:

• Agent volume is naturally high — agent might issue 1000 API calls/hour (vs. human 10 calls/hour). Baseline is different.
• Agent geo is variable — agent runs in cloud region, not user's laptop geo.
• Agent behavior is autonomous — traditional "impossible travel" heuristics don't apply.

IR 8587 doesn't adjust monitoring for agents — that's the gap NIST admitted in Section 1.1.1.

Section 1.1.1: NIST's explicit AI/agent gap admission

Here's the exact framing from IR 8587 Section 1.1.1 (AI/AI Agents):

> Organizations SHOULD apply the token protection guidelines in this document when AI agents use signed tokens for authentication or authorization. > > However, this document is NOT a comprehensive guide to the unique access control risks posed by AI agents. Those risks — including agent identity, provenance, autonomy, prompt injection, and cascading authorization — require additional guidance and standards. > > NIST and CISA recognize this gap and are developing further guidance. See NCCoE's concept paper on agent identity (referenced in NIST Sep 15 news).

Translation:

• IR 8587 helps if your agent uses OAuth tokens, API keys, or SAML assertions — those tokens should be signed, short-lived, monitored.
• IR 8587 doesn't help if you need to know: Which agents exist? Who approved them? What can they access? How do you revoke one agent without breaking others?

That's the agent authorization gap.

What IR 8587 doesn't solve (agent-specific risks)

Here are the agent-specific risks that IR 8587 explicitly does not address:

1. Agent inventory and discovery

Problem: You don't know how many agents are running, where, with what access.

IR 8587 coverage: None — token logging tells you "token X was used," but not "agent Y used it."

What's needed: Machine-readable agent registry (see Stop Rogue AI Act guidance).

2. Agent identity and provenance

Problem: Agents borrow human credentials (developer's API key, user's SSO token) — no separate identity.

IR 8587 coverage: Tokens should be signed and validated — but doesn't say "agents need separate identity."

What's needed: Cryptographic identity per agent (keypair, certificate) + provenance (which model, version, training).

3. Prompt injection and agent hijacking

Problem: Attacker embeds malicious instructions in data processed by agent → agent executes attacker's commands.

IR 8587 coverage: None — this is an input validation problem, not a token problem.

What's needed: Prompt injection detection + behavioral monitoring (see Sep 14 Mandiant article context).

4. Agent-to-agent authorization cascades

Problem: Agent A calls Agent B, Agent B calls Agent C — unauthorized autonomous cascade.

IR 8587 coverage: Tokens might be properly signed, but no policy for "which agent can call which agent."

What's needed: Agent interaction control policy (allow/deny agent-to-agent calls).

5. Kill switch and instant revocation

Problem: Agent goes rogue (compromised, prompt-injected, or just buggy) — you need to stop it in <1 minute.

IR 8587 coverage: Token revocation exists — but how do you revoke agent's access without revoking human's access if they share tokens?

What's needed: Agent-specific kill switch (separate identity + instant revocation).

How IR 8587 + Stop Rogue AI Act work together

IR 8587 (finalized Sep 15, 2026) and Stop Rogue AI Act (introduced Sep 16, 2026) are complementary layers:

|| Aspect | IR 8587 (token security) | Stop Rogue AI Act (agent governance) | ||--------|------------------------------|----------------------------------------| || Focus | Protect tokens from forgery, theft, misuse | Govern agents runtime in production | || Scope | Signed tokens, access tokens, SSO assertions | Agent inventory, identity, monitoring, revocation | || Who's responsible? | IdP, token issuers, relying parties | Agent deployers, security teams, auditors | || Enforcement | NIST SP 800-53, EO 14306 (federal) | Federal procurement (FAR Council proposal ~18 months) | || What it solves | Token forgery, weak keys, static secrets | Shadow agents, borrowed credentials, no kill switch | || What it doesn't solve | Agent authorization, cascades, prompt injection | Token cryptography (delegates to IR 8587) |

Example scenario where both apply:

1. IR 8587 compliance: Your agent uses short-lived OAuth token (refreshed every 15 min) to access CRM API. Token is signed with RSA key stored in cloud KMS. Relying party validates signature + expiration.

1. Stop Rogue AI Act compliance (future): You have agent-commercial-001 in machine-readable inventory. Agent has separate keypair identity (not developer's personal token). Logs show every CRM access with tamper-evident hash chain. If agent behaves anomalously, kill switch revokes its keypair in <1 minute.

Both layers are necessary:

• Without IR 8587: Tokens might be weak, forgeable, stolen — even compliant agent can't trust them.
• Without Stop Rogue AI Act: Tokens might be strong, but who approved the agent, and how do you stop it?

Practical guide: Token + agent security for enterprises today

You don't need to wait for federal procurement mandates — here's how to implement IR 8587 token security + Stop Rogue AI Act agent governance today.

Step 1: Audit token usage by agents (IR 8587 baseline)

Action: List every AI agent deployed + which tokens/keys it uses.

Check each agent:

• Long-lived API key? (developer's personal OpenAI key, standing service account) → RISK: IR 8587 says use short-lived.
• Shared token? (agent borrows user's SSO token) → RISK: No separate identity, can't revoke agent without revoking user.
• Static secret? (hardcoded in code, no rotation) → RISK: IR 8587 says rotate regularly.

Recommended fixes:

• Short-lived tokens: Use OAuth refresh flow (tokens expire 15–60 min, agent refreshes automatically).
• Workload identity: Cloud providers offer workload identity (AWS IAM roles for pods, GCP Workload Identity, Azure Managed Identity) — agent gets ephemeral token from platform.
• Separate keys per agent: Create project API key per agent (OpenAI, Anthropic) — not developer's personal key.

Step 2: Implement key protection (IR 8587 outcome-based)

Requirement: Private keys used to sign tokens (if your agent issues tokens) must be protected.

Options (pick based on risk):

• Low risk (R0–R1 agents): Cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) — keys never leave HSM.
• High risk (R3–R4 agents): Dedicated HSM (Thales, Utimaco) or TPM (if on-prem).
• Extreme risk (financial, healthcare): FIPS 140-2 Level 3+ HSM + dual-control key ceremony.

IR 8587 doesn't mandate HSM — it mandates outcome (key not stolen, not logged, not exposed). Choose control appropriate to risk.

Step 3: Token monitoring + anomaly detection (IR 8587 + agent baseline)

Challenge: Traditional monitoring assumes human usage patterns. Agents break those assumptions.

Solution: Define separate baseline for agents:

• Human baseline: 10–50 API calls/day, geo-stable, working hours only.
• Agent baseline: 500–5000 API calls/day, cloud region geo, 24/7 operation.

Alerts to configure:

• Volume >5x agent baseline (not human baseline) → investigate potential prompt injection or runaway loop.
• New resource accessed (agent accesses endpoint never used before) → block + human approval required.
• Token shared across identities (same token used by human + agent) → flag as "borrowed credentials" violation.

TrustAI Vault implements agent-aware monitoring — separate baselines for human vs. agent usage, DLP before prompts, tamper-evident logs.

Step 4: Separate agent identity (Stop Rogue AI Act readiness)

IR 8587 alone doesn't require separate agent identity — but Stop Rogue AI Act will (once NIST standards published).

Action now: Create service account or keypair per agent, not shared with humans.

Benefits:

• Granular revocation: Kill switch agent-commercial-001 without breaking developer access.
• Precise logs: "agent-commercial-001 accessed CRM," not "developer accessed CRM."
• Least privilege: Agent gets only read_crm permission, not admin_crm.

How to implement:

• For internal systems: Create service account per agent (e.g., svc-agent-commercial-001) with dedicated keypair (ED25519, X.509 cert).
• For external APIs: Create project API key per agent (OpenAI project keys, Anthropic workspaces) — document agent_id ↔ API key mapping.

Step 5: Agent inventory + kill switch (Stop Rogue AI Act core)

Even without Stop Rogue AI Act passage, you need:

1. Machine-readable inventory: agents-inventory.json listing agent_id, model_version, owner, permissions, status.
2. Kill switch: Instant revocation (<1 min) for compromised agent — feature flag, cert revocation, or API key deactivation.

Why this prepares for both IR 8587 + Stop Rogue AI Act:

• IR 8587 compliance: You can prove which tokens are used by which agents (audit trail).
• Stop Rogue AI Act compliance: You can prove inventory, separate identity, kill switch, logs (federal procurement questionnaire).

Full guide: Stop Rogue AI Act: agent inventory, identity, kill switch.

Link to Mandiant credential harvest incident (Sep 14 context)

September 14, 2026: Google Mandiant documented autonomous AI agents harvesting credentials in six hours — multi-agent coordination, automated exfiltration, lateral pivoting with no human intervention.

IR 8587 would help if those agents stole tokens — but it wouldn't prevent:

• Prompt injection — attacker tricked agent into exfiltrating credentials (input validation gap).
• Agent cascade — Agent A called Agent B called Agent C autonomously (no agent-to-agent policy).
• No kill switch — even if tokens were short-lived, agents kept running until expiration (no instant revocation).

That's the agent authorization gap IR 8587 admits exists.

Stop Rogue AI Act addresses those gaps — inventory (know which agents ran), monitoring (detect cascade), kill switch (stop agents <1 min).

Bottom line: IR 8587 secures tokens. Stop Rogue AI Act will secure agents. Enterprises need both.

What to expect next (NIST + CISA agent guidance timeline)

NIST Sep 15 news mentioned:

> NIST and CISA continue work on AI agent access control risks. See NCCoE agent identity concept paper.

Expected timeline:

• Q4 2026 – Q1 2027: NIST publishes draft guidance on AI agent identity, provenance, and runtime controls (likely NIST SP 800-series or IR supplement).
• Mid 2027: Stop Rogue AI Act (if passed) directs NIST to finalize agent governance standards within 12–18 months.
• Late 2027 – 2028: FAR Council proposes revisions to Federal Acquisition Regulation — federal procurement requires compliance.

For enterprises: You have 12–24 months before agent governance becomes mandatory for federal contractors — and then your B2B clients will demand same proof.

Start now:

1. Implement IR 8587 token security (short-lived, monitored, separate keys).
2. Build Stop Rogue AI Act readiness (inventory, separate identity, kill switch, logs).

Don't wait for procurement mandates — your clients and auditors are already asking.

The 4 questions auditors will ask in 2027 (token + agent combined)

If you deploy AI agents accessing APIs, databases, CRM, or internal systems, prepare to answer:

Question 1: "Do your agents use NIST-compliant tokens?" (IR 8587)

What they're checking:

• Are tokens signed asymmetrically (not shared secrets)?
• Are tokens short-lived (minutes/hours, not months)?
• Are private keys protected (HSM, KMS, TPM)?
• Do you monitor token usage and revoke on anomaly?

How to answer:

• Show token issuance logs (OAuth refresh flow, expiration enforcement).
• Prove key protection (KMS audit logs, HSM attestation).
• Demonstrate monitoring (anomaly alerts, revocation triggers).

Question 2: "Does each agent have separate cryptographic identity?" (Stop Rogue AI Act)

What they're checking:

• Do agents borrow human credentials (developer's API key, user's SSO token)?
• Or does each agent have dedicated keypair/service account?

How to answer:

• Show agent inventory with agent_id ↔ keypair/API key mapping.
• Prove no shared credentials (logs distinguish agent vs. human).

Question 3: "Can you revoke one agent without breaking others?" (Kill switch)

What they're checking:

• If agent-commercial-001 goes rogue, can you stop it in <1 minute?
• Without revoking agent-support-002 or developer access?

How to answer:

• Demonstrate kill switch (feature flag, cert revocation, API key deactivation).
• Show test results (agent stopped <1 min, others unaffected).

Question 4: "Do you log all agent actions with tamper-evident logs?" (Compliance)

What they're checking:

• Are logs immutable (append-only, cryptographic chaining)?
• Can you prove what agent X did on date Y with irrefutable audit trail?

How to answer:

• Show tamper-evident logs (hash chain, each log references previous hash).
• Prove retention (90+ days, centralized storage).

If you answer "no" to any question, B2B contract may be rejected.

Conclusion

NIST IR 8587 (finalized Sep 15, 2026) delivers comprehensive token security guidance — signed identity tokens, short-lived access tokens, key protection, lifecycle controls, monitoring.

But Section 1.1.1 admits: AI agent authorization risks need separate guidance. Token security alone won't stop rogue agents.

For enterprises deploying AI agents:

1. Implement IR 8587 token baseline — short-lived tokens, key protection, monitoring.
2. Build Stop Rogue AI Act readiness — agent inventory, separate identity, kill switch, tamper-evident logs.
3. Don't wait for mandates — your B2B clients and auditors are already asking.

Convergence: IR 8587 (token security) + Stop Rogue AI Act (agent governance) = complete enterprise AI access control.

Timeline: Federal procurement compliance likely mandatory by 2028 — start building now.

If you deploy agents today, secure both tokens (IR 8587) and agents (Stop Rogue AI Act) before they become mandatory.