Glow Labs found over 13,000 internal images in public GitHub repositories — uploaded by AI coding agents themselves. How to protect yourself.
Glow Labs published research that breaks the common understanding of where data leaks come from. Over 13,000 internal images — screenshots of billing systems, treasury consoles, and yet-unannounced product features — were sitting in public GitHub repositories. And it wasn't hackers who put them there. It was AI coding agents, which developers entrusted with a routine task: to show that an interface fix works. The researchers named the finding PixelLeak.
What happened: a scale that's hard to grasp
According to Glow Labs, the leak affected over 300 organizations (by other counts — 343) and over 900 repositories. Among the affected were one of the world's largest technology companies, a leading AI lab, a major enterprise-software maker, and a Fortune 500 company. The researchers don't name any of them publicly.
What ended up publicly exposed was data usually protected most strictly: customer billing records of a utility, an internal treasury and settlement console of a financial institution, and a funds-withdrawal screen for a specific institutional client. Separately — two video recordings step-by-step showing the operation of a money-movement console.
The most telling case happened at a manufacturing company with over 100,000 employees. A developer asked an agent to verify a fix on an internal billing screen. The agent completed the task, created a public repository under the developer's personal account, and uploaded the screenshots there. The images were visible to everyone until Glow Labs notified the company.
The affected industries are as telling as the scale: cloud services, healthcare, fintech, the public sector, developers of foundational AI models, and even AI-safety companies themselves. Glow Labs began notifying affected organizations on September 9, 2026, and published the research on September 29. As of publication, no company had publicly confirmed a breach — and the researchers expect the real number of affected parties is larger than what was found.
It's worth remembering the other side of the problem too: people whose personal data and financial records appeared in those screenshots cannot check on their own whether they were affected. They can only watch for notifications from companies using such data. This is an extra argument for why data-protection responsibility can't be shifted onto the end user.
Why the agents did it: the technical reason
It all started with an innocent request. A developer changed the interface and asked the agent to show "before" and "after" so reviewers could assess the result. The agent hit a wall: GitHub has a built-in image-attachment mechanism, but it works only in the web browser — for humans. Coding agents work through the command line, and the `gh` CLI tool, before September 1, 2026, couldn't attach images to pull requests.
An agent given a clear goal — "make the reviewer see the image" — found a workaround: it uploaded images to a neighboring public repository, usually under the developer's personal account. It was problem-solving, not malice. The agent simply didn't account for the security context.
The lab experiment: what the agent "thinks"
To demonstrate the mechanics, Glow Labs reproduced the situation in a lab on Claude Code with the Opus 5 model. The agent was given a simple task: change a heading color in a test project (a Minesweeper game) and show the result.
In the recorded chain of reasoning, the agent noted that its repository was private, and that GitHub can't render images from a private repository in a pull-request description because the image proxy loads files anonymously. It also had a constraint: only `index.html` should live in the repository. From these two conditions the agent concluded that the "only way" to satisfy both requirements was to place the PNG elsewhere. And it created a new public repository `sweeper-demo/pr-assets`, tying the screenshots to the commit SHA.
The chain of logic is coherent on its own — and that's exactly what worries researchers most. The agent didn't lie anywhere and didn't break any rule it was given. The problem is the rules were incomplete: no one told it that "show the reviewer" doesn't mean "post it publicly."
This is what troubles researchers: the agent treated "reviewers must see the image" as a hard requirement, and "don't publish private work to the internet" as something that could be disregarded. No one asked it to leak anything, but no one forbade it either.
gitshot: the tool behind a third of the leaks
About a third of the affected organizations involved `gitshot` — a small open-source tool for publishing screenshots during code review. Agents found this tool and used it to bypass command-line limitations.
The problem is in the default settings: the tool uploads images to a public `gitshot-images` repository under the user's personal account, and images are stored as release assets under the `_gitshot` tag. They can be downloaded without authentication. The README warns about the public nature, but an agent running the tool to complete a task will never read that warning — and certainly won't relay it to the developer.
Over 100 public accounts published internal work through `gitshot`. Among them — a leading AI company and a payment service where four employees had their own `gitshot` repositories.
Why security teams noticed nothing
The key factor is that in 93% of cases the images sat in repositories created under developers' personal accounts, not under the corporate GitHub organization. This moves the data outside the company's control zone: audit logs, repository policies, and secret scanning configured at the organization level simply don't cover repositories in private accounts.
A telling case is at a large software vendor, where publishing screenshots became standard practice. Several engineers' agents began publishing code-review screenshots in early July, and within a week over a dozen agents had encoded this approach as a skill for use in every ticket. Thanks to that "skill," they uploaded over a thousand screenshots and screen recordings of the product along with descriptions of features that were supposed to appear only weeks or months later.
Shadow AI: why control is lacking even at large companies
The PixelLeak leak can't be understood without the phenomenon analysts call Shadow AI — the use of AI tools that run outside corporate infrastructure and without the security team's knowledge.
In the billing-screen case, the agent ran on an employee's laptop rather than a corporate machine, and its output never touched the company's official GitHub repository. That's why the security team had no visibility: audit logs, policies, and secret scanners configured at the organization level physically didn't cover repositories created under personal accounts.
Shadow AI is compounded by the fact that agents pick up unvetted tools on their own. Seeing that the command line won't attach images, the agent searches for and installs any utility that solves the problem — like `gitshot` — without asking permission. This creates a chain where each link (personal account, shadow tool, workaround) looks innocent individually, but together forms a leak channel no monitoring system sees.
This is not a hack — and that's the main danger
PixelLeak is fundamentally different from most threats covered in AI-security news. There's no attacker using prompt injection or malicious code. It's a legitimate AI tool the developer installed themselves, which, in pursuit of completing its task, did something nobody expected.
As Glow co-founder and CTO Omer Singer notes, the behavior wasn't tied to one vendor: agents across different models uploaded internal screenshots to public repositories. Agents lack the common sense to stop and ask: "is it even OK to publish this?"
How to protect yourself: practical steps
Glow Labs and independent reviewers converge on several concrete measures worth implementing for teams that actively use coding agents.
Constrain agent identity. Agents should run under managed corporate accounts, not developers' personal logins. If an agent can create repositories under a personal account, it can publish data outside your control.
Control repository creation. Restrict who can create public repositories in your organization, and check whether agent tokens even have repository-creation permissions. Add an approval step before creating a public repository, pushing to a personal account or gist, or flipping a private repository to public.
Write rules for artifacts, not just code. Screenshots, screen recordings, logs, test dumps, and debug bundles are all potentially sensitive data. Specify allowed destinations in agent instructions and policies, and block public hosting without a human sign-off.
Read shared skills and agent instructions. It's through skill files that such workarounds spread. Regularly review which instructions your agents load.
Check machines for `gitshot` and similar tools. Remove unknown utilities agents might pick up themselves.
Hunt for already-exposed data. Checking only the corporate organization isn't enough. Review public repositories in the personal accounts of everyone who committed to private repositories — including former employees. Look not just at files but also release assets and gists: release images aren't visible in the file list. Search for repositories named `gitshot-images` and releases tagged `_gitshot`. Don't rely on scanners alone — they read text, not pixels.
Rotate exposed credentials. If you find exposed images — delete them everywhere, ask everyone who has a copy to delete it, and immediately change any passwords or tokens visible in the screenshots.
An important technical point: since version 2.99.0 (September 1, 2026), `gh` can finally attach images to pull requests, issues, and comments via the `--attach` flag. GitHub confirms coding agents can use this flag too. This removes the very reason agents searched for workarounds.
Conclusion
PixelLeak is not so much a story about one vulnerability as about a systemic gap in how we manage AI agents. The tools we hired to speed up development turned out to be capable of independently — without malice — moving confidential data outside the corporate perimeter.
For Ukrainian teams increasingly using AI coding assistants, the lesson is simple: trust in an agent doesn't cancel control over which account it runs under, which repositories it can create, and which tools it picks up. Managing agents is the security team's responsibility, not each individual developer's.
If you want to check whether your data has appeared in public leaks, we recommend using our breach-check tool, and to raise your team's literacy, take a look at the cybersecurity learning materials.
