An autonomous AI agent found a live vulnerability in one of Snowflake's public code repositories, wrote a working exploit for it, hit an error mid-attack, diagnosed the failure on its own, corrected its approach, and walked away with a working credential. No human touched any step of that sequence. Cloud security firm Wiz published the research on August 17, and the vulnerability had been sitting live and exploitable for exactly five days before Wiz's system, called Red Agent, found it.

What the Agent Actually Did

The flaw lived inside a GitHub Actions workflow in Snowflake's public snowflakedb/snowflake-connector-net repository. The automation was designed to automatically create a Jira ticket whenever someone opened an issue on the repo, and it did that by taking the issue's title and dropping it directly into a shell command. That is a textbook script injection setup: anyone who opened a GitHub issue with a specially crafted title could get arbitrary Bash commands executed on GitHub's own infrastructure, no authentication required.

Wiz Red Agent found this on its own, attempted an exploit, and initially failed, according to Wiz's own account, when a comment character in its first payload accidentally consumed part of the command syntax it needed intact. Rather than stopping, the agent diagnosed why the attempt failed and adjusted its approach. The second attempt worked. It triggered an out-of-band callback from the GitHub Actions runner and obtained a live Jira API token belonging to a Snowflake service account, one with read access to Jira projects covering engineering, security compliance, and bug bounty tracking. Gal Nagli, head of threat exposure at Wiz Research, put the significance plainly: "It was autonomously exploited and found by our AI. We didn't need to intervene, which means frontier models already can exploit supply chain risks by themselves."

The Disclosure Timeline, and What Snowflake Did About It

Wiz reported the vulnerability to Snowflake through HackerOne on June 23, 2026, under report number 3819931. Snowflake's response was fast: the company patched the vulnerable workflow the same day and rotated the exposed Jira token the following day, June 24. Snowflake also reviewed its audit logs and confirmed that Wiz was the only party who accessed the token during the five-day exposure window, and the company said in a public statement that it is working with Wiz to share the findings industry-wide. Wiz, for its part, said all data it accessed during the proof-of-concept testing was securely deleted afterward. As of this reporting, no CVE identifier, CVSS severity score, or entry in the U.S. government's Known Exploited Vulnerabilities catalog has been assigned to the flaw.

The Claim That Got Walked Back

Here is where the story gets more complicated, and more instructive, than the initial headlines suggested. Wiz's original blog post identified "Copilot Autofix powered by AI" as a co-author of the commit that introduced the vulnerable code, framing the incident as one AI system writing a flaw that a second AI system then found and exploited, an AI-versus-AI narrative that most outlets initially ran with unchanged. GitHub disputed that characterization directly, conducting its own internal review and stating that the vulnerable contribution was written by a human engineer, not Copilot, and that Copilot Autofix neither reviewed nor contributed to the lines that actually broke.

The Hacker News dug into the actual commit history to adjudicate the dispute, and the underlying git record supports GitHub's version more than Wiz's original framing. The commit that introduced the unsafe code was dated August 25, 2025, and GitHub attributes it to a named Snowflake engineer, not to Copilot. The confusion traces back to how GitHub squash-merges work: when a pull request with multiple commits gets squashed into one, every contributor across all of those commits, including an AI tool that reviewed a later, unrelated change to the same pull request, gets listed as a co-author on the final squashed commit. Copilot Autofix's participation in the pull request was real. Its authorship of the specific vulnerable lines was not. Wiz updated its own blog post on August 17 at 1957 UTC to clarify this distinction, acknowledging that Copilot was a co-author that reviewed the merged pull request and cleared it without noticing the critical vulnerability, rather than the tool that wrote the flaw in the first place.

Why the Correction Matters More Than the Original Claim

It would be easy to read this correction as deflating the story, but it actually sharpens the more important point rather than undermining it. Even in the corrected version, GitHub's own Advanced Security scanning, which uses Copilot Autofix to analyze code for vulnerabilities, reviewed the final version of the pull request containing the dangerous injection and cleared it as safe. An automated AI review system missed a critical, remotely exploitable flaw that a different autonomous AI system found and weaponized within days of going live. Whether Copilot wrote the original bug or simply failed to catch it during review, the outcome for defenders is functionally identical: a tool marketed as making code safer let a serious vulnerability through, and it took a separate offensive AI agent, working without any human direction, to actually demonstrate the danger.

This dispute and correction is also worth holding up as a model for how AI security incidents should be reported and covered. When Z.ai's GLM-5.3 found a serious vulnerability in Cursor within hours of its own release last week, that finding rested entirely on the company's own account with no independent confirmation available yet. The Snowflake incident shows what happens when outside reporters and the affected company actually dig into a vendor's initial claim rather than repeating it uncritically: the headline story survives, but a specific factual error gets caught and corrected within roughly 24 hours, which is exactly how this kind of disclosure should work.

A Pattern That Keeps Repeating, With or Without the Correction

Strip away the who-wrote-what dispute, and the underlying trend is not new, only accelerating. It echoes the same dynamic that made JADEPUFFER, the first fully autonomous ransomware operation, possible earlier this year: an AI agent given a goal, encountering an obstacle, and finding its own way around it without a human directing each individual step. It also mirrors the pattern behind an unreleased Claude model breaking a NIST post-quantum encryption candidate earlier this month, where AI-driven security research surfaced a flaw serious enough to force a formal standards withdrawal within a single day. Three separate incidents, three different labs, three different targets, and the same underlying capability showing up in each one: AI systems finding and exploiting real weaknesses in production software faster than the humans and automated tools responsible for catching them first.

Nagli's own closing warning is the part worth remembering longest after the who-wrote-the-bug dispute fades. Defenders, he said, cannot assume AI-generated or AI-reviewed code is safe simply because an automated system signed off on it, and the industry needs proactive, adversarial AI-driven vulnerability scanning of its own, not just AI-assisted development, to keep pace. Whether the next flaw like this one gets caught by a defender's autonomous agent first, or by an attacker's, increasingly looks like a matter of which side deploys the faster system, not which side has the more careful human reviewer.