For years, the biggest bottleneck keeping artificial intelligence agents out of core enterprise workflows has not been a lack of model intelligence. It has been something far more mundane and far more terrifying for security teams: the credentials. Every time an AI agent reaches for an internal database or a proprietary API, it typically carries the authentication keys with it. If that agent is compromised, or if it simply behaves unexpectedly, those keys are exposed. Anthropic has introduced two new capabilities for Claude Managed Agents that directly address this vulnerability. These features—self-hosted sandboxes and MCP tunnels—fundamentally change how ai agents enterprise apis can connect securely. This article breaks down five distinct ways these tools are reshaping the landscape.
1. The Split Architecture: Separating the Brain from the Hands
The most significant shift in connecting ai agents enterprise apis is the architectural separation between the agent’s planning loop and its tool execution. In traditional deployments, the entire agent—including its reasoning, context, and the credentials it uses—runs as a single unit. Anthropic’s approach for Claude Managed Agents splits these functions.
The agent loop, which handles orchestration, context management, and error recovery, continues to run on Anthropic’s infrastructure. The tool execution, however, runs on the enterprise’s own system. This is not a minor tweak. It is a fundamental redefinition of where trust boundaries lie.
Consider what happens when an agent needs to query a customer database. In the old model, the agent carried the database password inside its context window. If an attacker exploited a prompt injection, they could extract that password. In the split architecture, the agent sends a request to execute a tool, but the tool runs inside the enterprise perimeter. The credentials never leave the building. The agent completes its task without ever holding the keys that unlock the system.
Why This Matters for Security Architects
For a security architect integrating ai agents enterprise apis, this split changes the threat model entirely. The attack surface shrinks because the credentials are no longer a moving target inside the agent’s context. They remain static, managed by the enterprise’s own identity and access management systems. This single architectural decision can satisfy compliance requirements that previously made AI agent deployment impossible in regulated industries.
2. Self-Hosted Sandboxes: Tool Execution Inside Your Perimeter
The first of the two new capabilities is the self-hosted sandbox. This feature allows enterprises to run tool execution inside their own infrastructure perimeter. Instead of sending code or API calls to an external environment where the agent might inspect or manipulate them, the execution happens on hardware the enterprise controls.
Imagine a financial institution that needs an AI agent to process loan applications. The agent must access a legacy mainframe that contains sensitive credit data. With a self-hosted sandbox, the tool that reaches into that mainframe runs on a server inside the bank’s data center. The agent itself never sees the mainframe’s IP address, let alone its login credentials.
Self-hosted sandboxes are currently in public beta for Claude Managed Agent users. They address the immediate need for file and package isolation. If an agent needs to run a Python script to transform data, that script executes in an environment the enterprise provisions and monitors. The agent cannot exfiltrate the script’s output to an unknown server because the network egress is controlled by the enterprise’s own firewall rules.
A Practical Starting Point for Existing Teams
For teams already using Claude Managed Agents, the practical starting point is the self-hosted sandbox. Move the tool execution onto your own infrastructure first. Test how the boundary holds under normal workloads. This step alone reduces the risk of credential leakage significantly. It also gives your operations team direct visibility into what the agent is actually doing at the execution level.
3. MCP Tunnels: Private Network Connectivity Without Exposed Credentials
The second capability, MCP tunnels, addresses a different layer of the security problem. While self-hosted sandboxes handle file and package isolation, MCP tunnels solve credential exposure at the network level. They connect agents to private MCP servers without ever exposing the credentials in the agent’s context window.
Think of an MCP tunnel as a lightweight, outbound-only gateway that sits inside your organization’s network. When the agent needs to call an internal API, it sends a request through this tunnel. The tunnel authenticates the request using credentials stored securely within the enterprise network. The agent itself never sees the API key, the database password, or the OAuth token. It only sees the response.
MCP tunnels are currently in research preview. They represent the next evolution in how ai agents enterprise apis can interact without compromising security. For a CISO evaluating this technology, the key insight is that the tunnel moves credential control to the network boundary. The credentials are managed by your existing secrets management system, not by the agent’s runtime environment.
What MCP Tunnels Add Beyond Existing Sandboxing
If your enterprise already has a robust sandboxing solution, you might wonder what MCP tunnels add. The answer lies in the network layer. Sandboxes isolate the execution environment. Tunnels isolate the network path. Together, they create a layered defense. A sandbox prevents an agent from running arbitrary code that accesses your files. A tunnel prevents an agent from reaching your internal APIs even if it somehow escapes the sandbox. They are separate concerns that map to different parts of the security stack.
4. Moving Credential Control to the Network Boundary
This is the unifying principle behind both self-hosted sandboxes and MCP tunnels. Historically, when an AI agent executed a tool call, the credentials traveled with the agent. They were stored in the agent’s context, visible to the model, and potentially extractable through prompt injection or other attacks. The new architecture moves credential control to the network boundary.
What does this mean in practice? Imagine a manufacturing company using an AI agent to monitor its supply chain. The agent needs to query an internal ERP system to check inventory levels. In the old model, the ERP credentials were passed to the agent as part of the tool definition. If the agent’s context was logged for debugging, those credentials might appear in a log file. If the agent was compromised, an attacker could use those credentials to access the ERP system directly.
In the new model, the agent sends a request to execute the inventory check. The request goes through the enterprise’s network boundary, where the credentials are applied. The agent never possesses them. The log files show only that a tool call was made, not the authentication details. This simple shift has profound implications for compliance with standards like SOC 2, ISO 27001, and GDPR.
You may also enjoy reading: iOS 27 Design Leak: 5 Features I Sounded Off For.
Why This Matters More Than Keeping the Entire Agent In-House
Some enterprises might wonder why they should adopt this split architecture instead of simply running the entire agent on-premises. The answer is operational overhead. Running the agent loop—the orchestration, context management, and error recovery—requires significant infrastructure. By keeping that loop on Anthropic’s platform while moving only tool execution in-house, enterprises get the best of both worlds. They benefit from the platform’s scalability and updates while maintaining control over their sensitive data and credentials.
5. Mapping Workflows More Effectively with Separate Concerns
The final way these capabilities transform enterprise connectivity is through better workflow mapping. Because sandboxes and MCP tunnels are separate concerns, teams can design their agent workflows with greater precision. They are not forced into a one-size-fits-all security model.
Consider a healthcare organization that needs an AI agent to handle both patient record queries and administrative scheduling. The patient record queries require the highest level of security—self-hosted sandboxes with strict network isolation. The scheduling queries can use a less restrictive environment. With the split architecture, the organization can define different sandboxes and tunnels for different types of tool calls. The agent’s workflow maps naturally to the security requirements of each task.
How Orchestration Teams Benefit
For orchestration teams, this separation is more than a security update. It helps agents run better. When sandboxes determine where tool execution happens and MCP tunnels determine how agents reach internal systems, teams gain fine-grained control over performance and reliability. They can route high-priority queries to dedicated resources. They can implement retry logic at the tunnel level without affecting the agent’s reasoning loop. They can monitor execution separately from orchestration, making it easier to debug issues.
Teams evaluating this platform for the first time should treat the sandbox architecture as the primary technical differentiator. It is not just a deployment model. It is a change to the threat model itself. The agent no longer needs to be trusted with the keys. It only needs to be trusted to ask nicely.
A Word on the Broader Landscape
Anthropic is not alone in recognizing this need. OpenAI added local execution to its Agents SDK in April 2025, responding to similar demand from enterprise customers. However, the architectural distinction Anthropic draws—splitting the agent loop from tool execution—is unique. OpenAI’s approach keeps the agent more integrated, which may appeal to teams that want simplicity over granular control. The choice between these approaches depends on your organization’s risk tolerance and operational maturity.
Getting Started: Practical Steps for Your Team
If you are ready to explore how these capabilities can connect your ai agents enterprise apis, here is a practical path forward.
First, if you are already using Claude Managed Agents, start with self-hosted sandboxes. They are in public beta and ready for testing. Move one non-critical tool execution onto your own infrastructure. Monitor the performance. Check the logs to confirm that credentials are not leaking. This will give you confidence in the architecture before you tackle more sensitive integrations.
Second, keep an eye on MCP tunnels as they move from research preview to general availability. When they are ready, they will solve the network-layer credential problem. Plan your internal API gateway strategy now so that you can quickly integrate tunnels when they become available.
Third, if you are evaluating the platform for the first time, focus on the sandbox architecture as your primary evaluation criterion. Ask your vendor how they handle credential management during tool execution. If the answer involves the agent carrying credentials in its context, that is a red flag. The split architecture is not a nice-to-have. It is a fundamental requirement for secure enterprise AI deployment.
The era of trusting AI agents with your API keys is ending. The era of network-boundary credential control is beginning. These five ways—the split architecture, self-hosted sandboxes, MCP tunnels, boundary-level credential management, and workflow-specific security mapping—represent the new standard for connecting ai agents enterprise apis safely and effectively.
