Guide

Claude Code Security: Hardening AI Coding Agents on Developer Machines

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

Claude Code security comes down to one decision: what the agent may do on your machine without asking. Claude Code and Cursor read files, change code and run shell commands with the privileges of your user account, and any text the agent reads can try to steer it somewhere else. You make them safe to use with the right approval mode, hard deny rules, a sandbox with a network allowlist, vetted MCP servers and a team policy that switches off the risky modes.

What a coding agent can do on your machine

A chat assistant suggests code; a coding agent ships it. It reads the repository, creates files, runs tests, installs packages and fetches web pages, all from a local process running as you. Whatever that process can reach, an instruction smuggled into the agent's context can potentially reach too. The fundamentals of AI agent security apply directly, except that the agent doesn't live on a server. It lives on a developer laptop next to SSH keys, cloud credentials and browser sessions.

This is how the vendors describe the default capabilities (documentation as of 28 October 2026):

Anthropic is explicit about one limitation: the working-directory boundary is a permission prompt, not isolation. A Bash command you approve can still write anywhere your user account can. Cursor adds that changes are written to disk immediately and, with auto-reload enabled, may execute before you have reviewed them.

Choosing approval modes and the sandbox

Claude Code permission modes

According to the permissions documentation, Claude Code has six modes. Which one a session starts in depends on how you launch it: recent versions start interactive terminal and VS Code sessions in auto when it is available, while claude -p and the Agent SDK start in default. Check the actual mode with /permissions instead of assuming it.

Per the documentation, auto mode blocks by default, among other things, downloading and executing code such as curl | bash, sending sensitive data to external endpoints, force pushes and production deploys. Anthropic states plainly that auto mode reduces prompts but does not guarantee safety, and that bypassPermissions offers no protection against prompt injection. Both can be switched off with permissions.disableAutoMode and permissions.disableBypassPermissionsMode, most effectively in managed settings that users cannot override.

Rules: deny before ask before allow

Rules are evaluated in a fixed order: deny, then ask, then allow. A deny at any level cannot be overridden by another level, not even from the command line. The documentation itself names two limits:

• Bash rules match command text. Bash(curl *) stops curl https://example.com but not /usr/bin/curl … or sh -c 'curl …'. Anthropic says such rules are not a security boundary around a program and calls patterns that try to constrain arguments "fragile".
• Read deny rules don't cover every process. Read(./.env) applies to the built-in file tools and recognised commands such as cat or sed, but not to a Python or Node script that opens the file itself.

For boundaries that don't depend on command text, Anthropic points to the sandbox.

The Claude Code sandbox

The sandbox isolates shell commands and their child processes at OS level, using Seatbelt on macOS and bubblewrap on Linux and WSL2. It is built on the open-source sandbox-runtime package. On native Windows, the documentation says commands run unsandboxed. The sandbox is off by default; turn it on with /sandbox or sandbox.enabled. What you need to know:

• Writes are limited to the working directory, a temp directory and approved additional directories. Settings, hooks, .mcp.json, shell startup files and Git hooks stay write-protected even there.
• Reads are allowed almost everywhere by default. The documentation spells out that this leaves ~/.ssh and ~/.aws/credentials readable unless you block them with denyRead.
• Network traffic goes through a local proxy with a domain allowlist that starts empty. Anthropic warns that broad entries such as github.com can open paths for data exfiltration, because by default the proxy does not inspect TLS.
• Exceptions: hooks, local MCP servers and the built-in file and web tools run outside the sandbox. If a command fails, Claude may ask to retry it unsandboxed. allowUnsandboxedCommands: false prevents that, and failIfUnavailable: true stops Claude Code from silently running without a sandbox when it can't start one.

Anthropic sums it up: effective isolation needs both a filesystem and a network boundary. Without the network boundary, a compromised agent could exfiltrate SSH keys; without the filesystem boundary, it could backdoor its way to more access.

Cursor security: run modes and sandboxing

Cursor governs execution through run modes. Auto-review, which Cursor recommends, runs allowlisted calls straight away, other shell commands in the sandbox where possible, and sends the rest to a classifier. Allowlist runs only approved actions without asking; Run Everything runs every call with no sandbox and no classifier. Cursor states that Auto-review is not a security boundary and that the classifier can make mistakes. The sandbox uses Seatbelt on macOS and Landlock plus seccomp on Linux. Network access starts blocked and is opened according to the network mode; .git/config, .git/hooks, .vscode and .cursorignore are protected. Team settings take precedence over individual and project configuration.

Prompt injection via repositories, issues, web pages and dependencies

The OWASP Top 10 for LLM Applications 2025 lists prompt injection as LLM01 and distinguishes direct from indirect injection: in the indirect case, the instructions come from external content such as websites or files that the model processes. OWASP notes that it is unclear whether fool-proof prevention exists. For a coding agent, almost everything is external content:

• Repository content: READMEs, comments, test fixtures, docs and agent instruction files in a third-party or forked project.
• Issues and pull requests: the agent is told to "fix the issue" and reads text that anyone with access to the tracker could have written.
• Web pages: documentation, forums and search results the agent fetches.
• Dependencies: source code and files of installed packages the agent opens while debugging.
• Tool output: responses from MCP servers, logs and error messages from third-party systems.

An injected instruction becomes dangerous through the privileges the agent can use next: running a command, creating a config file, sending data to an outside address. OWASP covers this as LLM06 Excessive Agency and recommends limiting extensions and permissions to what is necessary and requiring human approval for high-impact actions. That is exactly what approval modes, deny rules and the sandbox are for.

Claude Code adds a few more layers: network commands such as curl and wget are not auto-approved, WebFetch usually hands Claude the answer of a separate model call rather than the raw page, and in Manual mode commands that Claude Code can't fully analyse trigger a prompt. Anthropic also advises against piping untrusted content directly to Claude and recommends running scripts that touch external services in VMs. For how injection works through MCP tool descriptions specifically, see our article on MCP prompt injection and tool poisoning.

MCP servers, plugins and skills as attack surface

Every MCP server you connect extends what the agent can do and feeds text into its context. Anthropic encourages writing your own MCP servers or using servers from providers you trust, and states that it does not security-audit or manage any MCP server. In Claude Code, servers from a project's .mcp.json need their own approval. The documentation points out, however, that more servers can come from user settings, connectors and plugins, so reviewing .mcp.json doesn't show everything a session loads.

According to its agent security documentation, Cursor requires approval for every MCP connection and then for each tool call, unless the tool is on an allowlist. A publicly documented case shows that an approval can be tied to a file that changes later:

• CVE-2025-54136 (Cursor): according to NVD and the vendor's GitHub advisory, an attacker with write access to a shared repository could swap an already approved MCP configuration for an arbitrary command without triggering a new approval. Fixed in version 1.3.

Plugins and skills deserve the same care: in Claude Code, plugins can bring their own MCP servers and hooks, and skills can carry hooks and pre-approved tools. Treat them like any software you install. For hardening an MCP server itself, see our guide to securing MCP servers; for the risk classes at a glance, the OWASP MCP Top 10.

Hooks and configuration files in the repository

Hooks are shell commands that Claude Code runs automatically on certain events, with your environment and your privileges. They can live in .claude/settings.json inside the repository and get committed with it. That is useful for teams, and it is also why a third-party repository can run code on your machine once you start the agent in it.

Claude Code guards against this with the workspace trust dialog: in an untrusted folder, an interactive session asks first, and allow rules from the project only apply after you accept. Two details from the documentation matter:

• claude -p and the SDK never show the trust dialog. Hooks from project settings are used there, and servers in .mcp.json connect without asking. For repositories you didn't write, Anthropic recommends --setting-sources user, --bare or --settings '{"disableAllHooks": true}'. Setting the latter only in your user settings isn't enough, because project settings take precedence.
• Trusting a parent folder partly counts. A project's hooks are then already used, while its allow rules still wait for your own approval.

CVE-2026-40068 shows why this boundary is worth attacking: according to NVD and Anthropic's advisory, a crafted repository could use a Git worktree file to bypass the trust dialog and immediately execute hooks from .claude/settings.json. The attacker had to know or guess a path the victim had already trusted. Fixed in version 2.1.84. On the Cursor side, CVE-2025-54135 (advisory) describes a chain in which indirect prompt injection made the agent create a missing .cursor/mcp.json, because creating a new dotfile didn't require approval. Fixed in version 1.3.9.

Both vendors have responded. Claude Code never auto-approves writes to protected paths such as .git, .claude, .vscode, .mcp.json, shell startup files and .npmrc; the exception is essentially bypassPermissions. Cursor requires approval for configuration files. Per its documentation, Cursor's workspace trust is disabled by default and can be enabled with "security.workspace.trust.enabled": true; in restricted mode, AI features don't work.

Secrets in context: .env files, keys and tokens

OWASP lists sensitive information disclosure as LLM02. With coding agents, the risk has two steps: a secret enters the context, for example because the agent reads a .env file to understand an error. From there it can end up in logs, commits or test files, or leave the machine via an injected instruction.

• Claude Code: Read deny rules such as Read(./.env) or Read(./secrets/**) block the built-in tools. Blocking every process requires the sandbox with denyRead. A .claudeignore file has no effect, according to the docs.
• Cursor: .cursorignore blocks files for the agent and for @ mentions. Per the documentation, however, terminal and MCP tools can't be prevented from accessing them, and complete protection isn't guaranteed.
• Regardless of tool: the safest secret is one that doesn't sit in the project as a plaintext file. Use low-privilege development credentials, short-lived tokens and a secrets manager locally. Production keys don't belong on a developer machine that runs an agent.

How secrets end up in Git and in frontend bundles is covered in our vibe coding security checklist.

Supply chain: packages, extensions, agent configuration

OWASP lists the supply chain as LLM03. With a coding agent it has three layers:

• Packages the agent installs. Per the documentation, Claude Code's auto mode allows installing dependencies declared in lock files or manifests by default. Review new entries in those files like code. Package-manager install scripts run with the privileges of the command.
• Agent extensions: MCP servers, plugins, skills and editor extensions. Some of them run outside the sandbox.
• Configuration from the repository: hooks, .mcp.json and agent instructions. They arrive with every git pull and deserve the same review as a CI script.

Claude Code security for teams: policy and hardening checklist

Individual developers can configure a lot themselves. It only becomes binding through centrally distributed settings: Claude Code offers managed settings that user and project settings cannot override, and Cursor offers team settings that take precedence over individual configuration. A team policy for AI coding agents should cover at least the following:

A starting point for a project-wide .claude/settings.json, built from the examples in the documentation. Adjust paths and domains to your project:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org"]
    }
  }
}

Deny rules from the project apply immediately, even before the trust dialog, because they only restrict. For a policy nobody can loosen locally, put the same values into managed settings. For the organisational side of AI tool use, see our article on writing an AI acceptable use policy.

What a configuration file can't tell you

A clean settings file doesn't prove that it holds up in practice: whether an excludedCommands entry undermines the sandbox, whether an approved MCP server can do more than intended, whether a hook in the repository does something different after the next pull, or whether an instruction in an issue can talk the agent into leaking data. That only shows when someone tests the setup with an attacker's methods, within an agreed scope and on systems approved for testing.

Frequently asked questions

Further reading

• AI Agent Security: A Practical Overview
• MCP Server Security Risks and How to Fix Them
• MCP Prompt Injection and Tool Poisoning
• Service: AI pentesting and MCP security

Sources

• Claude Code Docs: Security
• Claude Code Docs: Configure permissions
• Claude Code Docs: Permission modes
• Claude Code Docs: Sandboxing
• Claude Code Docs: Hooks reference
• Anthropic: sandbox-runtime (GitHub)
• Cursor Docs: Agent Security
• Cursor Docs: Run Modes
• Cursor Docs: Ignore files
• Cursor: Security
• OWASP Top 10 for LLM Applications 2025
• NVD: CVE-2026-40068 and GHSA-q5hj-mxqh-vv77
• NVD: CVE-2025-54136 and GHSA-24mc-g4xr-4395
• NVD: CVE-2025-54135 and GHSA-4cxx-hrm3-49rm