For one evening this week, the internet had a perfect AI horror story: one AI wrote a security hole into a major data company's code, and another AI found it and broke in. "Slop pipeline," went the headlines. It's a great story. It's also only half true — and the half that survived is the more interesting one.

Here's what actually happened, and what didn't.

The part that's real: an AI agent did the break-in

Security firm Wiz has an autonomous offensive-security agent called Red Agent. Pointed at Snowflake's open-source .NET connector, it found a command-injection flaw in a GitHub Actions workflow — the automation that runs when someone opens an issue on the repo. The workflow dropped the issue's title straight into a shell script without properly escaping it, and a guard meant to block this failed on issue events. So a specially crafted issue title could run commands on GitHub's servers.

The detail worth pausing on is how the agent behaved. Its first exploit attempt failed with a syntax error. Rather than stall, Red Agent read the error, worked out that one of its own characters had swallowed a closing parenthesis, rewrote the payload, and succeeded on the second try. It then used the access to reach credentials for Snowflake's internal Jira — engineering, security-compliance and bug-bounty projects.

That is a notable thing: an AI agent ran an end-to-end offensive operation — find the flaw, write the exploit, debug its own failure, assess the blast radius — on a target whose code had passed GitHub's own Advanced Security scanning. Snowflake, to its credit, went from report to patch in a single day — though the flaw had sat exploitable in the repo for several days before Wiz found it — and says its logs show no access beyond Wiz's own test traffic. But the capability on display is the story.

The part that fell apart: "an AI wrote the bug"

The viral framing was that GitHub's Copilot Autofix — an AI tool that suggests security fixes — had authored the vulnerable code. That is the claim that did not hold.

GitHub ran an internal review and rejected it: a human wrote the contributions that led to the vulnerability, and Copilot Autofix neither reviewed nor contributed to them. The reason Copilot's name appeared at all is mundane and worth understanding, because it will happen again. When Git "squashes" a pull request — collapsing many commits into one — it can carry co-author metadata from everyone who touched the PR, whether or not they wrote the offending line. Copilot showed up as a co-author tag, not as the author of the flaw. The actual vulnerable commit traced back to a named human engineer.

To its credit, Wiz softened the claim the same evening, to a far more honest "it's unclear whether the code-change was AI-assisted." But the retraction, as always, travelled a fraction as far as the original.

Why the distinction matters

It would be easy to file this under "AI writes insecure code," and there is a real, separate debate to be had about AI coding assistants and security. But this particular incident is not evidence for it. Reading a co-author tag as proof of authorship is a technical mistake, and building an "AI caused this" narrative on top of it is exactly the kind of overclaim that makes it harder to see the real risks when they arrive.

And the real risk here is not hypothetical. An autonomous agent found and exploited a real flaw that automated defences missed, then reasoned its way past its own failed attempt. That is the capability defenders now have to plan around — and it cuts both ways, because the same kind of agent that Wiz pointed at its own client's code can be pointed at anyone's.

The honest headline isn't "AI wrote a bug and AI found it." It's narrower and sharper: an AI security agent is now good enough to do the finding, the exploiting and the debugging by itself — and the story about the other AI was a metadata artifact that unravelled by the end of the day. Keep the first half. Bin the second.