The pitch for the sandbox is appealing, which is why so many careful organisations reach for it. Stand up an isolated virtual machine, put Claude inside it, allow no sensitive data and no client information, and let people log in and experiment. Nothing the agent touches can reach your real systems. The blast radius is a disposable VM. You have given your workforce the tool and your security team a clean answer, all at once.

I want to be fair to the instinct before I take it apart, because it is not foolish. It is the right move for week one. It is a bad plan for month six, and the gap between those two is where I keep finding organisations stuck, having mistaken a scaffold for a building.

The box stops the leak you can see, not the one that happens

Start with the security story, because that is the part the sandbox is supposed to be best at, and it is the part that holds up worst.

The isolated VM controls network egress. It governs what the machine can reach. What it does not govern is the human sitting in front of it, who can read an answer on the screen and paste a confidential document into the prompt, or copy the output into an email. That paste is the dominant data-loss path in modern enterprises, and the control everyone assumes covers it does not. A Microsoft staffer says so plainly on Purview’s own Q&A: the DLP “Block” action for pasting into a browser “isn’t implemented for pasting”, and “lacks enforcement capability for browser paste operations.” Silent blocking of a paste is not a feature that exists. So the sandbox quietly fills with real, sensitive work, pasted in by people doing their jobs, and the box that was meant to contain the risk is now the place the risk lives, with no production controls around it.

Then there is the leak that makes the whole isolation premise look dated. The sandbox assumes AI inference produces network traffic you can intercept. That assumption is breaking. A project like WebLLM runs a full language model “directly within web browsers without server-side processing,” on the user’s own GPU through WebGPU, with the weights fetched once and cached. After that download, nothing leaves the device. An employee can paste a confidential memo into a capable model running in a browser tab with no packet crossing your perimeter. No egress to allowlist, no login to restrict, no VM to escape. The hard problem was never the model in a cloud you could block. It is the capable model that arrives as a web page and never phones home, and an isolation strategy built for the first one does nothing about the second.

Friction is a recruiter for shadow AI

Here is the part that turns the sandbox from merely insufficient into actively counterproductive.

People route around friction. When the sanctioned tool is slow, locked down, and stripped of the context that would make it useful, the work does not stop. It moves to the path of least resistance, which is the personal phone, the home laptop, the personal account your tools never see. You built the box to prevent shadow AI and the box is the reason for it.

The proof runs the other way too, and it is the most useful number I know on this topic. Netskope tracked a year of enterprise AI use and found that where organisations shipped a good sanctioned tool, personal-account GenAI use fell from 78% to 47% while company-approved use rose from 25% to 62%. Shadow AI shrank, not because anyone blocked harder, but because the official path got good enough to prefer. That is the whole lesson. You reduce the unsanctioned tool by making the sanctioned one better, not by making it more annoying. A friction-heavy sandbox does the precise opposite, and a CISO measuring success by “how locked down is the box” is optimising the number that drives the leak.

This is the spine that runs through everything I write about rollout: restriction is the risk. Over-isolate and you do not contain the work, you exile it to where you cannot see it. The same fight shows up in stopping shadow AI and in blocking the personal account, and it has the same answer every time. The control that holds is making the governed path the easy one.

The ephemeral box throws away the thing worth keeping

Set security aside for a moment, because even if the sandbox were airtight it would still be a dead end, and this is the argument I find lands hardest with the people who actually run these programmes.

The value in an enterprise AI tool is not that one analyst can ask it a question. That is table stakes, and they can get it from a consumer chatbot. The value that compounds is organisational: the instruction file that encodes how your firm actually works, the skills that capture a process once so everyone runs it the same way, the accumulated context that makes the tool a little sharper every month. That is the org-wide deployment where the real return lives, and all of it depends on persistence.

An ephemeral sandbox is persistence’s opposite by design. Every session starts from a clean image. Nothing accrues. There is no place for an org-wide instruction file to live and improve, no surface for a skill to be installed once and reused by everyone, no memory of what worked last week. You have built an environment whose defining feature, disposability, is exactly the property that prevents the compounding you are paying for. People get individual, throwaway value and the organisation gets nothing it can keep. You have capped your own ceiling and called it a security win.

The instinct is right, the permanence is the mistake

I am not arguing the isolation impulse is paranoid. It is not. Agentic tools really do exfiltrate, and not as a theoretical worry. PromptArmor showed a Claude Cowork prompt injection that used a curl command to upload a victim’s file to an attacker’s account, and “at no point in this process is human approval required.” A tool that can take actions on its own is a different risk class from a chat box, and wanting a blast-radius limit while you work out the controls is sound engineering.

The error is treating the limit as the destination instead of the scaffold. You isolate to buy time. You spend that time building the things that let you take the isolation down safely: managed identity so every session is a known corporate account, a gateway that inspects and logs the traffic, tool and server allowlists, an audit trail wired to your SIEM, the baseline settings that hold before anyone logs in. Those are the controls that govern the tool on a real endpoint doing real work. The sandbox buys you time. It does not buy you governance, and if you never use the time to build the governance, you have just paid for a holding pattern and parked in it.

Take the scaffold down

So treat the sandbox as what it is. A fine place to start, while no sensitive data is in play and you are still learning the tool’s failure modes. A scaffold you erect so you can pour the floor behind it. The mistake is leaving it standing, because a scaffold left up long enough stops being safety equipment and becomes the structure everyone mistook for the building, with none of the load-bearing controls a building needs.

The destination is the unglamorous one I keep coming back to: governed access to the real tool on managed devices, which is the whole of phase zero. Identity, connectivity, a tool allowlist, an audit log. Lay those and you can let people do real work with real data and still sleep, because the controls travel with the work instead of trying to wall it off from everything that makes it worth doing. The sandbox was never going to get you there. It was only ever meant to hold the gap while you built the thing that would.