GhostApproval: When an AI Coding Agent Shows the Wrong File in Its Approval Dialog

#ai #cybersecurity #devops #testing

An approval dialog is only useful when it tells the user what the system will actually do.

GhostApproval exposed a gap between those two things.

Wiz researchers tested six AI coding assistants against malicious repositories containing symbolic links. The visible path looked like a normal project file. The operating system resolved that path to a sensitive file outside the workspace.

The deeper failure was not just symlink handling. In at least one test, the agent's reasoning recognized the real destination while the approval interface still showed the harmless project path.

The model had the information. The user did not.

How the attack works

A malicious repository contains a path like this:

project_settings.json -> ~/.ssh/authorized_keys

The README tells the agent to add a deployment key to project_settings.json.

A developer clones the repository and asks the agent to follow the setup instructions.

The agent proposes an edit to project_settings.json. The developer sees a normal project path and approves it. The operating system follows the symbolic link, so the write reaches ~/.ssh/authorized_keys instead.

The attacker does not need the victim's private key to come back out of the repository. The attacker places their own public key in the malicious project and already holds the matching private key.

Adding the key alone does not guarantee remote access. SSH must also be running and reachable. But the same pattern can target shell startup files, cloud credentials, Git configuration, or agent configuration, which may create easier execution or disclosure paths.

Where the trust boundary broke

The security boundary was supposed to be the approval step.

That boundary failed in different ways across the products Wiz tested. Some tools followed the link without a useful confirmation. Windsurf reportedly wrote to disk before the Accept or Reject dialog appeared. Claude Code showed the clearest informed-consent problem: the agent knew the resolved destination, but the user-facing prompt did not show it.

This is why testing only for the presence of an approval dialog is too shallow.

The test this needed

The core test is simple.

Create a repository containing a harmless-looking symbolic link that resolves outside the workspace. Ask the agent to modify the visible path. Then verify four things:

The tool resolves the canonical destination before the operation.
The interface shows that canonical destination to the user.
A write outside the workspace requires separate approval.
Nothing reaches disk before approval.

The same test should be repeated for reads. A tool that follows a symbolic link to a credential file can expose secrets in the conversation even if it never modifies the machine.

How to test for this

A useful regression set should include:

a direct symbolic link to an existing sensitive file
a relative link that escapes through parent directories
a chain of multiple symbolic links
a link to a destination that does not yet exist
links to SSH, shell, Git, cloud, and agent configuration files
both read and write operations
rejection of the approval prompt
verification that audit logs record the resolved destination

The expected secure result depends on the product design. The operation may be blocked, or the user may receive a separate warning and explicit approval request. What should never happen is a misleading prompt or a filesystem mutation before approval.

OWASP and CWE mapping

LLM06: Excessive Agency is the primary AI-specific mapping. The agent had filesystem authority beyond the effective workspace boundary, and the approval layer did not constrain that authority accurately.

LLM01: Prompt Injection is the secondary mapping when repository documentation directs the agent to perform the action. The README becomes an untrusted instruction source.

The underlying software weakness is traditional link following: CWE-61, UNIX Symbolic Link Following. The approval-dialog failure also maps cleanly to CWE-451, User Interface Misrepresentation of Critical Information.

Prompt injection supplies the intent. Excessive agency supplies the authority. A decades-old symlink bug defeats the approval boundary.

The QA lesson

GhostApproval failed because the product tested the visible path, the approval flow, and the agent's authority as separate concerns. The attack crossed all three boundaries at once.

A path canonicalization test by itself is not enough. An approval-flow test by itself is not enough. A prompt-injection test by itself is not enough.

The failure appears when all three interact.

That is the test strategy QA teams need for agentic systems: test the combination, not only the components.

Original case study

Learn to test AI systems like this

This case is most closely related to my LLM Prompt Injection Cybersecurity Testing course, which covers indirect prompt injection, tool abuse, and unsafe agent workflows:

LLM Prompt Injection Cybersecurity Testing