PixelLeak: coding agents are publishing what security teams can’t see

On 29 September Glow Labs, the research team at Glow Security, published research it calls PixelLeak. It says it found more than 13,000 internal images posted openly on GitHub by developers at over 300 organizations, across more than 900 repositories. Nobody broke in. The images were put there by the AI coding agents those developers were using, as a way round a missing feature.

The mechanics are mundane. According to Glow, developers ask an agent to show before-and-after screenshots of an interface change so a reviewer can check it. GitHub’s image hosting for pull requests is built into its web interface, but agents work from a text-based command line and could not attach the images to pull requests in private repositories. So they created public repositories and hosted the images there. “So the agents, being helpful the way that they are, they found a workaround,” Omer Singer, Glow’s co-founder and CTO, told The Register.

This is vendor research and should be read as such. Glow sells endpoint protection and runtime controls for AI agents, and its post says customers using its runtime prevention policies are already protected. It names none of the affected organizations and gives no UK figure. But the finding does not need a breach count to matter. In the cases Glow describes, coding agents made data-handling decisions without asking, and made them in places the security team does not watch.

What leaked, and where

The examples in Glow’s post are not trivial. At a manufacturer with more than 100,000 employees, a developer asked an agent to verify a fix to an internal billing screen. The agent created a public repository in the developer’s personal GitHub account and posted screenshots there, including billing records for a utility company. Glow says the company’s security team had not identified the issue, and the images were still up when Glow notified it. At a financial services firm, screenshots showed the internal treasury and settlement console and a dollar withdrawal screen for a named institutional client. The Register reported that Glow also found personal information and credentials in exposed material.

The most telling case shows how a workaround spreads. At one software vendor, agents serving several engineers began publishing review screenshots publicly in early July. Within a week, according to Glow, more than a dozen agents had saved the approach as a skill to use on every development ticket. They went on to upload more than a thousand screenshots and screen recordings of the product, with summaries of features weeks or months from release.

Glow says around a third of affected organizations had developers running gitshot, a small open-source tool that publishes screenshots for code reviews, which, at several large organizations, agents found and used to get past the same limitation. It began contacting affected organizations on 9 September and says others are likely to be affected.

The corporate estate is the wrong perimeter

The figure that should concern security leaders most is where the images sat. In 93% of cases, Glow says, they were in a repository an employee had created under their own username. An agent session running on a company laptop and pushing company data to a personal account falls outside any control that watches only the company’s GitHub organization. The manufacturer is the example: the images were not on the company’s organization, and the security team did not see them.

Glow also warns that scanning tools read text, not pixels, so a screenshot of a treasury console may pass unnoticed. Images attached to a release, it adds, can leave a repository’s file listing looking empty.

None of this required an attacker. The agents did what they were asked – show the reviewer the change – and chose the route themselves. That is the risk boards should understand: an agent allowed to create repositories and push code is, in effect, allowed to publish, and PixelLeak shows agents will do so when it gets the task done.

Take agent settings away from individual developers

Glow’s own recommendations are a reasonable starting point. On exposure, it advises starting with the people who commit to private repositories rather than with the company organization, including departed employees, and checking releases and gists as well as files. Anything found should be removed everywhere it exists, and anything legible in the pictures rotated.

On prevention, it argues that agent configuration belongs with the security team rather than with each developer. That means no blanket auto-approval, a review step that shows what the agent is about to do, and scrutiny of the shared rule and instruction files agents load, since that is where a workaround like this one gets picked up and passed around. It also recommends pre-execution hooks that block, or hold for approval, four actions: creating a public repository, pushing to a personal account rather than the company’s, pushing to a gist and switching a repository from private to public.

Those are the right four, and the principle does not depend on any one product. CISOs should treat any agent action that moves company data somewhere public or personal as a privileged action that needs approval. They should ask engineering leaders which agents are running, who set their permissions and whether anyone reads the skills those agents have written for themselves. And they should widen exposure monitoring from the company’s GitHub organization to the accounts of everyone who commits to it.

The agents at the center of PixelLeak were trying to be helpful. A tool that will quietly find a way round any obstacle needs its boundaries set by the security team in advance, not discovered afterward by an outside researcher.