Agents Need Sandboxes, Not Just Warnings
2026-06-05 · 4 min read · Janaina Maia
The agent conversation has spent too much time asking what AI can do, and not enough time asking where it is allowed to do it.
VentureBeat reported that Microsoft has introduced MXC, an operating-system-level sandbox for AI agents. The idea is simple in plain English: before an agent runs on a machine, the organisation can declare which files, folders, network resources, screen access, clipboard access, and tools it is allowed to touch. The operating system then enforces those limits, even if the agent tries to do something else.
I think this is a more important product signal than another demo of an agent completing a task. It moves the trust problem from promises to enforcement.
Warnings are not enough.
Most AI safety language still sounds like advice. The model should follow policy. The prompt should tell it not to leak data. The user should review the output. The agent should ask before doing something sensitive.
Those things matter, but they are soft controls. They depend on the agent behaving well, the user noticing risk, and the workflow having enough time for careful review. That is fragile when the agent can browse, edit files, execute code, call tools, or move across enterprise systems.
A sandbox is different. It says: this agent can work inside this box, and the box has walls. If the agent tries to delete a file it only has permission to read, the system should stop it. If the task does not require clipboard access, the agent should not see the clipboard. If the agent is acting in one workspace, it should not quietly spill into another.
Containment becomes a design surface.
Security teams will naturally see this as infrastructure. Design leaders should see it as experience design too.
When a user delegates work to an agent, the interface should make the boundary understandable. Not with dense policy language, but with plain cues: this agent can read these project files, write only to this folder, use these approved tools, and cannot access your desktop, clipboard, browser, or other applications. That boundary changes how safe delegation feels.
The important shift is that permission is no longer a buried admin setting. It is part of the moment of trust. Before I ask an agent to investigate a problem, prepare a report, refactor code, or collect evidence, I should understand the box it is operating inside.
Identity matters as much as the box.
Microsoft’s approach also points to agent identity. Each agent can be bound to a local or cloud-backed identity so its actions can be attributed and audited. That matters because enterprise accountability breaks when automation becomes anonymous.
If an agent changed a file, opened a system, called an API, or triggered a workflow, the organisation should know which agent did it, under whose authority, using which policy, and with what evidence. “The AI did it” is not an audit trail. It is a shrug in expensive clothing.
Design implications.
- Show the sandbox: explain what the agent can read, write, call, view, and never touch.
- Match autonomy to risk: lightweight tasks can use lighter containment; risky tasks need stronger isolation and review.
- Make policies human-readable: users and managers should understand the practical boundary, not only the technical rule.
- Audit the actor: record the agent identity, user instruction, approved scope, actions taken, and final outcome.
- Design stop controls: people need fast ways to pause, narrow, or revoke the agent’s operating box.
My take.
Enterprise AI will not become trustworthy because agents sound more confident or because vendors add more reassuring labels. Trust will come from bounded autonomy: clear identity, constrained access, visible scope, enforced policies, and review where the work becomes consequential.
The most mature agent products will not ask users to trust the agent’s intentions. They will show the environment that limits the agent’s impact.
Before agents earn more freedom, they need better boxes.