Agent Sandboxing: Why Your AI Agent Needs a Walled-Off Workbench – and an Approval Step Anyway

Imagine your new employee gets the master key to the whole building on day one: offices, warehouse, server room, safe. Nobody has told them which doors to use, and nobody is looking over their shoulder. No sensible managing director would do that. With AI agents, it happens surprisingly often. An agent gets access to the file system, a database, the mailbox, because that is the fastest way to set it up. You only notice the risk when something goes wrong.

This article covers a concept known as the "sandbox": a walled-off workbench where an agent can work without reaching everything else. It is an evergreen topic, not news from today. We still cover it because Anthropic presented a concrete version in May 2026 that shows the principle well. We stick strictly to what the sources confirm, and we say explicitly what is beta, what is not, and what we could not verify.

We assign the topic to our Code-Operator. On our website we describe this agent as handling "bugs, fixes, pull requests with your approval". That fits, because wherever an agent executes code, the question of the workbench is most pressing. The article ends with the difference that matters: an agent with limits and an approval step versus an agent that is simply allowed to "do it".

What a sandbox is, in everyday language

A sandbox is an isolated execution environment. When an AI agent starts a script, writes a file or calls a tool, this does not happen on your main system but in a separate, limited space. What happens there can stay there. What the agent should not see is simply not present.

An analogy from daily business: a visitor badge opens only certain doors, a master key opens all of them. A tradesman repairing the heating in your house gets access to the boiler room, not to your office. A sandbox translates this logic into technology. The question is not "Do we trust the agent?" but "What can possibly happen in the worst case if it is wrong?" If you have limited the answer to the second question technically, you have less to worry about on the first.

This matters because AI agents make mistakes. That is not malice but a property of the technology: an agent reads instructions, documents, web pages and emails and derives actions from them. If a document contains a smuggled instruction, or the agent misunderstands a task, it may carry out steps nobody wanted. Whether those steps cause damage depends less on the model than on what the agent can technically touch.

"What do we need a human's approval for?" and "What can the agent technically touch at all?" are two different questions. A safe setup answers both.

What Anthropic published on May 19, 2026

Let us start with what is confirmed. The primary source is the post "New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels" on claude.com, published on May 19, 2026. It describes two innovations for "Claude Managed Agents", Anthropic's offering in which Anthropic runs agents for you.

First: self-hosted sandboxes. By default, the tools of a managed agent run in environments that Anthropic provides. With the new option, you move tool execution into your own infrastructure or to a managed sandbox provider. The post names Cloudflare, Daytona, Modal and Vercel. You define resource size and runtime image yourself. The status according to the post and the documentation: public beta.

What stays with Anthropic matters. According to the post, the agent loop, meaning orchestration, context management and error handling, continues to run on Anthropic's infrastructure. Only tool execution moves to you. The documentation adds that tool inputs and outputs still flow to Anthropic's control plane so that the model can receive results and decide what to do next. Anthropic also stores skills and memory stores; your sandbox holds a copy for the duration of the session. Anyone who reads "self-hosted" and assumes no data leaves the house is mistaken. What is meant is: you decide where code runs and files live, not that everything stays with you.

Second: MCP tunnels. MCP is the standard through which agents talk to tools and data sources. An MCP tunnel connects managed agents to MCP servers in your private network without making those servers publicly reachable. A gateway you provide opens a single outbound connection; according to the post, no inbound firewall rules are needed. The status: research preview, access must be requested. Organization admins manage it in the workspace settings of the Claude Console.

The documentation makes clear that the two are independent of each other. A session in Anthropic's own sandboxes can reach private MCP servers through a tunnel, and a self-hosted session can use tunneled or public MCP servers. If you want both execution and tool access to stay inside your own boundary, you need both.

Availability: what is usable and what is coming your way

Precision is worthwhile here, because the difference between "concept", "beta" and "product" determines your planning.

• Sandboxing as a principle is neither a product nor a beta. It is a security idea you can apply regardless of vendor and model.
• Self-hosted sandboxes in Claude Managed Agents are a public beta according to the source. We therefore do not describe them as something you should simply adopt for production today, but as what is coming for companies. The documentation also lists restrictions: sessions in self-hosted environments support only memory stores as a resource; sessions with file or GitHub repository resources are rejected.
• MCP tunnels are a research preview with access on request. Do not build a business process on this before you have checked the terms.
• Region and DACH: The sources name no country restriction. Whether and under what conditions the offerings apply to your company in Germany, Austria or Switzerland is therefore not confirmed. We claim nothing about this.
• Pricing and license terms are not in the sources we rely on. Clarify this with the vendor.

For you, this means: you do not have to wait for a beta to apply the principle. But if you talk to a service provider or platform that promises "sandboxing", ask where exactly the boundary runs and which part is beta.

The limits of a sandbox: what it does not solve

A sandbox limits what can technically happen in case of error. It does not decide whether an action is correct in substance. Many people confuse this. Three examples show the difference.

Example 1: The payment. An agent prepares a transfer on behalf of your accounting. The sandbox ensures it does not read foreign files or reach systems it does not need. Whether the transfer goes to the right recipient is something the sandbox cannot judge. That takes a human who approves before execution.

Example 2: The external email. An agent drafts a reply to a customer. In the sandbox it cannot delete anything that is not its own. But whether the tone is right, whether a commitment is defensible or whether a contract detail is misrepresented is decided by your responsibility, not by technology. That is why, for example, emails are created as drafts with us rather than sent directly. That is also what our website says.

Example 3: The deletion. An agent tidies up files. In a well-drawn sandbox, that affects only the folder intended for it. Whether that folder really contains only superfluous items is a question of substance. Before something disappears irreversibly, a human belongs in between.

The sandbox is therefore the technical boundary, the approval step the one of substance. Without a boundary, an error can reach far; without approval, it can go unnoticed. A serious setup has both.

Why the topic is getting attention right now

In our source overview, the topic "agent with limits" keeps appearing. The "AI Engineer" conference published talks in October 2026 whose titles revolve around sandboxing, security and governance of agents. We could not check the content of those talks individually for this article and base no statement on them. We mention them only as a hint that the field is thinking about the same question: not which model is best, but how to operate agents without giving them more than they need.

The security community has reacted as well. The OWASP GenAI Security Project published a framework titled "OWASP Top 10 for Agentic Applications for 2026" on December 9, 2025, which names the most critical security risks of autonomous and agentic AI systems. We could not see which risks are listed on the publicly accessible page; the list sits in the downloadable document. We therefore refrain from quoting individual items. If you are drafting internal security rules for agents, that document is worth a look.

Four questions to ask every vendor and your own team

You do not need to be a technical expert to assess an agent setup. These four questions are enough for a first picture.

1. Where does the code the agent creates or starts run? On the employee's computer, on a company server or in an isolated environment? If the answer is "on the machine where everything else lives too", there is no sandbox.

2. What access does the agent have, and why exactly these? Every access should be justified. An agent that prepares invoices does not need access to HR data. Anthropic's documentation gives a vivid hint: keep the API key used to start sessions away from the machine where the agent runs tools, because tool calls could read it there. That is the principle in pure form: what the agent must not be able to read must not be there.

3. What happens in the worst case? Play it through. If the agent is completely wrong, what is the worst thing it can trigger? If the answer is "we don't know", the boundary is too wide.

4. Which actions have real effect and need approval? Payments, external emails, deletions, changes to production systems. For this list: a human approves before anything happens.

What you can prepare this week

Because the concrete products are partly still in beta, we recommend preparation rather than adoption. These steps cost little and pay off in any case, regardless of which platform you choose later.

1. Inventory of access. List which systems AI tools in your company can already reach today: mailboxes, drives, databases, development environments. Often it is more than management realizes.
2. The approval list. Write a short list of actions that must never happen without human approval: payment, external sending, deletion, changes in production systems. Half a page is enough.
3. Separate secrets. Check where credentials and keys are stored and whether an agent could reach them. What the agent should not read does not belong within its reach.
4. A small pilot with a tight boundary. If you try an agent, start with a task where little can go wrong, and with a separate workspace.
5. Ask about beta status. Ask every vendor which functions are generally available and which are beta or preview. Plan productive processes only on what is generally available.

What this looks like at Amazing Agents

We deliberately describe our approach here and not success figures. For every agent we set up, we first clarify two things: what it should be able to do and what it must not be able to do. The Code-Operator is a good example. Our website says it handles bugs, fixes and pull requests with your approval. The "with your approval" is not an add-on but part of the task description: the agent prepares, a human approves. Our website puts it generally: every agent runs within a defined frame with approval steps for critical actions.

That is the difference between an agent with limits and an approval step and an agent that is simply allowed to "do it". The first falls back on a limited environment and a human check when something goes wrong. The second has neither.

Summary: workbench yes, blank check no

To sum up: a sandbox is a walled-off workbench on which an agent can work without reaching everything else. On May 19, 2026, Anthropic presented self-hosted sandboxes as a public beta and MCP tunnels as a research preview. That shows the direction of the market: tool execution should be able to take place where you decide. At the same time, the documentation shows that the boundary is not absolute, because inputs and outputs continue to flow to the vendor's control plane.

A sandbox does not replace an approval step. It only limits what can technically happen in case of error. The decision whether a payment, an email or a deletion may take place stays with a human. Anyone who thinks both together, the technical boundary and the human approval, has a setup that holds even when an agent is wrong once.

Sources

• Anthropic: "New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels", claude.com/blog/claude-managed-agents-updates, May 19, 2026 (primary source).
• Anthropic: documentation "Self-hosted sandboxes", platform.claude.com (status: beta; retrieved October 28, 2026).
• OWASP GenAI Security Project: "OWASP Top 10 for Agentic Applications for 2026", genai.owasp.org, December 9, 2025 (only title and date checked, individual risks not viewed).