46  Code w/ Claude London 2026: Rethinking How We Build

46.1 Overview

On May 26, 2026, Anthropic held Code w/ Claude London 2026, the European stop of its global developer conference tour. Building on the momentum of the San Francisco event two weeks earlier, the London conference shifted the focus from capability announcements to infrastructure and boundary — specifically, how to run agentic systems within enterprise boundaries without compromising on security, data residency, or control.

The theme, “Rethinking How We Build,” captured a pivotal moment in the industry’s relationship with AI. The question was no longer “can agents do this?” — that had been answered. The question was “how do we run agents on our infrastructure, within our security boundaries, touching our private networks?” The two headline announcements addressed exactly this:

1. Self-hosted sandboxes (public beta) — the ability to run agent tool execution on your own infrastructure.
2. MCP tunnels (research preview) — a way to connect agents to private network servers without exposing them to the internet.

Both features shared a common philosophy: enterprise capabilities should not require enterprises to compromise their security boundaries. Agents could be powerful AND run within the walls that enterprises had spent years building.

46.2 The European Context

The London event was particularly significant for European enterprises, who faced some of the world’s strictest data protection regulations (GDPR) and had been slower to adopt AI tools that required data to leave their controlled environments. The announcements at Code w/ Claude London were designed to address these concerns directly.

Concern	European Enterprise Need	London Announcement
Data residency	Data must stay within EU/region	Self-hosted sandboxes
Network security	Private services must not be exposed	MCP tunnels
Compliance	Full auditability and control	Both features run in enterprise boundary
Vendor trust	Minimal data sent to vendors	Both features minimize vendor data flow

Note

The choice of London for these announcements was deliberate. Europe’s regulatory environment — GDPR, the AI Act, sector-specific regulations — created the most demanding requirements for data control and sovereignty. By solving for Europe first, Anthropic was building capabilities that would benefit enterprises globally, not just in the EU.

46.3 Announcement 1: Self-Hosted Sandboxes (Public Beta)

46.3.1 The Problem

Claude Code and Managed Agents could execute tools — running code, accessing file systems, making network calls — as part of their workflows. Previously, this tool execution happened in Anthropic-managed sandboxes. While these sandboxes were secure and well-isolated, they meant that the code and data involved in tool execution flowed through Anthropic’s infrastructure.

For many use cases, this was fine. But for enterprises with strict data residency requirements, classified workloads, or sensitive proprietary code, the requirement to send execution data to Anthropic’s infrastructure was a blocker. They needed tool execution to happen on their own infrastructure, within their own security perimeter.

46.3.2 The Solution: Self-Hosted Sandboxes

Self-hosted sandboxes allowed organizations to run agent tool execution on their own infrastructure. The agent (running in the cloud) could invoke tools that executed in a sandbox hosted on the organization’s own servers, cloud accounts, or edge locations.

Traditional (Anthropic-hosted sandbox):
┌──────────┐     tool call     ┌──────────────────┐
│  Agent   │──────────────────►│ Anthropic Sandbox│
│ (Cloud)  │                   │ (Anthropic infra) │
└──────────┘◄──────────────────└──────────────────┘
                              Code & data flow through Anthropic

Self-hosted sandbox:
┌──────────┐     tool call     ┌──────────────────┐
│  Agent   │──────────────────►│ Your Sandbox     │
│ (Cloud)  │                   │ (Your infra)     │
└──────────┘◄──────────────────└──────────────────┘
                              Code & data stay in your boundary

46.3.3 Supported Platforms

Self-hosted sandboxes were designed to work with popular infrastructure platforms, each offering different deployment models:

Platform	Deployment Model	Best For
Cloudflare	Edge-deployed (Workers-based)	Low latency, global distribution
Daytona	Container-based development environments	Development workflows, reproducibility
Modal	Serverless Python compute	Data science, ML workloads
Vercel	Edge + serverless (Node.js)	Web applications, full-stack

# Example: Self-hosted sandbox configuration
agent:
  sandbox:
    type: self-hosted
    provider: cloudflare
    config:
      account_id: "${CF_ACCOUNT_ID}"
      worker_script: "claude-sandbox"
      region: "eu-west"  # EU data residency
    allowed_tools:
      - "code_execution"
      - "file_read"
      - "file_write"
    network:
      egress: "restricted"  # No outbound internet

46.3.4 How It Works

The self-hosted sandbox architecture:

1. The agent (running in Anthropic’s cloud or the customer’s cloud) determines it needs to execute a tool.
2. Instead of executing in an Anthropic-managed sandbox, the agent sends the execution request to the customer’s sandbox (on Cloudflare, Daytona, Modal, or Vercel).
3. The sandbox executes the tool within the customer’s infrastructure, with the customer’s network policies, data access controls, and audit logging in effect.
4. Results are returned to the agent.

Tip

Self-hosted sandboxes were particularly powerful when combined with private data sources. An agent could query a private database, process the results, and generate insights — all without the raw data ever leaving the customer’s infrastructure. The agent only saw the processed results, not the underlying sensitive data.

46.3.5 Use Cases

Regulated data processing: A healthcare company could have agents analyze patient data stored in their own HIPAA-compliant environment, with all processing happening within the compliance boundary.

Proprietary code execution: A company could have agents run proprietary algorithms or models without exposing the code to Anthropic’s infrastructure.

Air-gapped adjacent environments: Organizations with near-air-gapped networks could run sandbox execution in a DMZ that had carefully controlled connectivity, rather than fully exposing systems to the internet.

46.3.6 Beta Status and Roadmap

At the London event, self-hosted sandboxes were in public beta. This meant:

• The feature was available to all customers.
• APIs were considered stable but might have minor changes based on feedback.
• Additional platform integrations were on the roadmap.

Anthropic indicated that future platform integrations would include AWS Lambda, Google Cloud Functions, and Azure Container Instances, among others.

46.4 Announcement 2: MCP Tunnels (Research Preview)

46.4.1 The Problem

The Model Context Protocol (MCP) allowed agents to connect to external tools and data sources through MCP servers. An MCP server might wrap a database, an internal API, a file system, or any other resource the agent needed to access.

The challenge was network topology. MCP servers running on private networks — inside corporate firewalls, in VPCs, or on on-premises infrastructure — were not reachable by cloud-based agents. To make an MCP server accessible, organizations typically had to:

1. Expose it to the internet (via a public endpoint) — unacceptable for most enterprise systems.
2. Set up a VPN or private network connection — complex, fragile, and hard to scale.
3. Run the agent on-premises — defeating the purpose of cloud-based Managed Agents.

This “MCP reachability problem” was a significant barrier to enterprise adoption. The most valuable MCP servers — those wrapping internal systems — were often the hardest to reach.

46.4.2 The Solution: MCP Tunnels

MCP tunnels provided a way to connect cloud-based agents to private network MCP servers without exposing those servers to the internet. The tunnel created a secure, outbound-only connection from the private network to Anthropic’s infrastructure, which the agent could then use to communicate with the MCP server.

Without MCP Tunnels:
                    ┌─────────────────────────┐
                    │    Corporate Firewall    │
                    │   ┌───────────────┐     │
  Cloud Agent ──X──►│   │ MCP Server    │     │  X = blocked
                    │   │ (private)     │     │
                    │   └───────────────┘     │
                    └─────────────────────────┘

With MCP Tunnels:
  ┌──────────┐         ┌─────────────────────────┐
  │   Cloud  │         │    Corporate Firewall    │
  │  Agent   │◄────────┤   ┌───────────────┐     │
  │          │ tunnel  │   │ MCP Server    │     │
  └──────────┘ (outbound only)│ (private)   │     │
                            └──────┬────────┘     │
                                   │ outbound     │
                                   │ connection   │
                                   ▼              │
                            ┌──────────────┐      │
                            │ Tunnel Client│      │
                            │ (initiates   │      │
                            │  connection) │      │
                            └──────────────┘      │
                    └─────────────────────────┘

46.4.3 How MCP Tunnels Work

The key insight was that the connection was initiated from inside the private network, not from outside:

1. A tunnel client installed on the private network initiates an outbound connection to Anthropic’s tunnel relay.
2. The outbound connection is allowed by most firewalls (since it’s outbound).
3. When a cloud agent needs to access the MCP server, it communicates through the established tunnel.
4. The MCP server remains completely unexposed to the internet — no inbound ports are opened.

# Starting an MCP tunnel client
mcp tunnel start \
  --server "internal-analytics.corp.local:8080" \
  --tunnel-id "analytics-prod" \
  --auth-method "wif" \
  --relay "https://tunnels.anthropic.com"

# The tunnel is now active. Cloud agents can connect to
# "analytics-prod" tunnel to access the internal MCP server.

Note

The security model of MCP tunnels was based on outbound-only connections — a well-established pattern used by tools like ngrok, Cloudflare Tunnel, and SSH reverse tunnels. By initiating the connection from inside the private network, no inbound firewall rules needed to be changed, and the attack surface was minimized. The MCP server remained invisible to the internet.

46.4.4 Use Cases

Internal database access: An agent could query an internal database through an MCP server wrapped around it — without exposing the database to the internet.

Legacy system integration: Agents could access legacy systems through MCP wrappers, with the legacy system remaining safely behind the corporate firewall.

Internal API access: Private internal APIs (employee directories, inventory systems, HR systems) could be exposed to agents through tunnels without public endpoints.

Multi-region private access: A global company could use tunnels to give agents access to internal systems in multiple regions, each with its own tunnel client.

46.4.5 Research Preview Status

MCP tunnels were announced as a research preview — an earlier stage than the self-hosted sandboxes’ public beta:

• The feature was available but APIs were expected to evolve.
• Usage was recommended for evaluation and pilot projects, not yet for mission-critical production.
• Feedback from research preview users would shape the GA version.

46.5 The Combined Vision

Self-hosted sandboxes and MCP tunnels were designed to work together, creating a comprehensive enterprise boundary for agentic systems:

┌─────────────────────────────────────────────────┐
│              Enterprise Boundary                 │
│                                                  │
│  ┌─────────────┐    ┌──────────────────────┐   │
│  │ Self-Hosted │    │  MCP Servers          │   │
│  │ Sandbox     │    │  (Internal systems)   │   │
│  │ (Tool exec) │    │                       │   │
│  └──────┬──────┘    └──────────┬───────────┘   │
│         │                      │                │
│         │          ┌───────────┘                │
│         │          │                            │
│         ▼          ▼                            │
│  ┌──────────────────────────┐                   │
│  │    Tunnel Client         │                   │
│  │    (outbound connection) │                   │
│  └──────────┬───────────────┘                   │
│             │                                   │
└─────────────┼───────────────────────────────────┘
              │
              │ secure tunnel
              ▼
     ┌────────────────┐
     │  Cloud Agent   │
     │  (Managed)     │
     └────────────────┘

With both features active:

• Tool execution happened on the enterprise’s infrastructure (self-hosted sandboxes).
• Data access happened through private tunnels (MCP tunnels).
• No inbound ports were opened on the enterprise network.
• Sensitive data stayed within the enterprise boundary.
• The agent could operate with full capability while respecting enterprise constraints.

46.6 Early Adopters

Anthropic highlighted three companies already building on these new capabilities:

Company	Use Case	Feature
Amplitude	Product analytics with private data	Self-hosted sandboxes
Clay	Sales enrichment with internal APIs	MCP tunnels
Rogo	Financial analysis with proprietary models	Both

These early adopters demonstrated that the features were not theoretical — they were being used in production to solve real enterprise integration challenges.

Tip

The early adopter stories shared a common pattern: each company had a specific use case that was blocked by the inability to run agents within their enterprise boundary. Self-hosted sandboxes and MCP tunnels unblocked these use cases, enabling production deployments that had previously been impossible.

46.7 The Road Ahead: Tokyo

As with the San Francisco event, Code w/ Claude London was part of a global tour. The final stop was Code w/ Claude Tokyo (June 5-6, 2026), which would feature:

• Asia-Pacific-specific content and customer stories.
• Additional announcements (potentially including GA of features previewed in London).
• Region-specific networking and community building.

46.8 Key Takeaways

• Code w/ Claude London 2026 focused on “Rethinking How We Build” — shifting from capability announcements to infrastructure and boundary.
• Self-hosted sandboxes (public beta) allow agent tool execution on your own infrastructure (Cloudflare, Daytona, Modal, Vercel) — keeping code and data within the enterprise boundary.
• MCP tunnels (research preview) connect cloud agents to private network MCP servers without exposing them to the internet, using outbound-only connections.
• Both features share a common philosophy: enterprise capabilities should not require compromising security boundaries. Agents can be powerful AND run within enterprise walls.
• The European context drove the announcements: GDPR, the AI Act, and strict data residency requirements made these features essential for European enterprises — and beneficial globally.
• Self-hosted sandboxes support multiple platforms: Cloudflare (edge), Daytona (containers), Modal (serverless Python), Vercel (edge + Node.js), with more on the roadmap.
• MCP tunnels use outbound-only connections: No inbound firewall changes needed, MCP servers remain invisible to the internet — a well-established security pattern.
• Early adopters are already in production: Amplitude (analytics), Clay (sales enrichment), and Rogo (financial analysis) demonstrated real-world value.
• The combined vision: Self-hosted sandboxes + MCP tunnels create a comprehensive enterprise boundary where tool execution and data access both happen within the enterprise’s control.
• Tokyo (June 5-6) was the next stop on the global tour, with additional announcements expected.