Quick answer
For AgentCore Gateway rate limiting, the key difference is whose identity appears on downstream requests.
- With on-behalf-of (OBO) token exchange from the incoming user token, downstream requests retain the original user’s identity. Existing role and user buckets can apply to the agent’s tool and model calls.
- With machine-to-machine (M2M) credentials, downstream requests carry the agent or service identity. User claims no longer identify the originating caller, so add a stable agent-specific bucket such as an authorized-party claim supported by your identity provider.
Limit both the initial agent invocation and the resources the agent consumes. One invocation can fan out into many model, MCP, or HTTP calls.
Two traffic layers
| Layer | What to protect | Useful dimensions |
|---|---|---|
| Agent invocation | how often and how long callers invoke the agent | agent targetName plus role or user |
| Downstream consumption | tools, models, and services called during execution | propagated user identity for OBO; agent identity for M2M; target/model/tool |
A healthy invocation rate does not imply healthy downstream usage. A planning agent might call search repeatedly and invoke several inference passes; model TPM and tool RPM need their own buckets.
OBO: user identity follows the work
AWS says that when the agent exchanges the incoming JWT on behalf of the user, downstream requests carry that user’s identity. A per-role or per-subject limit can therefore constrain both direct calls and the agent’s delegated calls when the same dimensions match.
Verify the actual token at each hop. OBO does not mean every upstream claim should be forwarded, nor does it expand what the user is authorized to do. Token scope, audience, expiry, AgentCore Policy, and downstream permissions remain decisive.
M2M: the agent becomes the caller
With a client-credentials or other machine-to-machine grant, the downstream token represents the agent or service. Limits based on the original user’s claims will not match those requests.
Use a stable, trusted claim that uniquely identifies the agent—AWS gives $.context.jwt.azp as an example, subject to the identity provider’s token contract. Pair it with targetName, toolName, or qualifiedModelId when different agents or resources need distinct allocations.
Do not place every agent behind one shared service identity unless a single shared bucket is truly intended. Otherwise, a noisy agent can starve unrelated workloads and attribution becomes weak.
Choose the model deliberately
Use OBO when downstream accounting and authorization should remain tied to the end user and the token exchange safely preserves that identity. Use M2M when the agent operates as an independent service principal with its own authority and capacity allocation.
Some systems need both: a user invokes an agent under a per-user bucket, while background processing uses a separate agent identity under a service bucket. Record the boundary explicitly and prevent a workflow from silently switching identity models.
Test the full call graph
For each path, capture:
- inbound user or service identity;
- agent target and invocation bucket;
- token exchange type;
- downstream identity claims;
- tool, model, or HTTP target dimensions;
- matching explicit and wildcard entries;
- AgentCore Policy result;
- throttling, retry, and observability behavior.
Test two users through one agent, two agents through one downstream model, identity-provider claim changes, unmatched callers, token expiry, and fail-open behavior. Rate-limit logs show evaluated buckets; they do not prove delegated authorization is correct.
Frequently asked questions
How do OBO calls affect AgentCore rate limits?
With an on-behalf-of token exchange based on the incoming user token, downstream requests carry the original user identity, so matching user and role rate limits can apply.
How do M2M calls affect AgentCore rate limits?
With a machine-to-machine grant, downstream requests carry the agent or service identity rather than the original user’s claims. Add stable agent-specific dimensions and limits.
Should an agent invocation limit also cover downstream consumption?
No. Limit the agent target and the tools, models, or HTTP targets it consumes. One agent invocation can fan out into multiple downstream requests.
Can rate limiting replace delegated authorization?
No. Rate limits are fail-open traffic controls. Keep token scope, authentication, AgentCore Policy, WAF, and downstream authorization separate.
Related guides
- AgentCore Gateway rate-limits guide
- OAuth and IAM dimensions
- RPS, RPM, TPM, and CPS guide
- Rate-limit planner
Official sources
- AWS AgentCore Gateway rate-limit configuration guide
- AgentCore on-behalf-of token exchange
- AgentCore machine-to-machine authentication
Source check: August 8, 2026. Verify current token-exchange, claim, audience, scope, Policy, quota, and logging behavior before production deployment.