Claude Code Permissions Security Model for Teams

TL;DR: Before rolling out Claude Code to your team, understand the permission tiers, data flows, and GDPR considerations for European teams.

Before you roll out Claude Code across a 10-20 person engineering team, you need to understand exactly what the tool can read, write, and execute: and what it sends to Anthropic's servers. Getting this wrong is not a theoretical risk. A misconfigured Claude Code session can expose secrets stored in local config files, run shell commands outside the intended scope, or send file contents containing personal data to an external API. This article gives technical leads at small software companies the security model overview they need to make a confident rollout decision.

Claude Code is an agentic coding assistant that runs inside the terminal. Unlike a chat interface, it takes actions: it reads files, writes code, runs commands, and can chain multiple steps together. That capability is what makes it powerful. It is also what makes a clear permissions understanding non-negotiable before team deployment.

How Claude Code's Permission Tiers Work

Claude Code operates on a tiered permission model that distinguishes between what the tool does automatically and what requires your explicit approval.

Default (automatic) permissions cover actions Claude Code can take without asking: reading files in the current working directory, writing and editing files you have opened in the session, and running common shell commands like ls, cat, or grep.

Approval-required permissions cover higher-risk actions: running scripts, executing commands that modify system state, installing packages, or accessing directories outside the current project. Claude Code will pause and ask for confirmation before proceeding.

Blocked by design covers actions Claude Code will not take even if instructed: it will not push to remote repositories without confirmation, will not delete files without explicit approval, and will not override .gitignore rules.

In practice, the boundary between automatic and approval-required depends on your configuration. The default settings are designed to be conservative, but a growing software team should review and tighten them before shared use.

The Allow/Deny Configuration System

Claude Code uses a permission configuration system that lets you define what is allowed, what requires approval, and what is prohibited. This is set at the project level using a settings.json file (stored in .claude/settings.json) and optionally reinforced through a CLAUDE.md file at the project root.

Key configuration options for a mid-sized company's engineering team:

• Prohibited directories: Explicitly exclude directories containing secrets or sensitive data (.env files, credentials folders, certificate stores). Use the denyPaths configuration to prevent Claude Code from reading these directories at all.
• Command allow-listing: Rather than allowing all shell commands, restrict Claude Code to a defined set. For a development team, this typically means allowing build and test commands while requiring approval for any command that touches infrastructure.
• File write scope: Limit automatic writes to the src/ and tests/ directories. Any write outside those paths requires confirmation.
• Workspace isolation: Each engineer should run Claude Code scoped to their active project directory, not from a root home directory.

The CLAUDE.md file plays an important role here. Beyond giving Claude Code project context, it functions as a governance document. An engineering leader can specify in CLAUDE.md exactly what Claude Code is allowed to do in that repository: what files it should not modify, what external calls it should not make, and what review steps are required before any commit. See CLAUDE.md Configuration Guide for Engineering Teams for the full setup pattern.

What Data Claude Code Sends to Anthropic

This is the question every CTO at a technical team should ask before deployment: what leaves the machine?

Every interaction with Claude Code sends an API request to Anthropic. That request includes:

• The contents of files Claude Code has read in the current session
• Terminal output from commands it has run
• Your natural language instructions

This means that if Claude Code reads a file containing a database connection string, an API key, or a patient record, that content goes to Anthropic's API. The implications for a European engineering team are significant.

Anthropic does not train on API data by default (unlike consumer products), and data is processed under Anthropic's privacy policy. However, the transfer itself is a GDPR-relevant event if any personal data is included. European teams need to treat Claude Code API calls as a data processing activity, which means:

1. Personal data (customer records, employee data, any data subject to GDPR) must not appear in files Claude Code reads during a session.
2. If your codebase includes test fixtures with real personal data (a common anti-pattern), clean these before enabling Claude Code for your team.
3. Review your Anthropic API agreement against your data processing obligations. For most small software companies, Anthropic's data processing addendum covers standard requirements; confirm with your legal or privacy counsel.

The practical mitigation is straightforward: use .gitignore patterns and denyPaths configuration to prevent Claude Code from accessing any file containing personal data. Define this in your CLAUDE.md as a hard rule.

GDPR Configuration for European Teams

For a founder-led company or a professional services firm serving EU clients, the GDPR posture for Claude Code comes down to three controls:

Data minimisation at the session level. Claude Code should only read files relevant to the task at hand. Avoid opening entire project trees. Structure your workflow so that Claude Code operates on isolated modules, not on repositories that contain mixed sensitive and non-sensitive data.

No PHI, PII, or client-confidential data in scope. This is a categorical rule, not a best-effort guideline. If your codebase processes health data, financial records, or any regulated personal data, implement directory-level exclusions before team rollout.

Audit logging. Claude Code sessions generate logs. Establish a policy for how long these are retained and who has access, consistent with your existing data retention obligations.

Five-Point Governance Checklist Before Team Rollout

For an engineering leader at a growing software team preparing to deploy Claude Code to 10-20 engineers, this is the minimum governance baseline:

1. Configure denyPaths for all directories containing secrets, credentials, environment files, and any data that could include personal information.
2. Write a project-level CLAUDE.md for each active repository. Define what Claude Code is permitted to modify, what it must not touch, and what commands require human review.
3. Audit your test fixtures for real personal data. Replace any real data with synthetic equivalents before Claude Code is enabled in those repositories.
4. Brief your engineers on what Claude Code sends to Anthropic. This does not need to be a long session: a 15-minute team sync covering the permission model and the data minimisation rule is sufficient.
5. Run a pilot with two or three engineers first. Observe which approval prompts they encounter, whether any unexpected directories are being accessed, and whether the configuration is producing the right friction level. Adjust before full rollout.

A 20-person company that skips this checklist is not taking an acceptable risk. It is taking an avoidable one.

Ready to review your Claude Code rollout plan against these criteria? The AI Consulting service includes a tool governance workstream for European engineering teams.

FAQ

Does Claude Code store my code permanently at Anthropic?

Anthropic does not use API data to train its models by default. Session data is processed to generate responses and is subject to Anthropic's API data retention policy, not the consumer product retention policy. European teams should review Anthropic's data processing addendum and confirm it meets their GDPR obligations before full deployment.

Can Claude Code access files outside my project directory?

By default, Claude Code operates within the current working directory. It will ask for approval before accessing paths outside that scope. You can enforce this hard boundary using denyPaths configuration, which prevents Claude Code from reading specified directories regardless of user instruction. Always configure this before team rollout.

What happens if an engineer accidentally lets Claude Code read a file with credentials?

The credential content will have been included in the API call to Anthropic for that session. Your immediate response should follow your standard secret rotation procedure: treat the credential as compromised, rotate it, and audit for any usage from that point forward. Prevention is the correct approach: configure denyPaths to cover all credential-bearing files and directories.

Further Reading

• CLAUDE.md Configuration Guide for Engineering Teams: How to structure your CLAUDE.md for permission control and team governance.
• Claude Code Team Evaluation Scorecard: A structured scorecard for evaluating Claude Code fit before committing to team-wide rollout.
• Claude Code for Non-Technical Founders: What founders without an engineering background need to understand about Claude Code before approving its use.
• AI Governance Framework for European SMEs: Building the governance layer that makes AI tools safe to deploy across your organisation.