Wiz’s Red Agent broke into a public Snowflake repository and pulled a live Jira token, no human involved.
That part’s real, and it’s genuinely impressive tradecraft. What didn’t hold up was Wiz’s claim about who wrote the vulnerability its agent exploited. The company initially pinned it on GitHub Copilot Autofix. GitHub says that’s not what happened.
By Monday evening, Wiz had quietly rewritten its own account. The correction, as is often the case, never gets the same reach as the original reporting.
It’s the latest sign that figuring out what’s AI-made, AI-reviewed, or simply unverifiable is becoming a security problem of its own.
On Monday Wiz posted research outlining how its autonomous Red Agent found and exploited a vulnerability in a public Snowflake repository in under five days, extracting a Jira access token with no human involved.
GitHub fired back, stating not so fast. It asserts that a human, not an autonomous red teaming tool, helped with the hack.
The two companies dispute the others’ claim. Buckle up, if your job description includes AppSec and DevSecOps. Expect more provenance fights like this one.
As autonomous tools like Red Agent and Mythos take on more coding, code review and vulnerability research, figuring out exactly what a human wrote, what an AI wrote and what an AI merely reviewed may become part of incident response itself. Disputes like this one are likely to become routine, and less civil, in the months and years ahead.
The Bug
Wiz’s Red Agent scanned Snowflake’s public GitHub organization on June 23 and flagged a problem in the snowflakedb/snowflake-connector-net repository, according to Wiz’s own account.
The flaw was tied to the repository’s GitHub Actions workflow, a small script GitHub runs automatically, without a person clicking anything, whenever something happens in the project. This one was set to trigger any time someone opened an “issue,” GitHub’s built-in system for reporting bugs or requesting changes, something any visitor to a public repository can do with no special permissions.
When the workflow triggered, it took whatever text someone had typed as the issue’s title and ran it as a command, instead of just reading it as a label. Nobody had told the workflow to check that text first.
“The issue allowed an unauthenticated user to execute arbitrary commands within a GitHub Actions runner by opening a GitHub issue with a specially crafted title,” wrote Gal Nagli, head of threat exposure at Wiz Research.
Red Agent’s first attempt failed. It read the error, adjusted, and broke through, pulling a Jira token with read access to Snowflake’s internal engineering, security and bug bounty tickets. The vulnerable code had been live since June 18, five days before Wiz found it. Wiz reported the bug the same day, through Snowflake’s HackerOne program. Snowflake patched it and rotated the token within 24 hours, and said audit logs showed no one but Wiz touched it.
The Twist
Within hours of posting its research on Monday, Wiz walked back its claim. Wiz’s blog post now carries a timestamped update:
August 17, 2026, 1957 UTC update: This blog has been updated to clarify that Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities. It’s unclear whether the code-change was AI-assisted.
Translation: Copilot has been downgraded from alleged culprit to disputed bystander. Wiz no longer says Copilot wrote the vulnerable code. Wiz says Copilot reviewed the change and missed it.
Meanwhile, GitHub says Copilot didn’t even do that.
The disagreement stands.
Delving into the scope of Wiz’s walk back, the plot thickens.
Wiz’s original headline was blunt: “Red Agent Exploits Snowflake Vuln Created by Copilot Autofix.” After the update, that became the much more careful “Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Through a Flaw in a GitHub Copilot–Assisted PR.”
The change was more than cosmetic. Wiz originally framed the flaw as a vulnerability created by Copilot Autofix. Essentially, one AI writing the bug and another AI later exploiting it.
The updated Wiz post explains the vulnerable code came from a human-attributed commit, while Copilot contributed elsewhere in the same pull request. It also says it is unclear whether the vulnerable change was AI-assisted at all.
Don’t Miss Forest for the Tree
The bug and fix are not in dispute. The kerfuffle is over who wrote the vulnerable code in the first place. That may sound like inside-baseball Git archaeology. It isn’t.
As AI agents move deeper into both software development and offensive security, provenance, establishing who or what actually wrote, reviewed, found or exploited something, is becoming a security problem of its own.
Call it chain of custody for the age of agents. No surprise that this is a problem arriving just as autonomous bug hunting starts producing legitimate results at scale.
The Signal Is Real. So Is the Slop
Google’s Big Sleep showed the upside in 2024 when it found an exploitable SQLite flaw that developers quickly fixed. But as AI-generated findings surge, HackerOne says triage teams increasingly have to separate legitimate discoveries from duplicates, speculation and machine-generated noise.
But not all of that automation produces gold.
Curl maintainer Daniel Stenberg coined the phrase himself. In a July 2025 post he titled “Death by a Thousand Slops,” Stenberg described being buried in AI-generated bug reports, long, confidently written, and almost entirely worthless. By his count, roughly 20% of submissions that year were AI slop, and the share of genuine vulnerabilities had fallen to about 5%, down from a historical rate above 15%. Curl ended its bug bounty program on January 31, 2026, after six and a half years, 87 confirmed vulnerabilities, and more than $100,000 paid out.
Bugcrowd has confronted the same problem by tightening its rules around AI-generated vulnerability reports. Its basic principle is refreshingly old-fashioned: researchers remain responsible for the accuracy of what they submit, regardless of whether AI helped produce it.
That principle gets considerably more interesting when the “researcher” is increasingly an autonomous system. For the company receiving the report, provenance quickly becomes an operational problem.
AppSec must reproduce the flaw. Bug-bounty teams must validate it. Engineering must determine who—or what—wrote the code. Legal and communications need evidence before assigning blame.
CISA now asks buyers to examine controls around AI-generated code and AI-powered development tools.
AI security tools may therefore need to produce more than findings. They may need to produce receipts: logs, tool calls, model versions, timestamps, code lineage and human approvals.
That matters even more when agents move from finding bugs to exploiting them. The U.K. AI Security Institute recently found agents taking unsanctioned actions against real people and organizations.
At that point, provenance means proving what the agent knew, decided and did.
“The AI found it” is no longer enough. Neither is “the AI wrote it.”
