13,000 Internal Screenshots Ended Up on Public GitHub, and No Attacker Put Them There

Security researchers have found more than 13,000 internal screenshots from over 300 organizations sitting in public GitHub repositories. The screenshots were not stolen. They were published by the coding agents the organizations were using, during ordinary work.

The finding, reported by the security firm Glow, is one of the more instructive leaks in a while, because the usual assumptions do not apply. There was no breach, no compromised credential, and no malicious insider. An automated tool did what it was told, and what it was told turned out to include committing files that should never have left the building.

How a screenshot ends up in a public repo

Coding agents take screenshots for sensible reasons. When an agent is asked to verify that a user interface change worked, it opens a browser, loads the page, captures an image, and compares it against the expected result. That image is evidence. Many agents save it to the working directory so the step can be reviewed later.

From there the path to a public repository is short. If the agent's working directory is the project folder, and the project folder is a git repository, then a screenshot written to disk is one `git add` away from being committed. If the agent commits and pushes as part of its normal workflow, and nothing filters the new files, the screenshot goes to whatever remote the repository points at.

Now repeat that across thousands of runs, in hundreds of organizations, over months. Nobody decided to publish internal screenshots. The default behaviour of the tooling did it, and no step in the chain was checking.

Why this is not a small mistake

An internal screenshot is often more revealing than people expect. It can show a dashboard with customer names, an admin panel with pricing, a staging environment, a bug tracker, or a chat window in the corner of the screen. It can show the state of a product that has not launched. In aggregate, 13,000 images from 300 organizations is a map of what those companies were working on.

The images also persist. A commit pushed to a public repository stays in the history even after the file is deleted from the current version, unless the history is rewritten. So the exposure is not fixed by a later cleanup commit, which is the step most teams would reach for first.

Why agents make this worse

A human developer who takes a screenshot for a pull request usually looks at it before attaching it. The image is right there, and the person decides whether it is safe to share. That moment of judgement is the filter, and it works most of the time.

An agent has no such moment. It optimises for completing the task, and saving an artifact is part of completing the task. Nothing in the loop asks whether the artifact is sensitive, because nothing in the loop is equipped to know. The agent is not being careless in the human sense. It is doing exactly what the instructions said.

This is the same lesson that shows up in several areas of agent design. Permissions that were fine for a person typing commands are not fine for a system that acts at machine speed and never gets tired. A human committing a screenshot once a week is a slip. An agent doing it every run across a fleet is a policy outcome.

What the fix looks like

The controls that would have prevented this are not exotic. A `.gitignore` entry for screenshot directories is the simplest one, and it works only if someone writes it before the agent runs. A pre-commit hook that scans for image files in certain paths catches what the ignore file misses. Giving agents a scratch directory outside the repository for temporary artifacts removes the problem at the source.

None of these depend on detecting that an image is sensitive. They depend on deciding, in advance, where agent output is allowed to go. That is a design decision, and it has to be made by the team running the agents, because the agent cannot make it.

Why the numbers keep growing

The count of 13,000 images from 300 organizations is not a fixed figure. It is a snapshot of repositories that were public at the time of the scan, and the number will rise as more teams adopt agents and as more repositories are pushed. The researchers scanned public repositories, which means the true total, including private repositories where the same mistake happened, is unknowable from outside.

The organizations affected are not all small. The finding names more than 300 of them, which spans startups and larger firms using the same agent tooling. That is the nature of a default-behaviour problem: it does not respect company size, because every company using the tool inherits the same default.

What the report does not say

The finding does not claim that any of the exposed images were used maliciously, and there is no evidence that anyone outside the projects combed through them. The harm is potential rather than proven: the material was public, and anyone could have looked. Where harm has been demonstrated in related cases, such as credentials written into a public file, the damage is immediate.

It also does not tell us how many of the images were sensitive in any meaningful way. Some are almost certainly screenshots of a blank test page. But a leak is judged by the worst item in it, not the average, and 13,000 images across 300 organizations means the worst item is likely to be genuinely revealing.

The pattern behind it

Glow's finding is one of a cluster of similar reports. Researchers have shown that coding agents will reference software packages that do not exist, which attackers can exploit by registering those names. Others have found agents writing credentials or tokens into places they should not. The common thread is that agents produce artifacts as a side effect of doing work, and every artifact is a potential leak.

The reassuring reading is that this is fixable and mostly comes down to hygiene. The less reassuring reading is that the industry is deploying agents faster than it is building the guardrails around their output. A company that audits what its agents read is often not auditing what they write.

What to do this week

If a team is running coding agents against repositories, the immediate checks are worth doing. Look at whether the agent's working directory is inside the repo, whether screenshots or logs land there, and whether the commit step filters anything. Check the repository history as well as the current tree for image files that should not be public. And give agents a scratch path outside the tree for anything temporary.

None of that requires new tooling. It requires deciding that agent output, like agent input, is something a team controls on purpose rather than by accident.