AWS MCP on Amazon Bedrock: Enterprise Tooling with AgentCore Gateway

MCP architecture on AWS

Model Context Protocol (MCP) is the connective tissue between AI agents and the systems they act on. In 2025–2026 it has moved from experiment to enterprise expectation: one protocol for listing tools, calling them, and—increasingly—handling prompts, resources, streaming and stronger OAuth patterns.

On AWS, the practical centre of gravity for production MCP is Amazon Bedrock AgentCore Gateway: a managed gateway that converts APIs, Lambda functions and existing services into MCP-compatible tools, fronts existing MCP servers, and applies inbound/outbound authentication at scale.

Why MCP matters for UK enterprises

Without a protocol standard, every agent framework invents its own tool schema. That creates:

• Duplicate connectors for the same ServiceNow or SAP API
• Inconsistent auth (API keys in env vars vs proper OAuth)
• No single place for cyber to approve “what an agent may do”
• Painful audits when regulators ask who changed a customer record

MCP gives you a common contract. AgentCore Gateway gives you the enterprise control plane around that contract.

AgentCore Gateway capabilities UK teams should know

Gateway is more than a thin proxy. In current AWS guidance it provides:

• Translation — agent/MCP requests mapped to OpenAPI, Smithy or Lambda invocations without each squad reinventing adapters
• Composition — multiple APIs, functions, tools and (where configured) model routing behind one endpoint
• Security Guard — OAuth/IAM so only authorised users and agents reach tools
• Ingress and egress authentication — rare as a fully managed pair; critical for zero-trust designs
• MCP server fronting — bring existing MCP servers under central credential management and observability
• Evolving MCP support — prompts/resources as first-class concepts, streaming/session patterns where required, and support for newer MCP protocol versions (including dual-version rollouts so clients migrate safely)

For platform teams, Gateway is the place to enforce “no agent talks to production systems except through approved tools.”

Reference pattern: ops and agent tooling

A UK-friendly architecture:

1. MCP clients — Bedrock Agents, AgentCore Runtime agents, IDE copilots, or internal ops agents
2. AgentCore Gateway — single VPC-aware entry; IAM or OAuth inbound
3. Targets — Lambda (preferred for least privilege), private APIs, approved SaaS connectors
4. Identity — Entra ID / Okta for workforce; Cognito where customer-facing; outbound OAuth on-behalf-of where user context must flow
5. Observability — tool name, principal, correlation ID, success/failure into CloudWatch and your SIEM

Cloud operations and MCP tooling

What to put behind MCP first

Prioritise read-heavy, high-value, low-blast-radius tools:

• Knowledge retrieval wrappers (search Confluence/SharePoint via approved APIs—not raw filesystem mounts)
• Ticket create/update with mandatory fields and change windows
• Cost and inventory lookups (AWS Cost Explorer summaries, Config, Security Hub findings)
• Runbook steps that are idempotent (restart a known ECS service with approval token)

Defer autonomous payments, bulk data export, and IAM mutations until policy packs and human gates exist.

Operating model: platform vs squads

Successful UK programmes split ownership:

Publish an internal MCP catalogue (name, description, data classification, owner, environments). Treat catalogue changes like API gateway changes: PR, review, promote.

Protocol versioning without downtime

MCP has evolved quickly (sessionful streams toward more stateless HTTP-friendly designs in newer specs). AgentCore Gateway’s dual/multi-version support is important: keep older clients working while you add newer protocol versions via gateway configuration updates rather than big-bang rewrites.

UK takeaway: pin supported versions in change records; test SigV4 and OAuth clients independently; never silently drop a version that production agents still negotiate.

Security checklist for regulated firms

• Least privilege per tool (separate Lambdas > one mega-function)
• No long-lived SaaS tokens in agent prompts or logs
• Data exfiltration controls: deny tools that return unbounded datasets without pagination caps
• DLP on egress where tools can email or post externally
• Break-glass procedure if an agent loops on a mutating tool
• Evidence: retain tool-call audit for your regulatory retention period

Bridging DevOps and agent ops

MCP is also useful inside the SDLC: agents that query CloudWatch, open PRs, or summarise incidents. Put those tools on a non-prod Gateway first, with stronger human approval for prod write tools. Align with your existing AWS Control Tower / landing zone SCPs so agents cannot exceed account boundaries.

Getting started in four weeks

Week 1: Stand up Gateway in a sandbox account; expose one Lambda health-check tool; prove IAM inbound auth and logging.
Week 2: Add Entra ID / Okta OAuth; register two real read tools.
Week 3: Front one existing MCP server (if you have one) through Gateway for central credentials.
Week 4: Productionise with alarms, runbooks, and a catalogue entry process.

MCP on AWS is not a science project—it is how you stop every agent from becoming a bespoke integration nightmare. AgentCore Gateway is the enterprise-shaped way to do it: one protocol, one policy point, many tools.