Claude Code in Regulated Finance Environments

## Overview

Financial-services teams operate under strict expectations for where data goes, who can access it, and how every action is logged and auditable. Adopting an agentic coding tool like Claude Code in that environment is less about productivity claims and more about whether you can configure it to fit your existing controls.

The good news is that Claude Code is built around a permission-first model and exposes the enterprise primitives you need: configurable data retention (including Zero Data Retention for qualified Enterprise accounts), proxy and mutual-TLS network controls, multiple authentication paths including SSO via Claude for Enterprise, and filesystem/network sandboxing for autonomous work. This guide maps those documented capabilities to the control areas a security or compliance reviewer will ask about, then gives concrete hardening steps.

This is an architecture and configuration guide, not a compliance attestation. Claude Code's security program documentation (SOC 2 Type 2, ISO 27001 and related artifacts) is published in the [Anthropic Trust Center](https://trust.anthropic.com). What your specific deployment must satisfy for any given regulation remains your organization's responsibility.

> **Prerequisites**
>
> A clear picture of which model provider you will use (Anthropic first-party API, Claude for Enterprise, Amazon Bedrock, Google Vertex AI, or Microsoft Foundry) — this drives retention, encryption-at-rest, and default telemetry behavior. You should also know your network egress policy (proxy, TLS inspection, allowlists) and your identity model (SSO, console roles, or cloud-provider credentials) before rollout.

## How Claude Code handles your data

Claude Code runs locally and sends prompts and model outputs over the network to your chosen model provider, encrypted in transit with TLS 1.2+. It is compatible with most VPNs and LLM proxies.

A few facts that matter for a finance deployment:

- **Training.** Under commercial terms (Team, Enterprise, API, and third-party platforms), Anthropic does not train generative models on code or prompts sent to Claude Code, unless the customer explicitly opts in (for example, the Development Partner Program). Consumer Free/Pro/Max accounts have a separate, user-toggled training setting — which is one reason to standardize on commercial plans for regulated work.
- **Standard retention.** For commercial users the standard retention period is 30 days. Encryption at rest depends on the provider (for the Anthropic API, infrastructure-level AES-256 disk encryption).
- **Local cache.** Claude Code stores session transcripts locally in plaintext under `~/.claude/projects/` for 30 days by default to support session resumption. Adjust this with the `cleanupPeriodDays` setting, and account for these files in your endpoint data-handling policy.
- **Telemetry and feedback.** Operational metrics (latency, reliability, usage — no code or file paths) and Sentry error reporting are on by default on the Anthropic API and off by default on Bedrock/Vertex/Foundry. The `/feedback` command sends conversation history including code only when you run it. These are independently controllable (see hardening below).

## Control mapping

The table below maps common control areas to the specific, documented Claude Code capability that supports them. Treat it as a starting point for your own control matrix.

| Control area | Claude Code capability (documented) |
| --- | --- |
| Data retention / minimization | Standard commercial retention is 30 days. **Zero Data Retention (ZDR)** is available to qualified Claude for Enterprise accounts: prompts and responses are processed in real time and not stored after the response returns (except where required by law or to address misuse). ZDR is enabled per-organization by your Anthropic account team, not from admin settings. |
| Local data footprint | Session transcripts cached in plaintext under `~/.claude/projects/`; retention tunable via `cleanupPeriodDays`. Credentials stored in the macOS Keychain, or file-permission-protected on Linux (`~/.claude/.credentials.json`, mode `0600`) and Windows. |
| Encryption in transit | All prompt/response traffic encrypted with TLS 1.2+. |
| Encryption at rest | Provider-dependent: Anthropic API uses AES-256 disk encryption; Bedrock supports AWS-managed or customer-managed keys via KMS; Vertex supports Google-managed keys or CMEK. |
| Network egress control | Standard `HTTPS_PROXY` / `HTTP_PROXY` / `NO_PROXY` env vars are respected. A documented allowlist of required URLs (for example `api.anthropic.com`, `claude.ai`, `platform.claude.com`) lets you constrain firewall rules. SOCKS proxies are not supported. |
| TLS inspection / custom CA | TLS-inspection proxies work when their root cert is in the OS trust store; `CLAUDE_CODE_CERT_STORE` selects `bundled`/`system`/both, and `NODE_EXTRA_CA_CERTS` adds a custom CA. |
| Mutual TLS / client auth | Client-certificate auth via `CLAUDE_CODE_CLIENT_CERT`, `CLAUDE_CODE_CLIENT_KEY`, and optional `CLAUDE_CODE_CLIENT_KEY_PASSPHRASE`. |
| Authentication / IAM | Claude for Enterprise adds SSO, domain capture, role-based permissions, a compliance API, and managed policy settings. Console auth supports SSO and scoped roles (a "Claude Code" role limited to Claude Code API keys). Cloud-provider auth uses Bedrock/Vertex/Foundry credentials. Rotating creds via `apiKeyHelper`. |
| Authorization / least privilege | Read-only by default; non-read-only Bash and file edits require explicit approval. Write access is confined to the working directory and subfolders. Allowlists are per-user, per-codebase, or per-organization. |
| Isolation / sandboxing | `/sandbox` provides filesystem and network isolation for Bash commands; dev containers add stronger isolation. Web fetch runs in an isolated context window; new codebases and MCP servers require trust verification. |
| Centralized policy & monitoring | Server-managed / managed settings enforce org standards (and can be locked); OpenTelemetry metrics enable monitoring; `ConfigChange` hooks can audit or block in-session settings changes. Enterprise/ZDR orgs get audit logs. |

## Practical hardening

Concrete steps, grounded in the docs above:

1. **Standardize on a commercial plan and pin the provider.** Use Claude for Enterprise, Console/API, or a cloud provider (Bedrock/Vertex/Foundry) — not consumer accounts — so the no-training commercial policy applies and you control retention and encryption-at-rest keys.
2. **Request ZDR if your data policy requires it.** ZDR is not part of the standard Enterprise plan; contact your Anthropic account team to confirm eligibility and enable it per organization. Note that ZDR disables features that require server-side storage (Claude Code on the web, Desktop cloud sessions, `/feedback`) and that some models requiring retention are unavailable under ZDR.
3. **Constrain network egress.** Route traffic through your corporate proxy with `HTTPS_PROXY`, set `NO_PROXY` for internal hosts, and allowlist only the documented required URLs at the firewall. Add `NODE_EXTRA_CA_CERTS` for your internal CA and configure mTLS with `CLAUDE_CODE_CLIENT_CERT` / `CLAUDE_CODE_CLIENT_KEY` if your gateway requires client certs.
4. **Disable non-essential traffic.** Set `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` to turn off optional outbound traffic in one move, or target individually with `DISABLE_TELEMETRY`, `DISABLE_ERROR_REPORTING`, and `DISABLE_FEEDBACK_COMMAND=1`. Check these into `settings.json` so they apply org-wide. (The WebFetch domain safety check has its own `skipWebFetchPreflight` control.)
5. **Lock down permissions and run sandboxed.** Keep the default read-only posture, avoid broad allowlists like `Bash(* )`, enable `/sandbox` for filesystem/network isolation, and use dev containers for higher-risk work. Use `permissions.deny` to block tools you never want (for example network fetch commands).
6. **Centralize and audit configuration.** Distribute approved permissions and env vars through managed/server-managed settings under version control, enforce them at the org level, add `ConfigChange` hooks to catch in-session changes, and stream OpenTelemetry metrics to your own collector for monitoring and audit.
7. **Manage the local footprint.** Tune `cleanupPeriodDays` to match your data-handling policy, keep `~/.claude/projects/` transcripts and `.credentials.json` within managed/encrypted endpoints, and treat both as in-scope for any data-deletion or incident process.
8. **Train reviewers.** Because Claude Code only has the permissions you grant, the human approving a command is the last control. Reviewing proposed Bash and code changes before approval — especially anything touching customer data, payments, or production — is part of the control, not a formality.

## Not legal or compliance advice

This guide describes Claude Code's documented technical controls and how to configure them. It is not legal advice and is not a compliance attestation for any specific regulation, framework, or jurisdiction. Mapping these controls to your obligations, validating them against your risk and audit requirements, and deciding what data may be processed are your organization's responsibility. For Anthropic's compliance artifacts and certifications, see the [Anthropic Trust Center](https://trust.anthropic.com); for legal terms, review the applicable Commercial Terms of Service and Privacy Policy.

## Related resources

- [Claude Code security](https://code.claude.com/docs/en/security)
- [Zero Data Retention](https://code.claude.com/docs/en/zero-data-retention)
- [Data usage](https://code.claude.com/docs/en/data-usage)
- [Enterprise network configuration](https://code.claude.com/docs/en/network-config)