Coding agents leaked more than 13,000 internal screenshots to public GitHub repos while trying to get their pull requests reviewed
On September 29, Glow Labs published research they call PixelLeak: AI coding agents, asked to show a reviewer what their UI change looks like, put the screenshots in public GitHub repositories. The researchers counted more than 13,000 internal images from developers at over 300 organizations, spread across more than 900 repositories, including customer billing records, a financial firm's treasury console and screens from features that hadn't shipped yet. Nobody broke in. By Glow's account, the images were uploaded so a colleague could review the change.
What the agents were trying to do
The mechanism is almost reasonable, which is the uncomfortable part. A UI change wants before-and-after screenshots in the pull request. GitHub's image upload for pull requests lives in the browser, and coding agents live in a terminal. So the agents went looking for another way to get an image URL into the PR description, and in Glow's words they "figured out that they could make the image available to the human reviewer by hosting it in an adjacent public repo."
Glow reproduced it with Claude Code on Opus 5 against a test version of Minesweeper in a private repo called internal_sweeper. Asked to change a header color, the agent created a public repo named sweeper-demo/pr-assets and pushed the two screenshots there, pinned to a commit. Its reasoning was that GitHub's image proxy "fetches anonymously", so an image in a private repo would show up broken for the reviewer. The proxy detail is real: it fetches anonymously. The conclusion the agent drew from it is exactly the wrong one.
In 93% of the cases Glow found, the public repo sat under an employee's own username, outside the company's GitHub organization, where an org-level audit doesn't look. Many went through gitshot, a small open-source tool that publishes screenshots for code review, which developers at about a third of the affected organizations were running. At one software vendor, agents started doing this in early July. Within a week more than a dozen had saved the trick as a reusable skill, and with it they uploaded over a thousand screenshots and screen recordings, along with summaries of features weeks or months from release. Help Net Security's summary has the same numbers if you want the short version.
The reviewer saw the link
Here's the part I keep coming back to. The leak didn't happen somewhere off to the side of the review. Its whole purpose was the review: the screenshots were meant to sit in a pull request that a human would open, look at and, most likely, approve. The before-and-after would look fine, and the image URL would point at a public repo under somebody's personal account.
Most of us review the diff and skim the description. The description is where agent PRs now carry their evidence: screenshots, test logs, links to preview deployments, a summary of what the agent ran. Each of those is an artifact the agent had to put somewhere, and where it put it is part of the change, whether or not it shows up in the file list.
The PR that ships the habit
Glow describes agents saving the workaround as a skill. A skill is a file, and when a team shares one it usually lives in a repository, where with branch protection it goes through review like any other file. Below is a reconstruction of what such a pull request could look like. It isn't taken from any affected company, and it's short on purpose: read it the way you'd read a helper script a teammate's agent added.
.agents/skills/pr-screenshots/publish.sh
+25
It's tidy. It checks whether the repo exists before creating it, pins the image URLs to a commit so they never change under the reviewer, quotes its variables, and the comment at the top even explains the constraint it's working around. If you're scanning agent PRs between meetings, this looks like the kind of small quality-of-life script you're glad someone wrote.
What a trained eye flags here
Line 11. --public on a repository created under whoever is logged in (line 7 resolves the personal account, not the company org). Every screenshot this skill ever publishes is readable by anyone, stays in git history after a file is deleted, and never appears in the organization's audit log. The comment on lines 3 and 4 is the tell: it states a constraint that sounds right, that GitHub's anonymous image proxy can't fetch private images, and then solves it by removing the privacy.
The comment that earns full marks is short: "line 11 publishes our product screenshots, with whatever data is on screen, to a public repo under a personal account. Review artifacts can't leave the org. Attach them in the browser, or link a CI artifact or a preview deployment that needs a login." Then go back through the descriptions of the agent PRs this skill already ran on.
Nothing here is a bug in the usual sense. The script does exactly what it says, and no test would fail. The defect is what it's for, which is the kind of thing only a reviewer reading for intent catches.
What to look at in an agent's pull request
- Where every artifact lives. Hover the screenshots and links in the description. An image served from
raw.githubusercontent.comunder a personal account, a gist or a paste site means data left the organization. - Files under the agent's own folders. Skills, instruction files and hooks change what the agent does on every future task, so a few lines there deserve more attention than their size suggests. Reviewing shared skill and instruction files is on Glow's own list of recommendations for this reason.
- Commands with a visibility switch.
gh repo create --public,gh gist create --public,gh repo edit --visibility public, or a push to a remote that isn't the project's. - Pixels. Glow points out that secret scanners read text, not pixels. A billing record inside a PNG sails through every scanner you have, so a screenshot is only as private as the place it's hosted.
Glow's fix list is mostly configuration: know which agents run where, don't blanket auto-approve their actions, and use pre-execution hooks to block things like creating public repos or pushing to personal accounts before they happen. That's right, and as Glow puts it, it belongs with the security team, not with each developer. But review is still the step where a person looks at what the agent produced, and this incident is a good reminder that what it produced includes more than the diff.
Practise on the same shape of mistake
DiffDojo's library doesn't have a screenshot-leak PR yet, but it has several security PRs where an AI wrote the code confidently and no test would fail. Two to try before you read any answers: Authenticate address autocomplete with the Radar geocoding key (Angular) and Add the BYOK chat proxy endpoint (Python). If you'd rather read one with the answer already worked out, this retired Next.js example walks through a secret that was supposed to stay on the server.
Try a review
Review a real-looking AI pull request before you read the answer.
Leave inline comments and a verdict, then see what you caught. Free, no signup.
Browse the library →