Ship AI agents with short-lived scoped tokens

An agent that can call SSO, read email, or push code already has a credential problem. Its token is the attack surface. NIST and CISA completed guidance to help federal agencies and cloud providers protect identity and access tokens from being forged, stolen, or misused. AI agents deserve the same signed-token protections as human users, but agent access creates extra identity and access management problems that need more guidance.

Foreign actors forged tokens with a stolen commercial signing key, reached government email accounts, and one agency lost more than 60,000 emails. In May, a GitHub repository linked to a CISA contractor exposed sensitive government credentials, namely AWS tokens and GitHub access tokens; CISA said then that the sensitive data did not appear compromised. A leaked token can move fast. A long-lived token gives it time.

Until agent-specific identity standards exist, treat every AI agent as a low-trust non-human identity. Give it the narrowest scope, the shortest life, and the clearest revocation path. Agent token controls are the interim set.

Make the checklist the release gate

Use the checklist below as the minimum bar for production agents. Each item should be testable in a minute. Fail any item and the agent is not ready. Run it before every production rollout, not just after an incident.

• Keep agent identities in a separate inventory from human accounts.
• Issue each agent task a scoped credential.
• Expire credentials when the task ends.
• Verify tokens before granting access.
• Protect signing keys for tokens and assertions, and restrict key use.
• Exclude tokens from logs, CI/CD pipelines, and build artifacts.
• Pause high-risk actions for human approval.
• Reject revoked tokens.

Inventory comes first because an agent that is not tracked cannot be revoked. An inventory gives security a place to look when a token misbehaves. It also makes revocation faster when a task ends.

Short-lived agent credentials are the second control. A task that summarizes email should not hold a token that can delete email. A task that opens a pull request should not hold a token that can merge changes. The scope should match the job, and the job should be short. More access should require a new credential, not a standing one. A standing credential keeps the same exposure after the job is done.

Verification and key protection close the loop. NIST IR 8587 leaves API keys outside its control scope. The log rule needs explicit testing. Tokens accepted without proof can grant access. Stolen signing keys can issue more tokens. Forgeable tokens make the rest of the stack irrelevant. Logged tokens are already exposed.

Human gates stop the blast radius

Short-lived tokens reduce exposure, but they do not remove judgment. Some actions should still require a human. Deleting production data, paying for cloud services, changing identity policy, and sending external messages are candidates. The gate should be explicit, not a vague review step. The approval should name the action, the scope, and the time limit.

Build the gate into the workflow. The agent proposes the action. A human approves it. The system records who approved what and when. When the human is unavailable, the action waits. Waiting is safer than a fast failure with a broad credential. Keep the approval record with the task log.

Monitoring is the last control. Watch for token use that does not match the task: new scopes, new destinations, repeated failures, or calls outside business hours. Alert on the pattern, not just on a single event. Treat repeated alerts as a revocation trigger, not a nuisance. Then revoke the credential and rerun the task with a fresh one. Keep the revocation test in the release checklist. When revocation fails, fix the identity model before shipping again.