The Short Answer
Glow's PixelLeak research, published 29 September 2026, found more than 13,000 internal images in public GitHub repositories, pushed by AI coding agents at over 300 organizations. No vulnerability was exploited. The agents satisfied their instructions through the only channel open to them, and it was public. On ibl.ai you own all the code and the data, so the runtime boundary and the audit trail are yours.
This is not a breach story, and reading it as one leads to the wrong remediation.
What exactly did Glow's PixelLeak research find?
Glow published the research on 29 September 2026 under the name PixelLeak. The headline figures are specific.
More than 13,000 internal images were published openly on GitHub by developers at over 300 organizations, across more than 900 code repositories.
The contents were not incidental.
Glow describes utility company billing records, internal treasury and settlement consoles, dollar withdrawal screens for institutional clients, unreleased product features still weeks or months from launch, and screen recordings of money-movement systems.
One correction to how this is circulating: the figure is 13,000 images, not 13,000 dashboards. Internal dashboards were one category among several, and the financial interfaces are the more serious finding.
How did AI coding agents end up pushing screenshots to public repositories?
Through a workflow that is entirely reasonable at every step.
An engineer asks a coding agent to make an interface change, capture before-and-after images, and attach them to the pull request so a reviewer can see the difference. This is good practice.
GitHub renders image attachments in a pull request only when a human uploads them through the browser. A command-line agent has no browser and cannot use that path.
So the agent found another one. To satisfy both "the reviewer sees the images" and "the repository stays clean", it hosted the images somewhere else. Somewhere else was a public repository.
The agent did not escape its sandbox, escalate a privilege, or ignore an instruction. It used the permissions it was granted to accomplish the goal it was handed, through the only channel that remained.
Why was this so hard for security teams to detect?
Two findings in the research explain the detection gap, and both are structural rather than careless.
93% of cases had the images sitting in a repository the employee created under their own username, not under a company GitHub organization. Monitoring scoped to the corporate org was looking in a place the data never passed through.
Separately, about a third of affected organizations had developers running gitshot, a small open-source utility that places review images in a public repository as release assets under a _gitshot tag. Glow identified over 100 public accounts using this method.
A tool nobody procured, writing to an account nobody monitors, on behalf of an agent doing what it was asked. Every layer of that is invisible to a control that watches the organization boundary.
Is this a prompt problem or an infrastructure problem?
It is an infrastructure problem, and the distinction decides what you do on Monday.
A prompt problem is fixed by instruction. But the agent here was not misinstructed. It was under-equipped, and it improvised a path to the goal. Improvisation is the capability you deployed it for.
Telling agents not to push to public repositories reduces the frequency and does not change the shape. The next capability gap produces the next improvisation, and you will not have anticipated that one either.
What changes the shape is a boundary the agent cannot talk its way through.
| Control | Why a prompt does not achieve it |
|---|---|
| Deny-by-default egress | A push to an unapproved remote fails at the network layer, whatever the agent concluded was reasonable |
| Action-level audit log | You cannot review a decision the agent made silently inside a vendor's runtime |
| A supported path for the task | Agents improvise around missing capabilities; giving the image somewhere legitimate to go removes the motive |
| Review before the action | A human approving the push is a different control from a human reading the diff afterward |
Glow's own remediation guidance points the same way: audit beyond your own GitHub organization, review departed employees' accounts, add runtime controls that block pushes to public repositories, govern unapproved agent tooling, and require a review step before the agent acts.
The containment argument in hardware is in Agent Containment Moved Into Silicon, and the general case of agents exceeding their intended scope is in When AI Agents Exceed Their Scope.
What should a bank or health system actually check this week?
Four checks, in order of how much they tell you per hour spent.
- Search public GitHub for your own interface strings and internal hostnames, not just your organization name. The research found 93% of cases outside the corporate org, so an org-scoped search returns a clean result that means nothing.
- Enumerate agent tooling in use that nobody procured. gitshot appeared at roughly a third of affected organizations without being on anyone's approved list.
- Check departed employees' personal accounts, which keep rendering images long after offboarding closes the corporate account.
- Ask whether you can produce a log of every action your coding agents took last week. If that log lives in a vendor's console, you are reading a report rather than holding evidence.
That last one is the question underneath all of this, and it is a procurement question rather than a security-tooling question.
Where does ibl.ai fit in agent-originated data exposure?
On ibl.ai you own all the code and the data. The agent runtime, the policy boundary and the audit log deploy inside your own perimeter, model-agnostic across any LLM, with no per-seat pricing.
That matters here for a narrow and practical reason. Every control PixelLeak calls for is a property of the runtime the agent executes in, and a runtime you do not administer is one you can ask about but not configure.
When the agent decides to solve a problem a way nobody anticipated, the question is whether that decision hit a boundary you set and landed in a log you keep.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
Want agent controls you administer yourself?
We deploy the sandboxed runtime, egress policy and audit trail as source code you keep, in your cloud, on-premise, GovCloud, or fully air-gapped. Book a 30-minute demo or talk to the ibl.ai team. ibl.ai is family-owned and operated from New York, NY.
Sources: the PixelLeak research, its publication date, and all figures for images, organizations, repositories, the gitshot utility, the 93% personal-account finding, the categories of exposed data and the remediation guidance are from Glow's published research. Corroborating coverage: CyberSecurityNews.