Summary Claude Code’s agentic capabilities (file access, command execution, external tool integration) introduce security risks that its built-in controls alone can’t fully address. Teams need layered defenses like least-privilege access, secrets management, and dependency scanning to close the gaps. What Is Claude Code and Why Does It Introduce a New Security Model? Claude Code is a coding assistant designed to work directly inside a developer’s existing workflow. It integrates with environments like the terminal, IDEs, desktop apps, web interfaces, and Slack, allowing developers to build, debug, and ship code without switching tools. It operates by letting users describe what they want to accomplish in natural language. From there, it handles tasks such as analyzing codebases, generating code, running tests, and preparing pull requests. This reduces the need to manually navigate files or orchestrate multiple tools. Claude Code also integrates with development workflows and tools. It can connect to platforms like GitHub or GitLab, work alongside existing test suites and build systems, and operate within common editors such as VS Code and JetBrains IDEs. Claude Code introduces new security considerations because it can directly interact with the developer environment and take actions on the user’s behalf. Unlike traditional IDE assistants that only suggest completions, Claude Code may read repositories, execute shell commands, modify files, and interact with connected tools. This creates a larger attack surface where mistakes, malicious prompts, compromised dependencies, or unsafe permissions can lead to data exposure, unauthorized code changes, or command execution on the local system. For many teams, the practical question is not just whether Claude Code has built-in protections, but whether a Claude Code security scan is enough to secure day-to-day usage. The short answer is ‘NO’: native controls, reviews, and scan-like checks help reduce risk, but secure adoption still depends on permissions, sandboxing, isolation, human oversight, and independent security validation across code, dependencies, secrets, and pipelines. This is part of a series of articles about AI in software development. How Claude Code’s Security Model Works Claude Code’s security model is built around permissions, scoped access, and sandboxing. It provides the following key controls: Approvals: Protect a developer’s environment by requiring approval before sensitive actions like editing files, running shell commands, accessing external services, or using connected tools. Managed settings: Teams can define allow and deny rules, protected paths, and managed settings so Claude Code only works within approved parts of a project. Sandboxing limits what commands can access at the filesystem or network level. Auto mode tries to reduce approval fatigue by automatically allowing lower-risk actions and escalating riskier ones. What do these controls protect against? Claude’s built in controls are useful against many common risks, including accidental file changes, unsafe command execution, unwanted network access, over-broad tool use, and some prompt-injection attempts. They are especially useful when Claude Code is operating inside a repository, preparing code changes, running tests, or interacting with systems like GitHub, GitLab, build tools, or MCP servers. What don’t they protect against? Claude Code cannot compensate for potentially disastrous risks including careless approval of dangerous actions, overly broad permissions, secrets exposed in the local environment, malicious dependencies, access granted through external tools, and unsafe use of flags like bypassPermissions. Claude’s protections reduce risk, but they are not a full replacement for least-privilege access, secret management, code review, CI checks, and running high-risk tasks in isolated environments. Claude’s own documentation describes auto mode as a middle ground, not a security guarantee, because automated classifiers can still misjudge whether an action is safe. Key Security Risks in Claude Code 1. Weak Approval and Permission Governance Claude Code’s safety model depends heavily on user approvals and configured policies. If approval flows are too permissive, inconsistent, or frequently bypassed, the system can perform risky actions without sufficient oversight. Features like auto mode or flags that skip permissions can reduce friction but also weaken control if used without clear boundaries. In team environments, inconsistent governance creates gaps. One developer may run with strict rules, while another allows broad access to files, shell commands, or external tools. This inconsistency increases the chance of unsafe actions, especially when combined with shared repositories or automated workflows that assume trusted behavior. 2. Prompt Injection Attacks Prompt injection is one of the most significant risks in AI coding assistants. Attackers can embed malicious instructions in files, web pages, or external tools that the assistant processes, causing it to override its intended behavior. These attacks can lead to unauthorized command execution, data leakage, or manipulation of code. Because AI systems cannot reliably distinguish trusted instructions from malicious ones, even indirect inputs (like a poisoned repository or document) can compromise the system. 3. Supply Chain Risks Claude Code frequently interacts with external dependencies, packages, and repositories. If the assistant suggests or installs compromised libraries, it can introduce malicious code into the development environment. For example, a dependency with a hidden script could exfiltrate credentials or modify system behavior. Additionally, malicious repositories or configuration files can trigger unintended actions when opened, effectively turning the development workflow into an attack vector. 4. Data Exfiltration AI assistants with access to codebases, credentials, and internal data can be manipulated into leaking sensitive information. Prompt injection or other vulnerabilities may cause the assistant to extract secrets (such as API keys or SSH credentials) and send them to attacker-controlled endpoints. Real-world research has demonstrated attack chains where sensitive data is collected and exfiltrated without user awareness. The risk increases when Claude Code has access to broad local context combined with network-enabled tools or external integrations. A compromised prompt, malicious repository, or unsafe MCP server could cause the assistant to gather sensitive files, source code, tokens, or internal documentation and transmit them externally through API calls, shell commands, or generated requests. 5. Command Execution Risks Claude Code can execute shell commands and modify systems as part of its workflow. If manipulated, through prompt injection, malicious configurations, or unsafe approvals, it may run harmful commands that compromise the local machine or environment. Vulnerabilities have shown that attackers can trigger remote code execution or execute hidden commands via malicious projects or configurations, leading to full system compromise. The danger is amplified when Claude Code operates in environments with elevated privileges or unrestricted shell access. Commands executed by the assistant may modify system files, install malicious dependencies, alter CI/CD configurations, or open persistence mechanisms on the local machine. Even seemingly harmless commands can become risky when chained together in automated workflows. This is why Anthropic recommends combining command approvals with sandboxing, least-privilege execution, isolated environments, and careful human review. 6. Sensitive Code or Context Exposure Claude Code relies on access to local context to be useful. This often includes source code, configuration files, environment variables, and sometimes credentials. If this context is broader than necessary, the assistant may surface or reuse sensitive information in outputs such as logs, generated code, or pull requests. This becomes a risk when working with proprietary codebases, embedded secrets, or regulated data. Exposure can also happen indirectly. For example, when summarizing a repository, debugging errors, or generating examples, the assistant may include snippets that contain tokens, internal endpoints, or private logic. If those outputs are shared externally (e.g., pasted into tickets, chats, or public repos), sensitive data can leak beyond its intended boundary. What Are Claude Code’s Built-In Security Features? Claude Code’s built-in security features are best understood as a layered control model. They help reduce risk through permissions, centralized policy, visibility, isolation, secure deployment options, and security review workflows. Together, these controls make Claude Code safer to operate, but they are still guardrails, not a complete security boundary. Permissions Model Claude Code uses a tiered, permission-based model. By default, read-only actions such as file reads and search do not require approval, while higher-risk actions such as shell commands and file edits require user approval. Permissions can be managed with allow, ask, and deny rules, and deny rules take precedence over ask and allow rules. Rules can be scoped to specific tools, commands, files, domains, MCP servers, or working directories, allowing teams to define exactly what Claude Code can and cannot do. Claude Code also supports permission modes such as default, acceptEdits, plan, auto, dontAsk, and bypassPermissions, with Anthropic warning that bypassPermissions should only be used in isolated environments such as containers or VMs. Managed Settings Managed settings let organizations enforce Claude Code policy centrally so individual developers cannot override security-critical controls. These settings can control which tools, commands, MCP servers, and network destinations Claude Code may access, and they take precedence over local developer configuration. Anthropic documents several delivery mechanisms, including: Server-managed settings from the Claude admin console macOS plist Windows registry policies Linux/WSL file-based settings using /etc/claude-code/managed-settings.json macOS file-based settings using /Library/Application Support/ClaudeCode/managed-settings.json Monitoring via OpenTelemetry Claude Code supports organization-wide usage and security visibility through OpenTelemetry. Teams can export metrics, events/logs, and optionally traces to their own observability backend to monitor usage, cost, token activity, tool activity, permission-mode changes, API errors, MCP server connections, hooks, and other events. Administrators can enable and configure telemetry through environment variables or managed settings, and Anthropic notes that managed telemetry environment variables have high precedence and cannot be overridden by users. Sandboxing and Isolation Claude Code supports sandboxing as a defense-in-depth layer alongside permissions. Permissions decide which tools, files, and domains Claude Code is allowed to use, while sandboxing provides OS-level enforcement for Bash commands and their child processes. Anthropic’s sandboxing mechanism offers both filesystem isolation and network isolation: Filesystem isolation limits which directories commands can access or modify. Network isolation limits connections to approved servers or domains. If Claude attempts to access something outside the sandbox, the user can be notified and asked whether to allow it. Devcontainers Claude Code can run inside development containers to provide a consistent and more isolated development environment across a team. In this setup, Claude Code, terminals, language servers, build tools, and commands run inside the container rather than directly on the host machine, while project edits still appear in the local repository. Devcontainers can also be used to apply organization policy, restrict network egress, and standardize tooling. Anthropic cautions that devcontainers are not a complete security boundary, especially if –dangerously-skip-permissions is used or host secrets such as SSH keys or cloud credentials are mounted into the container. Secure Deployment Options Claude Code can be deployed as a managed service through Anthropic, or through cloud providers such as Amazon Bedrock, Google Vertex AI, or Microsoft Foundry, depending on an organization’s authentication, billing, compliance, and infrastructure needs. Anthropic’s enterprise deployment guidance also supports corporate proxies, LLM gateways, centralized usage tracking, custom rate limits, budgets, and provider-specific controls such as IAM policies, audit logs, RBAC, and cloud cost tools. For higher-security deployments, Anthropic recommends applying standard secure-agent principles, including isolation, least privilege, defense in depth, network controls, credential separation, and hardened production architectures. Security Review Capability Claude Code includes a security review capability that helps teams evaluate pull requests for vulnerabilities, logic flaws, and risky changes before merge. In practice, this gives organizations a form of Claude Code security review inside developer workflows, where multiple agents can inspect code changes in the context of the broader repository and surface findings as inline comments or review output. This capability is useful for accelerating developer feedback, but it should be treated as an assistive review layer rather than a final security decision-maker. Teams still need human validation, secure coding standards, and independent testing to confirm that important risks have been addressed before release. Claude Code security review can improve speed and coverage, but it does not replace formal AppSec review processes, CI security checks, or broader SDLC governance. Related content: Read our guide to Claude AI security (coming soon) Limitations of Claude Code Security Features Claude Code provides meaningful native protections, but those controls do not independently guarantee secure development outcomes. They reduce risk around permissions, command execution, and workflow governance, yet they do not eliminate insecure code acceptance, dependency risk, secrets exposure, prompt manipulation, or broader SDLC gaps. For most organizations, Claude Code security should be treated as one layer in a broader security model, not as a complete solution on its own. Insecure Code Acceptance Claude Code can help generate, edit, and review code, but its output still needs human review. Anthropic describes Claude Code as an agentic tool that can read codebases, edit files, run commands, and automate development tasks, which means an incorrect suggestion can become a real code change if accepted without inspection. Claude Code’s permissions and review workflows reduce risk, but they do not guarantee that generated code is correct, secure, performant, or aligned with business logic. Developers should continue using normal safeguards such as code review, tests, static analysis, CI checks, and manual validation before merging or deploying changes. Dependency and Package Risk Claude Code may work with package managers, repositories, build tools, and project dependencies as part of normal development. Its permission system can require approval for shell commands and can allow or deny command patterns, but it does not make third-party packages safe by default. If a developer approves package installation, script execution, or repository setup commands, malicious or compromised dependencies can still run within whatever access the environment provides. Anthropic’s secure deployment guidance recommends defense in depth, including least privilege, network controls, and isolation, because agents can take unintended actions due to prompt injection or model error. Enterprise Policy Enforcement Gaps Claude Code supports managed settings that take precedence over local configuration, and Anthropic recommends them for organization-wide security and compliance policies. However, enforcement depends on actually deploying those settings correctly across the organization and ensuring users authenticate through the managed organization flow. Server-managed settings require eligible Team or Enterprise plans, supported Claude Code versions, and network access to Anthropic’s API; endpoint-managed settings depend on device-management or system-level configuration. Gaps can appear on unmanaged devices, outdated clients, personal accounts, or environments where developers run outside centrally managed policy. Secrets Exposure Caused by Workflow Misuse Claude Code’s usefulness comes from access to local project context, but that context can include sensitive files, credentials, logs, transcripts, or environment-specific configuration. Anthropic warns that devcontainers do not prevent exfiltration of anything accessible inside the container when run with –dangerously-skip-permissions, including Claude Code credentials stored in ~/.claude, and recommends avoiding mounted host secrets such as SSH keys or cloud credential files. Anthropic also documents controls to reduce prompt-history exposure, such as shortening transcript retention, setting CLAUDE_CODE_SKIP_PROMPT_HISTORY, using –no-session-persistence, or disabling persistence through the Agent SDK. Prompt Manipulation and Risky Command Execution Claude Code’s security model reduces command-execution risk through permissions, command approval, deny rules, sandboxing, and permission modes, but it cannot eliminate prompt manipulation. Anthropic’s secure deployment guidance explicitly notes that agents can take unintended actions because of prompt injection or model error, and recommends defense in depth. Risk increases when users approve commands they do not understand, allow broad command patterns, enable more permissive modes, or use bypassPermissions / –dangerously-skip-permissions. Anthropic states that bypassPermissions skips the permission layer and that it is intended only for isolated containers or VMs. Broader SDLC Security Needs Claude Code’s built-in controls are not a replacement for a secure software-development lifecycle. Anthropic documentation clarifies that permissions, sandboxing, managed policy, monitoring, and secure deployment are layers of protection, not a complete security program. Teams still need least-privilege access, secrets management, dependency scanning, secure CI/CD, branch protection, code review, audit logging, runtime monitoring, and isolated environments for risky work. Best Practices to Secure Claude Code In light of the above limitations, here are steps your team can take to reduce the risks inherent in deploying Claude Code. 1. Secure Development Environments Use isolated, containerized environments for AI-assisted development to limit exposure if something goes wrong. Sandboxed environments reduce the impact of any unintended command execution or data leakage. Disable unnecessary internet access and block unapproved outbound connections to prevent exfiltration. Run Claude Code in user-space with limited privileges and avoid running it as root or granting elevated system access by default. Where possible, segment environments based on sensitivity; for example, separate environments for internal tools versus public-facing applications. This limits the blast radius of potential compromise and keeps high-risk operations contained. 2. Access and Permission Management Apply the principle of least privilege when granting Claude Code access to files, repositories, and external systems. Only enable the minimum permissions necessary for specific tasks. Avoid persistent credentials or tokens with broad scopes; use short-lived, scoped tokens with automatic rotation where possible. Enforce strict permission checks and audit logs when Claude Code interacts with infrastructure. This helps detect misuse or unexpected behavior early and ensures sensitive operations are traceable. Integrate Claude Code with identity providers to apply consistent access policies across tools. 3. Code Review and Human Oversight Never deploy AI-generated code without human review. Treat AI suggestions as drafts, not final implementations. Integrate Claude Code into pull request workflows so that all generated or modified code passes through peer review and automated testing. Encourage developers to verify logic, validate external inputs, and assess the security implications of any changes made by the assistant. Review proposed patches critically, especially for complex or privileged code paths, and ensure fixes align with organizational security standards. 4. Secrets Management Ensure Claude Code does not have access to plaintext secrets, tokens, or credentials. Store secrets in secure vaults and access them through environment variables or secret injection tools that restrict visibility. Mask or redact sensitive values during logging or assistant interaction. Prevent AI from generating or hardcoding secrets in code. Use templates or secret references instead. If a secret is accidentally exposed, rotate it immediately and investigate the source of leakage to prevent recurrence. 5. Dependency and Package Security Limit Claude Code’s ability to auto-install or recommend external packages without validation. Use internal mirrors or allowlists to restrict dependency sources to trusted registries. Require manual approval for new packages or versions introduced by AI. Scan all dependencies for known vulnerabilities using tools like software composition analysis (SCA). Prefer stable, well-maintained libraries with active communities. Avoid obscure or unverified packages, even if suggested by the assistant, as they may pose supply chain risks. 6. Audit Permission Configurations Regularly Review Claude Code permission rules on a fixed schedule, not just during setup. Check allow, ask, and deny rules across tools, file paths, shell commands, and network domains. Look for overly broad patterns (e.g., wildcard paths, unrestricted shell access) and tighten them to the minimum required scope. Ensure that deny rules cover sensitive directories, credential stores, and production infrastructure. Compare local configurations with managed settings to ensure developers have not drifted from policy. Where possible, automate audits and flag changes to permission modes, especially transitions to auto, dontAsk, or bypassPermissions. 7. Govern Auto Mode and Approval Behavior Treat auto mode as a controlled optimization, not a default. Define which actions qualify as low risk (e.g., read-only operations, limited refactors) and ensure higher-risk actions (shell execution, network calls, file writes in protected paths) still require explicit approval. Set clear boundaries on when more permissive modes can be used, such as in isolated devcontainers or non-sensitive repositories. Prohibit bypassPermissions in shared or production-linked environments. Monitor approval patterns to detect fatigue – frequent blanket approvals are a signal to tighten rules or reduce noise in prompts. 8. Log and Monitor Usage at the Team Level Enable centralized logging of Claude Code activity using telemetry. Capture events such as tool usage, command execution, file edits, permission decisions, and external connections. This creates an audit trail for investigations and helps identify risky behavior. Analyze logs for anomalies: unexpected network access, repeated permission escalations, or unusual command patterns. Correlate activity with user identity to maintain accountability. Feed logs into existing SIEM or observability platforms so alerts and dashboards align with broader security monitoring. 9. Define Policies for Sensitive Repositories and Environments Classify repositories and environments by sensitivity (e.g., public, internal, regulated, production). Apply stricter controls to high-sensitivity areas: deny access to secrets, restrict network egress, and limit allowed commands and tools. Require stricter approval flows and disable permissive modes. For critical systems, run Claude Code only in isolated environments with no direct access to production credentials. Enforce additional safeguards such as mandatory code review, signed commits, and CI validation before changes are merged. Document these policies so developers understand where AI assistance is allowed and under what constraints. If your team relies on Claude Code for code generation, review, command execution, or broader workflow automation, native protections alone are unlikely to provide enough assurance. At that stage, the key question becomes how to extend Claude Code security with independent validation across code, dependencies, secrets, and policy enforcement. Checkmarx Developer Assist Add independent security validation to Claude Code workflows Start 30-day Free Trial Now How to Choose Claude Code Security Tools When choosing security tools for Claude Code, teams should look for solutions that fit naturally into developer workflows while adding controls that Claude Code does not provide on its own. A strong solution should help developers catch issues early, support security teams during review, and provide governance across code, dependencies, secrets, and AI-assisted actions. Developer workflow fit: Choose tools that work where developers already use Claude Code: the IDE, terminal, pull request, CI/CD pipeline, and source-control platform. The goal is to avoid pushing developers into a separate security workflow after the code is already written. Look for inline findings, contextual explanations, and fix suggestions that appear while code is being generated, edited, or reviewed. Coverage of Claude Code security scan: Claude Code security tooling should not focus only on source-code vulnerabilities. It should also cover open source packages, dependency risk, secrets, containers, infrastructure-as-code, and configuration files. A strong toolchain should combine SAST, SCA, secrets detection, IaC scanning, and container scanning so security issues introduced by AI-assisted coding are caught across the full development surface. Support for Claude Code security review workflows: The tool should support both developer-side prevention and security-team review. For developers, this means fast feedback, inline explanations, and suggested fixes. For security teams, it means integration with pull request review, triage workflows, severity labels, and evidence that findings were reviewed or remediated. Robust tools should help review AI-generated or AI-modified code before merge, not just after deployment. Policy enforcement: Choose tools that can enforce organizational security rules rather than only advise developers. Useful controls include blocking or flagging unsafe patterns, enforcing vulnerability thresholds, applying approved coding rules, restricting risky dependency usage, and aligning findings with team policies. Policy enforcement is especially important when Claude Code is used across many teams, because local developer judgment alone may be inconsistent. Visibility into risky actions / permissions: Security teams need visibility into what AI-assisted development is doing. Look for tools that provide audit trails, telemetry, dashboards, and event logs around scans, findings, remediation activity, policy decisions, and developer interactions. This visibility helps identify risky patterns such as repeated introduction of vulnerable code, frequent use of ignored findings, unsafe package additions, or attempts to bypass controls. Remediation and prioritization support: The best tools do more than detect issues; they help developers fix the right issues first. Look for contextual remediation guidance, explainable fixes, severity scoring, prioritization based on exploitability or business risk, and support for validating that proposed fixes do not break functionality. This is important because Claude Code can generate large volumes of changes quickly, and developers need help distinguishing critical vulnerabilities from low-priority noise. Related content: Read our guide to AI code security solutions (coming soon) Securing Claude Code with Checkmarx Developer Assist Agentic development systems like Claude Code require agentic AI-driven security tooling. Checkmarx Developer Assist is a standalone, agentic AI security assistant that lives in the IDE and fixes code as fast as developers write it. It continuously scans human and AI-generated code for issues across SAST, SCA (including malicious packages), IaC, containers, and secrets, then generates safe, explainable fixes in-line so vulnerabilities never reach the repository. Built for agentic development tools like Claude Code and AI-native IDEs like Cursor and Windsurf, as well as traditional IDEs like VS Code and JetBrains, Developer Assist brings Checkmarx One intelligence directly to developers, shrinking remediation from hours to minutes without slowing delivery. Key capabilities of Checkmarx Developer Assist: Secure AI-generated and human code in real time: Detect vulnerabilities, misconfigurations, hard-coded secrets, and malicious packages as code is written, before commit. Inline, agentic remediation: Use Checkmarx agentic AI to propose and apply validated code changes, not just suggestions, directly in the IDE. Shorter fix cycles and lower remediation cost: Cut pre-commit fix cycles from hours to minutes and reduce remediation costs per issue, helping teams avoid expensive downstream rework. Guardrails for AI coding assistants: Work alongside systems such as Claude Code, GitHub Copilot, Cursor, and Windsurf to provide security guardrails and safe refactoring for AI-generated changes. Frictionless rollout and adoption: Run locally in the IDE, send only minimal metadata (no source code), and be adopted independently of the full Checkmarx One platform as an easy on-ramp to agentic AppSec. Learn more about Checkmarx Developer Assist Conclusion Claude Code can be adopted securely, but not passively. Its built-in controls around permissions, sandboxing, managed settings, deployment, and security review provide meaningful guardrails, yet they do not eliminate the need for human oversight, secure configuration, and broader SDLC controls. Organizations that treat Claude Code as a powerful agentic development system – rather than just a coding assistant – will be better positioned to capture productivity gains while keeping security, compliance, and governance under control.
