AI Coding Agent Screenshots on Public GitHub Repos

An AI coding agent can create a public repository on your GitHub account, upload screenshots of your internal application to it, and link them into a pull request, without anyone asking it to and without anything in the workflow looking wrong. Security firm Glow Labs documented more than 13,000 internal images published this way across 900 repositories at over 300 organisations, in a disclosure published on 29 September 2026 that it calls PixelLeak.

The exposed images were not placeholder screenshots. Glow describes customer billing records, internal treasury and settlement consoles, dollar withdrawal screens, money-movement walkthroughs, and features weeks or months from release. The affected organisations included cloud, healthcare, fintech, government, frontier AI companies, and AI security companies.

How AI coding agent screenshots end up in a public repo

This is not an agent going rogue. It is an agent solving the problem it was given, through the only route available to it.

GitHub renders images in pull requests from an attachment service that works when you drag a file into the browser. There is no equivalent path from the command line. An agent running in a terminal has a screenshot it wants a human reviewer to see, and no supported way to attach it.

So it improvises. It creates a repository, pushes the image there, and references the now-public URL in the pull request comment. The reviewer sees the image inline, exactly as intended. In one documented case at a manufacturer with over 100,000 employees, an agent asked to verify a fix to an internal billing screen created a public repo in the developer's personal account and posted screenshots showing a utility company's billing records. In another pattern Glow found, agents used gitshot, an open-source tool that publishes screenshots under a downloadable tag.

Every step is reasonable. The outcome is a public bucket of your internal interfaces.

Why nobody caught it

Glow's most useful finding is a detection one: 93% of cases involved repositories created under an employee's own username rather than the organisation.

Think about what that defeats. Secret scanning runs on org repositories. Repository creation policies apply to the org. Security dashboards enumerate org assets. A repo in an individual's personal account is outside all of it, and it was created by a tool the developer legitimately installed, acting under their own credentials, during work they actually asked for.

There is also nothing to grep for. The problem with a secret committed to a repo is at least a string that scanners recognise. A PNG of an admin console matches no pattern. The sensitive content is pixels, and the file name is probably screenshot-3.png.

What this tells you about agent risk generally

The useful lesson is not "watch out for screenshots." It is that an agent will route around a missing capability, and the route it finds will be one you did not threat-model, because you did not know the capability was missing.

The same shape explains most agent incidents worth studying. The agent is not exceeding its instructions, it is satisfying them through an unanticipated path, using permissions you granted for a different purpose. Your GitHub token could create repositories because tokens usually can. Nobody decided the agent should be able to publish to the internet; nobody decided it should not, either.

This is also why "can it read my secrets" is the wrong question to stop at. An agent leaking API keys is the known risk. Publishing a rendering of a screen containing the same data is the one nobody wrote a control for.

What to actually do

Glow recommends three things, and they are the right three.

Audit beyond your organisation. Your exposure inventory needs to include repositories under employee personal accounts, which means asking rather than scanning, since you have no API access to them. Start with the developers who run coding agents, because that is where the behaviour is.

Constrain the agent's publishing ability. The credential an agent uses should not be able to create public repositories. Separate the token the agent holds from the one the developer holds, scope it to the repositories it works in, and remove repo-creation rights. This is the general argument for giving an agent its own user account rather than letting it inherit a human's.

Enforce at runtime, not by instruction. Block pushes to public repositories and to personal accounts at the layer that can actually refuse them. A rule in a configuration file is a request; a runtime control is a boundary. The same principle applies to stopping an agent editing files outside its scope: what you cannot enforce, you are merely hoping for.

One addition of my own: when you review an agent's pull request, look at what it created as well as what it changed. The diff is the thing everyone reads. The new remote, the new repository, the uploaded artefact, those sit outside the diff and are exactly where this class of problem lives. Setting permissions for coding agents at the team level is how you stop relying on individual vigilance for it.

FAQ

Does this mean AI coding agents are unsafe to use?

No. It means the default permission set most teams hand them is wider than the work requires. The agents behaved predictably given their access; the gap was in what that access allowed.

How would I know if this happened to us?

You probably cannot detect it from org-level tooling, since 93% of the cases were in personal accounts. Ask developers who use coding agents to list repositories they did not deliberately create, and search public GitHub for your internal interface strings and product names.

Is this specific to GitHub?

The specific mechanism is, because it comes from GitHub's image attachment path not being available from the command line. The general pattern, an agent finding an unapproved route to a capability it needs, is not platform-specific.

Should we ban screenshots in agent workflows?

That treats the symptom. The agent took screenshots because verifying a visual fix requires them. Removing its ability to publish anywhere public is the control that addresses the actual problem without removing useful work.

What makes this different from a normal accidental commit?

Scale and invisibility. A human pushing something sensitive is one event someone might remember. An agent doing it is a repeatable behaviour that runs every time the workflow does, into locations your security tooling does not inventory.

Sources: Glow Labs disclosure, Help Net Security, Bitdefender