Which gateway target takes which outbound authorization
An AgentCore gateway is an MCP server in front of its targets: a client lists and calls tools on the gateway, and the gateway calls the target with the target's own credentials - its outbound authorization. What a target can use depends on its type (as of 2026-09-30):
| Target | No authorization | Gateway service role (IAM) | Caller IAM credentials | OAuth client credentials | OAuth authorization code | OAuth token exchange | Token passthrough | API key |
|---|---|---|---|---|---|---|---|---|
| Lambda function | - | Yes | - | - | - | - | - | - |
| API Gateway REST API stage | Yes | Yes | - | - | - | - | - | Yes |
| OpenAPI schema | Yes | Yes | - | Yes | Yes | Yes | - | Yes |
| Smithy model | - | Yes | - | Yes | - | - | - | - |
| MCP server | Yes | Yes | - | Yes | Yes | Yes | - | Yes |
| AgentCore Runtime (HTTP) | - | Yes | Yes | Yes | - | - | Yes | - |
IAM with the gateway service role (GATEWAY_IAM_ROLE) signs the request with SigV4. For Lambda, API Gateway, Smithy and Runtime targets the gateway knows the service; for an MCP server or an OpenAPI API it needs the service name to sign for - bedrock-agentcore for AgentCore Runtime or another gateway, execute-api for API Gateway, lambda for a Lambda function URL. Anything that cannot verify SigV4, such as an Application Load Balancer or an EC2 instance, needs OAuth or an API key instead.
Inbound authorizer types and what they allow outbound
- JWT (
CUSTOM_JWT) - the gateway validates a bearer token against your identity provider's discovery URL and the allowed clients, audiences, scopes or claims. The AgentCore Token Flow Planner shows how each kind of client gets that token. - IAM (
AWS_IAM) - callers sign with SigV4 and needbedrock-agentcore:InvokeGatewayon the gateway. - Authenticate only (
AUTHENTICATE_ONLY) - the signature is checked, but any authenticated IAM principal gets through. - No authorization (
NONE) - anyone gets through.
With the last two the gateway authorizes nothing, so a policy engine on the gateway, an interceptor Lambda function or the target has to. Two outbound types depend on the inbound one: caller IAM credentials sign the target's request with the caller's own identity, so they need IAM or Authenticate only; token passthrough forwards the caller's JWT, so it needs JWT or No authorization. Paired that way, a gateway can front an existing runtime without changing its auth - AWS suggests it for onboarding and testing, and on-behalf-of token exchange instead of passthrough for production.
Credential providers for OAuth and API keys
An OAuth client or an API key is not written into the target. It is stored once in AgentCore Identity - a credential provider, in the gateway's account and Region, with its secret in AWS Secrets Manager - and the target refers to its ARN. The gateway service role then needs bedrock-agentcore:GetWorkloadAccessToken on the gateway's workload identity, GetResourceOauth2Token or GetResourceApiKey on the provider and secretsmanager:GetSecretValue on its secret; a role created by the console or the AgentCore CLI gets them on its own.
- Client credentials - a machine-to-machine token for the gateway itself.
- Authorization code - each user consents once; the browser comes back to your
defaultReturnUrl, and your application completes the flow for the signed-in user. - Token exchange - the gateway trades the caller's access token for one scoped to the target, carrying both the user and the agent.
The gateway's service role must be assumable by bedrock-agentcore.amazonaws.com; after the gateway exists, add aws:SourceAccount and aws:SourceArn conditions with its ARN to the trust policy.
Frequently asked questions
Is anything I choose sent anywhere?
No. The configuration is put together in your browser. The page only counts that the configurator was used, with which target type and which first problem.
Why does my Lambda function get a tool name with the target's name in front?
The gateway names each tool TARGET___TOOL, with three underscores, so tools of different targets cannot clash. The function receives that name in context.client_context.custom["bedrockAgentCoreToolName"] and should strip everything up to the delimiter before it decides which tool to run.
I changed my MCP server's tools - why does the gateway still list the old ones?
In the default listing mode the gateway lists a server's tools when the target is created or updated and keeps that list. Call SynchronizeGatewayTargets after every change, or set the target's listingMode to DYNAMIC to ask the server on each call.
A tool call returns "An internal error occurred" - how do I see the real error?
Turn on the gateway's debug messages (exceptionLevel DEBUG) while you develop; the AgentCore Error Decoder reads the messages it then returns, such as a Lambda target the service role may not invoke.
References
Set up outbound authorization for your gateway
Specify the authorization type and credentials to access the gateway target
Set up inbound authorization for your gateway
Supported targets for AgentCore gateways
Set up permissions for AgentCore Gateway