Enable Authorization on AgentCore Gateways

Risk Level: High (not acceptable risk)

Ensure that your Amazon Bedrock AgentCore gateways are configured with an authorization type other than NONE to control access to the tools and resources exposed through those gateways. Amazon Bedrock AgentCore gateways support three inbound authorization types: AWS IAM (AWS_IAM), which validates AWS IAM identity credentials and enforces IAM policies; Custom JWT (CUSTOM_JWT), which validates JSON Web Tokens issued by a supported identity provider such as Amazon Cognito, Okta, or any OpenID Connect-compatible provider; and No Authorization (NONE), which allows any caller to invoke the gateway without any form of authentication or authorization. By default, when a gateway is created with the NONE authorization type, any entity that can reach the gateway endpoint can invoke it and interact with its targets, including calling Lambda functions, querying API Gateway endpoints, and accessing MCP servers.

When authorization is enabled, AgentCore evaluates the credentials or token presented by the caller before routing requests to any of the gateway's targets. With AWS_IAM authorization, callers must have the bedrock-agentcore:InvokeGateway permission on the specific gateway resource. With CUSTOM_JWT authorization, callers must present a valid JWT issued by the configured identity provider and meeting all claims restrictions such as allowed audiences, clients, and scopes. Either option ensures that only authenticated and authorized identities can interact with your AI agents' tooling layer through the gateway.

Security

Enabling authorization on Amazon Bedrock AgentCore gateways is critical to preventing unauthorized access to your AI agent infrastructure. A gateway with no authorization (NONE) is effectively a public endpoint — any caller who knows or can discover the gateway URL can invoke its targets without presenting any credentials. This exposes potentially sensitive tools and backend services to unauthenticated actors, enabling unauthorized data retrieval, abuse of backend Lambda functions, and exploitation of any API endpoints registered as gateway targets.

Authorization also provides an audit trail that connects gateway invocations to specific identities. With IAM authorization, all requests are logged in AWS CloudTrail under the caller's IAM identity; with JWT authorization, the JWT subject claim is recorded in CloudTrail gateway events. This traceability is essential for incident investigation, compliance auditing, and detecting anomalous access patterns. Enabling authorization is a foundational security control that should be in place for all gateways, regardless of whether the gateway operates in development or production.

Audit

To determine if your Amazon Bedrock AgentCore gateways have authorization enabled, perform the following operations:

Using AWS Console

01 Sign in to the AWS Management Console.

02 Navigate to the Amazon Bedrock AgentCore console available at https://console.aws.amazon.com/bedrock-agentcore/home#.

03 In the left navigation pane, select Gateways.

04 Review the list of gateways in the selected AWS region.

05 Select the gateway you want to examine by clicking on its name.

06 In the gateway details page, locate the Inbound Auth configurations section.

07 Review the Authorization type field. If the value is None, the selected gateway does not have authorization enabled and is accessible to any caller.

08 Repeat steps no. 5 – 7 for each gateway available in the selected AWS region.

09 Change the AWS cloud region from the console navigation bar and repeat the Audit process for other regions.

Using AWS CLI

01 Run list-gateways command (OSX/Linux/UNIX) to list all Amazon Bedrock AgentCore gateways available in the selected AWS region:

aws bedrock-agentcore-control list-gateways
	--region us-east-1
	--query 'items[*].gatewayId'

02 The command output should return the requested gateway identifiers:

[
	"cc-agentcore-gateway-aBcDeFgHiJ",
	"cc-tools-gateway-kLmNoPqRsT"
]

03 Run get-gateway command (OSX/Linux/UNIX) with the ID of the Amazon Bedrock AgentCore gateway that you want to examine as the identifier parameter and output query filters to retrieve the authorization type for the selected gateway:

aws bedrock-agentcore-control get-gateway
	--region us-east-1
	--gateway-identifier cc-agentcore-gateway-aBcDeFgHiJ
	--query 'authorizerType'

04 The command output should return the authorization type configured for the gateway:

"NONE"

If the get-gateway command output returns "NONE" for the authorizerType attribute, as shown in the example above, the selected Amazon Bedrock AgentCore gateway does not have authorization enabled, meaning any caller can invoke the gateway without authentication.

05 Repeat steps no. 3 and 4 for each gateway available in the selected AWS region.

06 Change the AWS cloud region by updating the --region command parameter value and repeat steps no. 1 – 5 to perform the Audit process for other regions.

Remediation / Resolution

To enable authorization on your Amazon Bedrock AgentCore gateways, perform the following operations:

Amazon Bedrock AgentCore gateways support two authorization types: AWS IAM (AWS_IAM) and Custom JWT (CUSTOM_JWT). With IAM authorization, callers must hold an IAM identity with the bedrock-agentcore:InvokeGateway permission scoped to the gateway resource. With Custom JWT authorization, you must first set up a compatible identity provider (such as Amazon Cognito, Okta, Auth0, or Microsoft Entra ID) and provide the OIDC discovery URL to AgentCore. If you do not have an existing OIDC identity provider, see Option 2 in the AWS CLI remediation section below for complete instructions to set up Amazon Cognito from scratch using a machine-to-machine (M2M) client_credentials flow — the recommended approach for server-to-server (agent-invoking-gateway) scenarios.

Important: The authorizerType property of an Amazon Bedrock AgentCore gateway is immutable — it cannot be changed after the gateway has been created. If your gateway was created with authorizerType = NONE, you must delete the existing gateway and recreate it with the desired authorization type (CUSTOM_JWT or AWS_IAM). Make sure to note any existing gateway targets (Lambda functions, API Gateway endpoints, MCP servers) so you can reattach them to the new gateway.

Using AWS CloudFormation

01 Use the following AWS CloudFormation template to create (or update) an Amazon Bedrock AgentCore gateway with CUSTOM_JWT authorization enabled:

{
	"AWSTemplateFormatVersion": "2010-09-09",
	"Description": "Enable JWT authorization on an Amazon Bedrock AgentCore gateway.",
	"Resources": {
		"AgentCoreGateway": {
			"Type": "AWS::BedrockAgentCore::Gateway",
			"Properties": {
				"Name": "cc-agentcore-gateway",
				"Description": "AgentCore gateway with JWT authorization enabled",
				"RoleArn": "arn:aws:iam::123456789012:role/AgentCoreGatewayRole",
				"ProtocolType": "MCP",
				"AuthorizerType": "CUSTOM_JWT",
				"AuthorizerConfiguration": {
					"CustomJWTAuthorizer": {
						"DiscoveryUrl": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_Example123/.well-known/openid-configuration",
						"AllowedAudience": [
							"cc-agentcore-client"
						],
						"AllowedClients": [
							"cc-agentcore-client"
						]
					}
				}
			}
		}
	}
}

02 Use the following AWS CloudFormation template in YAML format:

AWSTemplateFormatVersion: "2010-09-09"
Description: Enable JWT authorization on an Amazon Bedrock AgentCore gateway.
Resources:
	AgentCoreGateway:
		Type: AWS::BedrockAgentCore::Gateway
		Properties:
		Name: cc-agentcore-gateway
		Description: AgentCore gateway with JWT authorization enabled
		RoleArn: arn:aws:iam::123456789012:role/AgentCoreGatewayRole
		ProtocolType: MCP
		AuthorizerType: CUSTOM_JWT
		AuthorizerConfiguration:
			CustomJWTAuthorizer:
			DiscoveryUrl: https://cognito-idp.us-east-1.amazonaws.com/us-east-1_Example123/.well-known/openid-configuration
			AllowedAudience:
				- cc-agentcore-client
			AllowedClients:
				- cc-agentcore-client

Using Terraform (AWS Provider)

01 Use the following Terraform configuration to create an Amazon Bedrock AgentCore gateway with CUSTOM_JWT authorization enabled:

terraform {
	required_providers {
		aws = {
			source  = "hashicorp/aws"
			version = "~> 5.0"
		}
	}
	required_version = ">= 1.3.0"
}

provider "aws" {
	profile = "default"
	region  = "us-east-1"
}

resource "aws_bedrockagentcore_gateway" "cc_agentcore_gateway" {
	name          = "cc-agentcore-gateway"
	description   = "AgentCore gateway with JWT authorization enabled"
	role_arn      = "arn:aws:iam::123456789012:role/AgentCoreGatewayRole"
	protocol_type = "MCP"
	authorizer_type = "CUSTOM_JWT"

	authorizer_configuration {
		custom_jwt_authorizer {
			discovery_url    = "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_Example123/.well-known/openid-configuration"
			allowed_audience = ["cc-agentcore-client"]
			allowed_clients  = ["cc-agentcore-client"]
		}
	}
}

Using AWS Console

Important: The Authorization type of an Amazon Bedrock AgentCore gateway cannot be changed after creation. You must delete the non-compliant gateway and create a new one with the desired authorization type. Before deleting, note all existing targets attached to the gateway so you can reattach them to the new gateway.

01 Sign in to the AWS Management Console.

02 Navigate to the Amazon Bedrock AgentCore console available at https://console.aws.amazon.com/bedrock-agentcore/home#.

03 In the left navigation pane, select Gateways.

04 Select the non-compliant gateway identified in the Audit section (see Audit section part I to identify the right resource).

05 Note the gateway's current targets, name, and role ARN — you will need these when creating the replacement gateway.

06 Choose Delete to remove the non-compliant gateway and confirm the deletion.

07 Choose Create gateway to create a new gateway with the same name and role ARN.

08 In the Inbound Auth configurations section, select either IAM identity or JSON Web Token (JWT) as the authorization type:

If you select IAM identity, ensure that the callers of this gateway have an IAM policy granting bedrock-agentcore:InvokeGateway on the new gateway's ARN.
If you select JSON Web Token (JWT), provide the Discovery URL of your OIDC-compatible identity provider (e.g., Amazon Cognito) and configure the Allowed audiences and Allowed clients to restrict which token recipients may invoke the gateway.

09 Re-attach all previously noted gateway targets.

10 Choose Create to finish creating the new compliant gateway.

11 Repeat steps no. 4 – 10 for each gateway that has no authorization configured.

12 Change the AWS cloud region from the console navigation bar and repeat the Remediation process for other regions.

Using AWS CLI

Important: The authorizerType property of an Amazon Bedrock AgentCore gateway is immutable — it cannot be changed after the gateway is created. To remediate a gateway with NONE authorization, you must delete it and recreate it with the desired authorization type.

The create-gateway command requires all mandatory gateway configuration parameters. Choose one of the following two approaches depending on whether you have an existing OIDC-compatible identity provider or need to set one up from scratch using Amazon Cognito.

Option 1: Custom JWT — Using an Existing OIDC Identity Provider

Use this approach if you already have an OIDC-compatible identity provider (e.g., Okta, Auth0, Microsoft Entra ID, or an existing Amazon Cognito user pool) and know its discovery URL and client identifiers.

01 Record the existing gateway configuration (see Audit section part II to identify the right resource). Note the --name, --role-arn, and any targets attached to the gateway:

aws bedrock-agentcore-control get-gateway \
	--region us-east-1 \
	--gateway-identifier <gateway-identifier>

02 Run delete-gateway command (OSX/Linux/UNIX) to remove the non-compliant gateway:

aws bedrock-agentcore-control delete-gateway \
	--region us-east-1 \
	--gateway-identifier <gateway-identifier>

03 Run create-gateway command (OSX/Linux/UNIX) to recreate the gateway with CUSTOM_JWT authorization enabled. Replace the --name and --role-arn parameter values with the values from your existing gateway, and set the discoveryUrl and allowedClients values from your identity provider:

aws bedrock-agentcore-control create-gateway \
	--region us-east-1 \
	--name cc-agentcore-gateway \
	--role-arn arn:aws:iam::<account-id>:role/<AgentCoreGatewayRoleName> \
	--protocol-type MCP \
	--authorizer-type CUSTOM_JWT \

Notes:

The discoveryUrl must end with /.well-known/openid-configuration and its issuer value must match the iss claim in incoming JWT tokens.
At least one of allowedAudience, allowedClients, or allowedScopes must be provided. Both allowedAudience and allowedClients can be supplied together if your IDP issues distinct aud and client_id claims.
To use AWS_IAM authorization instead, omit --authorizer-configuration and set --authorizer-type to AWS_IAM.

04 The command output should return the new gateway information with the authorization type set:

{
	"gatewayArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/cc-agentcore-gateway-kLmNoPqRsT",
	"gatewayId": "cc-agentcore-gateway-kLmNoPqRsT",
	"name": "cc-agentcore-gateway",
	"status": "CREATING",
	"authorizerType": "CUSTOM_JWT",
	"createdAt": "2026-03-13T10:00:00Z",
	"updatedAt": "2026-03-13T10:00:00Z"
}

05 Re-attach any gateway targets that were previously configured on the deleted gateway.

06 Repeat steps no. 1 – 5 for each gateway that does not have authorization enabled, available in the selected AWS region.

07 Change the AWS cloud region by updating the --region command parameter value and repeat the Remediation process for other regions.

Option 2: Amazon Cognito — Complete Setup from Scratch

Use this approach if you do not have an existing OIDC identity provider and need to create one. The following steps create an Amazon Cognito user pool, a custom resource server with OAuth 2.0 scopes, a machine-to-machine (M2M) app client using the client_credentials grant, and then recreate the gateway to use it as the JWT authorizer. This approach is recommended for server-to-server (agent-to-gateway) scenarios.

Step 1: Record existing gateway configuration and delete the non-compliant gateway

01 Record the existing gateway configuration (see Audit section part II to identify the right resource). Note the --name, --role-arn, and any targets attached to the gateway:

aws bedrock-agentcore-control get-gateway \
	--region us-east-1 \
	--gateway-identifier <gateway-identifier>

02 Run delete-gateway command (OSX/Linux/UNIX) to remove the non-compliant gateway:

aws bedrock-agentcore-control delete-gateway \
	--region us-east-1 \
	--gateway-identifier <gateway-identifier>

Step 2: Create a Cognito user pool and M2M app client

Run the following commands to create the Cognito resources. Record the output values — you will need them in Step 3.

# Create a Cognito user pool
export POOL_ID=$(aws cognito-idp create-user-pool \
	--pool-name "cc-agentcore-user-pool" \
	--region us-east-1 \
	--query 'UserPool.Id' \
	--output text)

echo "User Pool ID: $POOL_ID"

# Create a resource server (defines the M2M scopes the gateway will validate)
# Note: Use a simple non-URL string for --identifier. The AWS CLI attempts to
# resolve https:// prefixed values as remote URLs, which causes a parse error.
aws cognito-idp create-resource-server \
	--user-pool-id $POOL_ID \
	--identifier "bedrock-agentcore" \
	--name "bedrock-agentcore" \
	--scopes '[{"ScopeName":"invoke","ScopeDescription":"Invoke AgentCore Gateway"}]' \
	--region us-east-1

# Create a hosted domain for the Cognito OAuth token endpoint
# The domain prefix must be globally unique — append a short random suffix
export DOMAIN_PREFIX="cc-agentcore-$(openssl rand -hex 4)"
aws cognito-idp create-user-pool-domain \
	--domain "$DOMAIN_PREFIX" \
	--user-pool-id $POOL_ID \
	--region us-east-1

# Create a machine-to-machine app client (server-to-server, with secret)
export CLIENT_ID=$(aws cognito-idp create-user-pool-client \
	--user-pool-id $POOL_ID \
	--client-name "cc-agentcore-m2m-client" \
	--generate-secret \
	--allowed-o-auth-flows client_credentials \
	--allowed-o-auth-scopes "bedrock-agentcore/invoke" \
	--allowed-o-auth-flows-user-pool-client \
	--region us-east-1 \
	--query 'UserPoolClient.ClientId' \
	--output text)

echo "Client ID: $CLIENT_ID"

# Retrieve the client secret for token requests
export CLIENT_SECRET=$(aws cognito-idp describe-user-pool-client \
	--user-pool-id $POOL_ID \
	--client-id $CLIENT_ID \
	--region us-east-1 \
	--query 'UserPoolClient.ClientSecret' \
	--output text)

echo "Discovery URL: https://cognito-idp.us-east-1.amazonaws.com/$POOL_ID/.well-known/openid-configuration"

Step 3: (Optional) Obtain a client credentials token to test the setup

Use the Cognito hosted UI token endpoint to exchange client credentials for a JWT access token. This token can be presented to the gateway to verify that the authorization flow works end-to-end.

# Request an access token using the client credentials grant
export TOKEN_RESPONSE=$(curl -s -X POST \
	"https://$DOMAIN_PREFIX.auth.us-east-1.amazoncognito.com/oauth2/token" \
	--header "Content-Type: application/x-www-form-urlencoded" \
	--data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=bedrock-agentcore/invoke")

echo $TOKEN_RESPONSE

# Extract the access token
export ACCESS_TOKEN=$(echo $TOKEN_RESPONSE | python3 -c \
	"import sys, json; print(json.load(sys.stdin)['access_token'])")
echo "Access Token (use as Bearer in Authorization header): $ACCESS_TOKEN"

Step 4: Recreate the gateway with Cognito JWT authorization

01 Run create-gateway command (OSX/Linux/UNIX) to recreate the gateway with the Cognito user pool as the JWT identity provider. Replace the --name and --role-arn values with those recorded from the deleted gateway:

aws bedrock-agentcore-control create-gateway \
	--region us-east-1 \
	--name cc-agentcore-gateway \
	--role-arn arn:aws:iam::<account-id>:role/<AgentCoreGatewayRoleName> \
	--protocol-type MCP \
	--authorizer-type CUSTOM_JWT \
	--authorizer-configuration "{\"customJWTAuthorizer\":{\"discoveryUrl\":\"https://cognito-idp.us-east-1.amazonaws.com/$POOL_ID/.well-known/openid-configuration\",\"allowedClients\":[\"$CLIENT_ID\"]}}"

02 The command output should return the new gateway information:

{
	"gatewayArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/cc-agentcore-gateway-kLmNoPqRsT",
	"gatewayId": "cc-agentcore-gateway-kLmNoPqRsT",
	"name": "cc-agentcore-gateway",
	"status": "CREATING",
	"authorizerType": "CUSTOM_JWT",
	"createdAt": "2026-03-13T10:00:00Z",
	"updatedAt": "2026-03-13T10:00:00Z"
}

03 Re-attach any gateway targets that were previously configured on the deleted gateway.

04 Repeat steps 1 and 2 of **Step 4** for each gateway that does not have authorization enabled, available in the selected AWS region.

05 Change the AWS cloud region by updating the --region command parameter value and repeat the Remediation process for other regions.

References

AWS Command Line Interface (CLI) Documentation
list-gateways
get-gateway
create-gateway
delete-gateway

CloudFormation Documentation
AWS::BedrockAgentCore::Gateway
AWS::BedrockAgentCore::Gateway AuthorizerConfiguration
AWS::BedrockAgentCore::Gateway CustomJWTAuthorizerConfiguration

Terraform Documentation
Data Source: aws_iam_policy_document

Publication date Mar 17, 2026

Audit

Using AWS Console

Using AWS CLI

Remediation / Resolution

Using AWS CloudFormation

Using Terraform (AWS Provider)

Using AWS Console

Using AWS CLI

References

Related BedrockAgentCore rules