Scout: Three MCP Perimeter Architectures Arrive Within Weeks — IAM Tagging vs. Egress Tunnel vs. Six-Layer Platform

Summary

Three months ago the practitioner question was whether the gateway-and-registry middle tier was a real product category. It is (the slot-based landscape that emerged last quarter) — and this quarter three vendors shipped three structurally different answers to “how do agent tool calls cross a security perimeter,” all arriving within the same few weeks — two at GA, one a research preview. AWS made its managed MCP Server generally available on May 6 and added two global IAM condition context keys (aws:ViaAWSMCPService and aws:CalledViaAWSMCP) that tag every managed-MCP request so existing IAM policies and SCPs can treat agent-initiated calls as a distinguishable class. Anthropic shipped MCP Tunnels (research preview) — an outbound-only gateway that lets Claude Managed Agents reach private MCP servers with no inbound firewall rules, by running cloudflared inside the customer network. Cloudflare named its six-layer agent platform (compute, orchestration, memory, browsing, commerce, plus the networking/identity plane underneath) with MCP as the tool-access layer and an egress proxy that injects credentials so the agent never holds them. These are not three flavors of the same gateway. They are three different bets on where the perimeter lives — in IAM, in an outbound tunnel, or in a single vendor’s network — and the more your policies, audits, and egress posture build around the pick, the harder it is to walk back.

Key Findings

1. The three architectures answer different questions, not the same one better

It is tempting to line these up as competitors. They mostly aren’t. Each one solves a distinct perimeter problem, and a team’s existing infrastructure usually decides which problem is theirs.

The practical read: AWS’s offering is for teams whose sensitive resources are AWS resources. Anthropic’s is for teams whose sensitive resources sit behind their own firewall and who’ve already committed to Claude as the agent runtime. Cloudflare’s is for teams willing to adopt a single vendor’s primitives for the entire stack in exchange for the tightest integration. A team can — and several will — run two of these at once.

2. AWS reuses IAM instead of inventing a gateway — and that’s the whole design

AWS’s managed MCP Server, GA since May 6, 2026, deliberately does not define its own actions, resources, or service-specific condition keys. Per AWS’s IAM documentation, it “authenticates your request using SigV4, adds standardized condition context keys, and forwards the request to the downstream AWS service,” which then “performs the authorization check using your existing IAM policies.” Your agent works with your existing credentials and service-level permissions; there is no separate MCP permission model to administer.

The two keys are the entire governance primitive:

• aws:ViaAWSMCPService — “A Boolean key set to true for any request that passes through an AWS managed MCP server.” One condition blocks (or allows) everything agent-initiated.
• aws:CalledViaAWSMCP — “A single-valued string key containing the service principal of the specific AWS managed MCP server,” with example values aws-mcp.amazonaws.com, eks-mcp.amazonaws.com, and ecs-mcp.amazonaws.com (AWS). This lets a policy treat the EKS MCP server differently from the general one.

This is the cleanest fit for an AWS-native shop: a single SCP can enforce “the MCP path is read-only even for principals who can mutate directly,” and the audit surface is the one your compliance team already lives in. CloudWatch metrics publish under an AWS-MCP namespace so MCP calls are observable separately from direct human calls, and CloudTrail captures the API calls for a full record (AWS blog). Notably, AWS deprecated the preview-era aws-mcp:InvokeMcp / CallReadOnlyTool / CallReadWriteTool actions — if you wrote Deny statements against those during preview, they now silently have no effect and must be rewritten against the new condition keys (AWS). That migration is a real, easy-to-miss trap for early adopters.

The critical limitation. The context keys mark the first call but do not survive a hop into customer-run compute. As one practitioner write-up dissecting the model puts it, a Lambda invoked by an MCP-tagged request “runs under its own execution role… That call is from Lambda’s principal, not the user’s,” and “the shape generalizes to anything that runs customer code under its own principal: Step Functions tasks, EventBridge rule targets, CodeBuild projects, Glue jobs” (agentlair.dev). The consequence: “Any L3 deny that hangs on the new context keys needs a mirror deny on the downstream role, evaluated without the context key.” If your threat model is “an agent should never delete S3 objects,” tagging the front door is necessary but not sufficient — the moment the agent’s action fans out through a Lambda, the agent provenance is gone. Treat the keys as a perimeter control on direct service calls, not as end-to-end agent-intent enforcement.

3. Anthropic inverts the perimeter: the agent comes to you, outbound-only

Where AWS tags requests inside its own cloud, Anthropic’s MCP Tunnels solve the opposite problem — a hosted agent reaching a server that lives behind your firewall. The mechanic is an outbound-only tunnel: traffic “flows over an outbound-only connection, so you don’t need to open inbound firewall ports, expose services to the public internet, or allowlist Anthropic’s IP ranges on your origin” (Claude docs). For a security team, “no inbound rules” is the sentence that gets a project through review, and the positioning is explicit: orchestration — context management and the agent loop — stays on Anthropic’s infrastructure, while tool execution and now tool reachability move to the customer’s perimeter (the-decoder).

The deployment is two components inside your network: cloudflared (the tunnel agent making outbound connections to “the Anthropic-operated tunnel edge”) and a proxy that “terminates inner TLS, validates that upstream IPs fall within an allowed range, and routes each request to the correct upstream MCP server based on hostname” (Claude docs). The identity story is layered: outer mTLS between Anthropic and the transport, inner TLS terminated by a certificate “that only you hold” (so the transport provider cannot read payloads), and OAuth on each MCP server itself. The tunnel “carries encrypted traffic to your MCP server but does not authenticate to it” — upstream auth remains your job, independent of the tunnel.

Three caveats deserve to land before anyone builds on this:

• It is a research preview, “as-is.” Anthropic states the feature is “provided ‘as-is’ without any uptime, support, or continuity commitment” and “may modify or discontinue MCP tunnels at any time” (Claude docs). The companion self-hosted sandboxes shipped at a more mature public-beta tier the same week (9to5Mac); the tunnel is the less-baked half. This is not a load-bearing-production primitive yet.
• The transport is Cloudflare, named explicitly. The docs disclose that the tunnel “depend[s] on a third-party network provider (Cloudflare)” acting as a subprocessor, which receives connection metadata — egress IP, a cloudflared host fingerprint, connection timing and byte-volume, and your assigned subdomain — though not payloads (Claude docs). A team choosing Anthropic’s tunnel to avoid a vendor is quietly taking a dependency on two.
• The secrets blast radius is specific. Per the docs’ own warning, an attacker who obtains your tunnel token and a TLS private key “could impersonate your proxy and read MCP request payloads.” Both are high-value secrets, and rotation/management is on the customer side of the shared-responsibility table.

4. Cloudflare’s answer is “don’t run a gateway, run our platform”

Cloudflare’s move is the broadest and the most lock-in-shaped. Rather than shipping one gateway, it named a full agent platform spanning compute (Dynamic Workers plus container Sandboxes), orchestration (Dynamic Workflows, a ~300-line MIT-licensed library), memory (Agent Memory, private beta), browsing (Browser Run rebuilt on Containers, with WebMCP exposing tools through the browser), and commerce (a Stripe-co-designed protocol) (InfoQ). MCP is the tool-access layer threaded through it: agents connect to MCP servers for external tools, with Code Mode reducing token cost and “Shadow MCP detection” for spotting unsanctioned MCP servers (Cloudflare).

The core security idea is the egress proxy. Instead of an agent holding credentials, the boundary does: Cloudflare’s compute layer provides “secure credential injection via egress proxy so agents never see raw tokens” (InfoQ). Identity runs through Cloudflare Access — SSO, MFA, and contextual signals like device posture and location — and the reference architecture for enterprise MCP combines Access, the AI Gateway, and MCP server portals that let administrators enforce DLP rules and fine-grained tool exposure (InfoQ). For a team that wants one console for identity, egress, observability, and tool governance, this is the most integrated option on the board.

It is also the one that most clearly trades portability for cohesion. Independent analysis of Agents Week notes that five of the eighteen releases concern identity or authority — the largest single category — positioning Cloudflare as a candidate “identity plane for automated action on the public web” (wal.sh). That is the integration advantage and the lock-in risk in one sentence. The same analysis frames the open question precisely: whether the competing credential-vault-plus-egress-proxy stacks (Cloudflare’s and Anthropic’s) federate or fragment. They have not federated yet.

5. MCP-spec coverage is uneven, and “MCP-compatible” hides the gaps

All three vendors are genuinely MCP-speaking and converge on Streamable HTTP as the production transport, but primitive coverage diverges in ways that matter once you go past tool-calling. A cross-vendor implementation comparison maps the unevenness (hidekazu-konishi): tools are universally “Full,” but resources, prompts, sampling, roots, and elicitation are a patchwork — “Spec primitives such as sampling, roots, and elicitation are widely advertised but only partially implemented.”

The architectural postures differ too. AWS “treats MCP as a gateway protocol between agents and existing AWS resources” — and the managed AWS MCP Server routes all AWS APIs through a single tool rather than exposing each operation as a named tool (AWS blog). Cloudflare “serves as the host between an MCP client and an MCP server,” the lowest-friction place to run remote servers. Anthropic is the reference-SDK provider and closest tracker of spec changes, but its own Messages API connector is deliberately tool-scoped, omitting resources and prompts (hidekazu-konishi). Practitioner takeaway: “MCP-compatible” on a vendor page means tool-calling works. If your design leans on sampling, elicitation, or resource subscriptions, verify the specific primitive against the specific surface — not the marketing checkbox.

6. The audit surfaces don’t compose

A point that’s easy to miss when these are evaluated one at a time: their audit/logging surfaces live in three different places and do not stitch together. AWS gives you CloudTrail plus a dedicated AWS-MCP CloudWatch namespace — first-class, queryable, in the place your AWS audit already is. Anthropic’s tunnel keeps “network policies, audit logging, and security tooling” on the customer side of the perimeter by design, which means the agent-side audit trail and your network-side trail are two separate records you must correlate yourself. Cloudflare centralizes observability in its own console (AI Gateway token metering, MCP portals, DLP). A team running AWS resources and Claude agents and Cloudflare compute ends up with three audit planes and no built-in join key. For regulated workloads, that correlation gap is the real integration cost — larger, often, than any per-call pricing line.

Practical Implications

A decision tree for mid-2026

Start with: where do your sensitive resources live?

1. They are AWS resources (databases, S3, EKS, internal services in your VPC). Default to the AWS MCP Server. You reuse IAM, your audit lands in CloudTrail, and a single SCP using aws:ViaAWSMCPService enforces read-only-for-agents across the account. Budget for two things: rewriting any preview-era aws-mcp:* Deny statements against the new condition keys, and adding mirror denies on downstream Lambda/Step Functions execution roles, because the agent-provenance tag does not survive the hop into your own compute. If your threat model is satisfied by perimeter tagging on direct service calls, this is the lowest-friction governance you’ll find.

2. They sit behind your own firewall and you’ve standardized on Claude as the agent runtime. MCP Tunnels are the cleanest “no inbound port” story — but only out of research preview should you put a production workload on them. Until then, prototype with them and keep a fallback. Account for the Cloudflare-as-subprocessor dependency in your data-flow review (it’s disclosed, but your compliance team will want it named), and treat the tunnel token and TLS private key as paired crown-jewel secrets. Pair tunnels with Anthropic’s self-hosted sandboxes (public beta, with Cloudflare/Daytona/Modal/Vercel as managed options) if files also can’t leave your network.

3. You’re greenfield, want the whole stack on one substrate, and value integration over portability. Cloudflare’s platform is the most cohesive single-vendor answer — egress-proxy credential injection, Access-based identity, and MCP portals in one console. Go in clear-eyed about lock-in: identity and authority make up the largest single category of the platform’s new releases, and there is no federation story yet with the other vaults you might adopt. Keep your MCP servers protocol-pure (avoid leaning on Cloudflare-specific bindings inside the server logic) so the servers stay portable even if the platform doesn’t.

The cross-cutting rule. Whichever you pick, the portability lever you actually control is the MCP server itself. The most common path to a vendor-specific fork is depending on a non-portable feature — a Service Binding, a Lambda event shape, SigV4 outbound auth — inside server code that didn’t need it. Keep the protocol surface clean and you can move the server even when you can’t easily move the perimeter.

What to do this quarter

• AWS shops: Audit existing IAM/SCPs for deprecated aws-mcp:* actions today; they fail open. Then write the aws:ViaAWSMCPService deny-by-default policy and pressure-test it against an agent that fans out through Lambda — confirm the downstream mirror-deny actually holds.
• Claude-runtime shops: Request MCP Tunnels preview access for evaluation, but gate production behind GA. Inventory which internal MCP servers would be exposed and confirm each carries its own OAuth, since the tunnel won’t authenticate to them.
• Anyone going multi-vendor: Decide your audit-correlation strategy before deployment. None of the three exports a shared join key; if you run two of them, you own the SIEM-side correlation, and retrofitting it later is the expensive path.

Open Questions

1. Do the credential-vault-plus-egress-proxy stacks federate, or entrench? Anthropic’s tunnel already rides Cloudflare’s transport, yet the two run separate identity/authority models. If they converge on a shared delegation standard, multi-vendor agent perimeters get dramatically simpler. If they don’t, teams pick a camp and stay there.

2. Will AWS extend the context keys end-to-end? The first-hop-only limitation is the single biggest gap in the IAM-tagging approach. A Forward-Access-Session-style propagation of aws:ViaAWSMCPService into Lambda and Step Functions would turn perimeter tagging into genuine agent-intent enforcement. There’s no public signal yet that it’s coming.

3. When does MCP Tunnels leave research preview — and with what SLA? The “as-is, may discontinue at any time” framing keeps it out of regulated production. The GA terms (uptime commitment, support, the Cloudflare-subprocessor contract specifics) will decide whether it’s a serious enterprise primitive or a convenience for prototypes.

4. Does primitive coverage converge? With sampling, roots, and elicitation only partially implemented across every major surface, designs that need more than tool-calling are betting on roadmaps. Which vendor closes the gap first is a real differentiator that today’s “MCP-compatible” badges obscure.

5. Where does the audit-correlation burden settle? Today it’s entirely on the customer in any multi-vendor deployment. Whether a third-party observability layer or a cross-vendor trace standard emerges to join CloudTrail, Anthropic-side logs, and Cloudflare’s console is an open ecosystem gap — and a plausible product opportunity.

Sources

1. The AWS MCP Server is now generally available — AWS What’s New (GA date, regions, pricing, sandboxed execution)
2. The AWS MCP Server is now generally available — AWS Blog (CloudWatch AWS-MCP namespace, CloudTrail, fixed tool set)
3. How AWS MCP Server works with IAM — AWS Agent Toolkit docs (context-key definitions, SigV4, deprecated actions)
4. AWS MCP Server Reaches GA with Full API Coverage and IAM-Based Governance — InfoQ
5. AWS marked the agent traffic. One Lambda hop later, the mark is gone. — agentlair.dev (context-key propagation limitation)
6. MCP tunnels — overview — Claude API docs (tunnel architecture, security layers, research-preview terms)
7. Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems — InfoQ
8. New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels — Anthropic/Claude blog
9. Anthropic adds self-hosted sandboxes and MCP tunnels to Claude Managed Agents — The Decoder (decoupling brain from hands, supported providers)
10. Cloudflare Completes Its Agent Infrastructure Stack with Browser Run Rebuild and Six-Layer Platform — InfoQ (six layers, egress proxy credential injection)
11. Building the agentic cloud: everything we launched during Agents Week 2026 — Cloudflare (Code Mode, Shadow MCP detection, WebMCP)
12. Cloudflare Outlines MCP Architecture as Enterprises Confront Security and Governance Risks — InfoQ (Access/SSO/MFA, MCP portals, DLP, AI Gateway)
13. Cloudflare Adds Support for Claude Managed Agents — InfoQ (cross-vendor self-hosted-sandbox support, credential injection)
14. Cloudflare Agents Week 2026 (research notes) — wal.sh (identity-plane consolidation, federation question, lock-in analysis)
15. Self-hosted sandboxes — Claude API docs (sandbox provider options, perimeter fit)
16. MCP Server Implementation Reference — Anthropic, OpenAI, Google, Cloudflare, and AWS — hidekazu-konishi.com (cross-vendor identity, transport, primitive coverage)
17. Anthropic enhances Claude Managed Agents with two new privacy and security features — 9to5Mac (launch context, public-beta vs research-preview status)
18. MCP Enterprise Gateway Patterns — The Middle Tier Emerges — prior Grimoire scout (continuity; the slot-based gateway landscape this quarter’s GA wave builds on)