An AI Security Agent Hacked Snowflake. The Copilot Story Was Noise.

An AI agent broke into Snowflake's internal Jira in June, and the bit almost everyone led with was the wrong bit. The first version of the story said GitHub Copilot had written the vulnerable code, a tidy parable about AI poisoning AI. That version lasted a few hours. Wiz corrected its own disclosure the same day, GitHub flatly disputes the attribution, and what survives the correction is stranger and more useful: an autonomous agent found a live flaw, wrote an exploit, debugged its own failed payload and pulled working credentials, end to end, while the conventional scanners on the same code saw nothing. That is the story worth your time.

Key Takeaways - Wiz's Red Agent, an autonomous offensive security agent, found a script injection in a GitHub Actions workflow in Snowflake's public snowflake-connector-net repo and exploited it to steal a Jira token. No human touched the keyboard between discovery and credential exfiltration. - The flaw went live on 18 June 2026 and was found, exploited and reported on 23 June, all through Snowflake's HackerOne programme. Snowflake patched the same day and its audit logs show Wiz was the only actor in the window. - The initial claim that Copilot wrote the bug was walked back within hours. The vulnerable pattern was in a human-authored change; Copilot Autofix's documented contribution was a different file, and the co-author label was a squash-merge artefact. - GitHub Advanced Security scanned the exact vulnerable revision and missed it. A pattern-matching scanner looked at the same code an agent reasoned over, and only one of them understood it. - The genuinely agentic part was narrow but real: diagnosing a failed exploit and rewriting it. The rest was good automation with a language model inside.

What happened

The timeline, all from Wiz's disclosure and Snowflake's response to it:

• 18 June 2026. PR #1218 is merged into snowflakedb/snowflake-connector-net, Snowflake's public .NET connector repo. It rewrites a workflow called jira_issue.yml, which auto-creates Jira tickets when someone opens a GitHub issue. The rewrite replaces a safe pattern (issue title passed through an environment variable into jq --arg) with direct interpolation of the title into a shell run: block.

• 23 June. Red Agent, Wiz's autonomous security research agent, flags the workflow as injectable while scanning Snowflake's GitHub organisation under the company's HackerOne bug bounty programme. It builds an exploit, fires it, hits a shell syntax error in its own payload, diagnoses the error, rewrites the payload and succeeds on the second attempt. An Azure-hosted GitHub Actions runner calls back to Wiz's listener with a base64-encoded Jira API token, tied to a service account. Wiz reports it via HackerOne the same day.

• 23 June, same day. Snowflake patches the workflow, restoring the safe pattern.

• 24 June. The Jira token is revoked and rotated. Snowflake's audit-log review finds no access by anyone but Wiz during the five-day exposure window. Wiz says it deleted the data from its proof of concept.

• 17 August. Wiz publishes the write-up by Gal Nagli, head of threat exposure at Wiz Research, and updates it at 19:57 UTC the same day to clarify that Copilot was a co-author that had checked the merged PR and cleared it, and that it's unclear whether the vulnerable change was AI-assisted at all.

The token carried read access to Snowflake's internal Jira: engineering, security compliance and the bug bounty programme itself. Nobody's customer data was touched, and the shipped connector was never affected.

On 23 June 2026, Wiz's autonomous Red Agent found and exploited a script injection in a GitHub Actions workflow in Snowflake's snowflake-connector-net repository, exfiltrating a Jira token with read access to internal engineering, security compliance and bug bounty projects, five days after the flaw went live and with no human involvement, per Wiz Research's disclosure. Snowflake patched the same day and found no third-party access in its audit logs.

The permission chain, link by link

The exploit is a tidy lesson in how much trust a CI pipeline quietly holds. Follow what one crafted issue title could reach:

1. The trigger. The workflow ran on issues: opened, meaning any GitHub account on earth could fire it by opening an issue. A conditional check meant to gate access always evaluated to true on issue-opened events, per the technical coverage.

2. The injection. The new code did TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). GitHub expands the ${{ }} template before the shell runs, so the sed escaping arrives too late. One single quote in the title closes the string and the rest of the title executes as shell.

3. The environment. Commands now run inside a GitHub Actions runner, which is a machine full of credentials by design. This one held a Jira API token for a service account, because creating Jira tickets was the workflow's whole job.

4. The exfiltration. The payload base64-encoded the token and sent it to Wiz's listener as an out-of-band callback, so nothing suspicious ever appeared in the workflow logs.

5. The prize. The token authenticated to Snowflake's internal Atlassian environment with read access across engineering, security compliance and bug bounty projects.

Every link in that chain is ordinary, approved, boring infrastructure: a public repo, a workflow doing its job, a service account with the permissions it needed. The vulnerability wasn't any single misconfiguration; it was the composition. The blast radius of a workflow is everything its runner can reach, and runners can usually reach more than the team that wrote them remembers. It's the same argument I make when clients ask about agent governance: the question is never what the agent is, it's what the agent can touch.

The exploit chained five layers of legitimate trust: an unauthenticated GitHub issue triggered the workflow, a single-quote injection escaped the shell, the runner's environment held a Jira service-account token, an out-of-band callback exfiltrated it, and the token opened read access to Snowflake's internal Jira. GitHub's template expansion runs before shell escaping, which is why the sanitisation arrived too late, per Wiz's write-up.

What was agentic and what wasn't

I want to be precise here, because "AI agent hacks Snowflake" invites two lazy readings: that this was just a scanner with better marketing, or that Skynet is loose. Neither survives the details.

Ordinary automation with a model inside. The scanning and flagging. Red Agent's CI/CD capability crawls GitHub organisations looking for workflow files that interpolate untrusted input into run: blocks. That's a well-understood vulnerability class with a recognisable shape, and flagging jira_issue.yml is the kind of thing a good static rule could plausibly do. Choosing the target, reading the workflow, judging it exploitable: skilled, but close to what Wiz already sells as continuous attack-surface management.

Genuinely agentic. The exploit loop. The agent's first payload used a comment character that broke the shell syntax and failed. It read the resulting bash error, worked out why the payload was malformed, rewrote it to close the script properly, and succeeded on the second attempt. Then it validated that the stolen token actually worked against Snowflake's Jira and assessed what the token could reach. Diagnosing a novel runtime failure in your own attack and adapting, unprompted, is not signature matching. That loop, attempt, observe, correct, is the thing that separates an agent from a scanner, and it's the same loop I've written about in agentic architecture more generally. Seeing it run offensively, against a Fortune 500 target, unsupervised, is a first worth noting.

Not the agent at all. The scope, the ethics and the disclosure. Red Agent operated inside Snowflake's HackerOne programme, a sandbox a human at Wiz chose and authorised. The autonomy was real but bounded, sanctioned and monitored, which is exactly the point I'd underline for defenders. Wiz launched Red Agent in March and made it generally available in late July, built in part on Anthropic's Claude Opus. The capability is now a product any security team can rent, so the offensive version of this loop is about to be very common.

Red Agent's scanning and triage were automation with a model inside; the agentic core was the exploit loop: when its first payload threw a shell syntax error, the agent diagnosed the bash failure, rewrote the payload and succeeded on its second attempt, then validated the token and mapped its blast radius, all without human help, per Wiz's disclosure.

The Copilot row is the least interesting part

The first headlines said Copilot wrote the bug. The record says otherwise. Copilot Autofix's documented contribution to PR #1218 was a separate fix to a different file, jira_close.yml. The vulnerable interpolation sat in a commit attributed to a named Snowflake engineer, and GitHub told reporters its internal review found Copilot Autofix neither wrote nor reviewed those lines. The "co-authored by Copilot" label on the merged PR was an artefact of a squash merge dragging the trailer along. Wiz amended its post the same day; The Register corrected its story. Wiz CTO Ami Luttwak's comment to CSO is the honest takeaway: when multiple agents run on every PR, "just looking at co-authors of the PR is not enough" to establish who wrote what.

Two things can be true at once. GitHub Advanced Security, which uses Copilot Autofix, scanned the final revision of that PR including the vulnerable workflow and did not flag the injection; that's in Wiz's account and GitHub hasn't disputed it. And the specific claim that Copilot authored the flaw is unsupported. AI-assisted review missed a critical bug in code it cleared as fine. That is a real story about the limits of AI review; it just isn't a story about AI writing the bug, and conflating the two helps nobody deciding how much to trust AI review on their own PRs.

Wiz initially implied Copilot helped write the vulnerable code, then clarified the same day that Copilot Autofix's documented contribution was a different file in the same PR and the co-author label was a squash-merge artefact. GitHub says a human engineer wrote the flawed refactor and Copilot never reviewed it. Undisputed: GitHub Advanced Security scanned the vulnerable revision and flagged nothing, per Wiz's updated post and CSO's reporting.

What to do now

If you run GitHub Actions with any secrets in them, this week:

1. Grep your workflows for ${{ github.event.* }} inside run: blocks. Any interpolation of issue titles, PR titles, branch names or comment bodies into shell is injectable, full stop. Move the value into an env: variable and pass it with proper quoting, or parse it with jq --arg. This is the pattern Snowflake restored.

2. Assume your runners are credential stores. Scope workflow tokens to the minimum, prefer short-lived OIDC credentials over long-lived service-account tokens, and treat any workflow triggered by untrusted events (issues, pull_request_target, comments) as internet-facing code.

3. Don't let AI review be your last line. GitHub's own scanner looked at this exact code and passed it. Layer your checks, and be suspicious of any workflow where review, authorship and scanning are all delegated to one vendor's models.

4. Expect a five-day window to feel slow. An agent went from zero knowledge of this repo to working credentials in under a week. If your disclosure process assumes months of attacker dwell time, update the assumption, and have a credential-rotation runbook you can execute the same day, as Snowflake did.

FAQ

Did GitHub Copilot write the Snowflake vulnerability?

No, not on the current evidence. Copilot Autofix was a co-author on the merged PR, but its documented change was to a different file, the label was an artefact of the squash merge, and GitHub says a human engineer wrote the vulnerable code. What is true: GitHub Advanced Security scanned the vulnerable revision and missed the injection.

How did the Wiz agent get into Snowflake's Jira?

It found a workflow that interpolated issue titles directly into a shell script. Opening an issue with a crafted title ran arbitrary commands on the runner, which held a Jira service-account token. The agent exfiltrated the token with an out-of-band callback and used it to read internal Jira projects. Snowflake patched the workflow the day it was reported and rotated the token the day after.

Was this a real attack?

It was a sanctioned one. Red Agent operated under Snowflake's HackerOne bug bounty programme, Wiz disclosed immediately, and Snowflake's audit logs confirmed Wiz was the only actor during the five days the flaw was live. No customer data was accessed. But the technique works identically for an unsanctioned agent, which is the point.

What does this mean for AI security agents?

That the offensive ones are ahead of the defensive ones. An autonomous agent found, exploited and scoped a real flaw days after it shipped, while the automated scanner on the same code saw nothing. Defenders should assume agent-speed discovery is the new baseline and that anything internet-triggerable will be probed at that speed.

The bottom line

Strip away the Copilot drama and two facts remain. A conventional, expensive security scanner reviewed this code and cleared it. An autonomous agent read the same code, understood it well enough to weaponise it, and fixed its own mistakes along the way. The five-day gap between "merged" and "exploited by a machine" is the number security teams should be staring at, because offensive agents are now a product, not a research demo, and they don't take weekends. The Copilot attribution row will be forgotten by next month. The capability won't be.

If you're working out how much autonomy to give agents, offensive or defensive, inside your own pipelines, that's a conversation I have with clients regularly. Get in touch.

Sources

• Wiz Research (Gal Nagli), "Wiz Red Agent Finds Its Way Into Snowflake's Internal Jira Through a Flaw in a GitHub Copilot-Assisted PR": https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (published 2026-08-17, updated 2026-08-17 19:57 UTC, retrieved 2026-08-29)

• Wiz, "Introducing the Wiz Red Agent - AI-Powered Attacker": https://www.wiz.io/blog/introducing-the-wiz-red-agent (published 2026-03-23, retrieved 2026-08-29)

• Cybersecurity News, "AI Agent Hacks Snowflake GitHub Workflow": https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (published 2026-08-20, retrieved 2026-08-29)

• CSO Online, "Snowflake flaw slips past AI checks, gets exploited by another AI": https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (published 2026-08-19, retrieved 2026-08-29)

• Infosecurity Magazine, "Wiz AI Agent Finds Critical Snowflake GitHub Repo Flaw": https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (published 2026-08-18, retrieved 2026-08-29)

• daily.dev (from The Next Web), "GitHub disputes Wiz's claim that Copilot Autofix wrote a Snowflake flaw": https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (published 2026-08-18, retrieved 2026-08-29)

• snowflakedb/snowflake-connector-net repository: https://github.com/snowflakedb/snowflake-connector-net (retrieved 2026-08-29)