An AI wrote the vulnerability. Another AI found it five days later.
A Copilot Autofix pull request removed a shell-injection guard in a Snowflake repository. Five days later an autonomous agent found it, debugged its own failed exploit, and exfiltrated a Jira token.
Wiz published research on 17 August describing a script injection flaw in Snowflake's snowflake-connector-net repository. The technical details are ordinary. Where the bug came from is not.
The vulnerable code arrived in a pull request co-authored by Copilot Autofix powered by AI. It was found and exploited by Wiz Red Agent, an autonomous security agent. Five days separated the two events.
What the AI "fix" removed
The repository already had a safe pattern. A GitHub Actions workflow passed an untrusted issue title through an env: variable and built its JSON payload with jq --arg, the standard way to keep attacker-controlled text out of a shell.
PR #1218, merged on 18 June 2026, replaced that with direct template interpolation:
- env:
- ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...
+ run: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)
The sed escaping runs after GitHub expands the template. So a single quote in an issue title breaks out of the echo '...' and executes arbitrary commands. The workflow triggered on issues: opened, so any GitHub user could fire it by opening an issue.
GitHub's AI-assisted security review did not flag the change.
A security gate that was never closed
The workflow carried a condition that looked protective:
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')
On issues events, github.event.pull_request is always null. The condition collapses to null != 'whitesource-for-github-com[bot]', which is always true. Everyone passed.
The agent debugged its own exploit
This is the part that should hold your attention.
Red Agent's first exfiltration attempt used # to comment out the rest of the line. That broke the shell, because the comment also consumed the closing parenthesis of TITLE=$(...), and the runner threw a syntax error.
The agent did not stop or report a failure. It analysed the error, rewrote the payload to use ; echo ' so the shell block closed properly, and fired again. Within seconds a listener received a callback from a GitHub Actions runner carrying base64-encoded credentials.
The exfiltrated token authenticated as qa@snowflake.net and granted read access across Snowflake's engineering, security compliance and bug bounty tracking projects in Jira.
Response and timeline
Snowflake moved fast. Wiz reported through HackerOne on 23 June and Snowflake patched the same day, restoring the safe env: and jq --arg pattern. The Jira token was rotated on 24 June. Audit log analysis confirmed no third party reached the endpoint during the five-day exposure window, with all anomalous queries matching Wiz's testing IPs.
Three things this changes
AI-generated PRs need the same scrutiny as human ones. Coding assistants predict from probabilistic patterns, and they can reintroduce insecure shell idioms a team deliberately removed.
Discovery windows are collapsing. Five days from merge to autonomous discovery. Patch cycles and credential lifetimes now have to assume hours, not quarters.
AI assistants do not know why code was written a certain way. The safe env: and jq pattern existed specifically to prevent shell injection. An automated fix stripped it out because nothing recorded the reason it was there. Guardrails that stop agents from replacing hardened patterns have become a real control rather than a theoretical one.
The uncomfortable summary: one AI removed a security control because it did not know why the control existed, and another AI found the hole before any human did.