Paulo Victor Leite Lima Gomes

Posted on Jun 23

agent sandboxes are the new enterprise desktop

#ai #agents #sandboxes #security

GitHub put a 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.

The human knew, roughly, which commands were dangerous. The human noticed when a script looked strange. 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, 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.

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 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.

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.

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 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 or write? Can they access the network? Can they reach internal hosts? Can they see environment variables? Can they invoke Docker? Can they install packages?

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: which identities are present, where secrets live, what networks are reachable, what files persist, what activity is logged, and how access gets revoked.

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, and real work will continue outside the official path.

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.

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.

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 make controlled execution the default place where agent work happens.

If an agent opens a pull request, the review should not only show the diff and tests. It should show where the work ran: sandbox type, base image, identity, network policy, writeable paths, mounted secrets, commands, external endpoints, cost, and runtime. The code may look fine while the environment that produced it was much too powerful.

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.

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