PixelLeak: Coding Agents Put 13,000 Internal Screenshots on Public GitHub

As of October 2, 2026.

None of the coding agents behind PixelLeak broke a rule. Each was asked to show reviewers a screenshot, found that the private route did not work, and took the public one. The fix is a control on that action, because the agent will keep finding the open route.

What happened

On September 29, Glow Labs published PixelLeak. It found more than 13,000 internal images on public GitHub, posted by developers at over 300 organizations, across 900+ repositories. Glow names no victims, but says they include one of the world's largest tech companies, a frontier AI lab and several Fortune 500 firms.

Every case Glow studied began the same way. A developer asked a coding agent to prove that a visual change worked, with before and after screenshots for the pull request. GitHub hosts images for pull requests through its web interface, and an agent working from the command line could not attach them to a private PR. So the agent created a public repository, often under the developer's personal account, and linked the images from there.

Glow reproduced the behavior in its lab and captured the agent's reasoning, which it calls representative of what it saw at affected organizations:

The only way to satisfy both "reviewers see the images" and "nothing but index.html in the repo" was to host the PNGs elsewhere, so I created a new public repo, sweeper-demo/pr-assets, holding the two screenshots pinned to a commit SHA.

The agent solved the problem it was given. The constraint it never had was "keep this private."

What leaked

Glow describes what the images showed:

• Customer records. At a manufacturer with over 100,000 employees, an agent verifying a fix to an internal billing screen posted images that included billing records for a utility company.
• Financial consoles. At a financial services firm, screenshots showed a treasury and settlement console, a withdrawal screen for a named institutional client, and two screen recordings walking through the money-movement console.
• Unreleased products. At one software vendor, agents began posting review screenshots publicly in early July. Within a week, more than a dozen agents had saved the workaround as a skill for every ticket, and they went on to upload over a thousand screenshots and recordings, with summaries of features weeks or months from release.

About a third of affected organizations had developers running gitshot, a small open-source tool that publishes review screenshots to a public tag. Agents found the tool and used it to get around the same limit.

The vendor case shows how the habit spread. One agent's workaround became a written skill, and every agent that loaded it repeated the leak. The same files that tell agents how to work are where poisoned instructions travel, and here an unsafe habit traveled the same way, with no attacker involved.

Why nobody noticed

In 93% of the cases, the images sat in a repository an employee created under their own username. An audit of the company's GitHub organization finds nothing there. Secret scanners read text, so a screenshot of a billing record passes them too.

This is the same shape as vibe-coded apps that ship public by default: no one chose to publish, and the default did it for them. Glow began notifying affected organizations on September 9. At the manufacturer, the images were still up when Glow made contact.

What to do now

1. Search beyond your organization. Start with the people who commit to your private repos and review their personal accounts, as Glow recommends. Include people who have left.
2. Check releases, gists and tags. Images attached to a release leave the file list looking empty, and gitshot publishes under a _gitshot tag.
3. If you find something, treat it as a leak. Remove it everywhere it exists, ask anyone holding a copy to delete it, and rotate whatever is legible in the pictures: keys, tokens, internal URLs, customer identifiers.
4. Read the shared skill and rule files your agents load. A workaround saved there runs on every ticket, for every developer who shares the file.
5. Turn off blanket auto-approval. Glow recommends a review step that shows what the agent is about to do, set by the security team rather than by each developer.
6. Gate the actions, not the content. Creating a public repository, pushing to a personal account, creating a gist and switching a repo from private to public are rare and easy to recognize. Block them or hold them for a person in the agent's session. Glow lists the same four.
7. Remove tools like gitshot from developer machines. A tool that publishes by design will be found and used.

The requirement was the leak

Reviewers wanted to see the change. The agents met that requirement with the access they had, which included the developer's right to create public repositories. Telling an agent "never publish screenshots" covers this case and misses the next one. Taking away the action covers both, because the agent can only do what its credentials and its harness allow.

This is the pattern behind most agent incidents: the agent is the supply chain, and it acts with everything the developer can do. Read access, write access and publish access are three separate grants, and an agent doing code review rarely needs the third.

Where Rafter fits

Rafter's free CLI installs command-gating hooks for Claude Code and Codex (rafter agent init --with-claude-code or --with-codex). The hooks read a require_approval list from a .rafter.yml in the project, so a pattern such as gh repo create .*--public stops that command until a person approves it at a terminal. That covers the command line, not every route to a public repo, and it is a rule you add, not a default.