Most Claude Code security problems are not discovered during development. They are discovered when something goes wrong in production, in a CI/CD pipeline, or during an external security review.
A structured audit finds them first. This guide walks through every layer of a Claude Code security audit with a checklist your team can run in a day. Check off items as you complete them; your progress is saved in your browser.
Key Takeaways
- Eight audit domains cover the full Claude Code attack surface: Permissions, CLAUDE.md, hooks, MCP servers, secrets handling, generated code, CI/CD pipeline, and team policy.
- Most critical issues take under an hour to fix:
.claudeignoremisconfiguration and missing PreToolUse hooks are the two highest-impact gaps, both correctable in under 60 minutes. - Run the audit before first production deployment: Retrofitting security controls is significantly harder than building them in from the start.
- Three 2026 incidents validate every item on this list: The March source code leak, the June GitHub Actions CVE, and the GTG-1002 threat actor case each map to specific audit items below.
- Re-run after every significant change: New MCP servers, CLAUDE.md updates, and new team members joining the Claude Code environment each warrant a targeted re-audit.
Before You Start: What a Claude Code Security Audit Covers
A Claude Code security audit is not a code review. It is a configuration and policy review. The question is not whether Claude Code’s outputs contain vulnerabilities (though that matters too), but whether Claude Code itself is configured to operate within safe, auditable boundaries.
The audit covers eight domains:
- File system access controls (
.claudeignore, permission scope) - CLAUDE.md configuration review
- Hooks configuration (PreToolUse, PostToolUse, Stop, Notification)
- MCP server assessment
- Secrets and credential handling
- Generated code security review process
- CI/CD pipeline controls
- Team policy and access governance
Each domain has specific checklist items. Work through them in order: the first two domains resolve the highest-frequency risks fastest.
Domain 1: File System Access Controls
File system access is the first thing to lock down. Claude Code operates with your user’s permissions by default and will read any file it can reach unless explicitly restricted.
| Audit item | Done |
|---|---|
.claudeignore exists at project root and is committed to the repo | |
.claudeignore covers .env, .env.*, .env.local, .env.production | |
.claudeignore covers *.pem, *.key, *.p12, *.pfx | |
.claudeignore covers ~/.ssh/, ~/.aws/credentials, ~/.aws/config | |
.claudeignore covers ~/.config/, config/secrets.*, secrets/ | |
Claude Code is launched from a project-scoped directory, not ~/ or / | |
| File system access reviewed for production environments with sensitive data paths | |
| Container or sandbox used for sessions involving untrusted third-party code |
Common gap: Teams add .env to .claudeignore but forget environment-specific variants (.env.staging, .env.production) and certificate files. Audit all patterns, not just the obvious ones.
Domain 2: CLAUDE.md Configuration Review
CLAUDE.md is the primary behavior control layer for Claude Code. A missing or generic CLAUDE.md is the single most common source of misconfigured deployments.
| Audit item | Done |
|---|---|
| CLAUDE.md exists at the project root | |
CLAUDE.md lists permitted tools (Bash, Read, Write, Edit, etc.) | |
| CLAUDE.md lists tools requiring explicit confirmation before use | |
| CLAUDE.md has a “do not” section with explicit prohibited operations | |
| CLAUDE.md defines permitted file paths and directories for this project | |
| CLAUDE.md references internal documentation (architecture docs, API conventions, security policies) | |
| CLAUDE.md is reviewed and updated when project scope changes | |
| CLAUDE.md conventions are consistent across all nested config files in the repo |
Common gap: Generic CLAUDE.md with only positive instructions (“be helpful, follow best practices”) and no explicit restrictions. The restrictions are what protect you.
Domain 3: Hooks Configuration
Hooks are the production-grade enforcement layer. Without them, you have no way to log, validate, or block Claude Code actions before they execute.
| Audit item | Done |
|---|---|
| PreToolUse hook is configured and active for all shell command tools | |
| PreToolUse hook validates command patterns and blocks suspicious activity (not just logs) | |
| PostToolUse hook logs all tool calls with full command strings to an auditable log | |
| Stop hook alerts when Claude Code terminates unexpectedly or enters a failure loop | |
| Notification hook is active for file deletion, external network calls, and production path writes | |
| Hook implementations tested with known-bad inputs to confirm they fire correctly | |
| Hook logs stored in a location not accessible to Claude Code itself | |
| Hooks reviewed and updated when new tools or MCP servers are added |
Common gap: Hooks exist but only log, rather than block. A PreToolUse hook that logs a suspicious command without blocking it provides an audit trail but no protection.
Domain 4: MCP Server Assessment
MCP servers run as separate processes with your user’s permissions. Each one is a trust decision that should be treated like installing an executable on your machine.
| Audit item | Done |
|---|---|
| Complete list of all installed MCP servers is documented in CLAUDE.md | |
| Each MCP server has a known, verifiable author or organization | |
| Source code is available and has been reviewed for each installed server | |
| Each MCP server shows active maintenance (last commit within 6 months) | |
| Required permissions are proportionate to each server’s stated function | |
| Outbound network connections from MCP servers are reviewed and whitelisted | |
| No MCP servers from unknown or unverifiable sources are installed | |
| An approval process exists for adding new MCP servers (not installed ad hoc) | |
| MCP server list is reviewed when onboarding new engineers or adding integrations |
Common gap: MCP servers installed from community directories without reviewing source, permissions, or network access. Treat every MCP server installation like a dependency approval decision.
Domain 5: Secrets and Credential Handling
Secrets leak into the context window through files Claude reads. The default configuration does nothing to prevent this.
| Audit item | Done |
|---|---|
All credential file patterns covered in .claudeignore (see Domain 1) | |
Codebase scanned for hardcoded credentials before enabling Claude Code access (git-secrets, truffleHog, or equivalent) | |
| Environment variable references used in config files rather than literal credential values | |
| PostToolUse hooks include a credential pattern scan on outgoing context | |
| CI/CD environment variables excluded from Claude Code context in automated pipelines | |
| Engineers trained not to paste API keys or tokens directly into Claude Code prompts | |
| Terminal logging reviewed to confirm credential values do not appear in output streams | |
| A credential rotation process exists for suspected Claude Code session exposure |
Common gap: .claudeignore covers the obvious .env file but not the eight other places credentials live in a typical codebase.
Domain 6: Generated Code Security Review Process
Claude Code generates code at high speed. Without a structured review process, security vulnerabilities ship to production faster than they would without the tool.
| Audit item | Done |
|---|---|
| All Claude Code-generated code treated as a first draft requiring review before merging | |
| SAST integrated into CI pipeline and runs on all PRs with Claude Code-generated code | |
| Dependency scanning runs on all packages Claude Code introduces or updates | |
| Security-specific evals exist for high-risk output domains (auth, payments, data handling, external APIs) | |
| Engineers are familiar with OWASP Top 10 patterns to identify in generated code | |
| A process exists to flag and remediate Claude Code-generated vulnerabilities found in production | |
| Code touching production data or external services receives additional manual security review before deployment |
Common gap: SAST exists in the pipeline but engineers bypass it for “small changes” or “quick fixes” that Claude Code generated. Apply SAST uniformly regardless of change size.
Domain 7: CI/CD Pipeline Controls
The June 2026 GitHub Actions CVE demonstrated that Claude Code in automated pipelines creates a specific attack surface around untrusted external input. This domain addresses it directly.
| Audit item | Done |
|---|---|
YOLO mode (—dangerously-skip-permissions) is not enabled in any CI/CD pipeline processing external input | |
—allowedTools is explicitly configured in all CI/CD Claude Code invocations | |
| External contributor input (PR descriptions, issue bodies, comments) is sanitized or excluded from Claude Code context | |
| CI/CD secrets and environment variables are excluded from Claude Code context during pipeline runs | |
| Pipeline logs reviewed to confirm Claude Code outputs do not contain credential strings | |
| Changes to Claude Code CI/CD configuration require code review before merging | |
| Automated Claude Code pipeline runs logged with full tool call records for audit review |
Common gap: YOLO mode enabled in CI/CD for convenience without restriction of which tools are permitted, creating a complete removal of human oversight in an automated context.
Domain 8: Team Policy and Access Governance
Configuration controls fail when team policy does not enforce them. This domain covers the human and process layer.
| Audit item | Done |
|---|---|
| A written Claude Code usage policy exists and has been reviewed by all engineers with access | |
| Policy covers: permitted use cases, prohibited operations, MCP approval process, credential exposure handling, and escalation path | |
| New engineer onboarding includes Claude Code security configuration review before first use | |
| A process exists to remove Claude Code access when an engineer leaves | |
| CLAUDE.md and hooks configuration are version-controlled and require code review to modify | |
| A designated owner is responsible for Claude Code security review on a regular cadence | |
| A documented incident response process exists for Claude Code-specific security events |
Common gap: Claude Code configuration is treated as a developer convenience setting rather than a production security control. No review process, no owner, no incident response procedure.
Audit Summary: Severity and Effort Matrix
| Audit item | Severity if missing | Effort to fix |
|---|---|---|
.claudeignore for sensitive paths | Critical | Low (under 1 hour) |
| PreToolUse hook for shell commands | High | Medium (2 to 4 hours) |
| CLAUDE.md explicit restrictions | High | Low to medium |
| MCP server source review | High | Medium (varies by server count) |
| SAST in CI pipeline | High | Medium (1 to 2 days) |
| YOLO mode removed from CI/CD | High | Low (policy change) |
| PostToolUse logging | Medium | Medium |
| Credential scan in hooks | Medium | Medium |
| Team policy documentation | Medium | Low |
How Often Should You Run a Claude Code Security Audit?
| Trigger | Audit scope |
|---|---|
| Before first production deployment | Full audit, all eight domains |
| New MCP server added | Domain 4 (MCP servers) only |
| New engineer joins with Claude Code access | Domain 8 (team policy and access governance) |
| CLAUDE.md updated significantly | Domains 2 and 3 (CLAUDE.md and hooks) |
| Claude Code added to a new CI/CD pipeline | Domain 7 (CI/CD controls) |
| Any suspected security incident | Full audit, all eight domains |
| Quarterly maintenance | Full audit, all eight domains |
Want a Professional Security Review of Your Claude Code Deployment?
Running through this checklist internally is a strong start. A professional audit adds independent verification, documented findings with severity ratings, a prioritized remediation plan, and an outside perspective on your specific environment.
Phos AI Labs is an embedded AI consulting firm for small and mid-market businesses.
We identify the right AI problems, build the strategy, handle implementation oversight, and train your team until AI is how the business actually runs.
- Strategy before systems: We establish which workflows Claude Code should own and what security controls each one requires before any configuration work begins.
- AI Foundations that hold: We install the operating context, decision rules, and configuration standards your team runs on for years.
- Real team training: We build security fluency inside your actual workflows, not in generic compliance sessions.
- Private AI Workspace: We design a company-wide AI environment built around your knowledge base and existing stack.
- AI Implementation: We rebuild the workflows that matter most with security and governance built in from the start.
- Honest judgment, every time: We tell you which risks are real for your specific environment and which are theoretical.
- We stay until it compounds: We are not done when the audit report is delivered. We are done when the controls are running.
400+ engagements. Clients include Zapier, Coca-Cola, Medtronic, Dataiku, and American Express.
For certified Claude Code development with security-first configuration from day one, LOW/CODE Agency is one of the first Anthropic partners worldwide with 10+ CCA-F certified developers on staff.
If you want your Claude Code deployment to hold up under scrutiny, talk to the team at Phos AI Labs.
Frequently Asked Questions
What is a Claude Code security audit?
A Claude Code security audit reviews your Claude Code configuration, not code output. It covers access controls, CLAUDE.md restrictions, hooks, MCP server trust, secrets handling, and CI/CD controls.
How long does a Claude Code security audit take?
An internal audit using this checklist takes one to two days. A professional external audit with documented findings and a remediation plan typically takes one to two weeks.
What are the most critical items in a Claude Code security audit?
.claudeignore covering all sensitive file paths, PreToolUse hooks for shell command validation, and removal of YOLO mode from CI/CD pipelines. These three address the highest-severity risks with the lowest remediation effort.
Do I need a Claude Code security audit if we are just using it internally?
Yes. Internal use carries the same prompt injection, secrets exposure, and overpermissioned access risks as external-facing deployments. The attack surface exists regardless of whether the outputs are customer-facing.
How often should I run a Claude Code security audit?
Full audit before first production deployment and quarterly thereafter. Targeted audits after any significant change: new MCP server, new CI/CD integration, CLAUDE.md update, or new engineer joining with access.
What is the difference between a Claude Code security audit and a code security review?
A code review evaluates vulnerabilities in code output. A Claude Code security audit evaluates the agent environment: what it can access, what it logs, what it can execute, and who controls its behavior.
Related articles