Short-Lived Credentials and Brokered Tokens for AI Agents

Part 2 put the policy decision at the gateway. But a gateway is only as good as the credentials behind it. If the agent holds a long-lived AWS key, you have just put a strong door in front of a window that is permanently open. This part removes the standing key.

The default that causes the damage

Part 1's numbers — 29M secrets leaked on public GitHub in 2025, AI-service credential leaks up 81% year over year (GitGuardian 2026, vendor-reported) — are all symptoms of one habit: minting standing credentials and storing them somewhere. A leaked secret is only dangerous because it is still valid. So make it not be.

Short-lived credentials are already in the box

AWS Security Token Service issues temporary, scoped credentials by default. The durations are not folklore — they're documented:

(All from the AWS IAM documentation.) An agent built on AssumeRole holds a credential that expires in an hour by default and is scoped to a role's policy. There is no standing key to leak — and if one is captured, it is dead within the hour.

Don't pass tokens through — broker them

Short-lived is half the answer. The other half is not handing the same token down the chain. When an agent needs to act on a downstream system, it should present a brokered, scoped token for that hop, not reuse a shared one.

AgentCore Gateway supports exactly this: OAuth 2.0 On-Behalf-Of token exchange via AgentCore Identity, implementing RFC 8693 (token exchange) and RFC 7523 (JWT authorization grant) to broker tokens between agents and downstream tools (AWS). The agent acts downstream as a bounded delegate, not as a key-holder.

Conceptually, a tool call flows like this:

authenticated MCP session (gateway, per-user, bounded TTL)
        │
        ▼
OBO token exchange  (RFC 8693 / 7523, via AgentCore Identity)
        │
        ▼
short-lived STS credentials  (AssumeRole, ~1 h, scoped to a role)
        │
        ▼
downstream tool / AWS API   ← no standing key anywhere in the path

Per-action, per-identity authorization

Brokering tokens lets you decide access at the moment of each action, against the real caller. The reference integration of Auth0 for AI Agents with AgentCore shows the shape: AgentCore uses Auth0 as the IdP via OIDC discovery, Auth0 machine-to-machine tokens authenticate agent-to-agent calls, an Auth0 Token Vault stores upstream tokens while AgentCore Identity runs the OAuth approval flow, and Auth0 FGA evaluates permissions at the time of each agent action (AWS, a reference integration).

That last clause is the prize: authorization is a runtime decision per action, not a static grant baked into a key at provisioning time.

The takeaway

Two rules retire the standing-key problem:

1. Issue short-lived credentials by default — AssumeRole gives you ~1-hour, scoped tokens with no long-lived secret to leak.
2. Broker tokens, don't pass them through — OBO exchange (RFC 8693/7523) lets an agent act downstream as a bounded delegate, with authorization evaluated per action against the real identity.

The technology has shipped. What's left is the discipline to use it — which is exactly what Part 4 turns into a checklist you can run this week.

Researched and drafted with AI assistance; STS durations and the AgentCore / Auth0 token-exchange details are cited to AWS documentation, and a human reviewed before publishing.