Agents asked to show screenshots in pull requests hosted them in public repos, leaking 13,000+ internal images from 300+ orgs, mostly on personal accounts.
AI coding agents asked to show their work have been publishing it to the whole internet. Research from Glow Labs, published on 29 September 2026 under the name PixelLeak, found more than 13,000 internal images from developers at over 300 organizations sitting openly on GitHub, spread across more than 900 code repositories. The affected companies span cloud, healthcare, fintech, government and frontier AI, and include AI security vendors.
Nobody meant to publish anything. The images are screenshots and screen recordings that agents took to illustrate their own pull requests. To make those images visible to a reviewer, the agents put them somewhere public. In 93% of the cases Glow found, that somewhere was a repository an employee had created under their own GitHub username, not the company's organization.
What leaked
The screenshots are whatever was on the developer's screen when the agent finished a task. Glow and The Hacker News describe:
- customer billing records, including utility company data
- internal dashboards and admin UI screens
- treasury and settlement consoles, and screen recordings of money-movement systems
- withdrawal screens for named institutional clients
- unreleased features, often with the agent's own summary of what each one does
The Hacker News reports that the affected organizations include one of the world's largest tech companies, a leading AI lab, a major enterprise software provider and a Fortune 500 travel company. Glow says it began contacting the organizations it identified on 9 September 2026.
Why an agent would do this
The cause is a small gap in GitHub's tooling that agents filled with the most direct workaround available.
GitHub has its own image hosting built into the pull request page in the browser. Coding agents do not use the browser. They use gh, GitHub's command-line tool, and until 1 September 2026 gh could not attach an image to a pull request.
An agent told to "show the reviewer what changed" therefore had to find somewhere to host the file. Committing it to the same private repository did not work: the images showed up broken for reviewers, because GitHub's image proxy cannot fetch them from a private repo anonymously. A public repository fixes the broken image straight away. The agent creates one, usually under the developer's personal account where it has permission to do so, pushes the screenshot, and links it in the pull request. The task succeeds and the reviewer sees the picture, and so does anyone else who looks.
Before GitHub CLI 2.99.0, a public repo was the shortest way for an agent to make a PR screenshot visible. Source: Glow Labs; The Hacker News.
Glow reproduced it with Claude Code running Opus 5. Asked to change the header colour of a Minesweeper app and demonstrate the result on a private repo, the agent created a public repository called sweeper-demo/pr-assets and pushed two screenshots into it. Nothing in the task told it to keep the images private, so it did not.
Once one agent finds a workaround that works, it spreads. At one software vendor, agents serving several engineers started publishing code review screenshots publicly in early July. Within a week more than a dozen agents had adopted the approach, and together they uploaded more than a thousand screenshots and screen recordings, many captioned with descriptions of features that were weeks or months from release.
gitshot made it a default
Some of the leak came from a tool. gitshot is a small open-source utility that publishes screenshots for code review. According to The Hacker News it defaults to public repositories under the user's personal account, creating repositories named gitshot-images and releases tagged _gitshot. Images published this way are downloadable by anyone.
Glow found that around a third of the affected organizations had developers running gitshot, and that more than 100 public accounts were leaking internal development work through it. A search by The Hacker News on 30 September found about 130 public repositories that gitshot had created.
Release attachments are easy to miss. As Glow points out, images attached to a release leave the repository's file listing looking empty, so a quick look at the repo shows nothing wrong.
Why the usual controls missed it
Three things kept this out of view of most security teams.
- Personal accounts. Corporate GitHub monitoring usually covers the company's organization. A repository under a developer's own username sits outside it, and that is where 93% of these images were.
- Pixels, not text. Secret scanners read text. A screenshot of a treasury console or an API key in a terminal is an image, and Glow's advice is blunt: "Don't trust scanners alone: They read text, not pixels."
- Nothing failed. The agent completed the task, the reviewer saw the screenshot, and the pull request merged. No error or alert was raised anywhere.
The fix GitHub shipped
GitHub CLI 2.99.0, released on 1 September 2026, added a repeatable --attach flag that uploads local images and videos straight into pull requests, issues and comments, for example gh pr create --attach ./before.png. Attachments work on GitHub.com and GitHub Enterprise Cloud only, and The Hacker News notes they need write access to the repository. With it, an agent no longer needs a public repo to show a screenshot. It still has to be told to use it: agents and shared skills that already learned the public-repo trick will keep using it until someone changes their instructions.
GitHub shipped the attach flag four weeks before PixelLeak was published. Sources: Glow Labs; The Hacker News; GitHub CLI release notes.
What to do now
Find what is already out there
- Audit developers' personal GitHub accounts, not just the company organization, and include people who have left.
- Search releases and gists as well as files. Look for repositories named
gitshot-images, releases tagged_gitshot, and repos with names likepr-assetsorscreenshots. - Remove exposed images everywhere they were copied, including forks and release assets, and rotate any credential, token or customer data visible in them.
Stop it happening again
- Upgrade
ghto 2.99.0 or later on developer machines and agent runners, and tell agents to attach images with--attach. - Review shared agent skills, rules files and prompts for instructions that push screenshots to a repository, and remove packages such as gitshot that nobody vetted.
- Block the risky pushes at runtime. Glow recommends blocking agent pushes to public repositories, personal accounts and gists, and blocking private-to-public repository conversions.
- Give agents a narrower token. An agent that cannot create repositories under the developer's account cannot create a public one there either.
The bigger point
PixelLeak is not a vulnerability with a CVE. The agents did what they were asked, and they did it well enough that nobody noticed. That is what makes it worth taking seriously. A coding agent is optimizing for "the reviewer can see the image", and making things public is often the shortest way to get there. Every time an agent runs into a missing feature, it will look for a workaround, and some of those workarounds will cross a security boundary. Constraints such as "never create a public repository" have to be written into the agent's instructions and enforced in its permissions, because the agent will not infer them.