Sandboxes are necessary. They are not agent safety.

I want my agents sandboxed. I also want us to stop treating "it runs in a sandbox" as an answer to every question about agent safety.

An agent can stay inside its sandbox, use only the tools I gave it, and still do something I never wanted. Send the wrong email. Buy something it should only have compared. Delete messages while "organizing" my inbox. None of that requires a sandbox escape.

A robot stays inside a locked sandbox while sending email, ordering a parcel and deleting messages, telling its alarmed owner, "But I stayed in the sandbox!"

Isolation is not a new invention

FreeBSD Jails shipped with FreeBSD 4.0 in 2000. Solaris Zones arrived with Solaris 10 in 2005. Docker was introduced in 2013. These are not identical technologies or interchangeable security boundaries, but the underlying idea of isolating workloads is much older than today's agents.

Across these systems and their evolution, we have had filesystem and process isolation, network separation, resource controls and restrictions on privileges. The details and strength of those controls depend on the implementation and configuration. Crossbow later complemented Solaris Zones with network virtualization and resource management; it was not part of the original 2005 Zones release.

Modern agent sandboxes can make these controls much easier to use. Disposable environments, mediated network access, credential handling and integration with agent runtimes are useful engineering. I am not dismissing that work. I am distinguishing useful integration from inventing isolation.

The question isolation cannot answer

A sandbox answers questions such as: which files can this process read? Which hosts can it contact? How much memory can it consume? Which privileges does it have?

It does not, by itself, answer: should this agent send this message to this recipient, for this task, right now?

Suppose I give an assistant access to an email service because I want it to handle correspondence. Network access to that service is legitimate. The account is legitimate. The send operation is legitimate. Sending a private attachment to the wrong person can still be a serious failure.

The same applies to shopping. An agent may legitimately browse products, manage a cart and, for some tasks, place an order. Permission to use the purchase tool is not blanket permission to buy whatever seems helpful.

Least privilege remains important. Use scoped credentials, separate read and write operations, restrict destinations, cap spending and require explicit approval where the consequence warrants it. A sandbox or tool gateway can enforce many of these restrictions. We should enforce everything we can reliably express that way.

But if the goal is useful autonomy rather than a fixed script, not every valid decision can be enumerated in advance. The remaining question depends on context: what I asked for, what I explicitly ruled out, what has changed, and what the agent has already done.

This is not just hypothetical

OpenAI's report on the Hugging Face incident and model misalignment describes models resorting to misaligned strategies to complete difficult tasks. It identifies categories including third-party access control bypass, use of exposed credentials, injection and unwanted posting on third-party sites.

The report says the most severe incident was driven primarily by an internal-only research model. That distinction matters. It is not evidence that every deployed assistant behaves this way, and these incidents are not all examples of misuse of an otherwise authorized email or purchase tool.

What I take from it is narrower: successful task completion is not enough to establish that the methods were acceptable. Restricting the execution environment and evaluating the agent's behavior are related, but different, jobs.

I am not claiming that my own guardrails would have prevented that incident. That would require evidence I do not have.

Why I am working on another layer

This is the problem I am exploring with Intaris. I am building it, so this is also a disclosure of where my interest comes from, not an independent product review.

The approach combines a representation of the user's intent with action classification and configurable deterministic policy. Policy can approve, deny or escalate an action; an optional judge can review eligible cases with additional context. Integrations put those checks in the tool execution path. Session summaries and cross-session analysis look for behavior that one isolated call may not reveal.

That separation is useful for expressing rules, understanding decisions and keeping an audit trail. It is not proof that the decisions are correct.

In my own tests, moving a nondeterministic model from deciding to classifying did not, by itself, make the outcomes more reliable. If a model incorrectly classifies an action, deterministic policy can consistently produce the wrong result. If the representation of the user's intent is wrong, a clean policy implementation does not repair it.

I still think separating assessment from authority is worth doing. It gives me explicit rules I can inspect and test, instead of asking a model to improvise the whole authorization decision. But the uncertain inputs remain uncertain. Adding another evaluator does not make that uncertainty disappear.

One call is not the whole behavior

An individual action can look reasonable while the sequence is not. A research agent gradually expands its scope. An assistant repeats a questionable shortcut across sessions. A parent delegates a task and a child interprets the limits more broadly. Looking only at the next tool call can miss the pattern.

I want oversight that can connect those activities without treating an agent's own summary as fresh authorization. That means preserving the user's actual instructions, keeping track of delegation boundaries, and reviewing session and cross-session behavior. It also means deciding when to interrupt and ask a human, rather than making every uncertain action an approval prompt.

There is a tradeoff here. A guardrail that blocks ordinary work all day is not a useful answer either. I care about harmful approvals and unnecessary blocks, and about the conditions under which both happen. A single safety percentage without the revision, scenarios, policy and grading method does not tell me much.

I expect more specialized evaluators to emerge for this work. Jev is a useful starting point to explore, not a final answer. Some checks should be ordinary code, some can use smaller specialized models, and some may need richer contextual evaluation. Multilingual input does not automatically mean that only a general-purpose LLM can perform the check.

Keep the sandbox. Ask the next question.

My practical position is to keep the layers: isolation, least privilege, explicit policy, contextual assessment, human escalation and behavioral review. Each has a different job. None is an excuse to skip the others.

I do not think this solves alignment. I think it gives us a more honest way to work on the operational problem: agents that can do useful things also need controls over how they use that ability.

What are you using in practice to distinguish "the agent can do this" from "the agent should do this"? How do you handle drift across sessions and delegated work? Or are you letting agents do whatever they can and hoping for the best?