Claude Code Security: Secure Permissions, Secrets & MCP

Claude Code security essentials

Claude Code can assist with security reviews, but because it has powerful terminal, filesystem, and potentially network access, it must be treated as a privileged agent: review its suggested actions, restrict permissions and MCP servers, avoid exposing secrets or untrusted content, and use isolation plus human-reviewed security testing.
Review every consequential command or tool action before approval.
Use least-privilege permissions and explicit allowlists; block sensitive paths and high-risk operations.
Run Claude Code in a sandbox, container, VM, or otherwise isolated development environment where appropriate.
Use only trusted, explicitly governed MCP servers and avoid broad filesystem or network integrations.

Claude Code can assist with security reviews, but its terminal, filesystem, and potential network access make it a privileged agent: review its actions, restrict permissions and MCP servers, protect secrets and untrusted content, and use isolation plus human-reviewed testing.

Claude Code security is defense in depth—not an automatic guarantee that an application, repository, or development environment is secure. Use the current official Claude Code documentation for version-specific settings, commands, and controls.

Claude Code security essentials

Review every consequential command, file edit, tool action, and external-access request before approval.
Apply least privilege with explicit allow, ask, and deny decisions for commands and directory access.
Run the agent in a sandbox, container, virtual machine, or otherwise isolated environment where appropriate.
Keep API keys, credentials, .env files, and sensitive customer or production data outside its accessible workspace.
Use trusted, explicitly governed MCP servers, Skills, plugins, and hooks alongside human review and conventional security testing.

What Claude Code Security means

The term Claude Code Security covers two related subjects:

Claude Code’s broader security posture: how safely a terminal-based coding agent handles commands, files, dependencies, APIs, configuration, credentials, and integrations.
Security-review functionality: the agent’s ability to analyze code changes and identify potential security issues.

Claude Code’s broader security posture

Claude Code’s effective security boundary is defined by the permissions, workspace, tools, integrations, and data available to it. A narrowly scoped development task can become a broader risk if the agent can reach unrelated repositories, credentials, services, or production resources.

Security reviews and `/security-review`

The built-in /security-review workflow can analyze pending changes or Git diffs and help identify issues or focus further investigation. It is an aid for finding problems and proposing changes, not proof that software is secure. A human must validate findings, assess their severity, review proposed changes, and confirm the final diff.

Use security reviews alongside human code review, vulnerability and dependency scanning, configuration testing, SAST, DAST, red teaming, and remediation verification. Do not apply AI-generated security patches automatically.

Claude Code attack surface and threat model

Terminal and shell access

Unreviewed commands can alter the environment, overwrite or delete files, install dependencies, change configuration, transmit data, or create persistence. Unvetted tool calls can contribute to command injection, data exfiltration, safeguard bypass, or other unintended actions.

Before approving a consequential command, check what it does, which directories it touches, whether it downloads or uploads data, and whether it changes security controls.

Filesystem, dependencies, APIs, and configuration

Repository access may expose source code, build files, environment files, private keys, local configuration, test data, and documentation. Dependencies and configuration files can also contain instructions or other content that influences the agent’s behavior.

Limit the workspace and connected services to what the task requires. Avoid access to unrelated repositories, deployment keys, production configuration, or broad external systems.

Prompt injection and untrusted content

Prompt injection is a concrete risk, not a theoretical one. Malicious instructions may appear in repository files, external content, dependency information, generated output, or other material the agent inspects. They may attempt to redirect the task, request secrets, trigger commands, or bypass safeguards. The same attack pattern is explained in more detail in Agent Goal Hijacking.

Treat repository and external content as untrusted data. A repository is not automatically safe because it is part of a development task, and useful-looking instructions do not justify unrestricted tool access.

Risk	Possible consequence	Primary control
Prompt injection	Unintended tool calls, disclosure, or unsafe changes	Separate instructions from untrusted content and review consequential actions
Shell and filesystem access	Command injection, destructive changes, or persistence	Least privilege, permission rules, and isolation
Secrets in the workspace	Exposure of keys, credentials, or sensitive source code	Protect secret paths and keep sensitive data outside the workspace where possible
MCP servers	Excessive permissions or unsafe external actions	Trusted-server allowlists and capability review
Extensions and hooks	Supply-chain or script-execution risk	Review, scan, control distribution, and disable unnecessary risky hooks
Excessive permissions	A small mistake becoming broad compromise	Narrow scopes, no root execution, and policy testing

Permissions and least privilege

Use allow, ask, and deny decisions

Allow only routine, understood actions that are necessary for the task.
Ask before high-impact commands, broad changes, external access, or operations requiring judgment.
Deny sensitive directories, dangerous operations, and capabilities the task does not need.

Restrict credentials, production configuration, unrelated repositories, deployment keys, and other sensitive paths. Avoid running Claude Code as root or with more operating-system privilege than necessary. Permission rules should favor narrow scopes over convenience.

Test the policy before production

Test the permission configuration in a representative non-production environment. Confirm that normal development tasks work while sensitive paths and risky commands remain protected. Verify current syntax, precedence, configuration locations, and platform behavior in the official documentation before deployment.

Sandboxing and isolation

Sandboxing reduces the impact of a malicious instruction, unsafe command, compromised dependency, or mistaken approval. Depending on the environment, useful layers include operating-system restrictions, an isolated container, a virtual machine, filesystem boundaries, and restricted network access.

Separate the agent from production credentials, unrelated repositories, host-level configuration, and sensitive personal or customer data. Make outbound access intentional rather than broadly available.

Isolation does not make actions trustworthy. The agent can still modify the isolated workspace, consume resources, or produce unsafe code. Continue reviewing actions, monitoring behavior, and validating changes.

Secrets and sensitive-data protection

Do not give Claude Code unrestricted access to API keys, private credentials, plaintext environment files, deployment tokens, unrelated source code, or sensitive customer data.

Keep secrets out of the working directory when practical.
Restrict access to secret paths.
Do not copy credentials into prompts, issues, logs, or generated files.
Use secrets-management controls instead of relying on plaintext environment files.
Separate development credentials from production credentials and limit their scope.
Review diffs and command output for accidental disclosure before committing or sharing them.

Vault, data-loss-prevention, retention, and redaction capabilities depend on the surrounding environment. Do not assume that Claude Code supplies these controls automatically.

MCP server security

Treat every MCP server as a privileged dependency. An MCP integration can expose additional tools, data sources, filesystem access, or external actions, expanding the agent’s effective permissions. For a deeper overview of the attack surface created by MCP integrations, see MCP Security Risks.

Use trusted-server allowlists

Maintain an explicit allowlist of reviewed and approved MCP servers. Document each server’s owner, purpose, tools, data access, network behavior, and required permissions. Remove integrations that are unused or cannot be justified.

Restrict dangerous capabilities

Be especially cautious with unrestricted filesystem access, broad network access, credential access, and integrations that can alter external systems. Prefer narrow capability scopes and additional approval for high-impact operations.

MCP configuration and enforcement mechanisms vary by Claude Code version and deployment. Verify current first-party documentation before relying on a particular setting or policy file.

Skills, plugins, and hooks

Skills, plugins, and hooks are software dependencies, not harmless convenience features. Review their source, purpose, permissions, update process, and distribution path before making them available.

Scan and distribute extensions through controlled processes where supported. Any extension that can execute code, read files, call tools, or influence agent behavior deserves scrutiny as a privileged development dependency.

Hooks can introduce additional script-execution paths around tool activity. Disable unnecessary or insufficiently trusted hooks where appropriate, but verify current product behavior and configuration first.

Security-guidance plugin and official resources

The GitHub security-guidance plugin is directly relevant to Claude Code security guidance and review workflows. Verify its current repository, ownership, maintenance status, installation process, commands, and capabilities before treating any behavior as official product functionality.

For product behavior, prioritize the current official Claude Code security documentation. Community and third-party guidance can supplement it, but should not be treated as authority for version-specific commands, settings, or enterprise controls.

Enterprise governance, monitoring, and audit

Organizations deploying Claude Code security controls across teams should centralize what can be centralized and make exceptions explicit. For a broader framework for organizing these controls across an enterprise, see AI Security Governance.

Assign ownership for identity, repositories, environments, permissions, extensions, and MCP approvals.
Define approved commands, directories, deployment contexts, MCP servers, Skills, plugins, and hooks.
Use access groups and capability restrictions appropriate to each team or environment.
Require an exception process for elevated access and review exceptions regularly.
Use managed or version-controlled configuration where supported to reduce policy drift.
Monitor file edits, command activity, outbound traffic, permission changes, and unusual behavior where the environment permits.
Retain appropriate interaction and activity evidence for investigation and audit.

Visibility differs between local development, containers, virtual machines, cloud sessions, and other deployment models. Do not assume that identity federation, SIEM export, immutable audit logs, telemetry, or a particular managed-settings path is available in every installation. Confirm current Claude Code documentation and platform capabilities.

A practical rollout sequence

Start with a limited, non-production pilot and define the repositories, data, tools, and integrations required.
Apply least-privilege permissions, isolation, secret protections, and trusted extension allowlists.
Test prompt-injection handling, permission boundaries, security-review procedures, and monitoring coverage.
Document approved exceptions and require security or platform review for elevated access.
Expand access only after controls work in the actual deployment environment, then continue reviewing policy drift.

Security-review workflow and validation

Define the task and the files, commands, data, and integrations it requires.
Apply the narrowest permissions and isolate the environment.
Review consequential commands and tool actions before approval.
Run /security-review against pending changes or Git diffs when appropriate.
Have a human validate each material finding, its severity, and the proposed remediation.
Run human code review, vulnerability and dependency scanning, configuration testing, and appropriate SAST or DAST.
For sensitive systems, add threat modeling, prompt-injection testing, red teaming, and remediation verification.
Recheck the final diff and continue monitoring after deployment.

A security review can improve coverage and shorten investigation time, but it does not guarantee complete vulnerability detection or safe automatic fixes. Treat its recommendations as inputs to an engineering decision.

If Claude Code exposes a secret or makes an unsafe change

If a review or audit identifies secret exposure, an unauthorized change, or an unsafe tool action, contain the affected environment and stop further access while the scope is assessed. Rotate exposed credentials through the relevant secrets-management process, preserve the available evidence, review recent commands and diffs, and remove or disable untrusted extensions or integrations when appropriate.

Restore only from a reviewed state, verify the remediation, and document the event. The exact response depends on the affected system and deployment model; involve security and platform owners for sensitive production environments.

Version and configuration caveat

Claude Code features and security controls can change. Before deployment, verify the current documentation for:

Permission-rule syntax, precedence, and platform-specific paths.
The current behavior and scope of /security-review.
Sandboxing and isolation options.
MCP allowlists and filesystem or network restrictions.
Skills, plugins, hooks, and extension-distribution controls.
Managed configuration, logging, monitoring, and enterprise availability.
Any CI/CD, repository, identity, or audit integration.

There is no universal safe configuration that can be copied across every version, platform, and deployment model. Build and test environment-specific controls rather than relying on unverified examples.

Final pre-deployment checklist

Permissions use least privilege with explicit allow, ask, and deny decisions.
Sensitive directories, production resources, and root-level access are restricted.
Commands and consequential tool actions require human review.
Execution occurs in an appropriate sandbox, container, virtual machine, or isolated environment.
API keys, credentials, .env files, and sensitive data are protected.
MCP servers, Skills, plugins, and hooks are reviewed and allowlisted where appropriate.
Developers understand prompt injection and treat repository and external content as untrusted.
/security-review findings are human-validated and checked against the final diff.
Security reviews are combined with code review, scanning, testing, and remediation verification.
Monitoring and audit coverage is understood for the actual deployment environment.

For sensitive production environments, involve security and platform owners before granting elevated access. Verify implementation details against the current official Claude Code documentation, and escalate when required controls cannot be tested or audited.