NCC Group maps security gaps across AI coding agents

NCC Group has published a white paper on AI coding agent security, examining self-hosted versions of Claude Code, Cursor and Codex.

Written by Alex Plaskett, a software vulnerability exploit developer at NCC Group, the study looks at how design choices, permission models and sandboxing affect resistance to attacks in coding agents developers run on their own machines.

Plaskett aims to draw a line between vendor-intended behaviour and flaws that amount to security vulnerabilities. It argues that this distinction has often been unclear because coding agents are designed to execute commands and interact directly with files, networks and developer tools.

This creates a difficult security model: some actions may be normal for an agent inside a trusted project, but the same actions could be a serious issue before workspace trust is granted or outside a sandbox.

Key findings

Protections vary widely across products, operating systems and configurations. Some tools do not have sandboxing enabled by default, while graphical and command-line versions of the same product may use different controls.

According to the research, that creates inconsistent security postures. The paper focuses on arbitrary code and command execution rather than data exfiltration, and reviews previously disclosed vulnerabilities alongside vendors' responses.

One recurring theme is that similar architectures can produce similar weaknesses. Vulnerabilities found in one agent often appeared in another because of comparable design decisions around command execution, file handling and approval flows.

The products reviewed all rely on a mix of permissions and sandboxing. Permissions govern which tools can be used and when a user must approve an action, while sandboxing is meant to stop commands from affecting files, networks or processes outside a defined boundary.

Implementation varies sharply, however. On macOS, Claude Code can use Seatbelt for sandboxing; on Linux, it can use bubblewrap. Native Windows support is more limited unless the tool is run under WSL2. Cursor and Codex also use different approaches depending on platform and product version.

Trust boundary

A major area of concern is workspace trust. The research treats any code execution before a user accepts a workspace as a security vulnerability, because the user has not yet approved the repository as trusted.

It cites previously patched issues in which code or commands could run before trust was established. It also points to cases where configuration files or binaries planted in a repository could alter behaviour before a user had approved access.

Once a workspace is trusted, the threat shifts. At that stage, attacks are more likely to involve direct or indirect prompt injection, sandbox escape, permission-prompt bypasses, sensitive file overwrites or unauthorised network access.

These risks are especially relevant because coding agents expose a large attack surface through the tools they can call, including shell execution, read and write functions, web access and, in some products, workflow or hook systems that can trigger external scripts.

Hooks receive particular attention because they often run without sandboxing. If an attacker can write a hooks file and then force an agent to use it, the result could be severe because the code may execute outside the agent's normal restrictions.

Shared patterns

The research also discusses "dangerous permission modes" that skip approval checks. In the products reviewed, these modes are documented by vendors, so the paper treats them as an accepted risk rather than a vulnerability.

By contrast, the study highlights cases where tools meant to be read-only could be manipulated to write files or execute commands. It says this class of issue has appeared repeatedly, particularly in command-validation logic for shell wrappers and path restrictions.

Network controls are another point of variation. Some products may permit access to a list of trusted hosts without prompting, while others ask users more often before making outside connections. The paper says those defaults can shape the practical risk of both direct and indirect prompt injection.

Plaskett also examines the limits of relying on models themselves to block harmful actions. Large language models may refuse obviously malicious instructions in some cases, the research says, but those refusals are inconsistent and should not be treated as a hard security boundary.

That leaves the surrounding software, or harness, as the main line of defence. The paper argues that developers and vendors should assume a model may attempt a dangerous action and use operating system controls, file protections and approval mechanisms to contain the result.

"One thing that was made clear by this research was that vulnerabilities which occurred in one agent were often also introduced into another agent's implementation due to the similar design choices being made," Plaskett said.