A developer clones an unfamiliar repository, asks an AI coding agent to set it up, and sees an approval box for a harmless-looking project file. The agent may understand more than the dialog shows. If that file is a symbolic link, the write can land outside the workspace: a shell startup file, an SSH authorization file, or another sensitive target.

AI coding agent workflow inside a sandbox with protected secrets outside the boundary

That is the uncomfortable lesson from GhostApproval, the July 8 research published by Wiz. On the same day, AI Now Institute published Friendly Fire, a proof-of-concept that turns defensive use of Claude Code CLI and OpenAI Codex CLI against the person running the review. Taken together, the two disclosures make a simple point: AI coding tools are no longer just smarter autocomplete. In many teams they are local automation runtimes with access to files, shells, package managers, network calls, credentials and review decisions.

That does not make them unusable. It does make the old trust model too weak. If a tool can read untrusted repository text, execute steps, edit files and ask a human to approve a partly summarized action, it belongs in the same risk category as a CI runner, a build agent or a privileged IDE extension. It needs boundaries, logs and policy. Vibes are not a control.

What changed: assistants became runtimes

The first generation of coding assistants mostly completed lines. Modern agents do much more. They traverse a repository, open files, infer setup steps, edit code, run tests, install dependencies, call external tools and sometimes operate in modes that reduce or remove per-action approval. That is the feature. It is also the attack surface.

A normal developer machine is full of valuable things: SSH keys, cloud credentials, npm and PyPI tokens, internal repositories, browser sessions, VPN access, shell configuration, package caches and history files. A coding agent that can write files and run commands on that machine is not merely suggesting code. It is operating inside a sensitive environment.

Security teams already know how to think about this in other places. CI runners get isolated. Production deployers get scoped credentials. Build systems get network rules. Security scanners running untrusted code should be sandboxed. AI coding agents need the same treatment, because they are now doing the same kind of work from a developer workstation.

GhostApproval in plain English

Wiz named its finding GhostApproval because the human approval step can approve the wrong thing. The researchers say the pattern affected six AI coding assistants: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity and Windsurf.

The primitive is old Unix behavior: symbolic links. A symlink is a file path that points somewhere else. If a repository contains a file that looks like a local project config but actually points to a sensitive file outside the workspace, a tool that writes through the symlink writes to the real target.

Wiz describes the issue as two problems layered together. The first is symlink following, mapped to CWE-61. The second is UI misrepresentation of critical information, CWE-451. In several tested tools, the agent or runtime could resolve the true target, but the approval dialog shown to the developer did not make that target clear. The user believed they were approving a local project edit. The write could affect something outside the project.

The vendor status matters. Wiz reported that AWS, Cursor and Google fixed promptly. It listed Amazon Q Developer language server versions before 1.69.0 as affected and fixed in 1.69.0, with CVE-2026-12958. It listed Cursor versions before 3.0 as affected and fixed in 3.0, with CVE-2026-50549. Augment and Windsurf were described as in progress at disclosure. Anthropic rejected the report as outside its threat model, according to Wiz, while SecurityWeek reported that Anthropic said it had already added mitigations against such attacks before the Wiz report.

The exact table may change as vendors update. The class of bug will not disappear just because one table changes. Any agent approval UI that shows a friendly path while the runtime acts on a different canonical target is asking the user to approve a story, not an operation.

Friendly Fire: the dangerous review workflow

Friendly Fire attacks a different habit: asking an agent to assess untrusted code for security. That is exactly the sort of workflow many developers and AppSec teams want to automate.

AI Now says its proof-of-concept enables remote code execution in Anthropic Claude Code CLI, with listed Claude models, and OpenAI Codex CLI with GPT-5.5 when used to defensively assess open-source or third-party libraries. The attack does not require a malicious MCP server, plugin, hook or special configuration file, according to the brief. It uses prompt injections distributed through ordinary source files in the library being reviewed. In AI Now's framing, a defensive agent reads hostile text while trying to inspect hostile code, and then follows instructions that turn the review environment against itself.

The article should not publish a recipe for exploitation, and the research is presented as a proof-of-concept rather than evidence of broad exploitation in the wild. Still, the risk model is clear. If the agent reads untrusted text and then uses tools based on that context, the repository is not passive input. It is part of the control channel.

That matters for open source maintainers too. A project can become a carrier for instructions aimed not at human readers, but at AI reviewers, dependency auditors and code-search agents. The README is no longer just documentation. Comments, tests, config files and issue templates can become instructions to a model that has tools.

The trust problem is bigger than one exploit

The same week brought a political and enterprise trust layer. CNA reported that a Chinese industry regulator warned of a "security backdoor" risk in Anthropic's Claude Code, while Anthropic described the mechanism as an anti-abuse measure that checked timezone and proxy-related signals to block unsupported regions and problematic entities. The CNA report also said Alibaba told employees Claude Code would be banned from July 10 due to security concerns, citing people familiar with the matter.

That story is not the same as GhostApproval or Friendly Fire. It is about telemetry, regional access controls, abuse detection and government suspicion. But it belongs in the same management conversation: opaque local coding agents with network access and enterprise source code will be judged not only by productivity, but by what they observe, where they send data, how they enforce policy and how clearly vendors document those behaviors.

Developer forums show the same discomfort in a less formal way. A Hacker News thread about Claude Code's "Extended Thinking" output drew hundreds of comments before these July disclosures. The thread was not evidence of GhostApproval, but it showed a live argument over whether visible surfaces in AI tools are raw truth, summaries, product theater or something in between. That question becomes more serious when the visible surface is an approval prompt for a file write.

Adoption is ahead of governance

Dark Reading framed the business problem bluntly: AI coding security risks are now part of the productivity debate. The article cites GitLab's 2026 AI Accountability Report, saying 91% of organizations use two or more coding tools and 54% use three or more. It also cites SonarSource survey figures: 72% of developers who tried AI coding tools use them daily, and the average perceived productivity gain is 35%, while 96% do not trust AI-generated code to be functionally correct as-is and only 48% always check AI-generated code before committing.

Those numbers should be read as survey signals, not physics. But the direction is believable. Companies adopted multiple assistants before they built one coherent control plane for them. A developer may use one vendor in the IDE, another in the terminal, a third in pull requests and an unofficial helper for one-off tasks. Each tool may have a different policy model, approval UI, sandbox story and telemetry posture.

That is how shadow AI becomes shadow infrastructure. The organization thinks it approved a productivity tool. In practice it has deployed several local automation systems with file-system access and partial human supervision.

What teams should do now

Start with inventory. Which AI coding tools are allowed? Which versions? Which developers use terminal agents, IDE agents, hosted agents or browser tools? Which tools can run shell commands, edit files, open network connections, access MCP servers or read secrets? If nobody can answer, the first risk is not the agent. It is the lack of asset management.

Turn off auto-approve and auto-review for untrusted repositories. If the repo came from the internet, a candidate, a vendor, a customer, a bug bounty report or a suspicious dependency, assume the text inside it is hostile to the agent. Ask the model questions if you want, but do not let it execute setup steps on your normal workstation.

Use disposable workspaces. Containers, dev VMs, cloud workstations or locked-down sandboxes should be the default for unknown code. The environment should not contain personal SSH keys, production cloud credentials, long-lived package tokens or access to internal networks unless the task truly requires them.

Resolve paths before approval. This is mainly a vendor responsibility, but teams can still set expectations: approval prompts should show canonical paths, flag writes outside the workspace, block symlink escapes by default and record what actually happened. If the UI says one path and the kernel writes another, the approval record is not useful.

Limit network egress. Many setup and test workflows do need the network, but not always. Sandboxes should make outbound access explicit. A security-review agent that can read a hostile repository and freely call the internet is easier to turn into a data-exfiltration path.

Separate secrets. Developers should not run agentic tools in shells loaded with broad tokens. Use short-lived credentials, least-privilege tokens, local secret stores that require explicit access and secret scanning before commits. GitGuardian's research, as cited by Dark Reading, argues that assistant-heavy workflows can increase secret exposure. Whether a team accepts the exact percentages or not, the operational fix is the same: reduce what the agent can see.

Log agent actions. Keep a record of tool calls, commands, file writes, approvals, denials and network events. If an incident happens, a chat transcript is not enough. You need evidence that maps user intent, model output and runtime behavior.

What vendors need to prove

Vendors should treat this as an engineering problem, not a trust exercise. The bar is not "the user approved." The bar is "the user approved accurate information about the operation that actually happened."

That means canonical path display, workspace-boundary enforcement, symlink-safe writes, clear warnings for external targets, safe defaults for untrusted repositories, honest status on CVEs, versioned advisories and enterprise controls that can be centrally audited. If a product has auto-mode, the documentation should say exactly what it may do without approval and how to disable it at organization level.

Telemetry and abuse controls also need plain documentation. Developers can accept many forms of fraud prevention when they are visible and bounded. They are less forgiving when a local coding tool appears to inspect environment signals in ways that were not obvious to the people deploying it.

The research direction is moving fast. The aiAuthZ preprint argues for off-host, identity-bound authorization for AI tool calls, with policy the agent cannot read or modify. Another July preprint systematizes execution-security research for AI coding agents across sandboxing, access control, TOCTOU and MCP threats. A third examines invisible Unicode TAG-block payloads in MCP metadata and the gap between what a human approval view shows and what reaches the model. These are preprints, not settled standards, but they point to the same pressure: approvals and policies must move closer to the runtime boundary, not live only in the model conversation.

What not to overclaim

There is no need to pretend every AI coding agent is malware. GhostApproval and Friendly Fire are research disclosures. The public material does not prove mass exploitation in the wild. Vendors are patching, disputing, mitigating and hardening at different speeds. Teams can reduce much of the risk with familiar controls.

The bigger mistake would be treating these disclosures as quirky edge cases. They are examples of a class problem: the model reads attacker-controlled context, the runtime has real authority, and the human approval layer may be incomplete. That pattern will keep reappearing in different forms: symlinks, hidden metadata, poisoned build scripts, malicious test fixtures, hostile MCP descriptions, dependency setup instructions and carefully written comments aimed at models rather than humans.

AI coding is not going away. The teams that benefit from it will be the ones that stop pretending it is just autocomplete. Put it in a sandbox. Strip its credentials. Give it a narrow network. Make approvals truthful. Keep logs. Then let it help.