Claude Code Enterprise Security Guide: CISO Controls

Claude Code enterprise security requires a different threat model than any other coding tool in your stack. Unlike autocomplete tools or chat-based assistants, Claude Code is a fully agentic system: it reads and writes files, executes shell commands, makes git commits, and connects to external services through MCP servers. When you deploy Claude Code across a development team, you are granting an AI agent production-adjacent access that can be redirected by malicious instructions embedded in the repositories, pull requests, or dependencies your engineers touch every day.

This guide gives security teams the technical controls needed to govern Claude Code deployments: the specific attack surfaces, documented CVEs, MCP governance requirements, CI/CD hardening steps, and a policy framework you can adapt for your organization.

Understanding Claude Code's Attack Surface

Before mapping controls to threats, security teams need an accurate picture of what Claude Code can actually do. Most developers see it as a fast coding assistant. From a security standpoint, it is an autonomous agent with an unusually broad set of capabilities:

Shell command execution. Claude Code can run arbitrary bash commands in the developer's environment. By default, each new command type requires user approval, but developers routinely allowlist common commands to avoid interruptions. Once allowlisted, those commands run without further approval. The platform also offers a "bypass permissions mode" that disables all permission checks, which Checkmarx and Anthropic both document as a high-risk setting for enterprise use.

File system access. Claude Code can read any file the developer's account can access, and write files within the working directory and its subdirectories. This means an agent session working on a backend service can read environment files, configuration files, and secrets stored anywhere in the developer's home directory.

Git operations. Claude Code can stage changes, create commits, and push to remote repositories. An agent session that has been manipulated through prompt injection can commit and push malicious code as a legitimate developer before any human review takes place.

MCP server connections. Developers can configure Model Context Protocol servers that give Claude Code access to databases, internal APIs, third-party services, and custom tools. Each connected MCP server extends the agent's blast radius. A single compromised MCP credential can give an attacker access to production data through the coding agent.

CLAUDE.md configuration. Claude Code reads a project-level CLAUDE.md file at startup as its behavioral configuration. This file is checked into the repository, which means any repository a developer opens with Claude Code can set the agent's behavior for that session. This is a direct vector for persistent instruction injection.

~/.claude/ settings and configuration. User-level and organization-level settings are stored in ~/.claude/settings.json. These files can be modified during a session through ConfigChange hooks if not restricted, and control everything from allowed commands to MCP server connections.

Documented Vulnerabilities and CVEs

Security teams evaluating Claude Code should be aware of the specific vulnerabilities discovered and patched in the past year.

CVE-2025-54794 and CVE-2025-54795 (InversePrompt)

Cymulate researcher Elad Beber disclosed two vulnerabilities in 2025, collectively called InversePrompt. The technique used the AI model itself to reverse-engineer its security restrictions.

CVE-2025-54794 exploited naive prefix-based path validation in Claude Code's directory containment system. The system checked whether a requested path began with the approved working directory prefix. An attacker could create a directory named similarly to the approved path (for example, /tmp/projectname_exfil) and manipulate the agent into writing files outside the intended scope. This was fixed in version v0.2.111.

CVE-2025-54795 (CVSS 8.7) is the more severe of the two. Despite Claude Code's whitelist-based command execution system, improper input sanitization allowed arbitrary shell commands to be injected through the echo command, which was whitelisted for automatic execution. The payload structure used sequences like echo "\"; ; echo \" to break out of the intended command context. This was fixed in version v1.0.20.

Required action: Verify that all developer workstations running Claude Code are on v1.0.20 or later. For organizations using managed Claude Code deployments, confirm the version enforcement mechanism in your managed settings configuration.

CI/CD CVEs: CVE-2026-35020, CVE-2026-35021, CVE-2026-35022

Three chained CVEs disclosed in April 2026 received a CVSS score of 9.4. The attack scenario: a crafted pull request title containing prompt injection instructions causes Claude Code, running in a GitHub Actions workflow, to exfiltrate the ANTHROPIC_API_KEY secret to an attacker-controlled endpoint before any trust verification occurs.

The three CVEs form a chain through the same root cause: the agent reads attacker-controlled input (PR title, PR description, or file content in the diff) and has concurrent access to environment secrets and shell execution in the CI/CD context. The combination is critical because CI/CD contexts typically have access to production credentials, deployment keys, and cloud provider tokens.

Required action: Apply the five-control hardening stack for any GitHub Actions workflow running Claude Code: (1) tool scope allowlists, (2) read-only GITHUB_TOKEN permissions, (3) OIDC-based secret routing instead of static secrets, (4) actor filtering to limit which users can trigger Claude Code workflows, and (5) subcommand loop caps to prevent unlimited sequential execution chains.

CLAUDE.md Injection

LayerX researchers demonstrated that a malicious CLAUDE.md file in a repository can bypass Claude Code's safety rules and execute SQL injection attacks, credential theft routines, and other multi-step attack sequences. The key insight from this research: when Claude Code receives a CLAUDE.md file with more than 50 embedded subcommand instructions, it stops performing per-command safety analysis and follows the entire sequence. This threshold creates a practical exploitation path.

An attacker who controls a repository (whether through a supply chain compromise, a malicious open source dependency, or social engineering) can embed a CLAUDE.md that looks like routine build configuration. When a developer opens that project, Claude Code may execute the embedded instructions, exfiltrating SSH private keys, AWS credentials, GitHub tokens, npm tokens, and environment secrets before the developer realizes anything unusual has happened.

In practice, this means the attack surface for Claude Code extends to every dependency and open source project that a developer opens with the tool. Supply chain risk and agentic AI risk are now directly connected.

Credential Exfiltration: Attack Paths and Controls

Credential exfiltration is the most immediate production risk from Claude Code deployments. Security teams have documented several specific attack paths.

ANTHROPIC_BASE_URL redirection. The ANTHROPIC_BASE_URL environment variable tells Claude Code where to send API requests. An attacker who can modify this variable (through a malicious .env file, a prompt injection that modifies shell configuration, or a compromised dependency) can redirect all API traffic to an attacker-controlled server. The full API key appears in plaintext in the Authorization header of every redirected request, and this occurs before the trust dialog appears.

MCP credential exposure. 48% of MCP servers document credential storage in insecure locations: plaintext JSON configuration files in the user's home directory, hardcoded values in server source code, or unencrypted .env files. When Claude Code connects to these servers, the credentials are readable by any process that can access the developer's home directory, and they are accessible to the agent itself during active sessions.

Shell history and log exposure. Commands that include API keys, passwords, or tokens as arguments are written to shell history files. Claude Code sessions that process sensitive values may also include those values in log output if verbose logging is enabled.

Controls:

• Use a centralized secrets vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for all credentials accessed by Claude Code sessions. Remove static API keys from environment files.
• Enforce 30-90 day rotation on all developer API keys.
• Block ANTHROPIC_BASE_URL modification through managed enterprise settings. Log any attempt to modify it.
• Require OIDC-based authentication for CI/CD credentials rather than static secrets in GitHub Actions secrets.
• Audit ~/.anthropic/ and MCP configuration files for plaintext credential storage as part of your developer workstation security baseline.

MCP Server Governance

MCP servers are the primary way Claude Code's capabilities extend into enterprise systems. The Center for Internet Security published its MCP Companion Guide in April 2026, applying CIS Controls v8.1 to MCP-based systems and formally recognizing MCP as a distinct security boundary requiring policy, oversight, and operational discipline.

For enterprise teams, the core governance requirement is that MCP server connections should go through the same vendor risk process as any other third-party software integration.

What Anthropic does and does not provide. Anthropic reviews MCP servers against listing criteria before adding them to the Anthropic Directory. However, Anthropic does not security-audit the source code of MCP servers or provide runtime security guarantees. The responsibility for evaluating MCP server security falls entirely on the deploying organization.

Enterprise MCP controls:

Approved server allowlist. Maintain a central registry of approved MCP servers. Block connections to unlisted servers through managed settings. Require security review before any new MCP server is approved for developer use, including source code review for servers that handle sensitive data.

Credential isolation. All MCP server credentials should be stored in a central key vault, not in individual developers' ~/.claude/ configuration files. Use machine identities or service accounts for MCP server authentication rather than developer personal credentials.

Least-privilege scoping. MCP server permissions should be scoped to the minimum required for the intended use. A database MCP server used for development should connect to a development replica, not a production database. Review MCP server permissions in the same way you would review service account permissions.

Audit logging. Log all MCP tool calls with timestamps, invoking user, server name, and action taken. Route these logs to your SIEM. Alert on tool calls that access production systems, external endpoints, or credentials outside business hours.

For a deeper treatment of MCP security architecture, see our MCP enterprise security guide.

CI/CD Pipeline Hardening

CI/CD is the highest-risk context for Claude Code deployment because automation pipelines combine agent execution with broad access to production credentials and deployment infrastructure. The April 2026 CVSS 9.4 CVEs make this concrete: an untrusted PR title is sufficient to trigger API key exfiltration in an unprotected Claude Code GitHub Actions workflow.

Five required controls for Claude Code in CI/CD:

1. GITHUB_TOKEN read-only by default. Set permissions: read-only at the workflow level and escalate only the specific permissions needed for each job. Claude Code workflows should not receive write permissions unless the specific task requires them, and write permissions should be scoped to the minimum necessary (for example, pull-requests: write rather than contents: write).

2. OIDC-based secret routing. Replace static secrets (API keys, cloud provider credentials) with OIDC authentication that generates short-lived, scoped tokens. This eliminates the credential exfiltration path: there is no static secret to exfiltrate if credentials are issued per-workflow-run and expire after the job completes.

3. Actor filtering. Restrict Claude Code workflow triggers to verified users and specific event types. Do not trigger Claude Code on pull_request events from external forks without additional controls. Use pull_request_target with explicit actor allowlisting for workflows that need to run on external PRs.

4. Subcommand loop caps. Set explicit limits on the number of sequential commands Claude Code can execute in a single CI/CD run. This directly addresses the CLAUDE.md injection vector where long sequences bypass safety analysis.

5. Network egress restrictions. Claude Code operates without network restrictions by default in CI/CD contexts. Use Harden-Runner or equivalent tooling to log and restrict egress to an approved list of endpoints. This prevents data exfiltration to attacker-controlled servers even if prompt injection succeeds.

For additional context on LLM security testing in CI/CD environments, see our LLM security testing guide for CI/CD pipelines.

CLAUDE.md and Settings File Security

CLAUDE.md is both Claude Code's most useful configuration mechanism and its most significant persistent injection vector. Every organization deploying Claude Code at scale needs a CLAUDE.md governance policy.

Project-level CLAUDE.md controls:

• Require security review for CLAUDE.md files in all repositories before they are opened with Claude Code. Include CLAUDE.md review in your code review checklist.
• Treat CLAUDE.md modifications as high-sensitivity changes in your git workflow. Require additional approval for CLAUDE.md changes in the same way you would for CI/CD configuration files.
• For repositories that ingest open source dependencies, do not open dependency directories directly with Claude Code. Use sandboxed environments for exploring third-party code.
• Consider maintaining organization-standard CLAUDE.md templates that override or supplement project-level files for sensitive repositories.

Managed enterprise settings:

Anthropic provides managed settings that organizations can deploy centrally to override or restrict developer-level configurations. Managed settings files are enforced at the organization level and take precedence over user-level settings. Key settings for enterprise deployments include:

• Disabling bypass permissions mode organization-wide
• Restricting which MCP servers can be configured
• Enforcing sandbox mode for shell command execution
• Enabling OpenTelemetry telemetry export to your SIEM
• Blocking ConfigChange operations during active sessions to prevent settings modification through prompt injection

The ~/.claude/settings.json hierarchy (user settings, project settings, managed org settings) is documented in the Claude Code official documentation. Enterprise administrators should understand which settings can be overridden by developers and which are locked by managed policy.

Monitoring and Behavioral Detection

One of the most difficult aspects of securing Claude Code is that a session following injected instructions looks identical in logs to a session following legitimate ones. Traditional log analysis surfaces behavioral deviations in network patterns or API call volumes. Semantic instruction deviations, where the agent was told to do something different than intended, do not appear in those signals.

Controls for behavioral monitoring:

OpenTelemetry integration. Claude Code supports OpenTelemetry metrics export. Enable this and route telemetry to your SIEM alongside your other development environment signals. The data provides visibility into tool call frequency, command types approved, MCP server interactions, and session duration.

Behavioral baselines per repository. Establish normal ranges for tool call patterns in each repository context. A Claude Code session on a frontend TypeScript project that suddenly executes network requests and reads ~/.ssh/ files is anomalous. This kind of detection requires repository-level baselines, not just aggregate averages.

ConfigChange hooks. Claude Code supports hooks that fire when configuration is modified during a session. Use ConfigChange hooks to log and alert on any settings modification attempted during an active session. Any legitimate workflow that needs to modify settings should do so before starting a Claude Code session, not during one.

Git commit signing and review. All commits made by Claude Code sessions should be signed with developer identity and subject to the same code review requirements as any other commit. Do not exempt Claude Code commits from pull request review policies.

Session recording for sensitive repositories. For repositories with production access (infrastructure-as-code, deployment configurations, secrets management), consider enabling full session recording and require human review of session logs before changes are merged.

For broader guidance on LLM security monitoring in enterprise environments, see our LLM security monitoring guide.

Incident Response for Compromised Claude Code Sessions

When a Claude Code session is suspected to have been compromised through prompt injection, CLAUDE.md injection, or a CVE exploit, the response follows a different pattern than a traditional endpoint compromise.

Immediate triage steps:

Terminate the active Claude Code session immediately. Kill the process; do not continue interacting with a session you suspect has been redirected.

Rotate all credentials that were accessible in the environment during the session: ANTHROPIC_API_KEY, any API keys in environment variables, cloud provider credentials, SSH keys accessible from the working directory.

Review git log for any commits made during the compromised session. If any commits were pushed to remote, alert your security team before those changes are merged or deployed.

Review MCP server logs for tool calls made during the session timeframe. Alert on any database queries, file reads outside the working directory, or network requests to unexpected endpoints.

Check network egress logs for outbound connections to unknown endpoints during the session. This is the primary indicator of active data exfiltration.

Forensic artifacts to preserve:

• Claude Code session transcript (if available)
• Shell command history from the session
• MCP server access logs
• Network egress logs for the session timeframe
• Git log with commit hashes and timestamps
• OpenTelemetry export data for the session

Post-incident:

Treat a Claude Code prompt injection incident the same way you would treat a compromised developer workstation. The agent had the same access as the developer account. Assume that anything accessible in that environment may have been read, even if you cannot confirm exfiltration. This includes environment files, SSH key directories, cloud credential files, and browser-stored tokens.

For a comprehensive AI incident response framework, see our AI incident response playbook.

Claude Code Acceptable Use Policy Template

Every organization deploying Claude Code should have an explicit acceptable use policy that developers acknowledge before access is provisioned. The following categories should be addressed:

Approved use cases. Define which repositories, environments, and tasks Claude Code is approved for. Separate policies may apply to production repositories versus experimental projects.

Prohibited configurations. Explicitly prohibit: bypass permissions mode, MCP servers not on the approved list, disabling sandbox mode for shell execution, using Claude Code with cloud provider credentials in the environment without OIDC, and running Claude Code as a privileged system account.

Review requirements. All code changes suggested or committed by Claude Code must go through the same review process as manually written code. Document that Claude Code session output is not exempt from security review because it is AI-generated.

Credential hygiene. Developers should not start Claude Code sessions with production credentials in their environment. Development credentials must be scoped to development resources and rotated on the organization's standard schedule.

Incident reporting. Define the process for reporting suspected Claude Code session compromise: who to contact, what artifacts to preserve, and expected response time.

Version currency. Require all developers to run approved Claude Code versions. Given the frequency of security patches (CVE-2025-54794 and CVE-2025-54795 were patched in separate minor versions), version currency is a meaningful security control, not just a feature hygiene item.

For additional policy frameworks and governance templates, see our enterprise AI acceptable use policy guide.

Compliance Considerations

Anthropic holds SOC 2 Type 2 and ISO 27001 certifications, accessible through the Anthropic Trust Center. These certifications cover Anthropic's internal security program for the Claude API infrastructure.

However, compliance certification does not cover the security of your organization's Claude Code deployment. For enterprises operating in regulated environments, the following additional controls apply:

HIPAA / healthcare. Claude Code must not be used in environments where protected health information (PHI) is accessible in the working directory or environment variables. Medical record data should never appear in Claude Code prompts, file context, or MCP tool calls.

PCI DSS. Development environments containing payment card data must have Claude Code isolated from cardholder data scope. OIDC-based credentials and network segmentation are required. See NIST SP 800-218A for secure software development guidance applicable to AI-assisted development workflows.

SOC 2 / enterprise data handling. Customer data used in development contexts (even anonymized samples) should not be included in Claude Code sessions without explicit DPA coverage for AI processing. Review your Anthropic Enterprise Agreement data processing terms before using customer data in Claude Code contexts.

FedRAMP / government. Claude Code does not currently hold a FedRAMP authorization. Federal agencies and contractors with FedRAMP requirements should consult with their authorization officer before deploying Claude Code in regulated systems environments.

Conclusion

Claude Code enterprise security is not a single control or a settings checkbox. It requires understanding a genuinely new attack surface: an AI agent with shell access, git operations, MCP connectivity, and persistent configuration injection vectors across every repository your developers touch.

The documented CVEs from 2025 and 2026 confirm that this attack surface is actively being researched and exploited. Path restriction bypasses, command injection via whitelisted commands, and CI/CD credential exfiltration via PR titles are all documented, patched, and in some cases still being discovered.

The control framework is available: managed settings, sandboxing, OpenTelemetry monitoring, dev containers, OIDC-based CI/CD credentials, and MCP server allowlisting. The gap is implementation. Most organizations have deployed Claude Code for productivity without the governance layer that the tool's capabilities require.

If your organization is deploying or planning to deploy Claude Code at scale, a security assessment of your agentic coding deployment is the right starting point. BeyondScale's AI security team specializes in agentic system threat modeling and can evaluate your Claude Code deployment against the attack surfaces documented in this guide.

Book an AI Security Assessment to evaluate your Claude Code deployment, or start with a free automated scan to identify immediate exposure in your AI systems.

---

References:

• Anthropic Claude Code Security Documentation
• NIST SP 800-218A: Secure Software Development Framework for AI
• Checkmarx: Claude Code Security Top 6 Risks
• Cymulate InversePrompt Research (CVE-2025-54794 and CVE-2025-54795)
• CIS Controls v8.1 MCP Companion Guide, April 2026