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. As agents take on longer and more consequential work, the stakes grow. They 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 problem is not the strength of the isolation mechanism, but 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.”

The practical outcome is that restrictions get loosened, exceptions accumulate, or developers bypass them entirely. The controls meant to secure the agent become obstacles to its productivity.

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 are no longer automatically exposed, other workloads can be isolated, and the environment can be terminated when the task ends.

That’s a much better starting point. But asking developers to run agents in completely locked-down containers or VMs would create even more friction than the built-in sandboxes discussed above. Without access to the systems they need, agents simply can’t get much work done.

Real work requires access to repositories, dependencies, internal services and organizational 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. An agent that needs to read production data shouldn’t automatically be able to modify it. Access needs to be limited to the resources and operations the task requires.

And it’s not enough to govern the obvious connections. Even basic infrastructure can expose unexpected paths outside the environment. The opening DNS incident illustrates this: direct web access was blocked, but an indirect path remained available.

Isolation contains where the agent runs, but not what it can reach or do. Both its permissions and the paths available to it need to be governed.

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.

A gateway only governs traffic that passes through it. Without control over the agent’s execution environment and alternative access paths, it cannot enforce policy over everything the agent can do.

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.

Classifiers can reduce the likelihood of harmful actions, but cannot guarantee prevention. The consequences of a miss depend on the authority the agent already has.

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.

EDR can detect and contain suspicious activity. It doesn’t, on its own, limit what an agent is authorized to reach or do.

What it takes to run agents unattended

For agents to operate unattended, organizations need confidence that their access and potential impact remain under control, without someone approving every action. No single sandbox, gateway or classifier provides that assurance on its own.

1. 01

   Contained execution. The agent can execute arbitrary code without compromising the host or unrelated workloads. Code and configurations it leaves behind must not become a way to execute outside the boundary with greater privileges.

2. 02

   Least-privilege access. The agent receives only the permissions its task requires, rather than inheriting the developer’s broader access. Credentials, network destinations, resources and permitted operations are restricted, limiting what even a compromised agent can reach or change.

3. 03

   Independent enforcement and response. The agent cannot disable its security controls, change its permissions or bypass policy through another tool or network path. Prohibited actions are blocked, violations can be detected while the agent runs, and security teams can revoke access or terminate sessions, automatically or manually, without the agent’s cooperation.

4. 04

   Reliable visibility and accountability. Security teams need a trustworthy record of what the agent actually executed and changed, not just its model conversations or tool requests. That record must be protected from modification by the agent.

5. 05

   Usable without constant supervision. The environment must support real workloads, including their dependencies, tools and internal services, without repeated human approvals or continual exceptions to policy.

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 its code 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?

The standard isn’t that an autonomous agent will never make a mistake. It’s that its authority and potential impact remain bounded when it does, and the organization can independently verify what happened.

That’s what makes unattended execution viable: agents can work independently without security depending on someone watching every step.

Where Relm fits

Relm is built to make unattended agent execution safe and practical at enterprise scale. We isolate where agents run, limit what they can reach and do, and enforce those limits independently of the agents themselves.

Agents should be able to work for hours or days across code, infrastructure and business systems, taking on consequential tasks without constant human supervision. The confidence to let them do that must come from enforceable limits on their authority and impact, not from assuming they will always act correctly.

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.