Agents Inside the Firewall

Every serious enterprise AI conversation hits the same wall around hour two.

"We're interested, but our data can't leave the perimeter." Your internal databases. Your ticketing systems. Your private APIs. The stuff that makes agents actually useful. Security says no outbound connections to external services. Without those connections, the agent is basically a smarter version of a public chatbot — fast, impressive in a demo, useless for real work.

Anthropic announced at Code with Claude London on May 19 that the wall just moved.

What Actually Shipped

Two features went live for Claude Managed Agents last week.

Self-hosted sandboxes let you run agent tool execution on your own infrastructure — or through a managed provider like Cloudflare, Daytona, Modal, or Vercel. The agent loop (orchestration, context management, error recovery) runs on Anthropic's infrastructure. But when the agent actually does something — runs code, reads a file, calls a service — that execution happens on your side. Your perimeter. Your audit logs. Your rules.

MCP tunnels take this further. They let an agent reach MCP servers inside your private network without those servers ever being exposed to the public internet. A lightweight gateway opens a single outbound encrypted connection from inside your network. No inbound firewall rules. No public endpoints. No VPN required on the agent side. The agent queries your internal Jira, your proprietary API, your on-prem database — and none of it touches the public internet.

Self-hosted sandboxes are in public beta. MCP tunnels are in research preview with request access.

The Architecture Split Is What Makes This Work

Most "enterprise AI security" features are compliance theater. They look responsible in a vendor deck and don't actually change what the system can reach.

This is different, and it's worth understanding why.

The architecture deliberately splits two concerns that were previously tangled together. The agent thinks on Anthropic's infrastructure — planning, orchestration, context management, model calls. The agent acts on your infrastructure — tool execution, file reads, service calls. That distinction matters because the raw bytes in your internal systems never have to leave your network to reach Anthropic's servers uncontrolled.

# MCP tunnel: one outbound encrypted connection from inside your network
# No inbound ports. No public endpoints.
claude managed-agents tunnel connect --server internal-db-mcp

That's a properly designed security boundary. The agent can use your internal knowledge without exfiltrating it. The model can reason over real production data without the data going through a public endpoint.

Compare this to what you'd have to do before: either expose your internal service publicly, or build a bespoke reverse-proxy VPN architecture your IT team would spend six months approving. Both were dealbreakers in most real enterprise settings.

The Conversation That Kept Killing Real Projects

I've watched this play out more times than I can count.

A team has a real use case. Agents that read the internal ticketing system and draft responses. Agents that pull last quarter's financials and generate analysis. Agents connected to the actual systems where the work lives, not a sanitized public version of it. The numbers are there. The prototype works. Someone measured 20+ hours saved per person per week.

Then someone from security sits down.

The project becomes a "pilot." The pilot uses sanitized public data. The sanitized data produces impressive demos. The demos impress leadership. Nobody ships. The team writes a findings document about "future potential" and the initiative stalls until the next planning cycle.

That cycle is the primary reason enterprise AI is still mostly in pilot mode three years into the agent era. Not model capability. Not cost. Not lack of trust in the output quality. Just the brute technical fact that agents couldn't reach the real systems where the valuable work actually happens.

MCP tunnels solve the network access problem. Self-hosted sandboxes solve the execution environment problem.

The Uncomfortable Part

Here's what nobody in the enterprise AI space wants to say in a meeting.

A lot of "our data can't leave the perimeter" objections weren't actually about security. They were organizational inertia dressed in a technical costume.

"We can't connect to internal systems" is a compelling objection. It sounds responsible. It references real risk. It's hard to argue with in a room full of executives. Even when the actual concern was closer to "we don't know if we want autonomous agents touching our production systems yet" — which is legitimate, but a completely different conversation with different stakeholders and different decision criteria.

Now the technical objection is gone. There is a properly architected, end-to-end-encrypted path to connecting agents to internal systems with no inbound exposure and no public endpoints. It exists. It shipped. You can apply for research preview access today.

If your AI project is still in pilot mode six months after MCP tunnels hit general availability, the blocker is organizational, not technical. Harder conversations. Different stakeholders. Fewer shields to duck behind.

The security argument was always partly borrowed credibility. Anthropic just took it back.

What This Opens Up for Builders

If you're building on top of Claude today, the useful surface area just expanded.

I wrote about MCP as a competitive moat when Thomson Reuters rebuilt CoCounsel on the Agent SDK. The argument was: your proprietary domain data is the product, MCP is the connector that makes it usable. What MCP tunnels add is the ability to run that connector inside your security perimeter. The data doesn't have to be already-public to be queryable by an agent. It just has to be reachable via a private MCP server you control.

Think about what that actually covers:

• Internal knowledge bases with proprietary processes
• On-prem customer databases that can't touch the cloud
• Legacy systems with valuable historical data and no public API
• Regulated data environments where residency requirements make public endpoints a non-starter

All of those just became viable agent targets.

For consultants and builders selling automation work: the "our data can't leave the perimeter" rejection is about to get a lot rarer. Scope your next proposal assuming agents can reach internal systems. That's a very different product than a public-data chatbot.

// managed-agents.config.ts — self-hosted sandbox
export default {
  sandbox: {
    provider: "modal",  // or "cloudflare" | "daytona" | "vercel"
    endpoint: process.env.SANDBOX_ENDPOINT,
  }
}

One config block. Agent execution stays in your infrastructure.

Go Pick Up the Project That Died

If you had a real agent use case that stalled in a security review — go find it.

Self-hosted sandboxes are in public beta today. MCP tunnels have a request form for research preview access. The "we can't connect to internal systems" wall that killed the project can now be architected around cleanly, with controls that even a cautious security team can actually evaluate.

The technical excuse is gone.

Ship the thing that should have shipped six months ago.