NIST: stop handing AI agents static API keys

There is a line in a new NIST paper that should make anyone running an agent in production wince: the fastest way to stand up an agentic proof of concept is to hand the agent a long-lived API key, and that is exactly how organizations are doing it. Agent identity is the part of the stack nobody budgets for, and NIST's argument is that skipping it recreates every access-management problem the industry spent twenty years unwinding.

What actually happened

Bill Fisher and Ryan Galluzzo of NIST's National Cybersecurity Center of Excellence published Back to the Future: Why Agentic AI Needs a Strong Identity Foundation on August 27. The core observation is about how pilots actually get wired: agents are given static API keys, long-lived bearer tokens, or — worse — run directly under a human user's account and permissions.

None of those prove who is acting. A bearer token is not an identity; it is a password that anything holding it can replay. An API key typically grants broad, unscoped access to everything the API exposes. And an agent running as a person makes the audit log useless, because now every action in the trail says the same name.

The recommendations NIST lands on:

• Treat agents as first-class entities with their own credentials, not borrowed human ones.
• Short-lived, dynamically scoped tokens in place of static keys.
• Granular authorization — least privilege at the action level, not the API level.
• Run local agents inside a hardened harness or sandboxed container.
• Limit human-in-the-loop approvals so the human does not develop consent fatigue and start rubber-stamping.

The paper points at existing machinery rather than inventing new: SPIFFE for workload identity, OAuth 2.0 with Rich Authorization Requests and Transaction Tokens, WIMSE, DPoP for proof-of-possession, AuthZen for the authorization API, X.509 and JWTs, and NIST SP 800-207 for the zero-trust frame around all of it.

Why agent identity matters for your business

You are not a bank, and you do not need SPIFFE. You do need to answer one question: when your agent did that, whose permissions did it use?

The pattern we find on almost every small-team audit is the same. One .env file. One key per vendor. The key is the one the founder generated at signup, which means it is an admin key, which means the agent that summarizes support tickets can also issue refunds and delete customers. Nobody chose that. It happened because there was one key and the agent needed a key.

Four things that are actually achievable this quarter:

Give each agent its own credential. Not a copy of yours. Separate keys are how you revoke one thing at 2am without taking down the business.

Scope the credential to the job. Most vendors now ship restricted keys — Stripe, GitHub, and the major model providers all do. Read-only for a summarizer. Write access only to the one table the agent owns.

Set an expiry. A key with no expiration is a key you will find in a repo in three years. Rotate on a schedule you can actually keep.

Log agent actions separately from human ones. Different identity, different line in the log. When something goes wrong you want the trail to say "agent-support-triage did this," not "the founder did this at 3:14am."

The consent-fatigue point deserves its own note. If your approval flow pings a human on every tool call, that human is clicking yes without reading inside a week. Gate the small set of actions that move money, touch customer records, or change infrastructure. Let the rest run.

Sources: NIST Cybersecurity Insights — Back to the Future: Why Agentic AI Needs a Strong Identity Foundation, NIST SP 800-207 Zero Trust Architecture.