FREE TOOL

AgentCore Gateway Target Configurator

Pick an Amazon Bedrock AgentCore Gateway target - Lambda, API Gateway, OpenAPI, Smithy, MCP server or Runtime - and see which outbound auth it takes, the credential provider, the create-gateway-target command and the service role policy.

  • Your data never leaves your browser: everything is calculated by JavaScript on this page, not on a server.
  • Nothing you enter is uploaded, processed on a server or stored. Check it in your browser's developer tools (Network tab).
  • Once the page has loaded, the tool works without an internet connection.

Target type

What the gateway calls when an MCP client uses one of the target's tools.

Gateway inbound authorization

How callers authenticate to the gateway - set once for the whole gateway. Some outbound types depend on it.

Outbound authorization

How the gateway authenticates to this target. Types the target does not take are dimmed.

See the configuration ↓
Authorizing API calls with IAM and OAuth is an AWS Developer Associate topicTry free DVA-C02 practice questions with answers and explanations.DVA-C02 questions →

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):

TargetNo authorizationGateway service role (IAM)Caller IAM credentialsOAuth client credentialsOAuth authorization codeOAuth token exchangeToken passthroughAPI key
Lambda function-Yes------
API Gateway REST API stageYesYes-----Yes
OpenAPI schemaYesYes-YesYesYes-Yes
Smithy model-Yes-Yes----
MCP serverYesYes-YesYesYes-Yes
AgentCore Runtime (HTTP)-YesYesYes--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 need bedrock-agentcore:InvokeGateway on 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