Claude Code Enterprise Security: Permissions & Governance

Claude Code Enterprise Security: Where Your Code Goes

The most common security concern about Claude Code is also the most straightforward to answer: when a developer uses Claude Code on a codebase, does that source code leave the organisation? The answer depends on how Claude Code is deployed, and getting this answer right is the first step in any enterprise security review.

Claude Code sends content to Anthropic's API to generate responses. This means source code, file contents, and context from your repository are included in API requests. Under Anthropic's standard API terms, this data is not used to train models. Under the Claude Enterprise agreement, Anthropic provides additional contractual protections: zero data retention by default, the option for private model deployment, and contractual data processing agreements compatible with GDPR, HIPAA, and other regulatory frameworks.

For organisations where any data leaving the network perimeter is prohibited — certain government, defence, and highly regulated financial contexts — there is a self-hosted option via Bedrock (AWS) and Vertex AI (Google Cloud), where API calls route through your own cloud infrastructure rather than Anthropic's directly. Our Claude AI governance service covers this deployment architecture in detail, including the trade-offs between self-hosted and Anthropic-hosted options.

Claude Code's Permission Model: What It Can and Cannot Do

Claude Code operates with your developer's system permissions by default — if your developer can read a file, Claude Code can read it. If your developer can execute a command, Claude Code can execute it. This is intentional and enables Claude Code to be maximally useful, but it requires careful thinking about the principle of least privilege when configuring workstation environments for Claude Code use.

Claude Code has a built-in permission system that can restrict what actions it will take. These restrictions are configured at several levels: the user's global settings file, the project-level settings file (version-controlled with the repository), and an interactive confirmation prompt system for sensitive operations.

Permission Configuration

The settings file at ~/.claude/settings.json (user level) or .claude/settings.json (project level) accepts a permissions block that controls which operations Claude Code will perform without confirmation and which it will refuse entirely.

// .claude/settings.json — enterprise permission configuration
{
  "permissions": {
    // Operations allowed without asking the user each time
    "allow": [
      "Read(*)",
      "Edit(src/**)",
      "Edit(tests/**)",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff)"
    ],
    // Operations Claude Code will never perform in this project
    "deny": [
      "Bash(git push *)",
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Bash(kubectl delete*)",
      "Bash(terraform destroy*)",
      "Bash(aws s3 rm*)"
    ]
  }
}

The deny list is the most important security control in this configuration. Listing destructive or irreversible operations here means Claude Code will refuse to execute them regardless of what it's instructed to do — even if a prompt injection attack in a file Claude Code reads attempts to override this. Deny rules take precedence over allow rules.

A well-governed enterprise deployment will have a standard project-level settings.json committed to every repository, with deny lists covering production write operations, credential access, and network exfiltration commands. This file should be reviewed by your security team and treated as a security control, not a developer convenience configuration.

Using Hooks for Governance and Audit

The Claude Code hooks system is the mechanism for enforcing governance policies programmatically. Hooks are scripts that run at defined points in the Claude Code lifecycle — before a tool is used, after a tool completes, when a session starts, and when a session ends. For enterprise security, hooks are how you implement audit logging, policy enforcement, and compliance controls.

Pre-Tool Hooks: Policy Enforcement

A pre-tool hook runs before Claude Code executes any tool call. If the hook exits with a non-zero status, the tool call is blocked. This makes pre-tool hooks the right place to enforce security policies that go beyond the static deny list — policies that depend on runtime context.

#!/bin/bash
# .claude/hooks/pre-tool.sh
# Blocks any git push and logs all bash commands

TOOL_NAME="$1"
TOOL_INPUT="$2"

if [ "$TOOL_NAME" = "Bash" ]; then
  # Log all bash commands to audit trail
  echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | USER:${USER} | CMD:${TOOL_INPUT}" \
    >> /var/log/claude-code-audit/bash-commands.log

  # Block any git push commands
  if echo "$TOOL_INPUT" | grep -q "git push"; then
    echo "BLOCKED: git push not permitted via Claude Code" >&2
    exit 1
  fi

  # Block access to credential files
  if echo "$TOOL_INPUT" | grep -qE "(\.env|credentials|secrets|\.pem|\.key)"; then
    echo "BLOCKED: credential file access flagged for review" >&2
    # Alert your SIEM or security tooling here
    exit 1
  fi
fi

This hook pattern — log everything, block specific patterns — is the foundation of a Claude Code audit trail. Every bash command Claude Code runs is recorded with a timestamp and user identity. Any command matching a sensitive pattern is blocked and can trigger an alert to your security tooling.

Post-Tool Hooks: Audit Logging

Post-tool hooks run after a tool completes and have access to the tool's output. This is where you log what Claude Code read, what files it modified, and what commands returned — the full context needed for a security investigation if something goes wrong. Sending this log data to your SIEM (Splunk, Datadog, AWS CloudTrail, or equivalent) creates a complete audit trail of AI-assisted development activity in your organisation.

Data Classification and Claude Code Access Policies

Not all code is equal from a security perspective. Source code for a public-facing marketing website carries very different risk from source code for a trading algorithm, a clinical data processing pipeline, or cryptographic key management infrastructure. Enterprise Claude Code deployments should map your existing data classification framework onto Claude Code access policies.

The practical implementation is per-repository or per-project CLAUDE.md and settings configuration. For public-tier repositories, the default enterprise configuration is appropriate. For confidential-tier repositories, add additional deny rules and stricter hook policies. For secret-tier or highly regulated repositories, consider whether Claude Code should be permitted at all — and if it is, enforce deployment through your private cloud infrastructure rather than Anthropic's hosted API.

Classification	Claude Code Access	API Routing	Additional Controls	Risk
Public	Full access, standard config	Anthropic hosted	Standard deny list	Medium
Internal	Full access, enhanced logging	Anthropic hosted + Enterprise DPA	Audit hooks, SIEM integration	Medium
Confidential	Restricted operations only	Bedrock/Vertex (private)	Extended deny list, approval hooks	High
Secret / Regulated	Case by case approval	Air-gapped or self-hosted only	Human review of all outputs	Critical

Claude Code in Regulated Industries

Financial services, healthcare, legal, and government organisations face additional constraints that standard enterprise Claude Code configurations don't address out of the box. Regulators are increasingly asking about AI tool usage in software development as part of technology risk assessments, and organisations need to be able to demonstrate controls — not just assert that they've thought about it.

Financial Services (FCA, PRA, MAS)

UK and Singapore financial regulators increasingly expect firms to document AI tool usage in the development of systems that affect clients or markets. For Claude Code, this means your audit trail (from hooks) needs to be retained in accordance with your regulatory record-keeping obligations, and your risk management framework needs to cover AI-assisted code generation as a category of operational risk. The good news: the hook-based audit system described above already produces the records you need. The governance layer is attaching those records to your existing operational risk framework.

Healthcare (HIPAA, NHS DSP Toolkit)

The concern in healthcare is straightforward: does any protected health information (PHI) end up in a Claude Code API request? In most software development contexts, the answer should be no — developers work with test data, not production data. The risk arises when developers use real patient records to debug issues or reproduce problems. Your Claude Code security policy should explicitly prohibit the use of PHI in development environments, and your pre-tool hook should flag any file access patterns that might indicate PHI presence (e.g., files in data directories that match patient record naming conventions).

Government and Defence

For UK government systems classified at OFFICIAL-SENSITIVE or above, the network routing requirement typically prohibits any data leaving the OFFICIAL network without explicit approval. Claude Code in these environments requires either a cloud-hosted Anthropic endpoint that meets the relevant classification requirements, or a fully self-hosted deployment. Our team has experience navigating these requirements — contact us for a confidential discussion about your specific context.

Prompt Injection: The Security Risk Specific to AI Tools

Prompt injection is an attack vector that doesn't exist in traditional development tooling. When Claude Code reads a file — a configuration file, a README, a comment in source code — that file can contain text that attempts to override Claude Code's instructions. For example, a malicious dependency's README might contain instructions telling Claude Code to execute a shell command, send data to an external server, or modify code in ways the developer didn't intend.

This is not a theoretical attack. It has been demonstrated in multiple AI coding assistant contexts and should be treated as a real threat model in enterprise deployments, particularly when working with third-party code, open-source dependencies, or any content from outside the organisation's control.

The defences are layered. The deny list prevents Claude Code from executing the most dangerous commands even if injected instructions ask for them. Pre-tool hooks add an additional layer of policy enforcement. Developer training creates awareness — developers should review Claude Code's actions before approving them rather than simply pressing 'approve' reflexively. And for the most sensitive environments, human review of all Claude Code-generated code before it's merged is a proportionate control.

Building this governance framework from scratch takes time and expertise. Our Claude AI governance and security service delivers the full framework — policy documentation, technical configuration, hook scripts, and SIEM integration — in a structured 4-week engagement. We've done this across financial services, healthcare, and government organisations and have the regulatory context to make the outputs useful in an actual audit, not just in theory.

If you're in the planning phase for a Claude Code rollout and want to understand the security requirements before you start, book a free strategy call. We'll walk through your specific environment and give you a clear picture of what governance work is required before you go live.