Amazon Bedrock AgentCore Runtime now supports serverless MCP-proxies

Amazon Web Services has published a detailed guide for deploying custom MCP proxies in Amazon Bedrock AgentCore Runtime. The new approach allows companies to add a programmable management layer between AI agents and external tools — without the need to set up and maintain their own infrastructure.

Why proxy became necessary

Model Context Protocol has become the principal standard for connecting AI agents to external systems. Through it, agents gain access to file systems, databases, corporate APIs, monitoring services, and thousands of other tools.

The problem is that direct connection of an agent to an MCP server is a security blind spot. When an agent communicates directly with a tool, the organization lacks:

• Centralized logging of all requests and responses
• The ability to apply access policies
• Tools for detecting anomalies in agent behavior
• A point for filtering sensitive data
• Control over resource consumption

For pilot projects, this is tolerable. For production deployments in regulated environments — unacceptable.

MCP proxy closes this gap. It intercepts all calls between the agent and tools, enabling the application of any business logic: request authentication, call auditing, PII masking, role and team-based rate limiting.

Meanwhile, the agent remains unaware of the proxy's presence — its interface remains standard MCP.

Amazon Bedrock AgentCore Runtime

AgentCore Runtime is a managed execution environment within Amazon Bedrock, designed specifically for AI agent workloads. Unlike generalized services like Lambda or ECS, AgentCore understands the lifecycle of agent sessions, manages context, and provides observability tools directly within the AWS ecosystem.

Running an MCP proxy on AgentCore Runtime adds:

• Serverless scaling — the proxy automatically scales under load; no servers required
• AWS IAM integration — access rights management through standard policies without custom code
• CloudWatch Logs and Metrics — centralized logging and metrics out of the box
• AWS X-Ray — distributed tracing for diagnosing agent call chains
• VPC integration — proxy isolation in a private organizational network

For enterprise teams, this means that the entire AWS compliance stack (audit, encryption, key management) is automatically applied to agent-tool interactions.

How it works

Technically, the scheme is straightforward. A developer writes a proxy service that accepts an MCP request from an agent, verifies permissions, applies organizational policies, transforms the request if necessary, forwards it to the target MCP server, receives the response, logs it, and returns it to the agent.

The service is packaged in a Docker container and deployed to AgentCore Runtime. From there, agents are configured to work through the proxy endpoint instead of the direct MCP server address.

"This provides a programmable layer for implementing proper governance, controls, and observability aligned with the organization's security policies" — AWS

Machine Learning Blog.

The key architectural advantage is centralization. Rather than embedding security logic in each agent or application separately, the organization configures a single proxy per business unit or for the entire enterprise. Policy changes apply immediately to all agents working through it.

What this means

AWS is consistently building out an enterprise layer for AI agents: execution infrastructure, memory management, security tools. Support for custom MCP proxies in AgentCore Runtime is a pragmatic response to a genuine request from corporate teams: how to deploy AI agents in production without compromising security and audit requirements.

For companies already operating on AWS, this lowers the barrier to entry — there's no need to design a governance layer from scratch; it's enough to follow the documented pattern.