Why Long-Running AI Agents Can't Do Without Sandbox Isolation

The Problem Isn't Time — It's Boundaries

As AI agents evolve from one-shot Q&A tools into systems capable of running continuously and completing complex tasks autonomously, a security principle keeps coming up: long-running agents need boundaries, not trust.

This cuts to the heart of the core tension in current agent security design. Many people intuitively assume that the longer an agent runs and the more complex its tasks, the higher the risk — as if time itself were the culprit. But the real problem has never been time. It's the action capabilities the agent possesses while running.

Modern agents actively edit files, execute system commands, and read external inputs. Each capability is a door — and the external input door is especially dangerous, as it may conceal malicious instructions that silently hijack the agent's behavior.

What ETH Zurich's Security Tests Revealed

Researchers at ETH Zurich conducted systematic testing of tool-using agents, covering 97 realistic tasks and designing 629 security tests.

The results were sobering. The study found that both attacks against agents and defenses built for them are extremely challenging. Attackers can manipulate agents through carefully crafted inputs, while defenders struggle to close vulnerabilities without sacrificing functionality.

The significance of these numbers is that they quantify what was previously theoretical: agent security is not an abstract concern, but a real risk that can be triggered repeatedly in real-world tasks. When an agent is granted permission to call tools, it simultaneously inherits the possibility of being turned against by those same tools.

This kind of systematic security evaluation for agents typically uses a Red Teaming framework: researchers take on the role of attackers and design test cases covering multiple attack vectors — including direct prompt injection, indirect injection (delivering malicious instructions via external content the agent reads), tool misuse, and multi-step reasoning hijacking. The scale of 629 security tests means the research team attempted to cover the combinatorial space of attack paths, rather than simply validating a handful of known vulnerabilities. Notably, the tradeoff between "functionality" and "security" is one of the core findings in such research — overly tight defenses often prevent agents from completing normal tasks, revealing the harsh reality that there is no "zero-cost defense" in agent security.

What Sandboxes Do — and Don't Do

Sandboxing is a critical tool for addressing these risks, but one misconception must be corrected first: a sandbox does not make a model more obedient or more well-behaved. It doesn't change the model's internal behavior. Instead, it imposes hard limits on the agent's capabilities at the operating system level.

Specifically, a sandbox constrains three categories of access:

• File access: limits the directories the agent can read from or write to
• Network access: controls which external addresses it can connect to
• Process access: restricts which system processes it can launch or interfere with

In other words, a sandbox doesn't try to "convince" an agent not to do something harmful — it makes the agent incapable of doing it. Even if a hijacked agent tries to delete critical files or exfiltrate data, OS-level isolation blocks it.

But sandboxes are not a silver bullet. Secrets management, human approvals, audit logs, and recovery mechanisms all live outside the sandbox. A sandbox is just one layer of the overall security architecture — not the whole thing.

From an implementation standpoint, sandboxes are typically built on OS-level namespace isolation (e.g., Linux's seccomp, cgroups), containerization (Docker/Kubernetes), or virtual machines. In Docker, for instance, the agent process is confined to an isolated filesystem view — host directories are completely invisible unless explicitly mounted. Network policies can whitelist permitted outbound addresses via iptables rules. This "hard capability cutoff" design philosophy echoes traditional software security's access control lists, with the key difference that sandboxes operate at the process level rather than the authentication layer. This is precisely why sandbox effectiveness is tightly coupled to configuration granularity — overly permissive mount paths or open outbound network policies can render a sandbox effectively useless.

Why Sandboxes Alone Aren't Enough

The limitations of sandboxes become especially apparent when long-term memory enters the picture.

Long-running agents often have memory capabilities, meaning that information received during one task — including potentially tainted inputs — can influence decisions in subsequent tasks. A sandbox can limit the permission boundary of a single run, but it cannot break the chain of errors propagating through memory across tasks.

Once malicious instructions settle into memory, they may activate at some future, seemingly unrelated task. This is the fundamental risk that distinguishes long-running agents from one-off calls — errors and attacks are delayed and cumulative.

In agent architectures, long-term memory is typically implemented as a vector database, key-value store, or structured log, allowing agents to persist and later retrieve information across conversation turns or tasks. This is distinct from a large language model's context window, which is cleared when a session ends — long-term memory persists. Prompt injection attacks exploit exactly this: an attacker embeds text disguised as system instructions in an agent's external input (such as a webpage or email body), tricking the agent into writing malicious information into memory storage, thereby influencing decision paths in completely different future tasks. The insidiousness of this attack lies in the time gap between infection and effect, making tracing and attribution extremely difficult.

The Real Question: How Far Can an Error Spread?

If you had to summarize the core proposition of agent security in one sentence, it would be: how far can an agent's mistakes actually reach?

As tasks progress, this "blast radius" must be continuously compressed, not left to expand. Achieving this requires multiple defensive layers working in concert:

• Keep permissions minimal: always follow the principle of least privilege — don't give agents capabilities they don't need
• Require approval for risky operations: introduce human confirmation for high-risk actions
• Log all tool calls: maintain a full audit trail of every tool the agent uses, enabling review and traceability

The goal of this layered approach is to limit the impact radius of any single failure or attack to the smallest possible scope. Sandboxes provide foundational isolation, while approvals, auditing, permission controls, and recovery mechanisms together form a defense-in-depth strategy.

Conclusion

The essence of agent security is a fundamental shift in mindset: from "trust that the model will behave well" to "assume the model could fail or be hijacked at any time, and constrain its potential damage in advance." Time is not the enemy — unchecked capability is. Designing clear boundaries for long-running agents, so that errors have nowhere to spread, is the prerequisite for building reliable autonomous systems.