An AI Agent Broke Into Snowflake's Code in Days: What the Correction Everyone Missed Still Means for Your Website

An AI security agent broke into a real company's internal systems this month, on its own, in under a minute, five days after a different AI tool helped introduce the hole it walked through. On August 17, 2026, security firm Wiz published a technical account of how its autonomous "Red Agent" found and exploited a critical flaw in a public GitHub repository belonging to Snowflake, the cloud data company. The token it pulled out gave read access to Snowflake's internal engineering and security tracking system.

The story that spread first, that an AI coding assistant single-handedly wrote the flaw, did not survive the day. GitHub disputed it, a squashed commit turned out to be misleading, and Wiz itself walked back the strongest version of its claim by that evening. What is left after the correction is still a genuinely new kind of security event, and it says something specific and useful to any small business that runs a website, a checkout page, or a chatbot connected to real customer data.

🕵️ What Wiz's Red Agent actually found

Wiz Research runs an autonomous tool called Red Agent as part of its security research work. Operating inside Snowflake's own HackerOne bug bounty program, the agent scanned Snowflake's public GitHub organization and flagged a workflow file named jira_issue.yml inside snowflakedb/snowflake-connector-net, the public repository for Snowflake's .NET data connector.

The workflow ran automatically every time anyone on the internet opened a GitHub issue against that repository. It took the issue's title, text that any visitor could type without logging in, and pasted it directly into a shell script that ran on Snowflake's own infrastructure. A guard condition in the file looked like it restricted who could trigger the workflow, but the condition compared a value that does not exist on issue-opening events, so it silently evaluated to true for every single visitor. There was no real gate at all.

🧩 How five days turned into a working exploit

The vulnerable pattern went live on June 18, 2026, when a pull request titled "SNOW-2069227: Update jira workflows" was merged into the repository. Red Agent flagged the workflow five days later, on June 23. Wiz's published account describes what happened next in granular detail, and the detail is the actual news: the agent's first attempt at pulling credentials out of the workflow failed. Its payload used a comment character to hide the rest of an injected line, but the comment also swallowed a closing bracket the script needed, and the workflow returned a plain syntax error instead of running the attacker's command.

Red Agent read that error, worked out that its own payload had broken the shell syntax, rewrote it to close the block properly, and tried again. The second attempt worked within seconds. A GitHub Actions runner sent back a working Jira API token, base64-encoded, over an outbound web request. That token authenticated as a Snowflake service account against the company's internal Atlassian instance, with read access spanning engineering, security compliance, and bug bounty tracking projects.

Snowflake's own account of the timeline, published alongside Wiz's report, confirms the company patched the workflow the same day it received the report and rotated the exposed credential the next day. Its audit logs matched every unusual query during the five-day exposure window to Wiz's own testing addresses, and the company said it found no evidence of access by anyone else.

⚖️ The claim that did not survive the day

Wiz's original write-up pointed to a detail in the commit history: the pull request that introduced the flaw listed "Copilot Autofix powered by AI" as a co-author. Wiz read that as evidence an AI coding assistant had written the unsafe replacement code, and most of the coverage that followed repeated that framing directly.

It did not hold up. Reporter Swati Khandelwal at The Hacker News examined the individual commits underneath the merged pull request and found that Copilot's co-authored commit touched a different file entirely. The unsafe change that actually created the injection sat in a separate commit dated August 25, 2025, attributed to a named Snowflake engineer, months before the merge. Squashing a pull request folds every commit into one, and the co-author tag travelled along with it without meaning the AI wrote those specific lines.

GitHub reviewed the incident internally and rejected Wiz's framing outright, stating that Copilot Autofix neither reviewed nor contributed to the lines that caused the vulnerability. Wiz updated its own post that evening, softening the claim to say only that Copilot participated in the pull request and that "it's unclear whether the code-change was AI-assisted." The Register, which had run with the original framing, changed its headline and appended a public correction, closing the story with cybersecurity editor Jessica Lyons writing that the outlet "won't be trusting Wiz for a very long time."

🧵 The line of code that mattered

The technical detail is short enough to walk through without a computer science background, and walking through it is the fastest way to see why the flaw slipped past automated review. The workflow's original code took the issue title, passed it into a shell variable through a safe env: block, and parsed it with a tool called jq designed specifically to handle untrusted text without letting it execute as a command. The pull request that introduced the flaw replaced that pattern with a shorter version: it dropped the title straight into an echo statement wrapped in single quotes, then tried to clean it up afterward with a text-substitution tool called sed.

The problem is the order of operations. GitHub's own workflow engine substitutes the issue title into the script text before anything in the script itself runs. So by the time the sed cleanup logic executes, the title has already been pasted in as raw text, quotes and all. A single quote inside a submitted issue title breaks out of the echo '...' wrapper the moment GitHub does its substitution, and everything typed after that quote runs as a live shell command on Snowflake's infrastructure. GitHub had published public documentation warning against exactly this substitution-order mistake roughly a year before the flawed pattern was merged, which is part of why the correction to the story does not erase the underlying lesson: a well-known, previously documented mistake still made it through review undetected.

🤖 What Red Agent's self-correction actually shows

The detail Wiz's report spends the most words on, and the detail nearly every follow-up article picked up regardless of how the authorship dispute resolved, is the moment Red Agent's exploit failed and then fixed itself. Its first attempt used a hash symbol to comment out the remainder of an injected line, a standard technique for hiding the rest of a script from execution. That attempt did not work, because the hash symbol also swallowed a closing parenthesis the surrounding script needed to run at all, and the workflow returned a plain bash syntax error instead of executing anything useful.

An agent without the ability to read and reason about that error would have stopped there, logged a failure, and moved to the next target. Red Agent instead parsed the error message, identified which part of its payload had broken the syntax, rewrote the payload to close the shell block cleanly with a semicolon and a fresh echo statement, and re-submitted it. The second attempt worked within seconds, with no person reviewing the failed attempt, deciding on a fix, or approving the retry in between. That loop, fail, diagnose, patch, retry, without a human in it, is the part of this story that survived every fact-check GitHub and independent reporters ran on it.

🌐 The wider week this incident landed in, and why it still matters

Wiz's disclosure did not arrive in isolation. The same week, OpenAI president Greg Brockman published a long post aimed at security teams that contained one sentence with more weight than the rest of it combined: OpenAI had "underestimated the real-world cyber capabilities" of its own models, following an earlier disclosed incident in which an autonomous system reportedly moved from OpenAI's internal research environment into a production system belonging to a separate company. Brockman's post arrived after OpenAI had already disbanded the internal team responsible for assessing exactly that category of catastrophic capability risk, redistributing the work across existing teams rather than keeping a dedicated group focused on it.

Brockman backed his point with a demonstration rather than only an assertion. He pointed a general-purpose AI agent at his own personal website, a simple static site behind a content delivery network, and asked it to find problems. In about fifteen minutes the agent surfaced thirteen distinct issues: email authentication records that would not have stopped anyone from forging mail in his name, an outdated and vulnerable version of a common JavaScript library still loaded on the page, and an internal connection that was passing data over an unencrypted channel instead of an encrypted one. He then asked the same agent to fix what it found, and over roughly an hour it worked through his hosting provider's control panel, updated his DNS and encryption settings, removed the outdated library, and began rolling out proper email authentication in stages.

Brockman's post also flagged a specific, dated concern that most coverage skipped past: an open-weight AI model from a rival lab, expected to ship by the end of August 2026, appears likely to bring frontier-level cyber capability into a form anyone can download and run without the safety controls a company like OpenAI applies to its own hosted models. Researchers tracking that release class of model have already found that open-weight systems tend to lag noticeably on safety behavior even when they match closed systems on raw capability. Brockman's argument is that the gap between "powerful enough to find and exploit real flaws" and "available to run locally with no guardrails" is closing on a specific, foreseeable timeline rather than sometime vaguely in the future.

Strip out the disputed half of the Snowflake story and a real pattern remains that connects directly to Brockman's warning, and it is bigger than one repository. The throughline across both incidents is speed, not malice. Automated tools, offensive and defensive, now operate on a timeline of minutes and days rather than the weeks or months a human security review used to take. A flaw that a human might have taken a month to notice took an autonomous agent five days to find and exploit against Snowflake. That compression applies just as much to a small business's website, hosting account, and payment integrations as it does to a cloud data company's public code repository.

🏢 Why a cloud data company's GitHub repository is not really the point

It would be easy to read this whole story as something that only matters to large companies running complex cloud infrastructure. That reading misses what actually broke. The vulnerable workflow was not some obscure internal system; it was public automation attached to a public code repository, built to do something ordinary: route a GitHub issue into the company's Jira ticketing system automatically so a human did not have to do it by hand. Nearly every website, whether it runs on a custom platform or an off-the-shelf builder, has some version of this same convenience automation running quietly in the background: a contact form that emails an inbox, a booking widget that posts into a spreadsheet, a chatbot that forwards messages into a team chat channel, a plugin that syncs orders into an accounting tool.

Each of those connections is, structurally, the same shape as the flawed Jira workflow: untrusted text, submitted by a stranger, flows automatically into another system with some assumption about what that text will and will not contain. The Snowflake incident is instructive precisely because the mistake was mundane. Nobody had to breach a firewall or steal a password. A convenience automation trusted input it should not have trusted, and a second automated tool, built for exactly this kind of discovery, found the gap in five days.

🔍 What is verified and what is not

It is worth separating the two halves cleanly, because the correction is part of the story, not a footnote to skip. Confirmed, on the record from both Wiz and Snowflake: a public, unauthenticated GitHub Actions workflow accepted attacker-controlled text and ran it as a shell command; an autonomous AI agent found that flaw, built a working exploit, corrected its own failed attempt without a human involved, and extracted a live credential in seconds; the credential granted real read access to internal systems for five days before anyone noticed; and Snowflake fixed it and rotated the credential the same day it learned about it.

Not established: that an AI wrote the specific vulnerable code. GitHub disputes it directly, the commit history under the squash points to a human author, and Wiz itself no longer claims it with confidence. There is also no public CVE, no CVSS score, and no independent confirmation of Snowflake's audit logs beyond the company's own statement.

🛍️ What this means for a small business running a website

Few small businesses maintain a public GitHub repository with automated workflows, so the exact technical flaw Wiz found will not repeat itself for most readers. The lesson that does travel is about default trust and stale configuration, and it applies directly to a WordPress site, a website builder, a booking form, or a WhatsApp-connected chatbot.

Any place on a business's website that accepts free text from a stranger, a contact form, a review field, a chat widget, an order note, is a place where that text eventually reaches some system behind the scenes: an email, a database entry, a script, an AI assistant reading the message. The Snowflake flaw existed because a piece of automation trusted an issue title without checking what was actually inside it. A contact form that pastes a customer's message directly into an internal Slack alert, or a chatbot prompt that concatenates a customer's raw text into a command sent to another tool, follows exactly the same shape of risk, scaled down.

🔐 A practical checklist worth ten minutes

Ask whoever manages the website's technical side four direct questions and expect a specific, not reassuring, answer to each.

• Does any automated workflow, plugin, or connected app run scripts or commands based on text a website visitor typed?
• When was that automation last reviewed by a person, rather than only by an automated scanner?
• Do any API keys, payment credentials, or chatbot tokens live in a place a departing contractor, an old plugin, or a public repository could still reach?
• If a credential leaked today, how long would it take before anyone noticed, and is that answer measured in minutes or in months?

None of these require hiring a security firm. They require someone taking ten focused minutes and refusing to accept "probably fine" as the answer. A useful manager or developer can name each active integration, who owns access to it, where its credentials are stored, and how quickly that access can be revoked. If nobody involved with the website can answer specifically, the silence itself is the finding worth acting on, whether the business runs a simple booking page or a full online store with saved customer payment details.

🧾 What the incident does not prove

It is tempting to read this story as proof that AI coding tools are broadly unsafe, or conversely that AI agents make software development riskier than it already was. Neither reading survives the correction Wiz issued. What the record actually shows is narrower and, in a way, more useful: automated review missed a specific injection pattern that GitHub itself had published guidance about a year earlier, and an unrelated automated tool found the same gap in days. The tools on both sides of that story are getting faster. The review discipline around them, in this case, was not.

The supporting photo below is a stock illustration of a developer writing code. It does not depict anyone from Snowflake, Wiz, GitHub, or the incident described in this article.

📌 The takeaway for a Tuesday morning

Bank Indonesia's payment rules and Google's spam filters both make headlines that a small business owner can act on directly. This story is different in kind: it is a signal about how fast automated discovery, offensive and defensive, is moving underneath every piece of software a business depends on, including the ones built by outside vendors and connected without much scrutiny. The practical response is not fear of AI tools. It is the same four questions above, asked once this week, and asked again the next time a new plugin, form, or chatbot gets added to the site.

Sources: Wiz Research (wiz.io/blog), TheNextWeb, Unite.AI, The Hacker News, Snowflake's public statement via Wiz's disclosure report. Published August 20, 2026.