Securing Agentic AI on Amazon Bedrock AgentCore: Zero-Trust Private Networking and Identity Patterns
Learn how to secure agentic AI applications on Amazon Bedrock AgentCore using VPC interface endpoints, VPC Lattice private egress, and AgentCore Identity's OAuth On-Behalf-Of token exchange. This guide covers network isolation, least-privilege access control, zero-trust identity, and observability: everything you need to deploy autonomous agents at enterprise scale.
A Practical Guide to Private Flows, Identity, and Zero-Trust Architecture
Agentic AI applications represent a significant development in enterprise automation, where intelligent agents autonomously execute complex workflows, access sensitive datasets, and make real-time decisions across your organization's infrastructure. Amazon Bedrock AgentCore accelerates enterprise AI transformation by providing fully managed services that remove infrastructure complexity, maintain session isolation, and enable seamless integration with enterprise tools — so organizations can deploy trustworthy AI agents at scale.
In production environments, AI agents are typically deployed within Virtual Private Clouds (VPCs) to maintain secure, isolated network access and to meet enterprise security and compliance requirements. This post walks through how to secure an agentic AI application end-to-end using AgentCore Gateway and AgentCore Identity, with a particular focus on keeping flows private and implementing zero-trust principles at every layer.
The Threat Model: What Are We Actually Protecting Against?
Before diving into AWS services, it's worth being explicit about the risks:
- Network interception — agent-to-gateway traffic exposed on the public internet
- Unauthorized tool access — any caller reaching your MCP tools, not just your agents
- Token leakage — credentials or bearer tokens exposed in transit or logs
- Privilege escalation — an agent acting beyond the scope of the user it serves
- Lateral movement — a compromised agent pivoting to downstream resources
Each of these has a corresponding control in the AgentCore stack.
The Architecture at a Glance
The architecture illustrates agents deployed across various AWS compute services — EC2 instances, Lambda functions, Amazon EKS, Amazon ECS, or preferably AgentCore Runtime — all operating within a VPC. These agents communicate with AgentCore Gateway to discover, access, and invoke external tools and services that have been transformed into agent-compatible resources.
In the default setup, traffic between agents and AgentCore Gateway flows over the public internet — which may raise security and compliance concerns for sensitive or regulated workloads.
To address this, organizations can deploy Interface VPC Endpoints powered by AWS PrivateLink, redirecting all communications through AWS's private internal network backbone rather than exposing them to the public internet. This approach brings several key benefits:
- Enhanced security — traffic never leaves the AWS network, significantly reducing the attack surface.
- Reduced latency — private routing eliminates unnecessary hops through the public internet, resulting in faster and more predictable response times.
- Improved compliance alignment — for industries subject to strict data residency or network isolation requirements (e.g., financial services), keeping traffic within a private network boundary helps meet regulatory obligations more easily.
This architecture pattern is particularly recommended for production environments handling confidential data or operating under frameworks such as GDPR, or similar standards.
The solution follows this workflow:
1. AI agent interaction — An agent running within the VPC obtains the required inbound authorization from identity providers, authenticates with Gateway, and sends a tool-use request (invokes the MCP tool) to the gateway through the interface VPC endpoint.
2. Gateway processing — Gateway manages OAuth authorization to ensure only valid users and agents can access tools and resources. It converts agent requests using protocols like MCP into API requests and Lambda invocations.
3. Secure access — The gateway handles credential injection for each tool, enabling agents to use tools with different authentication requirements seamlessly. It uses AgentCore Identity to securely access backend resources on behalf of the agent.
4. Target execution — The gateway data plane invokes the target, which can be a Lambda function, an OpenAPI specification, an MCP server running on AgentCore runtime, an API Gateway, etc.
5. Monitoring — AgentCore Gateway provides built-in observability and auditing. You can optionally enable VPC Flow Logs for logging IP traffic.
Key Scope Clarification: Data Plane vs. Control Plane
One important distinction before going further: interface VPC endpoint support applies only to the data plane endpoints of your gateway — the runtime endpoints where your applications interact with agent tools. Control plane operations such as creating gateways, managing tools, and configuring security settings must still be performed through the standard public AgentCore control plane endpoint (e.g.,
bedrock-agentcore-control.<region>.amazonaws.com ).Network Flow Privacy Reference
The table below summarizes every significant flow in an AgentCore agentic application, its default routing, whether it can be made private, and the mechanism to do so.
Flow | Direction | Default | Can Be Private? | How |
|---|---|---|---|---|
Agent → AgentCore Gateway (data plane) | Ingress | 🔴 Public internet | ✅ Yes | VPC Interface Endpoint (AWS PrivateLink) |
AgentCore control plane (create/manage gateways) | Ingress | 🔴 Public internet | ❌ No | By design — control plane only |
AgentCore Gateway → Lambda target | Egress | 🟢 AWS Backbone | ✅ Already private | Native — no config needed |
AgentCore Gateway → AgentCore Runtime target | Egress | 🟢 AWS Backbone | ✅ Already private | Native — stays on AWS backbone |
AgentCore Gateway → API Gateway target (regional) | Egress | 🟢 AWS Backbone | ✅ Already private | Native — stays on AWS backbone |
AgentCore Gateway → Private REST API (API GW) | Egress | 🔴 Public internet | ✅ Yes | OpenAPI target + VPC Lattice + routingDomain |
AgentCore Gateway → Self-hosted MCP server (VPC) | Egress | 🔴 Public internet | ✅ Yes | VPC Lattice privateEndpoint (managed or self-managed) |
AgentCore Gateway → External MCP server (outside AWS) | Egress | 🔴 Public internet | ❌ No | Provider is external — TLS only |
OAuth token retrieval → Self-hosted IdP (VPC) | Egress (Identity) | 🔴 Public internet | ✅ Yes | AgentCore Identity + VPC Lattice privateEndpoint |
OAuth token retrieval → External IdP (Azure AD, Okta...) | Egress (Identity) | 🔴 Public internet | ❌ No | Provider is external — TLS only |
JWKS key fetching → Self-hosted IdP (VPC) | Egress (Identity) | 🔴 Public internet | ✅ Yes | AgentCore Identity + VPC Lattice privateEndpoint |
JWKS key fetching → External IdP (Azure AD, Okta...) | Egress (Identity) | 🔴 Public internet | ❌ No | Provider is external — TLS only |
VPC Flow Logs → CloudWatch / S3 | Monitoring | 🟢 AWS Backbone | ✅ Already private | Native AWS service |
Gateway audit logs → CloudWatch | Monitoring | 🟢 AWS Backbone | ✅ Already private | Native AWS service |
Legend: 🔴 Public internet by default — 🟢 Already private by default — ✅ Can be made private — ❌ Cannot be made private (external dependency)
The key takeaway: a fully private agentic architecture is achievable on AgentCore when all components — agents, tools, and identity providers — live within AWS or your VPC. The only flows that are permanently public are those involving providers or services hosted entirely outside AWS, where the public internet is an unavoidable dependency.
Layer 1: Network Isolation with VPC Interface Endpoints
Step 1 — Security Group for the EC2 Agent Instance
Create a dedicated security group (
ec2-agent-sg ) for your EC2/ECS/EKS agent instances. Leave outbound rules as default (all traffic allowed) to ensure agents can communicate with necessary services.resource "aws_security_group" "ec2_agent_sg" { name = "ec2-agent-sg" description = "Security group for EC2 instances running AI agents" vpc_id = var.vpc_id
ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = [var.management_cidr] description = "SSH from management network" }
egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] }}Step 2 — Security Group for the VPC Endpoint
Create a second security group (
vpce-agentcore-sg ) that will be attached to the AgentCore Gateway interface VPC endpoint. This implements the principle of least privilege: only EC2 instances with the agent security group can access the VPC endpoint, blocking unauthorized access from other resources in the VPC.resource "aws_security_group" "vpce_agentcore_sg" { name = "vpce-agentcore-sg" description = "Security group for AgentCore Gateway VPC endpoint" vpc_id = var.vpc_id
ingress { from_port = 443 to_port = 443 protocol = "tcp" security_groups = [aws_security_group.ec2_agent_sg.id] description = "HTTPS from agent instances only" }
egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] }}Step 3 — Create the Interface VPC Endpoint
Navigate to the Amazon VPC console and create an interface endpoint targeting the AgentCore Gateway service. Enable private DNS so your agents can use the standard gateway URL while AWS silently routes traffic through the private endpoint — no code changes required.
aws ec2 create-vpc-endpoint \ --vpc-id vpc-xxxxxxxx \ --service-name com.amazonaws.<region>.bedrock-agentcore.gateway \ --vpc-endpoint-type Interface \ --subnet-ids subnet-xxxxxxxx \ --security-group-ids sg-vpce-agentcore \ --private-dns-enabledAfter creation (~2–5 minutes), verify that DNS now resolves to a private IP address:
# Before VPC endpoint: resolves to a public IPnslookup <gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com# Address: 52.86.152.150 ← public
# After VPC endpoint with private DNS enabled: resolves to a private IPnslookup <gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com# Address: 172.31.91.174 ← private, within your VPC CIDRNote: When you enable private DNS for AgentCore Gateway VPC interface endpoints, AWS automatically enables the "Enable private DNS only for inbound endpoints" option by default.
Step 4 — Configure the Endpoint Access Policy
VPC endpoint policies add a resource-level data perimeter on top of network controls. For initial testing, you can leave the policy set to full access. In production, restrict it to specific gateway ARNs:
{ "Version": "2012-10-17", "Statement": [ { "Principal": "*", "Effect": "Allow", "Action": "*", "Resource": "arn:aws:bedrock-agentcore:<region>:<account-id>:gateway/<gateway-id>" } ]}Important: ThePrincipalfield cannot be restricted further because AgentCore Gateway uses bearer token authentication rather than IAM principals. TheResourcerestriction is your key control here. Also avoid specifying control plane operations in theActionfield — use a wildcard to allow the necessary data plane operations.
Policy caching: AgentCore Gateway caches access policies, introducing a delay of up to 15 minutes before policy changes take effect. Always test policy changes in non-production environments first, schedule modifications during planned maintenance windows, and factor in this delay when diagnosing access-related issues.
Layer 2: Testing the Private Connection
With Private DNS Enabled (Recommended)
When private DNS is enabled, your applications seamlessly use the standard gateway URL while traffic automatically routes through the VPC endpoint:
curl -sS -i -X POST \ https://<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp \ --header 'Content-Type: application/json' \ --header "Authorization: Bearer $TOKEN" \ --data '{ "jsonrpc": "2.0", "id": "'$UNIQUE_ID'", "method": "tools/list", "params": {} }'With Private DNS Disabled
When private DNS is disabled, you must route traffic through the VPC endpoint DNS name and include the original gateway domain in the
Host header:curl -sS -i -X POST https://<vpce-dns-name>/mcp \ --header "Host: <gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com" \ --header 'Content-Type: application/json' \ --header "Authorization: Bearer $TOKEN" \ --data '{ "jsonrpc": "2.0", "id": "'$UNIQUE_ID'", "method": "tools/list", "params": {} }'Full Agent Test with the Strands SDK
The following Python script tests the complete AgentCore Gateway workflow — discovering available tools, creating a Strands Agent, and invoking tools through the private endpoint:
from strands.models import BedrockModel
from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp.mcp_client import MCPClient
from strands import Agent
import logging
import os
token = os.getenv('TOKEN')
gatewayURL = os.getenv('GATEWAY_URL') # VPC endpoint URL
gatewayHost = os.getenv('GATEWAY_HOST') # Original AgentCore Gateway domain
def create_streamable_http_transport():
"""Create HTTP transport with authentication headers (private DNS disabled mode)."""
return streamablehttp_client(
gatewayURL,
headers={
"Authorization": f"Bearer {token}",
"Host": gatewayHost
}
)
client = MCPClient(create_streamable_http_transport)
model = BedrockModel(model_id="amazon.nova-pro-v1:0", temperature=0.7)
logging.getLogger("strands").setLevel(logging.INFO)
logging.basicConfig(format="%(levelname)s | %(name)s | %(message)s",
handlers=[logging.StreamHandler()])
with client:
target_name = 'FinancialServicesGatewayTarget'
tools = client.list_tools_sync()
agent = Agent(model=model, tools=tools)
print(f"Tools loaded: {agent.tool_names}")
# List available financial tools
response1 = agent("Hi, can you list all tools available to you?")
print(f"Tool listing response: {response1}")
# Query portfolio risk exposure for a specific client
response2 = agent("Retrieve the current portfolio risk exposure for client ID C-48291 and summarize the top 3 risk factors")
print(f"Portfolio risk response: {response2}")
# Direct MCP tool invocation for validation
result = client.call_tool_sync(
tool_use_id="get-portfolio-risk-call-1",
name=f"{target_name}___get_portfolio_risk",
arguments={"client_id": "C-48291", "risk_metrics": ["var", "beta", "sharpe_ratio"]}
)
print(f"Direct MCP tool response: {result}")Set the required environment variables before running:
export GATEWAY_URL=https://<vpce-id>.gateway.bedrock-agentcore.<region>.vpce.amazonaws.com/mcpexport TOKEN=<your-bearer-token>export GATEWAY_HOST=<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com
python agent.pyNB: For production environments, you'd go one step further and avoid even storing the token in a shell variable, instead pulling it dynamically from AWS Secrets Manager or AWS Systems Manager Parameter Store at runtime, so the token is never exposed.
Layer 3: Securing Egress — Private Connectivity to Tool Targets
AgentCore Gateway doesn't just secure inbound agent traffic — it also supports private egress to tool targets inside your VPC, using Amazon VPC Lattice as explained in this documentation: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-vpc-egress.html . This means your MCP servers, internal APIs, and other backend resources never need to be exposed to the public internet.
Private MCP Server Targets
For self-hosted MCP servers running inside your VPC, configure a
privateEndpoint on the gateway target:{ "name": "my-private-mcp-target", "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0abc123def456", "subnetIds": ["subnet-0abc123", "subnet-0def456"], "endpointIpAddressType": "IPV4", "securityGroupIds": ["sg-0abc123def"] } }, "targetConfiguration": { "mcp": { "mcpServer": { "endpoint": "https://my-mcp-server.internal.example.com/mcp" } } }}AgentCore Runtime as a Target
When your MCP server is hosted on AgentCore Runtime, all communication between AgentCore Gateway and AgentCore Runtime stays on the AWS backbone — your data never traverses the public internet (except for cross-region calls to China datacenters). Use the direct AgentCore Runtime endpoint rather than a VPCE URL to avoid an unnecessary extra network hop:
{ "targetConfiguration": { "mcp": { "mcpServer": { "endpoint": "https://bedrock-agentcore.<region>.amazonaws.com/runtimes/<runtime-id>/invocations?qualifier=DEFAULT&accountId=<account-id>" } } }}Private API Gateway Targets
AgentCore Gateway communicates with regional API Gateway endpoints over the AWS backbone. For private REST APIs, export the API as an OpenAPI schema and use an OpenAPI target with a
privateEndpoint , setting routingDomain to your API Gateway VPC endpoint DNS name:{ "name": "my-private-apigw-target", "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0123456789abcdef0", "subnetIds": ["subnet-0123456789abcdef0", "subnet-0abcdef1234567890"], "endpointIpAddressType": "IPV4", "routingDomain": "<vpce-id>.execute-api.<region>.vpce.amazonaws.com" } }, "targetConfiguration": { "mcp": { "openApiSchema": { "inlinePayload": "<OpenAPI spec with server URL matching the public certificate domain>" } } }}Lock down your API Gateway resource policy to accept requests only from AgentCore Gateway:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "bedrock-agentcore.amazonaws.com" }, "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:us-west-2:111122223333:rest-api-id/api-stage/*/*", "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:bedrock-agentcore:us-west-2:111122223333:gateway/my-gateway-id" } } } ]}Lambda Targets
Lambda targets require no additional private endpoint configuration — AgentCore Gateway can immediately invoke Lambda functions that have been configured with VPC access. Scope the gateway execution role to invoke only the specific Lambda function required:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["lambda:InvokeFunction"], "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-specific-tool-function" } ]}TLS Certificates for Private Targets
VPC egress requires your target endpoint to have a publicly trusted TLS certificate. If your private resource uses a certificate from a private CA, place an internal ALB with a public ACM certificate in front of it. AgentCore routes traffic through the ALB via
routingDomain , which terminates TLS and forwards to your backend. All traffic stays inside your VPC.Layer 4: Zero-Trust Identity with AgentCore Identity
This is the most sophisticated security layer. AgentCore Identity solves a fundamental problem in agentic systems: how does an agent access downstream resources on behalf of a user, without accumulating excessive privileges and without exposing credentials?
The On-Behalf-Of (OBO) Token Exchange Pattern
Traditional approaches fail here. Giving the agent a service account with broad permissions means a compromised agent is catastrophic. Passing the user's actual token everywhere loses auditability and violates least-privilege.
- The user authenticates and an inbound token is issued
- The agent presents that token to AgentCore Identity
- AgentCore Identity exchanges it for a scoped downstream token targeting exactly the resource the agent needs
- The downstream token carries both the agent's identity and the original user's identity
- Resource servers can enforce per-user, per-resource authorization at every hop
The diagram below illustrates this flow end-to-end — from user authentication through the OBO exchange at the IdP, down to the scoped token being injected into the downstream request. Pay particular attention to the resulting downstream token, which simultaneously carries the original user's identity (
sub ) and the agent's identity ( act ), enabling downstream resources to enforce fine-grained, per-user authorization at every hop.
The agent developer never touches the inbound user token or manages client secrets directly. AgentCore Identity brokers the exchange and caches tokens in a Token Vault.
Keeping the Token Exchange Private: VPC Lattice for Self-Hosted IdPs
When AgentCore Identity performs an OBO token exchange, it needs to reach your IdP's token endpoint. If your IdP is a cloud-hosted external provider (Azure AD, Okta, Auth0), this call goes over the public internet — secured by TLS, but public nonetheless. This is unavoidable for external providers.
However, if your organization runs a self-hosted IdP inside your VPC (Keycloak, PingFederate, or any OIDC-compliant authorization server), AgentCore Identity can reach it entirely privately via Amazon VPC Lattice. This covers two distinct flows:
Inbound JWT authorization — when AgentCore Runtime or Gateway validates incoming JWT tokens, it fetches the IdP's JWKS keys via the OIDC discovery URL. Configure a
privateEndpoint block in the authorizer configuration:{ "name": "my-gateway", "authorizerConfiguration": { "customJWTAuthorizer": { "discoveryUrl": "https://idp.internal.example.com/.well-known/openid-configuration", "allowedAudiences": ["my-gateway-audience"], "allowedClients": ["my-client-id"], "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0abc123def456", "subnetIds": ["subnet-0abc123", "subnet-0def456"], "endpointIpAddressType": "IPV4", "securityGroupIds": ["sg-0abc123def"] } } } }}Outbound OAuth credential providers — when AgentCore Identity calls your IdP's token endpoint to perform OBO exchanges or client credentials grants:
{ "name": "my-private-idp-provider", "credentialProviderType": "OAUTH", "oauthCredentialProvider": { "providerType": "CUSTOM", "customProviderConfiguration": { "issuer": "https://idp.internal.example.com/realms/my-realm", "tokenEndpoint": "https://idp.internal.example.com/realms/my-realm/protocol/openid-connect/token" }, "clientId": "my-client-id", "clientSecret": "my-client-secret", "privateEndpoint": { "managedVpcResource": { "vpcIdentifier": "vpc-0abc123def456", "subnetIds": ["subnet-0abc123", "subnet-0def456"], "endpointIpAddressType": "IPV4", "securityGroupIds": ["sg-0abc123def"] } } }}AgentCore supports two VPC Lattice connectivity modes: Managed Lattice (simpler — AgentCore handles the full resource lifecycle, no VPC Lattice IAM permissions required) and Self-managed Lattice (advanced — you own the resources, enables cross-account connectivity via AWS RAM).
Configuring OBO: Two Standards Supported
RFC 8693 — OAuth 2.0 Token Exchange (
TOKEN_EXCHANGE grant type), used when your IdP supports the standard token exchange spec:aws bedrock-agentcore create-oauth-credential-provider \ --name "enterprise-idp-obo" \ --grant-type TOKEN_EXCHANGE \ --token-endpoint "https://idp.example.com/oauth/token" \ --client-id "agentcore-client" \ --actor-token-content M2MRFC 7523 — JWT Authorization Grant (
JWT_AUTHORIZATION_GRANT grant type), used with providers like Microsoft Azure AD:aws bedrock-agentcore create-oauth-credential-provider \ --name "azure-ad-obo" \ --grant-type JWT_AUTHORIZATION_GRANT \ --token-endpoint "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token" \ --client-id "agentcore-app-id" \ --scopes "https://graph.microsoft.com/.default"Actor Token Content Options
When using
TOKEN_EXCHANGE , you have three options for how AgentCore Identity proves its own identity as the "actor":Option | Behavior |
|---|---|
M2M | Performs client credentials grant first, sends resulting access token as actor |
AWS_IAM_ID_TOKEN_JWT | Calls sts:GetWebIdentityToken, sends JWT as actor |
NONE | No actor token — IdP derives actor identity from client auth alone |
Runtime OBO Token Exchange
# Step 1: Exchange inbound user token for a scoped downstream tokenDOWNSTREAM_TOKEN=$(aws bedrock-agentcore exchange-token \ --credential-provider-name "enterprise-idp-obo" \ --subject-token "$INBOUND_USER_TOKEN" \ --target-resource "arn:aws:bedrock:us-east-1:123456789012:knowledge-base/kb-id" \ --query 'accessToken' --output text)
# Step 2: Use the scoped token for the downstream callcurl -H "Authorization: Bearer $DOWNSTREAM_TOKEN" \ https://bedrock-agent-runtime.us-east-1.amazonaws.com/knowledgebases/kb-id/retrieveLayer 5: Observability and Auditing
Security without visibility is incomplete. AgentCore provides built-in observability across three dimensions:
AgentCore Gateway logs all tool invocations with request metadata, giving you a complete record of what each agent called and when.
AWS PrivateLink metrics are published automatically to Amazon CloudWatch, covering connection counts, bytes transferred, and error rates — useful for detecting anomalous traffic patterns.
VPC Flow Logs can be enabled on the endpoint's network interface to capture IP-level traffic for forensic analysis. Enable them on your endpoint subnet and ship to CloudWatch Logs or S3 for long-term retention.
Combined, these give you end-to-end traceability: which user → which agent → which tool → which downstream resource.
Deployment Patterns for Different Scale Requirements
Single Shared Gateway — Multiple agents from different services access a single centralized gateway through a shared VPC endpoint, simplifying network architecture while maintaining security through token-based authentication. Best for teams starting out or with homogeneous agent workloads.
Multi-Gateway, Multi-Agent — Multiple agents across different applications access multiple specialized gateways through dedicated VPC endpoints, providing maximum security isolation with access control per gateway. A compromised gateway affects only its own agents. Best for regulated industries or multi-tenant platforms.
Cross-VPC — Agents in multiple VPCs access AgentCore Gateway through VPC peering or AWS Transit Gateway connections, allowing centralized gateway access across network boundaries while maintaining isolation. For cross-account private resource connectivity, use the self-managed Lattice option with AWS RAM resource sharing.
Hybrid Cloud — On-premises agents access cloud-based gateways through Direct Connect or Site-to-Site VPN, with the VPC endpoint in private DNS-disabled mode (using the
Host header pattern shown earlier). This enables hybrid deployments without exposing gateway endpoints to the internet.Security Checklist
Before going to production, validate each of these:
- Agents deployed in private subnets, not public subnets
- VPC interface endpoint created for
com.amazonaws.<region>.bedrock-agentcore.gateway
- Private DNS enabled on the endpoint
- Endpoint security group restricts inbound (port 443) to agent security group only
- VPC endpoint policy scoped to specific gateway ARN(s) —
Principal: *,Resource: <gateway-arn>
- Control plane operations still routed through public endpoint (by design)
- Private MCP/API targets configured with
privateEndpoint(managed or self-managed Lattice)
- Private CA targets fronted by an internal ALB with public ACM certificate
- Lambda execution role scoped to invoke only the specific target function
- API Gateway resource policy locked down to AgentCore Gateway service principal
- Self-hosted IdP configured with
privateEndpointon both inbound authorizer and outbound credential provider (if applicable)
- External cloud IdP flows (Azure AD, Okta...) acknowledged as public — secured by TLS only
- OAuth credential provider configured with appropriate OBO grant type
- Token Vault in use — agents never handle raw client secrets
- VPC Flow Logs enabled on endpoint subnet
- CloudWatch alarms on PrivateLink error metrics
- Policy changes tested in non-prod before production rollout (15-minute cache delay)
Summary
Securing agentic AI at enterprise scale requires defense in depth across five layers:
Network ingress → VPC interface endpoints keep agent-to-gateway traffic off the public internet entirely, with private DNS making this transparent to application code. Only the data plane is affected — control plane operations remain public by design.
Egress to tools → VPC Lattice private endpoints for MCP servers, OpenAPI targets, and private API Gateways ensure that tool invocations also stay within the AWS network. Lambda targets and AgentCore Runtime targets use the AWS backbone natively.
Access control → VPC endpoint policies scope gateway access to specific resources; security groups enforce network-level least privilege at every hop.
Identity → AgentCore Identity's OBO token exchange ensures agents act strictly within the scope of the authenticated user. For self-hosted IdPs, VPC Lattice keeps even the token exchange private. For external cloud IdPs, TLS secures the flow — but the public internet is unavoidable.
Observability → Gateway audit logs plus CloudWatch metrics plus VPC Flow Logs give you full traceability for incident response and compliance.
Together, these controls let you deploy autonomous AI agents that are genuinely powerful — without trading away the security posture your enterprise requires.
Amazon Bedrock AgentCore is actively evolving. Check the AWS documentation for the latest on supported identity providers, endpoint availability by region, and new AgentCore capabilities as they launch.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article