Sandboxes, gateways and the limits of agent security.

On September 20, an OpenAI agent that had been denied internet access found the sandbox’s DNS resolver and used it to reach a public chatbot. OpenAI called the cause “a gap in our controls over network restrictions” and paused training. The agent didn’t break out of its sandbox. A network path nobody had governed stayed open, and the agent took it.

That is the question to ask of any control around an autonomous agent: not just whether it holds, but what it leaves open. Agents execute code, hold credentials and interact with internal systems, increasingly without human supervision. Anything they read or run may be compromised. What matters is what they can still reach and do when that happens.

Coding agents make these risks particularly visible because they execute arbitrary code. Security teams rely on five kinds of control for them: built-in agent sandboxes, dedicated isolated runtimes, LLM and MCP gateways, guardrails, and endpoint detection and response. They are often compared as alternatives, but each governs a different part of the agent’s activity.

01 / 05Built-in agent sandboxes

Coding agents now ship real, kernel-enforced sandboxes, with permission rules, managed settings and approval steps. When agents run inside an existing development environment, these controls restrict what their commands can access without requiring a separate execution environment. Turn them all on. The isolation mechanism is strong. The problem is how much the agent needs to be allowed to do.

A coding agent works inside a developer’s existing environment, with its tools, services, credentials and network access. It needs to install dependencies, run scripts, modify files and reach internal systems. The sandbox has to restrict access without getting in the way of that work. Make it too restrictive, and legitimate tasks get blocked. Loosen it enough to accommodate everything the agent needs, and much of the developer’s environment becomes accessible again.

Permission prompts handle exceptions by putting the developer back in the loop for work they were trying to delegate. Anthropic reports that users approve 97% of permission prompts. In its controlled study, testers who caught about 17% of dangerous commands early in a session caught only 5% after fifty prompts. And 25% of interactive Claude Code sessions start with permissions bypassed.

Centrally managed policies can prevent developers from bypassing enforcement, but they don’t solve the underlying problem: restrictions that interfere with legitimate work create constant pressure for exceptions.

“We’re going to have to press approve over and over and over again, because we just completely locked everybody down. Now we’re stuck: we have a security policy we want to put in place, but when we do, we break everything, because no one can press the yes button fast enough.”

There is a separate security problem even when the sandbox holds. Coding agents write code, scripts and configuration files into the developer’s workspace. Those files can later be consumed or executed by tools running outside the sandbox, with the developer’s privileges. Cursor fixed a vulnerability of this kind in February 2026, where an agent could modify Git hook configuration inside the sandbox and cause code to execute outside its restrictions.

02 / 05Dedicated isolated runtimes

Dedicated isolated runtimes take a different approach. Instead of restricting an agent inside an existing development environment, they give it a separate container or VM to execute in. The developer’s credentials don’t need to be exposed, other workloads can be isolated, and the environment can be terminated when the task ends.

But an agent doesn’t need to escape its container to cause damage. If it has credentials that allow it to deploy to production, modify a database or change cloud infrastructure, it can do all of those things from inside the container. The isolation boundary can hold perfectly while the agent does harm through connections it was given.

Real work requires access to repositories, dependencies and internal systems. The challenge is providing that access without recreating the developer’s broad permissions inside the isolated environment. An agent working on one repository shouldn’t have access to every repository its developer can reach.

03 / 05LLM and MCP gateways

LLM gateways govern calls to models, while MCP gateways govern interactions with connected tools and services. They can enforce policies, manage credentials and log activity. But they only see part of what an agent does.

A coding agent also runs shell commands, modifies files and executes programs. When it runs npm install or python script.py, a model gateway may see the requested command, but not what the code actually does: which files it reads, processes it launches or network requests it makes. Gateway logs are not a complete record of agent execution.

The same problem applies to enforcement. Suppose an MCP gateway restricts Jira to read-only operations. An agent with a Jira token and direct network access can simply call Jira’s REST API instead. The gateway enforces its policy correctly, but the agent modifies Jira through another path. The same applies to Git, SSH, cloud CLIs and any other interface the agent can use directly.

04 / 05Guardrails and classifiers

Guardrails and classifiers review an agent’s actions before they execute, using AI to identify potentially dangerous behavior. They can be effective: Claude Code’s Auto Mode caught 89% of dangerous commands in Anthropic’s controlled study, compared with 13.6% caught by human reviewers.

But classifiers don’t always see enough to judge what an action will actually do. They may see a command without the code it executes or the state it will affect, and some actions may bypass review entirely. We’ve examined these gaps in Claude Code’s Auto Mode.

And even with complete visibility, their decisions remain probabilistic. A classifier can miss a dangerous action, which then executes with whatever privileges the agent already holds. An agent with write access to a production database can still delete data if the classifier approves a destructive query. With read-only access, the same query would fail regardless of the classifier’s decision.

05 / 05Endpoint detection and response

Most enterprises already run EDR on developer machines, and it sees what gateways miss: the processes an agent launches, the files it touches, the connections it opens. When it detects suspicious activity, it can kill the process or isolate the host.

But EDR evaluates endpoint behavior, not whether an action was authorized for a particular agent task. Installing packages, running scripts and pushing to Git are things developers do all day. An agent that pushes to the wrong repository or deletes the wrong table, using access the developer legitimately holds, may look like ordinary developer activity. EDR may trace that activity back to the agent, but it doesn’t establish whether the agent was allowed to perform it.

The harder question

Consider an agent assigned to read a Jira issue, modify code in one repository, run tests and open a pull request. Could it reach unrelated repositories or production systems? Could something it writes later execute with greater privileges? Can security see what it actually did and stop it independently? And could it complete that work overnight without anyone approving commands or weakening the restrictions?

Autonomous agents will make mistakes. The standard is that their authority and potential impact stay bounded when they do, and that the organization can independently verify what happened.

Where Relm fits

Relm is built so enterprises can hand autonomous agents consequential work and leave them to it. We isolate where agents run and enforce limits on what they can reach and do, independently of the agents themselves.

Autonomous agents should be able to operate anywhere in the enterprise, even in the highest-stakes environments, without forcing organizations to compromise on security or control.