AWS runs four JWT claim gates in one Lambda before an MCP tool call reaches its data

A call arrives at the Amazon Bedrock AgentCore Gateway, which provides the HTTP endpoint and the JWT validation layer between clients and the MCP tools ^[6]. Validation stops at the token. It establishes that the caller is who the token says, and AWS is direct that a valid single sign-on confirms who the caller is but not what they should be allowed to do ^[8]. The MFA gate shows what happens after that. The gate issues no challenge of its own; it looks for the claim saying a challenge already happened, and that claim exists because you configured the Entra ID applications, claims and policies the gates rely on ^[7].

AWS splits enforcement explicitly in one example. A regulated organization requires MFA at sign-in and denies access from unapproved countries; the identity provider enforces the first requirement and the authorization layer enforces the second ^[10]. The published overview does not identify which claim carries the caller's country.

Evaluation happens on every invocation. AWS describes each MCP tool invocation as an access event that can require authorization at the tool and parameter level in addition to a valid token ^[1], and says standard OAuth 2.0 identity verification does not enforce what callers can do at that level ^[9]. The failure the pattern is built against is a single over-broad token reaching tools and data beyond the caller's role ^[17].

A few things have to hold before the gate count means anything in another stack. Every path to the tools has to terminate at the gateway the interceptor is attached to, because a tool Lambda invoked directly skips every gate ^[5]. The identity provider has to emit each claim a gate reads, on every token, not only at first sign-in. And the permission model has to be expressible as group-to-role mapping plus a per-tool check, which fits a read/write boundary on a register and fits badly where the decision depends on data the tool has not fetched yet.

AWS names financial services, healthcare and government as the organizations that can require controls this granular for compliance audits ^[15]. The post's stated outcome is "an auditable, composable security layer that sits between the user's natural-language request and your business logic" ^[18]. In my view four claim comparisons in one Lambda you own are easier to evidence at an audit than the same rules copied into every tool function, including on a multi-tenant risk register on DynamoDB ^[11].