AWS Bedrock AgentCore: Serverless MCP Proxy with IAM, OAuth 2.0 JWT, and CloudWatch Observability for Enterprise Governance

AWS published a reference architecture on April 29, 2026 for deploying a custom MCP proxy as a serverless workload on Amazon Bedrock AgentCore Runtime. The implementation directly targets organizations that already have governance and compliance logic for AI tools but do not want to refactor existing infrastructure into Lambda functions or sidecar containers. The article’s author is Nizar Kheir, Senior Solutions Architect at AWS.

What Is the Architecture of the MCP Proxy Layer?

The system has three layers that authenticate independently of one another. The MCP Client Layer contains the agent workloads on AgentCore Runtime. The MCP Proxy Layer is the custom intermediary handling governance logic — this layer is the novelty of the announcement. The Upstream Server Layer contains existing MCP endpoints (AgentCore Gateway, self-hosted servers, third-party services). The proxy transparently forwards requests while applying its own transformations, meaning existing tools do not need to know that a proxy is in the path.

How Does the Proxy Discover Upstream Tools and Authenticate Calls?

The proxy uses the FastMCP framework for dynamic upstream tool discovery at startup via a tools/list request — tools are then re-exposed locally without manual registration. For authentication, two methods are supported: IAM/SigV4, where the proxy inherits the execution role and automatically signs outbound requests, and OAuth 2.0 client credentials grant with JWT bearer tokens cached in memory with automatic refresh. Built-in observability comes through CloudWatch Logs and OpenTelemetry integration.

What Are the Concrete Governance Examples from the AWS Reference?

Two examples illustrate the power of the approach. PII tokenization: the proxy intercepts tool arguments, replaces sensitive data (personal IDs, card numbers) with reversible tokens before sending them to the backend system, then inverts the tokens in the response — the backend never sees raw PII data. Identity-based tool restriction: policy checks in tool handlers restrict which tools a specific caller may invoke, optionally filtering the tools/list response so the caller does not see tools they are not permitted to use. Kheir emphasizes: “Each layer in this architecture authenticates independently. You inject your own logic at the MCP protocol layer through the proxy, while the upstream server continues to execute tools and handle its own authorization.” The GitHub repository contains automated setup_and_deploy.py scripts for IAM role, container build, and AgentCore deployment.