On Monday, a security research firm claimed that an AI system had written a critical vulnerability into Snowflake’s code, and that another AI discovered and exploited it. Within hours, the first half of that claim unraveled. The second half still holds up. The story that remains is more nuanced and, in some ways, more alarming.

What the autonomous agent actually did

Wiz Research, the security arm of cloud security company Wiz, operates an autonomous tool called Red Agent. Under Snowflake’s HackerOne disclosure program, Red Agent scanned Snowflake’s GitHub organization and flagged a workflow file in the public repository for Snowflake’s .NET connector.

That workflow triggered whenever anyone opened an issue on the repository. It took the issue title and passed it directly into a shell script. Because the repository was public, any account on the internet could reach the workflow by opening an issue.

The underlying problem was a classic injection vulnerability, made worse by incorrect escaping. GitHub’s template engine substituted the issue title into the script before the sanitization commands ran. As a result, a single quote in the title could break out of the shell string and execute arbitrary commands.

A guard condition appeared to restrict access. It compared a pull request property against a bot name. But on issue events, the property does not exist. GitHub evaluates missing properties as an empty string, so the comparison always returned true. Every user, including anonymous ones, could pass through.

Then comes the part that matters. Red Agent’s first exploit attempt used a hash character to comment out the rest of the line. The runner threw a syntax error. The agent read the error, concluded that the comment had swallowed a closing bracket, rewrote the payload, and tried again. The callback arrived within seconds. No human touched a keyboard.

The token that Red Agent extracted granted read access across Snowflake’s engineering, security compliance, and bug bounty projects. That token was a Jira integration credential, and it gave the agent a foothold into systems that should have been far more protected.

Snowflake patched the same day

Wiz reported the vulnerability on 23 June. Snowflake patched it that same day, restoring the safe pattern in the workflow file. The company rotated the Jira token on 24 June. According to Snowflake, audit logs matched every anomalous query to Wiz’s own test addresses. Wiz says it deleted the data it had retrieved.

“The disclosure was received on June 23, and it was immediately investigated and remediated, and our investigation found no evidence of unauthorized access,” Snowflake said. The company emphasized that the weakness lived in repository automation, not in any released connector.

The co-author line and the squash artefact

Here is where the story went off the rails. The commit that carried the vulnerable code onto the main branch lists “Copilot Autofix powered by AI” among its co-authors. Wiz read that as proof that an AI had written the vulnerable code. Its own blog post said an AI autofix commit created the injection vector. Most news coverage followed that interpretation.

Then a security publication went back and examined the commits underneath the pull request. The Copilot co-authored commit changed a different file entirely. The unsafe refactor lived in a separate commit dated 25 August 2025, attributed to a named Snowflake engineer. Squashing, a common Git practice, folds every commit in a pull request into a single entry. The co-author line came along for the ride. It records participation in the pull request, not authorship of the lines that introduced the vulnerability.

In other words, the visible commit history confused the record. The AI-assisted commit existed, but it was not the one that broke the code. The vulnerability was introduced by a human engineer, and the AI tool was merely part of the same pull request.

GitHub’s response

GitHub, which owns both GitHub and Copilot, ran an internal review and rejected Wiz’s framing. The company said a human wrote the contributions that led to the vulnerability, and that Copilot Autofix neither reviewed nor contributed to them. That is a direct contradiction of Wiz’s initial claim.

Wiz softened its own post later the same evening. An update timestamped 19:57 UTC clarified that Copilot was a co-author that checked the merged pull request and called it clear without noticing the vulnerability. Then it added the sentence that undoes the headline: “It’s unclear whether the code-change was AI-assisted.”

A technology publication had already published its initial article. By midnight, it had changed its headline from an AI breaking the code to an AI failing to detect it, and appended a correction. The story’s editor ended the correction with a line that is rare for a major technology publication: “The publication regrets this error, has updated this story to reflect the revised information, and won’t be trusting Wiz for a very long time.”

Ownership and conflict of interest

Wiz is owned by Google. GitHub and Copilot are owned by Microsoft. That pairing does not automatically make the research wrong, but it does create a commercial and competitive backdrop. A Google-owned company published a claim that a Microsoft product wrote a critical security flaw, then withdrew the load-bearing part of that claim once independent reporters checked the commit history.

The retraction does not invalidate the underlying security research. But it does raise questions about how quickly and aggressively AI attribution claims are made when the tools involved come from rival corporate ecosystems. Readers, and editors, should treat such claims with extra scrutiny.

What survives the correction

Strip out the disputed half and a genuine finding remains. An autonomous agent scanned a public repository, spotted a live injection vulnerability, wrote an exploit, hit an error, diagnosed the problem, corrected its own payload, and extracted working credentials. The vulnerability was live for five days. That was the entire window between the introduction of the flaw and Wiz’s report.

This is not a laboratory exercise. The agent operated against a real company, using a real disclosure program, and exfiltrated a real token. The same approach applied to a different target could yield far more damage.

Researchers are already tracking a curve. In July, security researchers jailbroke Copilot workflows in a way that allowed prompt injection attacks. Around the same time, a separate GitHub agent leaked private repositories from a well-known organization. Then AI-discovered vulnerabilities moved from theoretical to practical. Just a day before this Snowflake report, an agent built a working exploit for a macOS flaw in four hours.

Greg Brockman, a co-founder of OpenAI, conceded on Sunday that his company had underestimated its own models on exactly this kind of autonomous capability. The direction of travel is not in question. Autonomous agents are getting better at finding and exploiting vulnerabilities, which means defenders need to assume that every public repository is a potential target.

What remains unproven

Several parts of the story are still unestablished. There is no CVE for this issue, no CVSS score, and no entry in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. The weakness sat entirely in repository automation, so no connector release carried it, and no public evidence points to anyone other than Wiz exploiting it.

Snowflake has not published audit logs. Neither the Jira permissions nor the workflow run logs are public. Everything about the blast radius rests on what Snowflake and Wiz say they saw. That is not the same as independent verification, and the distinction matters when a headline can move markets and reputations.

One additional detail deserves attention. GitHub published guidance in July 2025 warning exactly against the pattern that later appeared in Snowflake’s workflow. That guidance was available a month before the vulnerable commit was created. Whether anyone at Snowflake saw it is unknown, but the timing underscores how easy it is for developers to make this specific mistake.

The question that still needs an answer

The useful question is not which AI tool should be blamed. It is whether GitHub’s AI-powered review looked at this change and passed it. Wiz says it did. GitHub says Copilot Autofix never reviewed the vulnerable code at all. Those two statements cannot both be true, and only one company holds the logs that would show the truth.

Until GitHub makes those logs public, or Wiz provides more evidence, the world is left with a compelling demonstration of autonomous agent capability and a messy attribution dispute. The security lesson is clear: public repositories are ripe targets, and AI agents can move from finding a bug to exploiting it with no human intervention. The corporate blame game, meanwhile, remains unresolved.

Source: TNW | Data-security News