Why build house arrest when you can build a prison?

Imagine hiring an extraordinarily capable worker, giving them a master key, and then explaining—very carefully—which doors they must never open.
You write rules. You add approval dialogs. You inspect every request. You build a supervisor that watches the worker and interrupts suspicious behaviour. The system becomes more sophisticated, but the underlying fact never changes: the worker still has the master key.
This is how much of the AI agent security conversation feels today.
We are building better harnesses around increasingly capable agents. The harness decides which tools exist, validates arguments, asks for confirmation, filters output and tries to detect abuse. These controls matter. But when the agent, its tools and the sensitive system all live inside the same trust boundary, the protection starts to resemble house arrest.
The doors are unlocked. The resident has been told not to leave.
GlobalStacks starts from a harsher premise: if a workload may become hostile, confused or simply wrong, do not make good behaviour the security boundary. Put the workload somewhere its authority is structurally limited.
Do not merely tell the agent where it may go.
Build the walls.

The attractive idea of a safe harness

An agent harness is the layer that turns a model into an actor. It supplies prompts, tools, memory, credentials, retries, approvals and the loop that decides what happens next.
Because the harness sits between model intent and system action, it is a natural place to add protection:

• expose only named tools;
• validate tool arguments;
• require a human to approve dangerous actions;
• redact secrets from context;
• deny suspicious commands;
• limit the number or cost of operations;
• record an audit trail.

This is sensible engineering. A well-designed harness can prevent accidents, make intent legible and reduce the amount of authority an agent receives.
But it is easy to confuse a useful control plane with a hard security boundary.
A harness often evaluates danger using the same information environment that the agent can influence. It may pass model-generated strings into tools. Its tools may hold broad credentials. A “read-only” operation may reach an API with write access. A validator may understand the command but not the consequence. A human approval dialog may show a friendly summary while hiding a destructive detail inside a long argument.
The failure does not require an evil model. Prompt injection, ambiguous instructions, compromised dependencies, faulty tool code and ordinary software bugs are enough.
The agent was not necessarily trying to escape. The system simply gave it more world than the task required.

House arrest is a policy; prison is an architecture

The house-arrest metaphor is intentionally uncomfortable.
House arrest works because the subject is expected to understand the rule, because monitoring is assumed to detect violations, and because consequences exist after the boundary is crossed. It is governance imposed on top of an environment that remains physically open.
A prison changes the topology. Movement is constrained before anyone interprets intent.
In infrastructure terms, the distinction is between a policy enforced inside the agent loop and an authority boundary enforced below it.
An in-harness rule says:

The agent should not connect to the production database.

A fundamental boundary says:

This workload has no route to the production network and possesses no production credential.

An in-harness rule says:

The agent may read this repository but must not alter it.

A fundamental boundary says:

The repository is mounted read-only, and the workload identity cannot push.

An in-harness rule says:

Do not consume excessive resources.

A fundamental boundary says:

CPU, memory, process count, storage and execution time have enforced ceilings.

One asks software to make the right decision. The other makes an entire class of wrong decisions unavailable.
That is the security property we should care about: not how convincingly the agent promises to behave, but how small the blast radius remains when every higher-level assumption fails.

Why the harness cannot be the final boundary

The strongest argument for harness-level prevention is practical: the harness knows the task.
It can distinguish a legitimate deployment from a suspicious one. It can ask the user. It can understand that deleting a test namespace is different from deleting production. A low-level sandbox sees only system calls, files, packets and resource use. It lacks business context.
That argument is correct.
The mistake is concluding that semantic understanding should therefore carry absolute authority.
Meaning and enforcement belong at different layers. The harness should decide what the agent is trying to do. The infrastructure boundary should decide what the workload is physically capable of doing. The first provides useful judgment. The second limits the cost when that judgment is wrong.
This is the same reason mature systems do not rely on application code alone to protect every database row, network path and secret. We still use identities, permissions, network segmentation, process isolation and separate environments. Each layer assumes the layer above it will eventually make a mistake.
Agents do not invalidate that architecture. They make it more urgent.
The more general an agent becomes, the less reasonable it is to treat its instruction-following loop as the final guardian of the host.

The GlobalStacks premise

GlobalStacks begins with sandboxing because a platform that can run arbitrary workloads must assume that some workloads will be unsafe, badly configured or compromised.
That assumption changes the product.
The workload is not granted the ambient authority of the machine that happens to run it. Its placement, identity, storage, network access and resource limits belong to an explicit operating model. A local machine, a remote server and cloud capacity can participate without turning each workload into an administrator of the underlying host.
The goal is not to claim that isolation makes agents safe. Nothing useful is made perfectly safe by changing one layer.
The goal is narrower and more honest: make failure containable.
If an agent is tricked by hostile content, its available network should still be narrow. If a tool constructs the wrong path, the surrounding filesystem boundary should still matter. If a dependency is compromised, the workload should not inherit every secret on the host. If a runaway loop consumes resources, other workloads and the control plane should retain enough capacity to recover.
This is why sandboxing is not plumbing added after the agent product is finished. It is part of the product’s meaning.
An agent can be highly capable inside a small cell.

A useful model: intent, capability and containment

Agent security becomes clearer when split into three separate questions.

1. Intent: what is the agent being asked to do?

This belongs primarily in the harness.
The harness interprets the task, chooses tools, requests approval, checks arguments and keeps an audit trail. It should make consequential actions visible and resist untrusted instructions.

2. Capability: what authority does this task actually require?

This belongs in identities and explicit grants.
A code-review task may need a read-only repository view but no package-publishing credential. A migration task may need access to one database and one schema for a limited period, not a permanent administrative secret. A web-research task needs outbound access to selected destinations but no path to the private network.
Capability should be issued for the task, not inherited from the operator or host.

3. Containment: what happens when intent and capability controls fail?

This belongs in the execution substrate.
The workload needs an enforceable boundary around processes, filesystems, devices, networks and resources. The boundary should survive a malformed tool call, a compromised dependency and an agent that persistently attempts the wrong action.
These layers reinforce each other, but they are not substitutes.
A sandbox with broad credentials is still dangerous. A perfectly scoped credential can still be exfiltrated if network egress is unlimited. A careful harness still fails dangerously if its tools execute with host-level authority.
Security comes from the composition.

What the “prison” must actually contain

The metaphor is only useful if it turns into architecture.
For an agent workload, ask whether the following are bounded independently of the model’s cooperation:

• Identity: Does the task receive its own identity rather than borrowing a user’s or host’s credentials?
• Secrets: Are only task-required secrets present, with scope and lifetime limited?
• Filesystem: Are sensitive paths absent or mounted read-only? Is scratch state disposable?
• Network: Is ingress deliberate and egress narrow? Can the workload reach the control plane, management network or neighbouring workloads?
• Processes and devices: Can it inspect host processes, access privileged sockets or control devices it does not need?
• Resources: Are CPU, memory, storage, process count and runtime limited?
• Persistence: What survives after the task ends, and can a compromised task plant something for the next one?
• Observability: Can operators reconstruct what happened outside the workload’s ability to rewrite the evidence?
• Recovery: Can the platform terminate, replace and restore the workload without depending on the workload’s cooperation?

If the answer to these questions is “the system prompt says not to,” there is no boundary. There is an agreement.

Is stronger isolation worth its operational cost?

Fundamental isolation is expensive.
Stronger boundaries add startup time, operational complexity, image management, network policy, storage design and difficult debugging. A sandbox can also create false confidence. Kernel bugs exist. Hypervisors have vulnerabilities. Misconfigured credentials and permissive egress can punch holes through an otherwise impressive wall.
And some actions cannot be meaningfully isolated. If the task is to modify production, then some production authority must exist somewhere.
The answer is not to pretend every agent needs the strongest possible prison. It is to match isolation to consequence and make escalation explicit.
Most tasks can begin with little authority. A workload can analyze a copy, propose a patch, produce a plan or run against a disposable environment. A separate step can review and promote the result. When live authority is necessary, grant the narrowest capability for the shortest useful time, preserve an independent audit trail and assume the action may still be wrong.
GlobalStacks should make that gradient operable: lightweight containment for low-risk work, stronger isolation for hostile or high-consequence workloads, and explicit placement where stronger guarantees are required.
The important thing is that convenience does not silently collapse the boundary.

How to evaluate an agent platform

Do not begin by asking whether the platform has a safety prompt or an approval button.
Ask what remains true after the prompt is ignored, the approval is mistaken and the tool contains a bug.
A practical evaluation can start with five questions:

1. What can this workload reach without asking anyone?
2. Which credentials exist inside it, and what can each credential do?
3. Which controls are enforced outside the agent and its tool process?
4. How is authority expanded for one task and revoked afterward?
5. What is the maximum credible damage if the workload is fully compromised?

The fifth question is the real one.
A platform can advertise sophisticated prevention while leaving the blast radius equal to the entire host or account. Another platform may assume prevention will fail and design the default blast radius around one task.
The second system is not more pessimistic about AI. It is more realistic about software.

Defence in depth, not a choice of slogans

“House arrest or prison” sounds like a binary choice, but good systems need both.
The prison needs rules, cameras, operators and controlled doors. A sandbox without harness-level policy will still perform allowed but foolish actions. It may delete the data it legitimately owns, spend its entire permitted budget or publish something the user never intended.
Likewise, a perfect supervisor cannot compensate for an environment with no walls.
The proper hierarchy is:

1. use the harness to understand intent and keep the human informed;
2. translate the task into narrowly scoped capabilities;
3. execute inside a containment boundary that assumes the first two layers can fail;
4. observe from outside that boundary;
5. promote effects into more trusted environments through explicit gates.

This is not an argument against agent harnesses. It is an argument against asking them to carry a security guarantee they cannot provide alone.

Build for the day the agent is wrong

The industry is spending enormous effort teaching agents to behave inside powerful environments.
That work is necessary. It is also incomplete.
At some point, an agent will misunderstand. A model will follow a hostile instruction. A validator will miss an edge case. A tool will do more than its name suggests. A human will approve the wrong summary. The question is not whether one of these events can be prevented forever.
The question is what the architecture permits next.
House arrest tries to stop the subject from crossing an invisible line.
A prison assumes the subject may test every line and makes the boundary part of the physical world.
For agent infrastructure, the mature position is not “trust the model” or “fear the model.” It is simpler:
Give the agent enough freedom to do the work, but do not confuse freedom inside the workload with authority over the system.
Build the harness.
Then build the walls beneath it.

← All writing