Services Work Pricing Blog About Book a free call →
Blog

Cognito token exchange: what it changes for AI agents

Amazon Cognito now supports OAuth 2.0 token exchange. What it does, who should care, how to try it safely this week and what to check first.

7 min readAIAI agentsSecurity

On November 12, 2026, AWS announced OAuth 2.0 token exchange in Amazon Cognito. In short: when your service or AI agent acts for a signed-in user, it can now trade that user's token for a new one that is narrower in scope and meant for one downstream service. It no longer has to forward the user's original token. If you run an agent or an MCP server in front of your own APIs and your users sign in with Cognito, this is worth an hour of your time this week.

What was announced, and what was there before?

The announcement says Cognito now implements token exchange as defined in RFC 8693. AWS's own page uses a Model Context Protocol (MCP) server as the example: it exchanges a user's token for a narrow token to call a backend API.

Before, a service that wanted to call another service for a user had two usual options:

  • Forward the user's original token, which may be broader than the downstream service needs, or meant for a different audience.
  • Build its own token-minting logic, which means one more piece of security code to own.

The Cognito developer guide says the exchange is done by the GetDerivedToken API, which you can call with the AWS SDK or through the token endpoint. The announcement calls the API new.

How does the exchange work?

You present a subject token, the existing token for the user. Cognito returns a new access token or ID token for the downstream service. You can also present an actor token that represents the service doing the exchange.

The guide describes two modes, chosen per request:

  • Impersonation (no actor token): the issued token has no act claim. The downstream service cannot tell it from a request the user made directly.
  • Delegation (with an actor token): the token carries an act claim naming the intermediary. The service can apply its own rules to agents and record in audit logs that an agent made the call.

For an AI agent, delegation is usually the mode you want, because "the user did this" and "an agent did this for the user" are different facts in an audit trail.

What limits does the design put on the new token?

The guide lists a security model that matters more than the endpoint itself:

  • Down-scoping only. The issued scopes are the intersection of the scopes you request, the scopes in the subject token and the scopes the app client may issue. The exchange cannot add a scope.
  • No refresh token. The issued token is short lived. The guide's example shows expires_in of 3600 seconds. Plan your caching around that.
  • Subject token checks. Cognito validates the signature and expiration, checks for revocation such as a global sign-out, and requires the user to be enabled and confirmed.
  • Audience binding. You can bind the token to one audience and one resource, each validated against a resource server registered in your user pool.

One gap is stated in the guide: Cognito does not currently issue or evaluate the RFC 8693 may_act claim, which a token issuer could use to say in advance which actors may act for a user. So today, the decision about which agent may act for whom lives in your app client settings and your code, not in the original token.

Who should care, and who can ignore it?

Care if:

  • You expose tools to agents (an MCP server, an internal API gateway) and users sign in through a Cognito user pool.
  • Your agents currently carry the user's full token or a shared service credential.
  • Your users federate into Cognito from an OIDC or SAML identity provider. The guide says subject and actor tokens can come from a registered provider, as long as the user is already linked in the pool.
  • Customers or auditors ask how you separate agent actions from user actions.

Ignore it if:

  • You do not use Cognito for end users.
  • Your agents only run machine-to-machine jobs with no user in the loop. The guide says token exchange is distinct from machine-to-machine authorization, which authorizes an application rather than a user.

Cost and limits

The announcement page does not mention a price or quotas. What it does state, as of November 2026: token exchange is available on the Essentials and Plus feature plans, in all AWS Regions where Cognito is available. The guide adds that the feature must be enabled for your account, or the call returns an OperationNotEnabledException. Cognito bills per monthly active user (MAU). The Cognito pricing page lists, as of November 2026, $0.015 per MAU on Essentials above a 10,000 MAU free tier, and $0.020 per MAU on Plus with no free tier. Federated SAML or OIDC users cost $0.015 per MAU after 50 free. The page lists no separate charge for token exchange. A pool on the Lite plan would have to move up first. If a pool changes plan mid-month, each MAU is charged at the highest-priced plan enabled during that user's activity, so test in a separate pool.

How can a team try it safely this week?

  1. Use a test user pool, not production. Put it on the Essentials or Plus plan and confirm the feature is enabled for the account.
  2. Register one resource server with two scopes, for example one read and one write.
  3. Create two test app clients: one for sign-in, and one for the agent with only ALLOW_TOKEN_EXCHANGE_DELEGATION. Leave impersonation off.
  4. Get the two tokens. Sign in a test user for the subject token. For the actor token, use a token that identifies the agent; the guide accepts one issued by Cognito or by a registered external provider.
  5. Exchange with both tokens, requesting the read and write scopes while the subject token carries only read. The guide's rule says you should get only read back.
  6. Decode the issued token and confirm aud, scope, exp and the act claim.
  7. Make the backend log the act claim so you can see agent calls apart from user calls.
  8. Try to break it. Present an expired token and a token from a user after a global sign-out. Both should fail.

What would we check first before adopting it?

We start with these questions:

  • Which of your tools really need the user's identity, and which only need a service identity?
  • Is delegation enforced, or can any client with impersonation turned on skip the act claim?
  • Do your downstream services check aud and scope, or do they accept any valid Cognito token? Narrow tokens add nothing if nobody checks them.
  • How will you cache short-lived tokens, and what happens when an exchange fails in the middle of an agent run?
  • Does a pre token generation Lambda trigger already exist? The guide says it runs for exchanges with a distinct trigger source, so you can deny or adjust claims there.

If you want a second pair of senior eyes on how your agents authenticate to your APIs, our services page describes how we work.

This article is general information, not security or legal advice. Check the current AWS documentation and review your own design with a qualified professional.