AWS bedrock-agentcore documentation change
Summary
Renamed 'No Authorization' to 'Offloaded inbound authorization' and restructured content. Added detailed explanations of offloaded authorization types (Authenticate-only and No Authorization), their security implications, and guidance for implementation. Included new section on onboarding existing runtimes without changing auth.
Security assessment
The changes significantly enhance security documentation by clarifying risks of offloaded authorization configurations. New warnings explicitly state that gateways without proper authorization components allow any caller access. Added guidance on production security best practices and token exchange patterns helps prevent misconfigurations. However, there's no evidence this addresses a specific disclosed vulnerability.
Diff
diff --git a/bedrock-agentcore/latest/devguide/gateway-inbound-auth.md b/bedrock-agentcore/latest/devguide/gateway-inbound-auth.md index c0a43b2d3..17ad83270 100644 --- a//bedrock-agentcore/latest/devguide/gateway-inbound-auth.md +++ b//bedrock-agentcore/latest/devguide/gateway-inbound-auth.md @@ -7 +7 @@ -IAM-based inbound authorizationJSON Web Token (JWT)-based inbound authorizationNo Authorization +IAM-based inbound authorizationJSON Web Token (JWT)-based inbound authorizationOffloaded inbound authorization @@ -17 +17 @@ Before you create your gateway, you must set up inbound authorization. Inbound a - * **Authenticate only** – The gateway authenticates inbound requests by verifying Signature Version 4 (SigV4) signatures, but does not perform any authorization. Any authenticated IAM principal can invoke the gateway regardless of their permissions. This is useful when you want the gateway to authenticate the caller’s identity while delegating authorization decisions to the downstream target service. + * **Offloaded authorization types** – The gateway makes no authorization decision of its own and instead offloads authorization to another component, such as the downstream target, a policy engine attached to the gateway, or an interceptor Lambda function. This category includes **Authenticate only** and **No Authorization**. For details and guidance, see Offloaded inbound authorization. @@ -22,8 +21,0 @@ Before you create your gateway, you must set up inbound authorization. Inbound a -###### Important - -With `AUTHENTICATE_ONLY`, the gateway does not enforce any authorization policies. Any valid SigV4-signed request will be forwarded to the target. Ensure that your downstream targets implement their own authorization logic, or attach a policy engine to the gateway to control access. Without proper authorization at the target or gateway policy level, any authenticated caller can reach your backend services. * **No Authorization** – The gateway will not perform any inbound authorization. This makes your gateway accessible to all users to be invoked. - -###### Important - -Do not use No Authorization gateways for production workloads unless you have implemented your own authentication mechanism, such as an interceptor Lambda function. See No Authorization for security best practices. - @@ -42 +34 @@ If you don’t plan to use the default authorization configuration using Amazon - * No Authorization + * Offloaded inbound authorization @@ -242 +234,46 @@ For self-managed Lattice, cross-account setups, and advanced configurations, see -## No Authorization +## Offloaded inbound authorization + +With offloaded inbound authorization, the gateway does not make any authorization decision of its own. Instead, it offloads authorization to another component: + + * The downstream target service, which authorizes the request it receives. + + * A policy engine attached to the gateway, which evaluates access policies. + + * An interceptor Lambda function, which runs your custom authentication or authorization logic before requests reach your targets. + + + + +AgentCore offers two offloaded types: + + * **Authenticate only** (`AUTHENTICATE_ONLY`) – The gateway verifies the caller’s SigV4 signature to authenticate the caller, but makes no authorization decision. Requests must be signed, but any authenticated caller is forwarded to the target. + + * **No Authorization** (`NONE`) – The gateway performs no inbound authentication or authorization. Requests can be unauthenticated, and any caller is forwarded to the target. + + + + +With either type, you decide where authorization is actually enforced: + + * **Policy engine** – Attach a policy engine to the gateway to evaluate access policies centrally. This is a recommended pattern for production gateways and is frequently used together with OAuth. + + * **Interceptor Lambda function** – Run your own authentication or authorization logic before requests reach your targets. This is recommended for production gateways when the built-in inbound authorization options do not meet your requirements. + + * **Downstream target** – Let the target enforce authorization on the request it receives. This is useful for experimentation and progressive onboarding — for example, putting a gateway in front of an existing runtime **without changing the runtime’s authentication and authorization** — so you can adopt gateway capabilities incrementally while the runtime continues to enforce the auth it already trusts. + + + + +###### Important + +If you offload inbound authorization by choosing either `AUTHENTICATE_ONLY` or `NONE`, AgentCore Gateway does not enforce authorization on its own. In this scenario, you must offload authorization to a separate component — a policy engine, an interceptor Lambda function, or the downstream target — otherwise any caller can reach your target. + +### Authenticate-only authorization + +With authenticate-only authorization (`AUTHENTICATE_ONLY`), the gateway verifies the caller’s Signature Version 4 (SigV4) signature to confirm their identity, but does not make any authorization decision of its own. Any authenticated IAM principal can invoke the gateway regardless of their permissions, and the request is forwarded to the target. Authorization is delegated to the downstream target service or to a policy engine attached to the gateway. + +###### Important + +With `AUTHENTICATE_ONLY`, the gateway does not enforce any authorization policies. Any valid SigV4-signed request will be forwarded to the target. Ensure that your downstream targets implement their own authorization logic, or attach a policy engine to the gateway to control access. Without proper authorization at the target or gateway policy level, any authenticated caller can reach your backend services. + +### No Authorization @@ -260,0 +298,19 @@ Do not use No Authorization gateways for production workloads unless you have im +### Onboard an existing runtime without changing its auth + +When you pair an offloaded inbound type with a matching outbound authorization type that forwards the caller’s identity to the runtime, onboarding to a gateway can be as simple as setting an endpoint override on your existing client — no auth changes required: + + * **IAM runtimes** – Combine `AUTHENTICATE_ONLY` inbound authorization with **Caller IAM credentials** (`CALLER_IAM_CREDENTIALS`) outbound authorization. The gateway authenticates the SigV4 caller and then signs the request to the runtime with that same caller identity, so the runtime’s existing IAM authorization continues to apply unchanged. For more information, see [Caller IAM credentials](./gateway-building-adding-targets-authorization.html#gateway-building-adding-targets-authorization-caller-iam). + + * **OAuth runtimes** – Combine **No Authorization** inbound authorization with **Token passthrough** (`JWT_PASSTHROUGH`) outbound authorization. The gateway forwards the inbound JWT to the runtime without modification, so the runtime validates the token exactly as it does today. (Token passthrough forwards a bearer token, so it requires a JWT-bearing inbound type — JWT inbound authorization or `NONE`. It is not available with `AUTHENTICATE_ONLY`, which is SigV4-based and carries no bearer token.) For more information, see [Token passthrough](./gateway-building-adding-targets-authorization.html#gateway-building-adding-targets-authorization-jwt-passthrough). + +###### Note + +Token passthrough (`JWT_PASSTHROUGH`) is **not** the recommended approach for production. When you forward the inbound token unchanged, the same token is accepted by both the gateway and the downstream target, so it should be tightly scoped — for example, each token’s audience (`aud`) should be restricted to the intended resource. The recommended pattern is [on-behalf-of (OBO) token exchange](./on-behalf-of-token-exchange.html), where the gateway exchanges the caller’s token for a fresh, audience-scoped token for the target instead of replaying the caller’s token. Use token passthrough for easy experimentation, testing, and onboarding, and move to OBO for long-term production workloads. + + + + +###### Warning + +The identity-forwarding configurations in this section rely solely on the downstream runtime to authorize requests; the gateway adds no authorization of its own. They are intended for testing, experimentation, and low-disruption onboarding. For a production gateway, enforce authorization at the gateway — configure JWT or IAM inbound authorization, attach a policy engine, or use an interceptor Lambda function. To ensure callers cannot bypass the gateway once you adopt it, see [Enforcing traffic through the gateway](./gateway-target-http-runtime.html#gateway-target-http-runtime-source-validation). +