Someone in your organisation is going to ask this before anyone gets a seat, and they’re right to. The usual answers are useless in both directions — the sceptic says “it’s sending our code to a US company,” the enthusiast says “it’s fine, it’s enterprise-grade,” and neither has read the policy.
Here’s what’s actually true, in the order it matters.
The one thing most people get backwards
Consumer plans and commercial plans have different data policies, and the difference is not the one people assume.
| Plan | Training on your data |
|---|---|
| Commercial terms — Team, Enterprise, the API, third-party platforms like Bedrock, and Claude Gov | Anthropic does not train generative models on the code or prompts you send to Claude Code. The only exception is if your organisation explicitly opts in to something like the Development Partner Program, which an admin has to do deliberately. |
| Consumer plans — Free, Pro, and Max | you’re given the choice. When the data-sharing setting is on, Anthropic will train new models using data from those accounts — including data from Claude Code sessions run on them. |
Sit with the implication for a second. A developer or analyst on a personal Pro subscription, doing company work, with the default setting untouched, is in a different position from the same person on a Team seat. That’s not a scandal — it’s clearly documented, and you can change the setting at any time in your privacy controls at claude.ai/settings/data-privacy-controls. But it’s the single most common misunderstanding, and it’s the one your security team will care about most.
The practical rule: if it’s company work, it should be on a company seat. That one sentence resolves most of the anxiety in this whole area.
How long anything is kept
Retention follows the same split:
| Situation | Retention |
|---|---|
| Commercial (Team, Enterprise, API) | 30 days, standard |
| Consumer, data-sharing off | 30 days |
| Consumer, data-sharing on | 5 years |
Transcripts you send via /feedback, /bug, /share | 5 years |
| Session transcript you opt to share after a quality survey | Up to 6 months |
| Zero Data Retention (qualified Enterprise) | No server-side persistence |
Two things worth flagging that people miss.
Zero Data Retention is not automatic on Enterprise. It’s available to qualified accounts and enabled per-organisation by your account team after confirming eligibility — it is not part of the standard Enterprise plan. If ZDR is a hard requirement in your sector, raise it during procurement rather than assuming.
There’s a copy on your own machine. Claude Code stores session transcripts locally, in plaintext, under ~/.claude/projects/, for 30 days by default so you can resume sessions. That’s a local file on a laptop, which means it inherits whatever disk encryption and device policy you already have — and it’s adjustable via the cleanupPeriodDays setting. For most organisations this is a non-issue; for a few, it’s the detail that matters most.
What actually leaves your machine
Claude Code runs locally. To do anything useful it has to send your prompts and the relevant file content to the model over the network — encrypted in transit with TLS 1.2 or better. That’s the substance of the data flow, and there’s no version of this product where it doesn’t happen.
At rest, encryption depends on your provider: AES-256 infrastructure-level disk encryption on the Anthropic API, AES-256 with AWS-managed keys on Bedrock (customer-managed keys available through KMS), Google-managed keys with CMEK available on Google Cloud’s Agent Platform.
Alongside that there are two smaller streams, both controllable:
- Usage metrics — latency, reliability, usage patterns. These never include your code, prompts, or file paths. Turn them off with
DISABLE_TELEMETRY=1. - Error reports — Claude Code’s own crash traces, with known secret patterns, file paths, and personal information redacted before anything leaves the machine. Turn them off with
DISABLE_ERROR_REPORTING=1. These are only on at all for Pro and Max sign-ins connecting directly to the Claude API, and never for organisations with zero-data-retention or HIPAA agreements.
Set CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC and you turn off the lot in one go. On Bedrock, Google Cloud’s Agent Platform, and Microsoft Foundry, error reporting, telemetry, and bug reporting are off by default already.
One exception worth knowing because it surprises network teams: before fetching a URL, the WebFetch tool sends the hostname only — not the path, not the page contents — to api.anthropic.com to check it against a safety blocklist, cached per hostname for five minutes. This runs regardless of provider. If your network blocks that domain, web fetches fail until you allowlist it or disable the check.
The part you control: what Claude can touch
Policy is only half of safety. The other half is scope, and this is where you have the most direct control.
Claude sees the folder you open, and nothing else. Cowork formalises this as a folder-permission model — you grant read, write, and create access to specific directories, and files outside them aren’t visible. This isn’t a promise about good behaviour; it’s the mechanism. The practical consequence is that “how do we limit exposure?” has a very simple answer: point it at less.
It asks before consequential actions. On Desktop, the “Ask permissions” mode — the one the docs recommend for new users — pauses before anything that matters and waits for your click. Changes appear as visual diffs you accept or reject. Auto mode replaces the prompting with a classifier that lets safe actions through and blocks risky ones, and it hard-blocks certain categories outright, including destructive git commands when you didn’t ask to discard work.
Permission rules are explicit. Organisations can write allow and deny rules — down to matching specific tool parameters — and hard deny rules that block an action unconditionally regardless of any allow exception.
The honest summary: an agent with file access is exactly as safe as its scope and its approval gates. Both are configurable, both are visible, and the default posture asks rather than assumes.
What your IT and security team will actually ask for
For an Enterprise deployment, the checklist tends to be the same everywhere:
- Single sign-on — SAML 2.0 and OIDC are supported, so authentication centralises with everything else.
- Audit logging — authentication events, model calls with metadata, and file interactions. Retained 30 days by default in the admin console, exportable as JSON or CSV, or pushed directly to SIEM platforms like Splunk, Datadog, or Elastic.
- A Compliance API — programmatic endpoints to list, retrieve, and delete organisational data.
- Admin controls — org-wide toggles for capabilities like artifacts and connectors, role-based scoping on Enterprise, retention policies, and control over whether anything can be shared publicly.
- Regulated-sector options — customer-managed encryption keys, HIPAA agreements, and Zero Data Retention, each arranged with your account team.
If you’re running through cloud execution rather than local — Claude Code on the web — your repository is cloned into an isolated VM, GitHub authentication is handled through a secure proxy so your credentials never enter the sandbox, and all outbound traffic passes through a security proxy for audit logging.
The risk nobody’s policy covers: prompt injection
This one deserves its own section because it’s the genuinely new risk, and it isn’t solved by any setting.
An AI that reads a document is influenced by what’s in that document. A spreadsheet, a web page, or a file from outside your organisation can contain text crafted to manipulate the model — to make it reveal information from elsewhere in its context, or take an action you didn’t intend. Anthropic flags this explicitly for Claude for Excel: don’t apply it to spreadsheets from untrusted external sources.
The mitigations are unglamorous and effective:
- Treat files from outside your organisation as untrusted input, the same way you’d treat an email attachment.
- Keep the approval gate on for anything that reaches outward — sending, publishing, posting.
- Don’t give a session broad access and untrusted content at the same time. Scope is the defence.
That argues for keeping a human at the point where work leaves the building, not for avoiding the technology.
So — is it safe?
For company work on a company plan, with sensible scope and the approval gates on: yes, and the controls available are more granular than most organisations end up using.
The failure modes that actually bite are not exotic:
- Company work on a personal Pro account with data sharing on — the mistake this whole guide exists to prevent.
- Assuming ZDR is included on Enterprise when it has to be enabled per-organisation.
- Pointing it at everything because scoping felt like friction on day one.
- Trusting output that looks finished. No policy protects you from an unreviewed number in a board pack.
Fix those four and you’ve addressed more real risk than any amount of vendor-questionnaire theatre.
Rolling this out to a team? The team guide covers the sequencing, and the plans guide explains which plan puts you under the commercial terms described above.