What actually decides how much protection it gives?

What was put in the room, and especially which credentials came with it. A bounded space containing a broadly scoped key reaches whatever that key reaches, so the boundary is nominal. The useful audit is of contents and authorisations rather than of the walls, which are usually the part people look at.

Is running locally more contained than a vendor's cloud space?

It contains something different rather than more. Local work never leaves, which settles the data question, and it sits next to everything else on that machine. A vendor's isolated environment has no access to your estate at all unless you granted it. Which is safer depends on what you were worried about.

Does it remove the need to watch what happens?

No, and the reason is that containment says nothing about duration or cost. Something bounded can still run a long time achieving nothing, spending as it goes. The room answers where the consequences land; caps and a stop control answer how much of it there is.

Glossary

Sandboxing

Sandboxing confines what a running process may reach and change, so a mistake or a hijacked instruction is limited to a space you drew rather than loose in your systems.

In plain terms

Giving something a room to work in and locking the rest of the building. Whatever happens inside is bounded: it can only see what you put there, and only touch what you connected. The point is not that mistakes stop happening. It is that a mistake stays inside the room.

Why it matters

Because the thing you are containing is not only error. Material read from a web page or a document can carry instructions, and anything acting on that material may follow them. Containment is the control that does not depend on noticing, which makes it the one that still works on the day something behaves in a way nobody predicted.

How it works

It bounds reach rather than intent, which is the distinction that makes it useful. Nothing about it decides whether an action is sensible. It decides what is available to act on: which files, which systems, which network, which credentials. Those two questions are answered by different mechanisms and are constantly conflated in product descriptions.

The isolated environment is now a common product shape. Several platforms run work in their own cloud space rather than on your machine or inside your estate, which contains the blast radius by construction and also means the thing has no access to anything you did not deliberately hand it. That is a stronger default than most locally run alternatives.

Credentials are usually the weakest wall, and the one least often examined. A tightly bounded space with a broadly scoped key in it is not bounded, because the key reaches whatever the key reaches. The useful question is not what the environment can see but what the things inside it are authorised to do elsewhere.

Running locally trades one containment for another rather than removing the question. Work that stays on your own machine never leaves, which answers the data question decisively, and it puts the process next to everything else on that machine. Neither shape is safer in general; they contain different things, and knowing which one you have is the point.

It pairs with limits rather than replacing them. A bounded space with no ceiling on spend, no cap on turns and no stop control can still run for a long time doing something useless inside its room. Containment answers where; limits answer how much and how long, and unattended work needs both.

Two settings people describe with one word

The reason these get conflated is that both are answered by the same shrug in most product conversations, which is that the thing is restricted. Pressed for detail, what emerges is nearly always one column. A team that has thought hard about approvals often has an environment carrying credentials to the whole estate, on the reasoning that nothing will be attempted without a person agreeing. A team that has built a beautifully bare environment often runs it wide open inside, on the reasoning that there is nothing in there to damage. Both are coherent positions and neither is complete, and the gap only becomes visible when something behaves unexpectedly, which is precisely the case both were supposed to cover. The useful habit is to answer them separately and out loud, because a single word covering both is what allows one of them to go unset.

Seen in the wild

A general-purpose tool that plans and executes in its own cloud space rather than on your machine, so what it touches is what was handed to it.
Manus
Delegated tasks worked in an isolated cloud environment, several in parallel, returning finished work rather than acting in place.
OpenAI Codex
Self-hosting an automation platform on your own infrastructure, where data residency and control follow from where it runs.
n8n

Common misconceptions

People assume

It is the same as restricting what the thing is allowed to do.

In fact

Those are two settings and they fail differently. Permission decides which actions are attempted; containment decides what is within reach when one is. A tightly permissioned process with access to everything, and a broadly permissioned one in a bare room, are both half-protected, and each is regularly described as safe.

People assume

It protects against a hijacked instruction.

In fact

It limits the damage rather than preventing the following of it. Text read from a page or a document can carry an instruction, and containment does not make that instruction less persuasive. What it does is ensure that acting on it reaches only what was in the room, which is why the contents of the room are the actual decision.

Telling them apart

Sandboxing vs Autonomy level

Sandboxing

What is within reach when something acts.

Autonomy level

How much may be done before anybody is asked.

Containment and permission are independent. High autonomy inside a bare room is a different proposition from low autonomy with the keys to everything.

Questions

What actually decides how much protection it gives?: What was put in the room, and especially which credentials came with it. A bounded space containing a broadly scoped key reaches whatever that key reaches, so the boundary is nominal. The useful audit is of contents and authorisations rather than of the walls, which are usually the part people look at.
Is running locally more contained than a vendor's cloud space?: It contains something different rather than more. Local work never leaves, which settles the data question, and it sits next to everything else on that machine. A vendor's isolated environment has no access to your estate at all unless you granted it. Which is safer depends on what you were worried about.
Does it remove the need to watch what happens?: No, and the reason is that containment says nothing about duration or cost. Something bounded can still run a long time achieving nothing, spending as it goes. The room answers where the consequences land; caps and a stop control answer how much of it there is.

Key takeaways

It bounds reach, not intent; permission is a separate setting entirely.
The isolated cloud environment has become a common product shape.
Credentials are usually the weakest wall and the least examined.
Local and hosted contain different things; neither is safer in general.
It answers where, never how much or how long. Unattended work needs both.

Tools that use this

Manus
Plans and executes in its own cloud space rather than on your machine.
OpenAI Codex
Delegated tasks worked in an isolated cloud environment, in parallel.
n8n
Self-hosted on your own infrastructure, so residency follows where it runs.