Claude Code mods can be useful in a tax firm, for example as a warning before client data goes into a prompt, as a display of client number and deadline, as an audit trail, or as an extra approval before anything is sent. These are ideas, not a proven toolkit. Mods turn risky because they run without a sandbox with the user's privileges, see every prompt and therefore every piece of client text, and, without managed settings or a Team or Enterprise sign-in, can even override deny rules. In Germany, tax advisors are also bound by professional secrecy under § 203 of the Criminal Code (StGB). A firm that uses Claude Code with client data should therefore control mods centrally: managed settings, only its own mods, no mods from arbitrary folders. And the actual protection of client data does not belong in a mod, but at network level and in user permissions.
I work with Claude Code every day and also build AI employees for clients, among them a tax advisory firm; I describe that case in AI Agents for Tax Firms: A Real Case. Mods have only existed since October 1, 2026, and I have not built or tested one of my own yet. The technical facts here come from Anthropic's documentation, retrieved on October 26, 2026. The ideas are my own thinking, clearly marked as ideas. Everything about Claude is collected on my Claude page. I explain the basics in Claude Code Mods: Examples, Risks, Control.
Why mods matter for professional firms
In a tax firm, almost every prompt is client text: a tax assessment, a payslip, a question about a receipt. According to Anthropic, a mod is a plugin whose code runs inside Claude Code itself. The docs list what a loaded mod can reach: it can read and write files anywhere the user can, start programs and make network requests, read environment variables and settings including keys, see and rewrite every prompt and every tool call, approve a call before anyone is asked, and trigger model calls on the firm's account. Plus this sentence: "Mods aren't sandboxed."
For a firm this means: whoever installs a mod gives its code the same view of client data as they have themselves. That is why mods are worth more than a shrug as a developer toy; they belong in the rules you already have for software with access to client data.
Four ideas for how a mod could help in a firm
All four are ideas, not built and not tested. They rest on the capabilities Anthropic describes in its docs. Whether they hold up day to day only a trial will show.
I know that last limit from the case above: there, the AI employees work with their own DATEV user without filing or payment rights. A boundary in user permissions holds even when a program on the machine wants something else.
Where a mod turns risky in a firm
Mods from outside sources. Anthropic runs a community catalog of third-party plugins that their authors submitted, and writes about other providers' catalogs: "Anthropic doesn't review third-party marketplaces." A third-party mod sees every prompt, so every piece of client text, and can pass data on through network requests or programs it starts.
Deny rules that do not hold. Without managed settings and without a Team or Enterprise sign-in, the built-in guard sec-default does not load. Then, per the docs: "the mod can approve a call that a deny rule refuses or a PreToolUse hook blocked." A firm working on Pro, Max or an API key without managed settings does not have this guard.
The mod's own calls. Even with the guard, permission rules only cover Claude's tool calls. "With Read(.env) denied, a mod can still read that file with $.fs.read or start a program that does." The same goes for a folder of client files you blocked with a deny rule.
Model calls on the firm's account. A mod can call a model itself. Per the docs, these calls use the session's credentials, so they run on the firm's plan or key.
Professional secrecy and data protection
Up front: this isn't legal advice, it's a pointer to the rules you should know before client data goes into an AI system. The assessment for your firm belongs with a specialist or your chamber. The rules below are German and EU law.
§ 203 StGB. For tax advisors, unauthorized disclosure of third-party secrets is a criminal offense under § 203(1) no. 3 of the German Criminal Code. Under § 203(3) sentence 2, they may disclose secrets to other persons involved in their work, but only to the extent this is necessary for using those persons' services. Under § 203(4) sentence 2 no. 1, a professional is also liable if they did not ensure that an involved person was bound to secrecy and that person then discloses a secret without authorization.
§ 62a StBerG. For service providers, the German Tax Advisory Act requires: access to confidential facts only as far as the service requires, careful selection, a contract in text form with a confidentiality obligation, and for services abroad only where secrecy protection there is comparable.
GDPR. Art. 28(1) requires processors that provide "sufficient guarantees" for appropriate technical and organizational measures, and Art. 28(3) a contract binding them to instructions. Among the possible measures, Art. 32(1) explicitly names "the pseudonymisation and encryption of personal data", along with "a process for regularly testing, assessing and evaluating" their effectiveness.
My view as an operator, not a lawyer: the author of a third-party mod has neither been selected as a service provider nor bound to confidentiality, and there is no contract with them. Still, their code sees every prompt. Whether and when that is a disclosure within the meaning of § 203, I cannot judge. The question belongs with your specialist before installation, not after. What applies to contract and training at the AI provider itself is in Claude Privacy and GDPR: What Applies, and how I decide in general which data an AI may see is in AI and Privacy: What the AI Gets to See.
The admin's must-do list
What follows is my recommendation as a hypothesis, derived from Anthropic's admin docs. Whether it is enough for your firm, check with your specialist.
- Managed settings on every machine. Only then does the
sec-default guard also load for sessions on an API key or through a cloud provider. With Team or Enterprise it also loads through the sign-in. Managed settings come as a file, through device management or from the claude.ai admin console.
- Only your own mods.
allowManagedModsOnly as an option of the guard stops users' mods from running; allowManagedHooksOnly also blocks hooks from users' own settings.
- No mods from arbitrary folders.
disableSideloadFlags rejects --plugin-dir and --plugin-url at startup and does not load mods Claude writes during a session.
- Only approved catalogs. An allowlist such as
strictKnownMarketplaces decides which marketplaces anything can be installed from.
- Central deny rules and hooks. Rules for client folders and critical commands belong in managed settings, not in each person's settings. Per the docs,
PreToolUse hooks from managed settings run before any mod.
- Network requests from mods. A deny rule for WebFetch does not stop a mod's network requests. If the organization's policy does not allow WebFetch at all, however, Claude Code also refuses the mods' requests. Programs a mod starts are not covered; hence point 2.
- A dedicated user with limited rights for every AI employee, so that the most important boundary sits in the system and not in the program on the machine.
I would not set the option allowModsToOverrideDenyRules in a firm: it explicitly lets users' mods approve calls that a deny rule refuses. What else sets Team and Enterprise apart is in Claude Enterprise or Team: Cost and GDPR. How deny rules, sandbox and hooks work together is in Claude Code Security: Permissions and Sandbox.
Why the protection must not live in a mod
A mod sits in the program on the machine. Anthropic itself says that even an organization's guard mod is not a hard boundary: "A session can run without your mod." If the thread running the installed mods crashes three times, Claude Code unloads every mod that is not built in, and with --safe-mode a session starts without them. A mod meant to protect client data protects only while it runs.
That is why I place the protection of client data in two other places. The first is user permissions, as described above. The second is a principle I call a data lock, a checkpoint in the network that every request has to pass before it reaches the model: client data is pseudonymized before it reaches the model, at network level, between all of the firm's programs and the AI provider. Names and other details that point to a person are replaced with placeholders before a request leaves the building; the mapping back stays in-house. Because the data lock sits in the network, it applies to every program, whatever runs on the machine and whether a mod is loaded or not. Pseudonymization is the first measure Art. 32(1)(a) GDPR names; it does not make data anonymous, but separates it from the information needed to re-identify it, which under the definition in Art. 4(5) GDPR is kept separately. So the GDPR still applies to pseudonymized data.
A mod can complement a data lock, for example as an early warning right in front of the person, but it cannot replace one. Other routes for client data are Claude through AWS Bedrock in EU regions and open models on your own hardware, described in Claude on AWS Bedrock: EU, GDPR and Cost and Local AI and Privacy: Cloud or Server?.
The same situation for law firms and medical practices
The same questions arise wherever § 203 StGB applies. Lawyers, notaries and auditors are listed in the same number as tax advisors (para. 1 no. 3), doctors and dentists in para. 1 no. 1. Medical and dental practices also handle health data, whose processing Art. 9(1) GDPR prohibits in principle, subject to the exceptions in Art. 9(2). The technical answers above apply there just the same, and the legal review belongs with a specialist there too.
Frequently asked questions
May a tax firm use Claude Code mods?
Technically yes; there is no general legal answer. Relevant in Germany are, among others, § 203 StGB, § 62a StBerG and the GDPR. A firm's own reviewed mod under managed settings is a different case from a third-party mod from an unreviewed catalog. This is a pointer, not legal advice; the review for your firm belongs with a specialist.
Can a mod pass on client data?
Yes, if its code does that. Per the docs, a mod can see every prompt, read files, make network requests and start programs, with the user's privileges. Permission rules cover Claude's tool calls, not the mod's own calls.
Is a deny rule for the client folder enough?
Against Claude's file tools and the file commands Claude Code recognizes in the shell, yes. Per the docs, it does not cover commands that read files without naming them, such as a grep -r run from the folder that holds the files, or scripts that open files themselves; that is what the sandbox is for. Against a mod it does not hold: without managed settings or a Team or Enterprise sign-in, a mod can approve a refused call, and even with the guard it can read the folder itself. So block users' mods with allowManagedModsOnly.
Can a mod handle the pseudonymization?
It can warn, but not protect reliably. A mod runs in the program on the machine and drops out with --safe-mode or after three crashes. Pseudonymization belongs at network level, where it applies to every program.
What is the most important first step?
Managed settings on every machine where Claude Code runs with client data, with allowManagedModsOnly and disableSideloadFlags. Then no user mods run, and the built-in guard loads.
Where to go from here
First check how Claude Code is signed in at your firm: Team or Enterprise via /login, or Pro, Max and API keys. In the second case, without managed settings, the protective layers from this article are missing. Then have your specialist answer the question about third-party mods before anyone installs one. How DATEV and AI employees come together technically is in DATEV Integration: The Basics. And how I set up approvals, user rights and reviewer roles for my AI employees is what I show in my German-speaking community Claude Practitioners.
