Every Cowork rollout in an Australian business of any size stalls at the same point. Someone from risk asks where the data goes, and vague answers cost weeks. Anthropic's architecture documentation now answers most of that questionnaire directly, and a handful of facts do the heavy lifting.
Where the work runs
Cloud sessions are the default. The agent loop and code execution run in an isolated temporary sandbox on Anthropic managed infrastructure. Each session gets its own sandbox, created when the session starts and destroyed when it ends. Sandboxes do not share state with each other or across organisations.
Local sessions on desktop are a different arrangement. The agent loop runs natively on the device, and code execution happens in an isolated virtual machine using the platform hypervisor: Apple Virtualization.framework on macOS, Hyper-V on Windows.
That distinction is the first thing to put in front of a security reviewer, because it changes the answer to almost every follow up question. A reviewer who has been told there is one architecture will keep finding contradictions in the documentation.
The four facts that close most objections
No access to your network by default. The sandbox cannot reach private, internal, link local or cloud metadata addresses.
Egress is enforced outside the sandbox. All traffic passes through a mandatory proxy the sandbox cannot reconfigure or bypass, and only allow listed destinations are reachable.
Short lived credentials only. The sandbox holds session scoped tokens that expire within hours.
Connector authorisation tokens never enter the sandbox. Connector calls are made server side.
That last one matters more than it first sounds. The common fear, and it is a reasonable one, is that an agent holding a Xero or Google Workspace token could have that token extracted by something hostile it reads during a task. The token is not there to extract. The enforcement point is also worth naming precisely: egress is enforced outside the sandbox, so it is not a setting the running code can talk itself out of.
Local file access, and how permission is checked
A cloud session reaching files on a staff member's machine goes through the Claude desktop app over an Anthropic brokered connection, limited to folders that member has connected. Every local tool call is checked against their permissions before it runs, rather than once at the start of the session.
On the data layer, every stored record is scoped to your organisation and account. Conversation data carries the same commercial commitments as other Team and Enterprise data and is not used to train Claude.
The admin controls to name in your submission
Both device and organisation level controls exist, and naming them turns a policy argument into a configuration exercise.
Device level through MDM: isLocalDevMcpEnabled disables plugin and locally configured MCP servers, isDesktopExtensionEnabled blocks MCPB and DXT extension servers.
Organisation level: disable cloud sessions while keeping local desktop Cowork, set the network access policy for cloud sessions, require persistent always allow approval or per call prompts, and mandate trusted device enrolment with a recent sign in.
An Australian firm that can point at those settings in its submission usually clears review in one round instead of three. When a $50,000 pilot is waiting on a security sign off, a round of review is real money and a quarter of momentum.
The gap reviewers will find, so name it first
Two things are not covered by the sandbox story, and a good reviewer will find them. Network egress permissions do not apply to the web fetch and web search tools, or to MCP servers including Claude in Chrome. And computer use has no sandbox between Claude and the screen at all.
Raising those yourself is the stronger play. It signals you read past the marketing, and it moves the conversation to controls you can actually offer: which sites are in scope, which applications are blocklisted, and which task types require manual approval.
What a reviewer is really asking
Behind the questionnaire sits one question: if this goes wrong, what is the blast radius. The architecture answers it well. A session that cannot reach your internal network, cannot bypass the egress proxy, holds credentials that expire within hours, and never sees a connector token has a small radius by construction.
The residual risk is not the sandbox. It is what a member connects to it and what they let it do unattended. That is a policy question you own, and saying so plainly earns more credibility than claiming the vendor has removed all risk.
Write it once
Put the architecture answer in a document, keep it beside your IT policy, and reuse it for the next tool. The structure is portable even when the vendor is not: where does execution happen, what can it reach, what credentials does it hold, and who can change those settings.
We build this document as part of a Cowork setup, because it is the artefact that unblocks everything downstream. Details at /contact.
