← Blog

Enterprise AI

When an AI agent's token outlives its task

September 18, 2026

Picture a procurement agent checking a supplier record before it drafts a purchase request. The request is finished in two minutes. The agent's access token, though, is valid for another hour and can still read supplier records. Nothing is wrong with the draft. The leftover authority is the problem.

On September 15, NIST finalized IR 8587, its guidance on protecting tokens and identity assertions. The report addresses signed tokens used in single sign-on, federation, APIs, and workloads. It explicitly says organizations should apply its guidance when AI agents use signed tokens to access data or tools. It also says agent access raises other questions the report does not settle.

That boundary matters. A secure token system can establish who may call an API. The application still has to decide whether this particular call belongs to this particular job.

Give the credential a smaller job

An agent that reads a supplier and drafts a request does not need the same credential as the service that updates vendor banking details. Yet the easiest integration often starts with a single service account and a broad token kept alive so that retries work. Once the workflow is running, that shortcut becomes hard to see.

NIST's report calls for an explicit audience, a limited scope, and a short lifetime. A resource server must reject a token meant for another audience. For agent work, those controls should follow the actual task: a supplier lookup credential should reach the supplier-read API, not a payment endpoint or every tool behind a shared gateway.

Consider a two-stage intake flow. The first stage reads a request and retrieves possible supplier matches. The second stage writes a proposed route for review. Separate the credentials. The read stage gets a read-only token for the supplier service. The proposal stage gets a token for the queue. Neither stage inherits authority to approve a supplier change. That division still leaves business policy to the application, but it limits what a stolen or misdirected token can do.

A scope label alone is not enough. The API must verify the audience, issuer, signature, expiry, and granted scope before it touches a record. It must also enforce tenant and record access from trusted server-side context. If the model supplies a different tenant ID in a tool argument, the token does not make that claim true.

Expiry is a bound, not a stop button

NIST recommends that access and identity tokens generally last no more than an hour, while allowing shorter lifetimes according to risk. For a two-minute agent job, an hour can be a long window. The application can issue a narrower token for the run and stop issuing new ones when the run ends. A short expiry limits the remaining window; it does not erase it.

The report is candid about revocation. In a stateless system, immediate global revocation may be impossible before a token expires. A button labeled "stop agent" may cancel the model loop while an already issued bearer token remains usable elsewhere. Product teams should test those as two separate claims.

Ask the identity provider and the API owner how revocation reaches a resource server. Does the server check token status, receive a session signal, or only wait for expiry? What happens to a queued retry after the user withdraws approval? A kill switch that cannot answer those questions is a user-interface control, not a complete access control.

Where feasible, sender-constrained tokens such as DPoP or mutual TLS add another boundary by tying token use to a client that holds a key. NIST discusses those mechanisms for workload identities. They reduce the usefulness of a copied token, but they do not replace narrow scope or a policy check on the requested action.

Keep credentials out of the agent transcript

The model needs the result of a supplier lookup. It does not need to see the token used to perform it. Keep credentials in the tool service or a trusted execution layer, fetch them from approved storage at runtime, and return only the data the agent needs for the next step.

NIST warns against tokens appearing in logs, build artifacts, console output, and caches. Agent systems add prompt traces and tool-call histories to that list of places engineers inspect during debugging. A trace that records the entire HTTP request can turn a debugging tool into a credential archive. Redact credentials before the trace leaves the execution boundary, then test the redaction with a deliberately marked dummy token.

Logs still need to explain what happened. NIST suggests recording token type, issuer, scope, client, audience, and timestamped issuance, acceptance, rejection, refresh, and revocation events. It says not to log the token itself or personal data contained in it. Link those records to the agent run and the business action without storing a reusable credential in either log.

Test the end of the run

Before giving an agent write access, run four failure tests. Try a token against the wrong API. Try it after expiry. Stop the agent and attempt a queued retry. Put a dummy secret into a tool response and inspect every trace and log. These tests catch different failures; a green result on one says little about the others.

Then test the business boundary. Let the token be valid while the requested action is out of policy, such as routing a high-value request without its required approver. The API should deny the action. The OWASP AI Agent Security Cheat Sheet calls for a separate execution component to check scope and approval before high-impact actions. A token's validity cannot be the whole decision.

NIST wrote IR 8587 for federal agencies and cloud providers, and its guidance for AI agents is deliberately limited to signed-token protection. The useful lesson for a commercial AI workflow is narrower and testable: identify every credential an agent can use, name the resource it can reach, measure how long it works, and prove what happens when the job stops.