Running Claude Code with data protection in mind: plans, DPA, Bedrock — and the step before

In short: no tool is GDPR compliant "by itself", and Claude Code is no exception. Only the controller can be compliant, meaning you or your company, with a concrete setup. That setup has three layers: the contract with Anthropic (consumer or commercial plan, DPA, retention period), the route you run it on (Anthropic API directly, AWS Bedrock or Google Vertex in an EU region), and the step most guides leave out: what happens to the prompt before it leaves your machine. Claude Code does not send only your question. It sends file contents, shell output and git diffs. If your repo holds customer data, keys or personal names, they go along. This post covers all three layers and ends with a checklist.

What data leaves with Claude Code

Claude Code is an agent in the terminal. That sets it apart from a chat window: you hand it a task, and the tool reads, executes and sends the results back to the model as context. In a typical session, this goes out:

Source	Example	When
Prompt and system instructions	your task, CLAUDE.md, project rules	every turn
File contents	anything Read opens: code, .env, fixtures, customer data exports	as soon as the model reads the file
Tool results	Bash output, git diff, env, logs, test output	every tool round
MCP results	database queries, tickets, mail from connected servers	when an MCP server is connected
Telemetry and error reports	usage statistics, crash reports	depends on configuration, can be switched off

The key point is the third row. Tool results are the richest source of unintended transfers: cat .env, a stack trace with a user's email address, an SQL dump in fixtures/. The model did not "ask" for this content. It is the normal working material of an agent.

Telemetry is the most harmless part and the only one you can switch off with an environment variable. The current switches are listed in the Claude Code documentation at docs.anthropic.com, in the section on data usage. Check the names there, as they have changed several times in recent versions.

What Anthropic offers by contract

It pays to separate things precisely here. Anthropic has two contract worlds, and Claude Code can run in either.

Consumer or commercial plan

• Consumer accounts (Claude Free, Pro, Max): you sign in to Claude Code with your personal account. The consumer terms apply. Since autumn 2025 there is a choice whether conversations may be used for training, with a much longer retention period if you agree. As far as we know, using Claude Code also falls under that choice. For company data this is the wrong contract regardless of the setting: you do not get a DPA on a personal account.
• Commercial plans (Team, Enterprise, API via the Console): the commercial terms apply. Anthropic commits there not to use inputs and outputs for training, and provides a Data Processing Addendum, which is the DPA in the sense of Art. 28 GDPR. According to the documentation, API data is retained for 30 days, and approved customers can get a zero-retention option ("Zero Data Retention").

The contract texts are at anthropic.com/legal. Which version applies to you, which contracting party (US company or European subsidiary) signs, and what retention period your plan actually has is stated there, not in a blog post. Check it at the date of signing and keep a copy of the version.

Data residency: Bedrock and Vertex

As far as we know, the Anthropic API itself is served from the US. If you need processing in the EU, you take one of the two cloud routes:

• AWS Bedrock offers Claude models in EU regions, including Frankfurt. Claude Code supports this route directly through the environment variable CLAUDE_CODE_USE_BEDROCK. Your contracting party is then AWS, with its DPA and region binding. Details: aws.amazon.com/bedrock.
• Google Vertex AI offers the same for Google Cloud regions in Europe, via CLAUDE_CODE_USE_VERTEX.

Two pitfalls. First, there is "cross-region inference", where a request can fail over to another region within a continent. For EU profiles, AWS states this stays within the EU, but you have to choose the profile deliberately. Second, not every model is available in every region at every point in time. A new model often appears in US regions first. If you commit to "EU only", you have to live with running an older model at times.

Bedrock answers the question "where is it processed". It does not answer the question "what is processed". A .env with production keys is just as sent in Frankfurt as in Virginia.

What else counts in Germany

For companies and freelancers with client work, four more things come into play that no provider can do for you.

Art. 28 GDPR, processing on behalf of a controller. As soon as personal data goes to Anthropic, AWS or Google, you need a DPA with exactly that service provider. The statute is at dsgvo-gesetz.de/art-28-dsgvo. The DPA is the minimum requirement, not proof of compliance.

Third-country transfer, Art. 44 ff. With the direct Anthropic API, data leaves the EU. The legal basis is then standard contractual clauses or a certification under the EU-US Data Privacy Framework. Check the current DPF list to see whether the actual contracting party is listed, and document it.

Record of processing activities, Art. 30. The use belongs in the record as its own entry: purpose (software development with AI assistance), data categories (source code, possibly customer data in test data and logs), recipients, retention period, deletion concept.

DPIA question, Art. 35. A data protection impact assessment is not mandatory by default. It becomes so when you regularly have special categories (health, finance) or large volumes of customer data in repositories that the agent reads. Here too, the content of the repos decides, not the tool.

Then there is what is not GDPR but is often harder: confidentiality agreements with clients. An NDA that forbids disclosure to third parties is breached by using an AI provider without the client's approval, however good the DPA is. And with employee data the works council has a say, because a tool that could log work behaviour falls under § 87 BetrVG (the German Works Constitution Act).

The step before: what should never leave the machine

All the points so far govern what happens to data after it has been sent. The most effective lever sits before that. What is not in the prompt needs no DPA.

Three measures, in rising order of effort:

1. Clean up your repos. No production dumps in fixtures/, no real customer emails in tests, .env in .gitignore and in the deny patterns of your tool permissions. This is hygiene, not data protection, but it is most of the effect.
2. Your own key instead of a shared account. One API key per team with a commercial contract instead of a personal account passed around. That settles which contract applies and who is responsible.
3. Replace secrets and personal data before sending. This is the step UltraNOS takes with cloak, and it is also the one whose limits we have to state most honestly.

How cloak works in UltraNOS

UltraNOS is an AI workspace in the browser, hosted in Nuremberg, that runs Claude either through the API or through Claude Code as a subprocess. cloak sits in the backend directly before sending. It replaces detected API keys, passwords in command lines, connection strings, PEM blocks and email addresses with placeholders of the form CLOAK_SECRET_… or CLOAK_EMAIL_…. Detection runs on 57 rules, including 27 provider prefixes (sk-ant-…, ghp_…, glpat-…) and 13 structural patterns. The placeholder is stable per value, so the model can work with it without seeing the value. On the hosted instance this runs in the enforce profile; whether it is active is shown by GET /api/health in the cloak field.

Now the limits, because they matter for exactly this post:

• On the Claude Code route, only the prompt and system prompt are masked. Claude Code runs its tools itself and talks to Anthropic over its own connection. What Read or Bash returns there, cloak does not see. Full coverage, including tool results of every round, applies only on the API routes that you choose with your own key.
• Pattern-based. A password with no prefix, no assignment and low entropy goes through. Real names in running text are only detected if they are entered in the vault. Images and PDFs are not scanned.
• The per-turn review copy is built but not yet wired in. Proof of what was actually replaced is today the server log and the health endpoint, not a view in the chat.

That is why we do not advertise "secrets never reach the model". What is true: detected secrets are replaced before sending, and you can see whether the protection is on. What this looks like day to day is described in Redact API keys before the LLM sees them. You can find the DPA for UltraNOS itself at ultranos.de/#avv.

Checklist: 10 points before you start

1. Commercial plan or API key through a Console organisation, no personal account.
2. DPA signed with the actual contracting party and archived (Anthropic, AWS or Google, depending on the route).
3. Retention period of the plan noted; zero-retention option checked, if needed.
4. Third-country transfer settled: standard contractual clauses or DPF entry documented, or EU region chosen via Bedrock/Vertex.
5. With Bedrock/Vertex: region and inference profile set so that it stays in the EU.
6. Entry in the record of processing activities created, DPIA question answered and justified.
7. Client NDAs checked for AI clauses; approval obtained where needed.
8. Repos cleaned: no production data in tests, .env and dumps in the tool deny lists.
9. Telemetry and error reports of the tool configured deliberately, not left at the default.
10. Pre-processing set up (redaction, placeholders) and its limits made known to the team.

Who this is not for

If you work only on your own code, with no personal data and no third-party secrets, all you need from this is repo hygiene and the right plan. If you are under strict regulation, for example with health data, banking secrecy or classified material, no cloud model will make you happy, not even in Frankfurt. There, the only option is a locally run model, at the price that it is much weaker than Claude. And if you expect a tool to take over the responsibility, you are looking for something that does not exist. The controller stays the controller.

FAQ

Is Claude Code GDPR compliant?

The question cannot be answered like that. A processing operation is compliant, not a tool. Claude Code can be run with data protection in mind using a commercial contract, a DPA, an EU region and cleaned repos. With a personal account and customer data in the repo, it can also be run differently.

Does Anthropic offer a DPA?

Yes, for the commercial plans and the API, Anthropic provides a Data Processing Addendum. There is none for consumer accounts. Check the current version at anthropic.com/legal and which contracting party signs for you.

Is AWS Bedrock in Frankfurt enough for GDPR?

Bedrock in an EU region settles the place of processing and the contracting party. It does not settle which data you send in, whether you keep a record of processing activities, or whether your client NDAs allow disclosure. It is one building block, not a free pass.

Which Claude Code settings affect data protection?

The choice of account (personal or commercial), the route (API, Bedrock, Vertex), the telemetry switches, and the approval and deny lists for tools. The exact variable names are in the documentation at docs.anthropic.com and change between versions.

What does UltraNOS do differently from Claude Code on its own?

UltraNOS redacts detected secrets and email addresses before sending, runs on servers in Nuremberg and offers a DPA. On the Claude Code route, redaction is limited to the prompt and system prompt. Full coverage including tool results is available on the API routes with your own key.

Your keys stay yours — the rest runs in the browser.

UltraNOS is the agentic web IDE: parallel AI agents, editor, git and terminal. cloak replaces API keys and passwords before a prompt reaches the provider. Hosted in Germany, 14 days free.

Try 14 days free →