On June 18, 2026, a change landed in Snowflake’s snowflake-connector-net repository that introduced a script injection flaw in a GitHub Actions workflow. Anyone could trigger it by opening a GitHub issue with a specially crafted title, and the flaw let an unauthenticated attacker run commands inside the CI runner. Five days later, Wiz’s autonomous red-team agent found it and used it to pull an internal Jira token. Snowflake fixed the hole the same day it was disclosed, rotated the credential, and confirmed through audit logs that Wiz was the only one who’d exploited it. As incidents go, that’s a clean one: found fast, fixed fast, no real damage.
The part that’s actually interesting happened a few weeks later, when Wiz published its writeup and said the vulnerable change had been co-authored by “Copilot Autofix powered by AI.” GitHub disputed that. Its internal review concluded the change was authored by a human and that Copilot never touched or reviewed it. Two companies, looking at the same commit, came away with different answers about whether an AI tool wrote a security bug.
The bug matters less than the argument about it
We’ve written before about AI agents deleting production databases and about coding tools that can be tricked mid-review. Those are stories about what AI gets wrong. This one is different, because the failure isn’t in the code, it’s in the paper trail. A serious vulnerability shipped into a widely used connector library, and afterward, two technically sophisticated organizations couldn’t agree on who or what put it there.
That should be a solvable question. Git tracks authorship. CI logs track what ran. If a commit went through an AI-assisted review or autofix step, that ought to be visible in the same record as everything else. The fact that it turned into a public he-said-she-said, playing out in security trade press instead of getting settled by pulling logs, tells you the provenance wasn’t being tracked cleanly enough to settle it. Whichever version is true, that gap is the finding.
Why the gap opens up
It happens because teams treat “AI reviewed it” and “AI touched it” as informal facts instead of recorded ones. A suggestion gets accepted, a fix gets auto-applied, a bot leaves a comment that gets merged without much scrutiny, and none of that is distinguished from a human typing the same diff. Six months later, when something breaks, you’re reconstructing intent from memory and commit messages instead of reading it off a record.
We see a version of this on nearly every codebase we’re brought in to work on that’s had heavy AI tool use. Not malicious, just casual. Nobody labeled which parts of a PR came from a suggestion versus a human decision, so nobody can tell you six months later why a particular check was written the way it was, or whether it was actually looked at by a person before merge. The tools accelerated the writing. They didn’t do anything to preserve the reasoning.
What actually holds up
The fix isn’t to distrust AI-assisted code more, or less. It’s to treat provenance as a requirement, not an afterthought. A few things we insist on:
Every AI-touched change gets flagged in the commit or PR, not just implied by tool defaults. If a fix came from an autofix bot, that’s in the commit trailer, not something you’d have to ask a vendor to confirm after the fact.
AI-authored and AI-reviewed are different claims, and we don’t conflate them. A tool suggesting a diff is not the same as a tool having actually reasoned about the security implications of that diff. Snowflake’s workflow apparently had a human merge a change that introduced a script injection bug, whether or not Copilot wrote the original text, and that human review is exactly where this should have been caught regardless of authorship.
CI and infrastructure changes get the same review bar as application code, arguably a higher one, because a bug in a GitHub Actions workflow runs with more privilege than most application bugs ever will. The Snowflake flaw wasn’t in a user-facing feature. It was in the plumbing that most teams review the least carefully.
This is the same discipline we bring to our AI-assisted engineering work: use the tools, because they’re genuinely faster for a lot of tasks, but keep a clear, queryable record of what a model touched versus what a person decided, and never let “the AI suggested it” substitute for review. If we can’t tell you who or what wrote a given line of your production code, we haven’t finished the job.
The ownership question underneath it
Strip away the security details and this is a story about code ownership. Not licensing, actual ownership: can you say, with confidence, where a piece of your codebase came from and who signed off on it. If the answer is “probably a human, but we’d have to check,” you don’t fully own that code, you’re renting confidence in it. That’s true whether the ambiguity comes from a contractor who left, a vendor tool with opaque defaults, or an autofix bot nobody configured carefully.
For a small connector library, that ambiguity is embarrassing. For a product you’re building a company on, it’s a liability you’re carrying without knowing the size of it. If you’re bringing on AI tooling for a serious build and want the speed without losing the paper trail, get in touch.