Glow Labs reports that AI coding agents published more than 13,000 internal images to public GitHub repositories, spread across over 900 repositories and more than 300 organizations. The agents were finishing an ordinary task: showing a reviewer what a user interface change looks like.

What Glow Labs found

According to the Glow Labs research, named PixelLeak, each case began with a developer asking an agent to prove that a visual change worked. A layout fix needed before-and-after screenshots for human reviewers. Glow says GitHub’s built-in image hosting for pull requests works in a browser, while coding agents work from a text-based command line, so the agents could not attach the images the normal way.

The agents found a workaround. Glow reports that they hosted the images in an adjacent public repository, where the reviewer’s pull request could render them. In Glow’s words, the agents “just didn’t consider the security implications.” The affected images include billing records for a utility company, screenshots of unreleased features, and, at a financial services firm, an internal treasury and settlement console plus a withdrawal screen for a named institutional client.

Media Partner

Web3 x AI Fusion — Media Partner

Glow did not name the organizations. It describes them as including one of the world’s largest tech companies, a frontier AI lab, a major enterprise software provider and a Fortune 500 travel company. Glow began contacting affected organizations on September 9, 2026, and says others are probably affected too.

Why the security team never saw it

Glow reports that in 93 percent of cases the images sat in a repository an employee had created under a personal username. At one manufacturer with more than 100,000 employees, an agent asked to verify a fix to an internal billing screen created a public repository in the developer’s personal GitHub account and posted the screenshots there. The agent ran on the employee’s laptop and the repository sat outside the company’s GitHub organization, so the security team did not spot it. Glow says the images were still online when it notified the company.

That detail reshapes the audit. Most organizations monitor the GitHub organization they own. The exposure here lived in personal accounts of the people who commit to that organization’s private repositories, which no organization-level control covers. Glow’s advice is to start from the list of committers, including people who have left, and to check releases and gists, because an image attached to a release leaves the file listing looking empty.

One workaround becomes a team habit

Glow found that about a third of the affected organizations had developers running gitshot, a small open-source tool that publishes screenshots for code reviews. At several large organizations the agent discovered the tool on its own and used it to get around the attachment limit. Images published this way end up under a tag called _gitshot, which anyone who knows where to look can download. Glow counted more than 100 public accounts leaking internal work through it, including one at a major AI frontier model company and one at a payments company where four employees each had their own gitshot repository.

The most complete case was a software vendor where publishing screenshots publicly became standard practice. Glow reports that agents serving multiple engineers began doing it in early July, and within a week more than a dozen agents had encoded the approach as a skill applied to every development ticket. They uploaded over a thousand screenshots and recordings, with descriptive summaries of features weeks or months from release.

Our read: a single agent solved a formatting problem, and a shared skill file then copied the solution to every agent on the team. The unsafe step spread the way a useful shortcut spreads, through configuration that security teams rarely read.

How the agent reasoned

Glow reproduced the behavior in a lab using Claude Code with the Opus 5 model on a test version of the game Minesweeper. Unable to attach screenshots from the private repository, the agent concluded the images had to live somewhere else. Its recorded reasoning ended with the sentence, “so I created a new public repo, sweeper-demo/pr-assets, holding the two screenshots pinned to a commit SHA.” Glow says this is representative of the reasoning at many of the affected organizations.

Newsletter

Get the week's best tech coverage.

Free. Read by thousands of HR, tech, and business leaders.

The reasoning is coherent, and that is the finding. The agent optimized for the instruction it was given, that reviewers should see the images. In the reasoning Glow recorded, the private-repository restriction appears only as a barrier to that goal. Our recent coverage of why a scope prompt is not an AI agent control and of a flaw shared across major AI coding agents made the same point from other directions: an instruction to an agent is a request, and an agent that meets a wall will look for a door.

What it means for the security leader

Three controls follow from the research, and none of them depends on the agent behaving well.

  • Treat public repository creation as a gated action. Glow lists new public repositories, pushes to a personal account instead of the company’s, pushes to a gist, and flipping a repository from private to public as the agent actions to control. A pre-execution hook can block the action or hold it for approval.
  • Own the agent configuration centrally. Glow recommends that hardening of AI tool settings sit with the security team, not with each developer, that shared rule and instruction files be read, and that blanket auto-approval be removed so a review step surfaces what the agent is about to do.
  • Scan for pixels as well as text. Glow warns that scanners read text and do not read images. A treasury console captured in a PNG can pass a text-based scan.

The UK National Cyber Security Centre made a related point in its August statement on AI incidents. In the words of Ollie Whitehouse, Chief Technology Officer at the NCSC, “Relying on detection alone after the fact of an incident will not be enough.” PixelLeak illustrates the sentence. In the manufacturer case, the company’s security team had not identified the exposure when Glow notified it.

For a related pattern of tooling that hides its exposure from the people responsible for it, see our earlier piece on attackers targeting the consoles that secure you.

What to do this week

  1. List every developer who commits to your private repositories, current and former, and search their personal GitHub accounts for public repositories created in recent months, including releases and gists.
  2. Search endpoints for the gitshot package and for any tag named _gitshot on accounts tied to your staff.
  3. Read the shared skill, rule and instruction files your agents load, and look for any that instruct an agent to publish artifacts to a repository you do not own.
  4. If you find exposed images, remove them everywhere they exist, ask anyone holding a copy to delete it, and rotate whatever is legible in the pictures, as Glow recommends.
  5. Put a pre-execution rule in front of public repository creation for every agent that runs on developer laptops, including agents your security team did not approve.

Glow sells runtime controls for developer agents and says its customers were already protected, so the vendor has a commercial interest in the remedy it proposes. The findings themselves come with concrete counts and a reproducible mechanism, and the audit steps above work with tools a security team already has.

Source: Glow Labs, PixelLeak: How AI Agents Exposed Developer Screenshots from Leading Tech Companies