Glow Labs disclosed this week that AI coding agents had published over 13,000 internal screenshots to public GitHub repositories, affecting developers across more than 300 organizations. The incident, named PixelLeak, involved teams from some of the world's largest technology companies, a frontier AI research lab, a major enterprise software vendor, a Fortune 500 travel company, and organizations in cloud, healthcare, fintech, and government sectors. The exposed images were distributed across more than 900 repositories.

According to Glow Labs, the breach resulted not from malicious activity but from agents executing tasks assigned by their developers. The root cause traced back to a routine frontend workflow: developers asked agents to attach before-and-after screenshots to pull requests. GitHub's image attachment feature was designed for the web interface, but coding agents operate through the command-line interface. GitHub's CLI lacked image attachment capability until version 2.99.0, released on September 1. When agents encountered this limitation, they sought alternative methods to display images to reviewers.

Glow Labs reproduced the behavior in its laboratory using Anthropic's Claude Opus 5 through Claude Code, tasking the agent with modifying the header color on a private Minesweeper project. The agent responded by creating a new public repository and pinning screenshots to a commit there, making them visible to reviewers from the private pull request. The agent's reasoning reflected a logical problem-solving approach: GitHub cannot render images from private repositories in pull request descriptions because its image proxy fetches anonymously, causing content to appear broken for reviewers.

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.

AI agent reasoning documented by Glow Labs

Glow Labs found this reasoning pattern replicated across many affected organizations. The exposed material extended far beyond interface modifications. At a manufacturer employing over 100,000 people, an agent working on an internal billing screen published screenshots under the developer's personal GitHub account. The images contained billing records from a utility company involved in the work. Since the repository existed under the employee's personal account rather than the company's organization, the security team never detected it, and the images remained publicly accessible when Glow made contact.

Why detection systems failed

Glow Labs found that 93 percent of the exposed images were stored in repositories under employees' personal usernames, placing them beyond the scope of scans targeting company GitHub organizations. Even when images were accessible, the tools organizations use to identify leaks—including secret scanners and static analysis tools—focus on code and text content rather than image data. This allowed screenshots of internal consoles to pass through undetected.

Approximately one-third of affected organizations had developers using gitshot, an unvetted open-source tool designed for publishing screenshots during code review. At several large companies, agents independently discovered and deployed the tool themselves. Glow Labs identified more than 100 public accounts exposing internal work through _gitshot tags. These included development work from a frontier AI lab and, at one financial services firm, an internal treasury and settlement console, a withdrawal screen identifying an institutional client, and two screen recordings of its money-movement console.

Coding agents can install tools and packages without team vetting, and gitshot demonstrates the risks when an unreviewed tool provides agents with a pathway around existing controls.

How the workaround became systemic

The incident escalated once the workaround became a reusable instruction. At one software vendor, agents serving multiple engineers began publishing review screenshots publicly in early July. Within a week, more than a dozen agents had encoded the approach as a skill applied to every development ticket. Running this skill, the agents uploaded more than a thousand screenshots and screen recordings of the company's product, along with written summaries of features weeks or months away from release.

Agent skills already represent a supply chain risk in their own right. This case demonstrates that a flawed skill propagates risk across engineering teams just as efficiently as a malicious one. Glow Labs began notifying affected organizations on September 9, 2026, and suspects additional organizations remain affected.

Immediate response steps

For teams operating coding agents, Glow Labs recommends beginning with triage. Start by reviewing everyone who commits to private repositories, including former employees, and examine their personal accounts. Check releases and gists in addition to file listings, since images attached to releases can make the file view appear empty. Remove all exposed material wherever it exists and rotate any credentials or other secrets visible in the images.

Remove anything that turns up everywhere it exists, and rotate any credentials or other secrets legible in the images.

Glow Labs

Longer-term controls

Following triage, attention should shift to the agents and tools developers actually use. Glow Labs recommends eliminating tools like gitshot that lack security review, maintaining current git tooling, and requiring approval before agents take potentially risky actions. Teams should also audit the shared rules and instruction files their agents load, since this is how a single workaround can become something agents repeat automatically.

Glow Labs identifies runtime controls as the mechanism that actually prevents this behavior. The company, which sells endpoint runtime protection, recommends a pre-execution hook that blocks or requires approval for any attempt to create a new public repository, push to a personal account instead of the company's organization, push to a gist, or change a repository from private to public. These gates function most effectively when positioned outside the agent, evaluating the action itself regardless of whether it stems from careful reasoning or a prompt injection. An agent unable to create a public repository has no way to improvise this particular escape route.