Adversarial Defense

GhostApproval: When the Agent Knew and the User Didn't

Wiz Research disclosed GhostApproval, a pattern in six leading AI coding agents that allowed a malicious repository to steer an agent into writing outside the workspace while the approval dialog displayed only an innocent filename. The finding exposes a core weakness in the human-in-the-loop model: the approval step only functions as a control when the interface shows the developer accurate information about what will actually happen. Across Amazon Q Developer, Cursor, Google Antigravity, Claude Code, Augment, and Windsurf, that condition frequently did not hold.

Updated on July 14, 2026
GhostApproval: When the Agent Knew and the User Didn't

Every AI coding assistant runs on the same bargain. The agent proposes a change, a confirmation dialog appears, and the developer approves it before anything touches the disk. That dialog carries the entire weight of the human-in-the-loop safety model, because once the developer clicks approve, the agent writes what it planned to write. The whole arrangement depends on the dialog describing the change accurately.

On July 8, 2026, the security firm Wiz published research showing that the dialog often does not. Wiz documented a pattern it named GhostApproval across six of the most widely used coding agents: Amazon Q Developer, Augment, Anthropic's Claude Code, Cursor, Google Antigravity, and Windsurf. In each tool, a booby-trapped repository could steer the agent into writing outside the project folder, in several cases straight into files that hand an attacker control of the machine. A developer could trigger the whole sequence by cloning a repository and asking the agent to set it up.

The mechanics behind it are decades old, which is part of what makes the finding uncomfortable. A human-in-the-loop control only governs anything when the loop shows the human accurate information, and across these six agents the loop showed the wrong file. The approval was real, and the thing approved was a fiction.

What Actually Happened

The attack combines two well-worn weaknesses. The first is symlink following, catalogued as CWE-61, a Unix problem that goes back decades, where a file that looks local actually points somewhere else and a program that fails to resolve the real path writes to the wrong place. The second is CWE-451, the misrepresentation of critical information in a user interface, which here means the approval dialog displays a harmless filename while the real target sits outside the workspace.

The proof of concept is short. An attacker plants a file named something like project_settings.json that is really a symbolic link to a sensitive target such as the developer's SSH authorized_keys file, then adds a README instructing the agent to update that file. When the victim clones the repository and asks the agent to follow the setup instructions, the agent writes the attacker's SSH key into authorized_keys and grants password-free access to the machine.

Tool

Vendor

Severity

CVE

Status

Amazon Q Developer

AWS

High

CVE-2026-12958

Fixed (language server 1.69.0)

Augment

Augment Code

Critical

None assigned

Acknowledged, no fix at publication

Claude Code

Anthropic

Disputed

None assigned

Disputed; later versions warn on symlinks

Cursor

Cursor

Critical

CVE-2026-50549

Fixed (version 3.0)

Google Antigravity

Google

Critical

Pending

Fixed

Windsurf

Cognition

Critical

None assigned

Acknowledged June 23, no update at publication

  1. Amazon Q Developer

    Amazon Q Developer, the AWS coding assistant, wrote to the filesystem before it presented an undo option, which meant the change landed before the developer could stop it. Wiz rated the issue High, and AWS assigned it CVE-2026-12958. AWS fixed it in language server version 1.69.0 and described the update as automatic for most customers.

  2. Augment

    Augment, the agent built by Augment Code, followed symlinks for both reads and writes with no confirmation dialog at all. In one test it read a file outside the workspace and printed AWS credentials into the chat, and in another it wrote a payload after its own reasoning had identified the file as a shell configuration. Wiz rated it Critical, and at the time of publication Augment had acknowledged the report without shipping a fix.

  3. Claude Code

    Claude Code, Anthropic's command-line agent, produced the clearest example of the interface problem. Its internal reasoning identified the file as a symbolic link to a settings file, while the prompt it showed the developer asked only whether to edit project_settings.json. Anthropic first classified the report as outside its threat model and closed the ticket as informative, on the reasoning that the developer had trusted the directory and approved the prompt. The company later told Wiz that a symlink warning had shipped in version 2.1.32 on February 5, 2026, nine days before the report arrived, as part of internal hardening, and that the decline-to-comment had come from an automated triage reply.

  4. Cursor

    Cursor, the AI-native code editor, showed the symlink path in its diff view, and when the developer clicked accept, the backend followed the link and wrote to the resolved target. Wiz rated it Critical, and Cursor issued CVE-2026-50549 with a fix in version 3.0.

  5. Google Antigravity

    Google Antigravity, Google's agentic development environment, displayed the symlink path in its permission dialog rather than the real destination, which let a write reach an SSH key file disguised as project_settings.json. Wiz rated it Critical, and Google fixed the issue and is weighing whether to assign a CVE.

  6. Windsurf

    Windsurf, the editor from Cognition, presented the most direct version of the timing problem, writing file changes to disk before the accept and reject buttons even appeared. By the time the developer saw the prompt, the attacker's key was already in place. Wiz rated it Critical, and Windsurf acknowledged receipt on June 23 without providing a further update before publication.

Wiz reported the findings to the vendors between February and March 2026. Google and AWS deployed fixes in May, Cursor published its advisory and fix in early June, and the full disclosure went public on July 8.

How It Works

The technical core is a failure to resolve a path before acting on it. A symbolic link is a pointer, so a file named project_settings.json can quietly resolve to authorized_keys in the developer's home directory. An agent that reads or writes that file without first resolving it to its true location follows the pointer wherever it leads. Where a sandbox exists, it often checks the name the developer sees instead of the canonical path underneath, so the boundary never triggers.

The interface problem sits on top of that and does the real damage. In several of the tools, the agent's own reasoning correctly identified the destination, noting in plain text that the file was a link to a configuration or settings file. The prompt shown to the developer repeated only the innocent name from the repository. The agent held the accurate information and passed along the misleading version.

Two distinct failure modes ran through the six tools. In Amazon Q Developer and Windsurf, the write reached the disk before the developer had a chance to approve it, so the confirmation step worked as an undo button rather than a gate. In Cursor, Google Antigravity, and the disputed Claude Code case, the write waited for approval, but the approval rested on a filename that did not describe what would happen. Both paths end with the attacker's key in authorized_keys, and both begin with the tool trusting input it should have questioned.

The delivery method deserves attention on its own terms. The malicious instructions arrived inside a README, which is untrusted content that the agent read and then carried out as though the developer had issued the command. That is the same weakness the industry calls prompt injection, reaching the agent through a cloned repository instead of a chat box. The symlink supplied the misdirection, and the README supplied the order to act.

Governance Implications

A single vulnerability rarely stays inside one discipline, and GhostApproval touches all four of the control layers an enterprise uses to govern AI. Reading the failure through each layer shows why patching the symlink, on its own, leaves most of the exposure in place.

  • Security: Why No Tool Canonicalized the Path Before Writing

The security gap is the absence of two basic controls. The first is canonical path resolution, meaning the agent should resolve any file to its true location and check that location before it writes. The second is a workspace boundary enforced by the operating system or a container rather than by a dialog box, so that a write aimed outside the project folder fails regardless of what the interface displays. The malicious README belongs here too, because an agent that executes instructions from an untrusted repository has widened its attack surface to every file it can reach. Guardrails against prompt injection and controls that govern what an agent may do at runtime are the categories that address this directly.

  • Governance: Trusted Directory Plus Approved Prompt, and Where Vendor Responsibility Ends

The governance question is the one the vendors disagree about, and it deserves both sides stated fairly. Anthropic's position draws a clear line, that the developer trusted the directory when the session began and approved the file operation when prompted, so the responsibility for a malicious workspace rests with the developer. The competing view holds that consent means little when the information behind it is wrong, because a developer who approves an edit to project_settings.json has not meaningfully agreed to overwrite an SSH key. Most of the vendors, including AWS, Cursor, and Google, resolved the argument in practice by treating the behavior as a defect and fixing it. Whoever holds the better argument, an enterprise still has to decide who owns that boundary inside its own walls, because the tools will not settle it for them.

  • Compliance: An Audit Trail That Logged the Wrong File

For a regulated organization, the approval step often exists to satisfy change management, least privilege, or separation of duties. An approval built on a false path corrupts the evidence those requirements depend on, because the log records that the developer approved an edit to a project file while the real action planted a credential. That is a break in non-repudiation, the property that ties an action to the person who authorized it. Injecting an SSH key also lands on the access-control obligations that frameworks such as SOC 2 and ISO 27001 impose, so a single GhostApproval write can produce a security incident and a compliance finding from the same event.

  • Monitoring: Nothing Flagged a Coding Tool Writing to authorized_keys

The monitoring layer is where the failure hides most completely. No runtime observability in these tools raised an alarm when a coding assistant reached outside the workspace to modify authorized_keys or a shell startup file. The distance between what the model reasoned and what it displayed is invisible to ordinary logging, which records the approved action rather than the intended one. Detection today depends on endpoint file-integrity monitoring watching sensitive paths, and most development machines do not run that kind of monitoring against the processes their coding agents spawn. Tooling to catch the pattern is starting to appear, though it sits outside the coding tools themselves.

What's Still Missing

The fixes that shipped are real, and they close the specific hole Wiz walked through. They also leave the larger problem sitting in the open.

  • The patches resolve symlinks and warn on suspicious paths, yet an agent that follows written instructions from an untrusted repository remains unaddressed. GhostApproval used a symlink for misdirection, and the underlying habit of treating a README as a command is still there.

  • No standard defines what an approval dialog owes the person reading it, and no audit trail captures the gap between what an agent intended and what it showed. The model's knowledge and the developer's record remain two different accounts of the same moment.

  • The fixes arrived tool by tool and version by version, two of the six vendors had shipped nothing by the time Wiz published, and no single control watches agent file operations across a mixed fleet of these tools.

  • The disagreement over who owns the trust boundary is still unsettled, and an organization that treats it as resolved is the one most likely to be surprised by the next variation on the technique.

Our Take

AI Security Take

The practical starting point is to stop treating a cloned repository as safe just because the session began in a trusted directory. A developer who runs an agent against unfamiliar code is handing that agent instructions written by a stranger, and the agent will act on them. Scoping the agent's file access through operating-system sandboxing or a container puts a real boundary where the directory-trust prompt only implied one.

From there, the work is inventory and observation. Security teams should know which of the six tools run inside the organization, at which versions, and whether each one resolves symlinks and shows the true path before it writes. They should also watch sensitive files, starting with authorized_keys, shell startup files, and stored cloud credentials, for writes that originate from a developer tool or the processes it launches.

The durable fix runs through procurement. An organization buying or renewing a coding agent can make interface honesty a written requirement, asking each vendor whether its approval dialog shows the resolved path and whether the tool writes to disk before or after the developer approves. Those two questions separate the tools that treat approval as a real control from the ones that treat it as decoration, and they belong in the evaluation alongside price and model quality. The AI Security listings at GetAIGovernance.net, covering adversarial defense and runtime controls, are built to support that comparison, and the accountability question they raise carries straight into the AI Governance category.

Related Articles

ServiceNow Launches Autonomous Workforce and Integrates Moveworks Into Its AI Platform AI Governance Platforms

Feb 27, 2026

ServiceNow Launches Autonomous Workforce and Integrates Moveworks Into Its AI Platform

Read More
Arize vs Fiddler vs Arthur: Which AI Monitoring Platform Actually Fits Your Enterprise? Model Observability

Mar 1, 2026

Arize vs Fiddler vs Arthur: Which AI Monitoring Platform Actually Fits Your Enterprise?

Read More
ServiceNow Introduces the Enterprise Identity Control Plane Following Its Acquisition of Veza AI Access Control

Mar 2, 2026

ServiceNow Introduces the Enterprise Identity Control Plane Following Its Acquisition of Veza

Read More

Stay ahead of Industry Trends with our Newsletter

Get expert insights, regulatory updates, and best practices delivered to your inbox