Where does client data go when your firm connects Claude?

Most firms ask whether Claude is safe for client work. It is the wrong question, or at least the wrong one first. Where your client data goes depends entirely on which connection you use, and the same tool has very different answers depending on how it is wired. Three questions settle it.

Where does the work actually run. What can the agent reach. What can you see afterwards.

The assumption worth checking

The instinct in most firms is to treat this as a procurement decision. Pick a vendor, read the security page, tick the box, roll it out.

That works when you are buying software that sits still. It does not work here, because the thing you are approving is not a product so much as a set of connections, and the connections are what carry the risk. Two firms can both be "using Claude" and have completely different exposure, because one connected it to a read-only view of a reporting database and the other pointed it at a live matter management system.

Look, the honest position is that the platform side of this is better than most people assume. It is the boundary you draw that tends to be vague.

Question one: where does the work run

Worth knowing that this moved recently, and is still moving. Claude Cowork sessions now run remotely by default, which means the agent loop and the code execution happen on Anthropic's servers, with sessions and files saved to the member's account. Remote execution is in beta and rolling out plan by plan, starting with Max, so check what your own plan is actually doing rather than assuming. Local execution is still there for existing desktop deployments, where the agent loop runs natively on the device and code runs in an isolated virtual machine, using Apple's Virtualization framework on macOS or Hyper-V on Windows.

The remote architecture is genuinely considered. Each session gets its own temporary sandbox, destroyed when the session ends, with no shared state between sessions or between organisations, and the infrastructure is kept separate from Anthropic's corporate, research and model training environments. The sandbox cannot reach private, internal, link-local or cloud metadata addresses, so it cannot be used to pivot into your network. Egress is forced through a proxy the sandbox cannot reconfigure or bypass. Credentials inside are session-scoped and expire within hours, and connector authorisation tokens never enter the sandbox at all, because connector calls are made server side.

That is a real answer to "where does it run", and it is a better one than the sceptical version of this conversation usually assumes.

Question two: what can it reach

This is the one firms skip, and it is the one that matters most.

An agent connected to a system of record is only as constrained as the interface you hand it. Not the policy you write about the interface. The interface.

Take the two servers I built for the Himalayan Trust. One indexes fifty years of photography from Nepal so you can search the archive by describing what is in a picture rather than remembering the filename. The other sits over the Trust's KPI Hub and returns the quarterly board reporting numbers.

Both are read-only, and not as a setting. The image server can search, describe and reindex, and there is no code path in it that alters a photo. The board reporting server issues GET requests against two defined API routes and has no write path to the underlying data at all. If someone asked me to make either of them write, that would be a rebuild, not a permission change.

That distinction is the whole thing. Scope enforced by the shape of the software holds under pressure. Scope enforced by a configuration screen holds until someone changes the configuration. I have written before about running agents under limits the runtime enforces rather than limits you politely ask them to respect. Same principle, one layer down.

/ From the workshop · Non-profit · New Zealand / Nepal

Himalayan Trust: Two production MCP servers giving Claude read-only access to a five-decade photo archive and to quarterly board reporting.

Read the case study →

The smaller decisions follow the same logic. The photo archive stays on local hardware because there was never a reason to move it, and the index handles cloud-synced placeholder files by reading their metadata rather than pulling the originals down. The board report server fails loudly with a clear error when it has not been told where the KPI Hub lives, rather than guessing a default and quietly reading the wrong thing. Neither is clever. Both are the kind of decision that is cheap before launch and expensive afterwards.

Question three: what can you see afterwards

Here is the part that catches people, and it is worth reading Anthropic's own words rather than mine.

On whether Cowork activity appears in audit logs: "Not currently. Cowork activity isn't captured in audit logs, the Compliance API, or data exports." The documented route for monitoring it is OpenTelemetry instead.

On whether your endpoint security tooling can see inside the code execution environment: "No. The VM is isolated from host-based security tools by design, and remote sessions run entirely outside your endpoints, so EDR tools can't observe them either. If your compliance posture depends on endpoint visibility, account for this before rolling out Cowork."

Read that last sentence again. That is the vendor telling you to check your assumptions before you deploy, in writing, on a public help page. It is not a scandal and it is not hidden. It is just the sort of thing that does not come up in a procurement conversation, because nobody thinks to ask what the audit trail looks like until they need one.

There are controls, and they are device-level rather than organisation-level. Two MDM keys govern the Claude Desktop app: isLocalDevMcpEnabled turns off plugin-bundled and locally configured MCP servers, and isDesktopExtensionEnabled blocks extension servers from running. There is also an organisation-wide toggle that decides whether Cowork is available at all. Knowing that those exist, and who in your firm holds the MDM console, is a five-minute conversation that is much better had early.

Build the connection or rent it

Once you have answered those three questions honestly, the build-or-buy decision gets easier, because you are choosing between known scopes rather than vibes.

A vendor's own connector is fast to switch on and you inherit whatever they decided. Xero, for instance, publishes an official MCP server as open source under an MIT licence. It was created in March 2025 and was still being pushed to in June 2026. That is a real, maintained thing from a Wellington company, and for a lot of firms it is the right answer precisely because someone else maintains it.

The trade is that you get the vendor's scope, not yours, and vendor scopes vary more than you would expect. Some connectors are read-only. Some will write. Some handle one account at a time and some do not. Xero's own server exposes tools that create and update records, which is useful if that is what you want and worth knowing if it is not. Go and read the tool list before you connect it, because that list is the actual answer to "what can it reach", and it takes about ten minutes.

Building your own is the other end. It costs more up front and it is a genuine software project with the maintenance that implies. What you get back is the ability to say exactly what the thing can do, and to have that be true because of how it was built.

The failure mode is the middle, where a firm routes live client data through a general-purpose integration layer because it was the quickest path, and nobody writes down what that means. That is not a build and it is not a buy. It is a decision nobody made.

The part most firms skip

Decide what the agent is for before you connect it to anything. Then give it exactly that much reach, and make the boundary something you can point at in the code rather than describe in a policy.

That order matters. Connecting first and constraining afterwards is how firms end up unable to answer a straightforward question about their own systems.

None of this touches whether you are permitted to proceed. That is a question for your professional obligations and your own judgment, and in New Zealand the Law Society and the Office of the Privacy Commissioner publish the guidance that actually governs it. I am not the authority on that and would not pretend to be. What I can tell you is what the plumbing does, which is a different question and one a lot of firms have not asked yet.

If you are staring at a connection you already made and are not sure what it can reach, a short call is the fastest way to find out whether it is worth changing.