Copilot Was on the PR. Wiz's Agent Walked Out With a Token

Copilot was on the PR. GitHub's scanners missed the flaw. Wiz's agent exploited it and reached a live token. What review independence takes.

A GitHub Actions workflow merged in June 2026 with every automated check green. Five days later, an agent pointed at the same code with a different job walked out with a live credential. In August 2026, Wiz published a writeup of its autonomous Red Agent finding and exploiting a script-injection flaw in a Snowflake GitHub Actions workflow, where an attacker-controlled issue title reached a shell. Wiz reported that GitHub Copilot was listed as a co-author on the pull request and checked the merged change without flagging it, and that GitHub Advanced Security code scanning ran over the vulnerable workflow without flagging the injection either. GitHub disputes that attribution. Wiz amended its post the same evening it published, saying it is unclear whether the vulnerable change was AI-assisted, and GitHub says a human wrote the contributions that led to the flaw and that Copilot neither reviewed nor contributed to them. The commit record backs that up: the Copilot co-authored commit changed a different file, and a squash carried the co-author line onto the merge. Nobody disputes the outcome. The flaw shipped, the scanners ran clean, and the agent that went looking for it got out with a credential.

Sources: Wiz: Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot, The Next Web: GitHub disputes Wiz's claim that Copilot Autofix wrote a Snowflake flaw

The end state was not a theoretical finding. The agent reached a live Jira API token that authenticated as a Snowflake address, carrying read access across engineering, security compliance, and bug bounty projects. Snowflake patched the workflow the same day Wiz reported it and rotated the token the next day, so the exposure window stayed short. The useful part of the finding is not the blast radius. It is that the review step never produced it. That is the difference between a static analyzer reporting a possible issue and an adversarial agent demonstrating the consequence, and a demonstrated consequence is the only kind of finding that survives a triage queue.

Why automated review missed the script injection

The automated passes missed it because neither one was independent of the change and neither could run anything. Copilot reviewed a diff in a pull request it was listed on, in a context where its task was to assess the change and report, and whether it had helped write the vulnerable lines is disputed. Advanced Security code scanning looked for patterns it recognizes. Neither was tasked with reaching a credential, and neither could execute anything to find out. The Red Agent came in as an attacker. It could run the workflow rather than only read it, and it was measured on whether it got out with something. The instinct here is to conclude that Copilot review is weak, and that reading is too convenient: the properties that let the flaw through belong to the setup, not to the model.

• Author and reviewer overlap: Wiz's initial reading was that the model reviewing the workflow had co-authored it, so the review inherited the assumptions that produced the flaw. That specific attribution is contested, and the failure mode it describes is still the one to test for, because nothing in a typical setup distinguishes the two roles.
• Read-only analysis: a reviewer that cannot execute cannot distinguish a theoretical injection path from a reachable one.
• Pattern matching: a scanner finds the shapes it already knows, and CI workflow injection through untrusted input is a shape that continues to slip past.
• Incentive: an agent asked whether a change looks acceptable is answering a different question than an agent asked to break it.

AI can review AI-written code, if the reviewer is independent

Wiz's Red Agent is itself an AI reviewing AI-written code, and it succeeded. Machine review works. The useful conclusion is narrower: independence and incentive determine review quality, and reviewer count and model sophistication do not. A second reviewer drawn from the same model family, given a cooperative prompt, and asked whether a change seems fine is decoration. It adds cost and a signature without adding a perspective.

In August 2026, Anthropic's Frontier Red Team documented the mechanism directly. Studying multi-agent systems, researchers documented failures from conformity, including 18 of 30 agents independently creating a git branch with the identical name, mvp-game-loop, with no coordination between them. A separate line of experiments on epistemic failure used hidden-profile tasks, where the correct answer requires combining information distributed across agents, and most models scored between 17 and 36 percent against solo ceilings near 100 percent. One model was the exception, reaching roughly 85 percent. Convergence is the common case, not a law. The researchers also expect agents in the wild to vary more than their test population did, since those agents will not all be Claudes. Still, agents that share a prior converge rather than diversify, which is the exact opposite of what you want from a review panel.

Sources: Anthropic Frontier Red Team: Patterns and problems in emerging multiagent systems

Why GitHub Actions workflows keep slipping through review

The flaw landed in a GitHub Actions workflow rather than in application code, and that location is predictable. Script injection here means an untrusted value, a branch name or an issue title or a pull request body, reaching an interpolated shell command and running as code. It is not prompt injection, and the two get conflated because both involve untrusted text entering a system that acts on it. Workflow files sit in a gap between the review habits teams have built. They are infrastructure, so application reviewers skim them. They are YAML, which reads as configuration even though these files execute shell with interpolated values. And because they change so rarely, whoever reviews one has probably not reviewed one recently. The credentials they carry then invert the usual relationship between how carefully a file gets read and how much damage it can do.

The base rate says Snowflake was not an unlucky draw. Datadog Security Labs reported in June 2026 that 38 percent of organizations have a GitHub Actions workflow vulnerable to script injection or a dangerous trigger, a figure drawn from its 2026 State of DevSecOps data that did not make the published report. Close to two organizations in five, in the one file type reviewers skim fastest. The Snowflake workflow was the case that had an autonomous agent pointed at it.

Sources: Datadog Security Labs: The case for GitHub Actions security after recent supply chain attacks

Add an agent to that gap and the pressure increases. Workflow syntax is exactly the kind of fiddly, well-documented, low-novelty task that teams hand to an assistant precisely because nobody wants to write it by hand. The output is usually correct, which builds the habit of approving it quickly. The failure mode is a value reaching a shell that nobody treated as untrusted. Some call that script injection and some call it command injection, and either way it is invisible at a glance and indistinguishable from the many similar-looking lines that are fine.

If you review one category of agent-authored change more carefully than the rest, make it the pipeline definitions. They are short, they are rare enough to review properly, and they carry the credentials.

The author does not approve their own work

Strip away the specifics and this incident is an instance of a rule that predates AI: the author does not approve their own work. Greptile puts the modern version bluntly, arguing that if agents are approving code, it would be absurd and perhaps non-compliant to have the agent that wrote the code also approve the code. Non-compliant is the operative word for anyone in a regulated environment. Separation of duties is not a preference in those settings, and a pipeline where one vendor writes, reviews, and self-approves has quietly collapsed a control that an auditor expects to see.

Sources: Greptile: There is an AI Code Review Bubble

The scale makes this urgent rather than academic. GitHub reported in May 2026 that Copilot code review had processed more than 60 million reviews with tenfold growth in under a year, and that more than one in five code reviews on GitHub involved an agent. Those are self-reported figures, and they describe a control surface that is already load-bearing on the largest code host. A structural weakness at that volume is not an edge case.

Sources: GitHub: agent pull requests are everywhere

Independence tests for your own setup

Run these against whatever review automation you have today. None of them require new tooling, and together they will tell you whether you have a review step or the appearance of one. A pass means you can name the mechanism that would have stopped this pipeline: a different author, a different framing, a different model, an execution attempt that actually ran. A fail is usually not a missing tool, it is a question you cannot answer.

• Does the reviewer share an author with the code? If the same system wrote and approved, you have no separation of duties regardless of how the steps are labeled.
• Is the reviewer adversarially framed? Read the actual prompt your pipeline sends. If it asks whether the change looks acceptable, that is the question you are getting answered.
• Can it execute, or only read? The Snowflake finding required reaching a credential, which a read-only reviewer cannot demonstrate. A read-only pass can tell you a path looks dangerous, and it cannot tell you the path is live.
• Do your reviewers share a model family? Anthropic's findings documented same-family agents converging on identical choices, so vary the model on the paths that carry credentials.
• Is anything rewarded for finding a problem? A pipeline where clean reports are the success metric will produce clean reports. If no gate, metric, or dashboard changes when a reviewer raises something, agreement is what you have paid for.
• Plant a known flaw and confirm the pipeline catches it. An unexercised review step is an assumption, not a control. Use the shape from this incident: an untrusted value that reaches a shell, in a file nobody expects to read closely.

Designing for independence rather than for reviewer count

TLM Forge starts from that thesis, and the Snowflake workflow is the failure mode it exists to catch. It separates authorship from review deliberately. A spec audit runs before code exists. Reviewers arrive with different framings instead of repeated passes from the same one, and a red-team gate attacks the change rather than signing it off. Adversarial review does not catch everything. A reviewer rewarded for agreement catches less, and a workflow that cleared review and then gave up a credential to an agent told to attack it is what that looks like in production.

If you take one action from this, do not add another reviewer. Change the framing and the incentive of the one you have, and confirm it did not write the code it is checking.

How far can you generalize from one finding?

This is one finding, published by a security vendor with a product in the space, and vendor writeups select for the cases that make the point. Greptile, quoted above, sells review tooling of its own. The attribution is contested too, and the author-equals-reviewer reading of this particular incident stays unproven. Wiz co-founder and CTO Ami Luttwak, walking the claim back, said clear attribution between humans and AI is becoming harder to establish, which is its own uncomfortable finding: teams increasingly cannot tell who wrote the line they are approving. One incident does not establish a rate, and nobody should conclude from it that Copilot review is generally ineffective. The failure is possible. That is what this establishes, along with its shape: a reviewer inheriting the author's assumptions, unable to execute, and rewarded for a clean report. Those three properties are checkable in your own pipeline this week, which beats a verdict on any particular vendor.

Sources: IT Pro: Wiz CTO speaks out amid confusion over Snowflake-GitHub Copilot flaw

Every control that gets cheap enough to apply everywhere eventually gets applied without anyone checking whether it still works. Review is at that point now. A review step that has never faced a flaw someone planted on purpose is an assumption wearing a control's job title, and a reviewer nobody can tell apart from the author is one reviewer with two invoices. The planted-flaw test is cheap. Skipping it is how a control becomes a formality.