Safety Boundaries and Sandboxes

We have given an AI system a mission, tools, permissions, an autonomy envelope and perhaps enough persistence to operate for days or weeks. That raises an unavoidable engineering question: What happens when it makes a mistake? One answer is to design the surrounding system so that even a capable agent cannot reach everything.

Instructions Are Not the Same as Containment

Suppose an agent is told:

That instruction matters. But we can build a stronger boundary by also making production modification technically unavailable.

What Is a Sandbox?

A sandbox is a restricted execution environment designed to limit what a program or process can access or affect.

The exact mechanism varies. A sandbox may use operating-system permissions, containers, virtual machines, restricted user accounts, filesystem isolation, network controls, API gateways, capability restrictions, resource quotas, or combinations of these.

The useful HAAW idea is simpler:

The Sandbox Is Not the Model

The transformer does not create the sandbox. The sandbox belongs to the surrounding computer system.

The model may request an operation outside the allowed environment. The important engineering question is what happens next.

Filesystem Boundaries

Imagine an AI coding agent that needs to modify one project.

Instead of exposing the entire machine:

the execution environment might expose only:

The agent can read and write inside the workspace while unrelated files remain outside its reachable namespace or permissions.

This reduces the blast radius of a bad command, mistaken path or incorrect model decision.

Blast Radius

Borrowing a useful engineering term, blast radius describes how much of the surrounding system can be affected when something goes wrong.

Operating-System Identity Is a Boundary

Our earlier permissions discussion now reaches the operating system.

An agent running as an ordinary restricted account should not automatically possess the powers of root or an administrator.

The operating system can enforce access rules regardless of whether the model “understands” those rules.

This is an important theme throughout HAAW:

Containers and Virtual Machines

Two common isolation approaches are containers and virtual machines, although their security properties and implementations differ.

Neither word automatically means “perfectly safe.” Configuration matters, vulnerabilities exist, and boundaries can be weakened by what is deliberately mounted, connected or permitted.

Network Sandboxing

A filesystem sandbox does little good if the agent has unrestricted network access and powerful remote credentials.

Network boundaries can restrict:

• which hosts can be contacted,
• which ports or protocols are available,
• whether the public Internet is reachable,
• whether internal production networks are reachable,
• which APIs may be called, and
• whether inbound connections are accepted.

This again separates capability from reachability. The model may know how to request something that the network architecture simply will not allow.

Credentials Are Capabilities

A password, API token, certificate or cloud role can turn a harmless-looking tool into a powerful one.

Therefore a sandbox should not casually contain credentials that exceed the mission's needs.

A read-only diagnostic mission may need credentials that can inspect service state. It probably does not need credentials that can delete infrastructure, change billing, create users or alter security policy.

Tool Boundaries

Another containment strategy is not to provide a general-purpose command interface at all.

Compare:

A capability array made of narrow tools can make the permitted action surface easier to reason about and audit.

Read, Write, Execute — Then Ask What Changed

Our refined HAAW model fits naturally here:

The sandbox helps determine what R/W/X operations are even possible against the surrounding environment.

And our earlier correction remains important: Change is not simply another permission bit. It is a question about consequence.

Resource Sandboxing

Files and networks are not the only things an agent can consume.

A controlled environment can also limit:

• CPU time,
• GPU time,
• RAM,
• VRAM,
• disk space,
• number of processes,
• execution time,
• API calls,
• tokens or model usage, and
• financial spending.

Time Is Also a Boundary

The persistence page added time to our autonomy envelope. A sandbox can do the same.

An execution environment might exist only for one task:

This is sometimes called an ephemeral environment: it is deliberately temporary.

Destroying the environment does not erase external effects that were already permitted—such as a message already sent or a database already changed. That is why isolation and external permissions must be considered together.

Input and Output Crossings Matter

A sandbox needs doors. Otherwise useful work cannot enter or leave.

Those doors are themselves security boundaries:

A sandbox with an unrestricted escape hatch is not much of a sandbox.

Human Approval Can Guard a Boundary Crossing

Suppose an agent develops and tests a configuration change entirely inside an isolated environment.

The transition to production can be a separate controlled event:

This combines sandboxing with the authority and escalation mechanisms from the previous HAAW pages.

Sandbox Escape

No serious discussion of sandboxes should imply that isolation is mathematically perfect.

Software can contain vulnerabilities. A flaw in an operating system, container runtime, hypervisor, browser, tool, driver or surrounding service may allow an unexpected crossing of an intended boundary.

That is why containment is usually stronger when it uses layers rather than trusting one mechanism.

Defense in Depth

This layered strategy is commonly called defense in depth.

If one control fails, another may still limit the consequence.

The point is not that every system needs every layer. The point is that safety does not have to rest on a single instruction or a single model decision.

Containment Versus Correctness

A sandbox does not make the model correct.

Inside a perfectly functioning sandbox, an agent can still:

• misunderstand the task,
• write broken code,
• hallucinate a fact,
• choose the wrong tool,
• misread evidence, or
• produce a useless result.

The sandbox addresses a different question:

Testing the Boundary

A safety boundary should itself be tested.

Useful tests might ask whether the agent can:

• read a forbidden file,
• write outside its workspace,
• reach a blocked network destination,
• invoke an unapproved tool,
• use expired or missing credentials,
• exceed CPU, memory or time limits,
• cross an approval gate without approval, or
• continue after its mission has been revoked.

A denied attempt is itself useful evidence that the boundary was exercised.

Long-Running Agents Make Boundaries More Important

A short-lived agent may make ten decisions. A persistent agent may make thousands of decisions across days or weeks.

Even if the probability of an error at any one step is small, more steps create more opportunities for unexpected behavior, stale assumptions, changed environments and failed tools.

That makes persistent controls valuable:

The WITNESS View

For WITNESS, a statement such as “the agent was sandboxed” is not enough.

The evidence should make the actual boundary reconstructable:

• which execution environment was used,
• which OS identity ran the process,
• which filesystems or directories were exposed,
• which resources were read-only or writable,
• which tools were available,
• which network destinations were reachable,
• which credentials and roles were active,
• which CPU/GPU/memory/time limits applied,
• which approval gates existed,
• whether any boundary crossing was requested,
• whether that request was allowed or denied,
• what external state actually changed, and
• how the resulting state was verified.

The Boundary

We can now add another layer to the HAAW system:

The model can still be capable. The agent can still be autonomous. The mission can still persist.

But the surrounding computer system can deliberately make the reachable world smaller than the entire world available to the host organization.