agent sandboxes are the new enterprise desktop

GitHub put a very normal-sounding feature into public preview this month: cloud and local sandboxes for Copilot.

Normal is doing a lot of work there.

The release says Copilot can now run inside secure, isolated sandboxes, either locally on the developer machine or in a GitHub-hosted cloud environment. Local mode restricts the filesystem, network, and system capabilities available to shell commands started by Copilot. Cloud mode gives the agent an ephemeral Linux environment, with enterprise policies attached.

That sounds like a product checkbox.

I think it is closer to a new category of enterprise desktop.

Not desktop as in "Windows with Outlook and a VPN client." Desktop as in the place where work happens, credentials appear, files are opened, tools are invoked, commands are run, and mistakes become expensive.

The agent is not a chatbot anymore.

It is a process.

And processes need places to run.

the dangerous part is execution

We still talk about AI systems as if the model is the interesting boundary.

Which model? How smart? How much context? How good at code? How many benchmarks? How cheap per million tokens?

Those questions matter. They are just not the whole system.

The risk changes when the model gets hands.

An agent that only writes text can be wrong in familiar ways. It can hallucinate an API, invent a policy, misunderstand a bug, or recommend a bad migration. Annoying, sometimes dangerous, but still mostly contained in the answer.

An agent that runs commands is different.

It can read files. It can mutate files. It can run tests. It can install packages. It can call internal tools. It can open network connections. It can touch credentials. It can generate artifacts. It can spend money. It can leave state behind.

At that point, "do we trust the model?" is the wrong first question.

The better first question is: "what can this process reach?"

That is why sandboxes matter. They move the conversation from vibes to boundaries.

your laptop was the default sandbox

For a lot of developer tooling, the laptop has been the lazy answer.

Install the CLI. Clone the repo. Authenticate with half the company. Put cloud credentials somewhere convenient. Add a token for the package registry. Add another token for GitHub. Open the editor. Let the assistant see the workspace. Let the terminal do what the terminal does.

This worked because the human was supposed to be the control loop.

The human knew, roughly, which commands were dangerous. The human noticed when a script looked strange. The human had muscle memory for "why is this asking for sudo?" The human understood that production credentials should not be sitting in a random shell session, at least on a good day.

Agents weaken that assumption.

They are very good at doing plausible-looking local work. They are also very good at trying things. They retry. They explore. They run commands to inspect the world. They follow tool output into the next step.

That is useful.

It is also exactly why the execution environment cannot be an afterthought.

If a coding agent inherits the developer laptop, it inherits a messy bundle of files, credentials, network access, local daemons, shell history, package manager caches, SSH config, and accidental permissions. Some of that is needed. Much of it is not.

The laptop was never a clean security boundary. It was just convenient.

cloud sandboxes change the ownership model

Cloud sandboxes are interesting because they shift agent execution away from the personal machine and toward a managed work environment.

That changes the ownership model.

On a laptop, platform teams can publish guidance, manage devices, push endpoint policies, and hope developers keep the local environment reasonably sane. In a cloud sandbox, the organization can define the base image, network policy, secrets path, filesystem lifecycle, logging, resource limits, and teardown behavior more directly.

That does not make it magically safe.

It makes it inspectable.

An ephemeral Linux sandbox can be created for a task, given only the repository and credentials required for that task, observed while it runs, and destroyed when it is done. The task can be tied to an issue, branch, pull request, cost center, and audit trail. The logs can show which commands ran, which tools were called, and which network paths were available.

That is a much better shape than "the agent ran somewhere on Alice's laptop and probably used the same token Alice uses for everything."

The important word is probably.

Security systems exist to reduce probably.

local still matters

I do not think cloud sandboxes make local sandboxes irrelevant.

Developers still need fast feedback. They still need to work in messy repos. They still need to try small things without paying the latency and ceremony tax of a remote environment. They still need agents that can inspect local state when local state is the problem.

So local sandboxing is not a toy feature. It is the bridge.

If Copilot can run shell commands locally with restricted access to the filesystem, network, and system capabilities, then a developer can let the agent do more work without handing it the whole machine.

That is the right instinct.

The mistake would be treating local sandboxing as a developer preference.

For enterprises, it needs to become policy. Which directories can agent commands read? Which can they write? Can they access the network? Can they reach internal hosts? Can they use SSH? Can they see environment variables? Can they invoke Docker? Can they install packages? Can they write outside the repository?

These questions sound dull until the agent runs the wrong command.

Then they become the entire incident.

this is bigger than coding

The same pattern is showing up around the rest of the agent stack.

AWS has been making the simple argument that agent location is a security decision. An agent is application code running in a compute environment. Put it where IAM, VPC boundaries, logs, and defense-in-depth controls already exist, and the control plane becomes more deterministic than whatever the model happens to "think."

Docker's MCP Gateway points in the same direction from the tooling side. Tools get packaged, exposed through a gateway, filtered into profiles, and run with supply-chain checks and scoped secret access. The agent does not just receive magical tools. It gets a controlled set of capabilities.

OpenAI is pushing Codex across roles and workflows with plugins, annotations, and shareable work. That is useful, but it also expands the number of places where agents need access to tools, documents, dashboards, code, and business context.

The pattern is not subtle.

Agents are becoming workstations for non-human collaborators.

That means the old endpoint management questions are coming back in a new costume:

what software is available?
which identities are present?
where are secrets stored?
what networks are reachable?
what files persist after the session?
who can approve elevated access?
what activity is logged?
how are costs attributed?
how do we revoke access quickly?

If that sounds like corporate IT, yes.

That is the point.

sandboxes need product taste

There is a bad version of this future where every agent task starts with twelve approvals and ends with a PDF nobody reads.

That will fail.

Developers will bypass it. Teams will keep running agents locally with broad permissions because the official path is too slow. Platform teams will declare victory because a sandbox exists somewhere, while real work continues outside it.

The sandbox has to be good enough to use.

That means fast startup, predictable base images, easy repository access, clear permission prompts, good logs, cheap teardown, and simple escalation when the task really does need a capability. It also means defaults that match common workflows. Running tests should be easy. Opening a pull request should be easy. Installing dependencies should be controlled, not impossible.

Security controls that ignore workflow become theater.

Agent sandboxes need product taste because they are not only security infrastructure. They are developer experience infrastructure.

If the safe path is painful, the unsafe path wins.

make the sandbox part of the review

One thing I would like to see become normal is attaching sandbox context to agent-authored work.

If an agent opens a pull request, the review should not only show the diff and tests. It should show where the work ran.

Not a giant log dump. A small, useful summary:

sandbox type: local or cloud
base image and important versions
identity used
network policy
writeable paths
tools available
secrets mounted
commands executed
external endpoints contacted
cost and runtime

That context changes the review.

A small dependency update produced in a locked-down cloud sandbox is a different risk profile from a large generated feature produced on a developer laptop with broad network access and personal credentials. The code may look similar. The provenance is not.

Reviewing agent work will increasingly mean reviewing the environment that produced it.

That is annoying.

It is also how engineering works when automation starts doing real work.

the punchline

Agent sandboxes are not a side feature for nervous security teams.

They are the execution layer for a new kind of worker.

The model can suggest. The agent can act. The sandbox decides what acting means.

That makes the sandbox one of the most important parts of the system. It defines filesystem reach, network reach, tool reach, credential reach, cost reach, and the durability of whatever happens during the task.

The companies that handle this well will not ask developers to choose between productivity and control. They will make controlled execution the default place where agent work happens.

Local when it needs to be local.

Cloud when it should be isolated, reproducible, and observable.

Always with boundaries clear enough that a reviewer can understand what the agent was allowed to do.

The old enterprise desktop was a managed machine for a human employee.

The new one might be an ephemeral sandbox for an agent.

Same boring questions.

Much faster hands.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

推荐订阅源

DEV Community