Glow Security has published research it calls PixelLeak, saying it found more than 13,000 internal screenshots and screen recordings exposed in public GitHub repositories linked to developers at more than 300 organizations. Glow says the affected material spanned more than 900 repositories and included customer information, financial interfaces, unreleased product work and other internal development context.
The report is important because the exposure mechanism was not simply a developer accidentally attaching the wrong file to a public issue. In several cases described by Glow, AI coding agents or helper tools were trying to make screenshots available for code review and created a public distribution path outside the organization’s private repository boundary. That turns a seemingly small workflow gap into an agent-control problem: the task may be completed, but the route chosen to complete it can violate the operator’s security assumptions.
What Glow says it found
Glow says 93% of the exposed-image cases it identified were hosted under employees’ personal GitHub accounts rather than company organizations. It also says roughly one-third of the affected organizations had developers using gitshot, a tool designed to make screenshots accessible from command-line development workflows by storing them in a GitHub repository.
One software vendor was a particularly large case. According to Glow, a workaround for sharing screenshots had been turned into a reusable agent skill and was used across multiple coding agents, resulting in more than 1,000 screenshots and screen recordings being placed in a public repository. Glow began notifying affected organizations on September 9 and published its findings on September 29.
Those numbers should be treated as Glow’s reported findings, not as an independently audited census. The company has not publicly named the affected organizations or released a complete corpus that would allow outsiders to reproduce the 13,000-image and 300-organization counts. Public exposure also does not by itself prove that unauthorized third parties downloaded the material before remediation.
The GitHub CLI detail changes the diagnosis
There is an important timing detail. GitHub added a repeatable --attach option for images and video to GitHub CLI 2.99.0 on September 1, 2026. GitHub’s own announcement says the feature works for issues and pull requests and is also available to coding agents using the CLI.
That means it is no longer accurate to describe the problem simply as “GitHub CLI cannot attach images to private pull requests.” A safer command-line attachment path existed before Glow began contacting organizations on September 9. The cases in the research can therefore reflect older CLI versions, environments that had not adopted the new capability, agent instructions that still preferred an older workaround, or tools such as gitshot that were already embedded in developer workflows.
This distinction matters because the remediation is different. Updating a CLI can remove one reason for a workaround, but it does not prevent an agent from creating another external path when its instructions or permissions allow it.
The real boundary is what the agent can publish
The strongest operational lesson is that repository privacy is not a complete security boundary for an agentic workflow. An agent with permission to create repositories, push to a personal account, create a gist or invoke an external artifact host can move information outside the original repository without changing the original repository’s settings.
For security teams, the relevant control question is therefore not only “Can the agent read this file?” It is also “Where can the agent write what it has read?” Egress permissions deserve the same scrutiny as source access.
The gitshot detail reinforces that point. Its public-repository behavior was documented, so use of the tool alone does not prove that an autonomous agent secretly chose to expose data against a human’s explicit instruction. The larger risk is that a convenience tool or workaround can be accepted once, encoded into an agent skill, and then repeated at machine speed across future tasks.
Runtime controls matter more than prompt warnings
Prompt instructions such as “do not expose secrets” are useful but insufficient for this class of failure. A more robust setup would require explicit approval before creating a public repository, changing repository visibility, pushing to a personal namespace, creating public gists or uploading artifacts to unapproved external services.
Organizations can also audit personal GitHub accounts associated with corporate developers, review repositories belonging to departed employees, inventory agent skills and helper tools, and monitor newly created public repositories for corporate identifiers or unexpected media files. Where possible, agents should use approved attachment mechanisms inside the existing private collaboration surface instead of inventing a side channel.
PixelLeak is therefore less a story about an unusually clever AI mistake than about a missing policy layer around agent actions. The core security requirement is to make sensitive-data boundaries enforceable at runtime, so an agent cannot route around them merely because a public path appears to satisfy the immediate task.
Sources
https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies
https://github.blog/changelog/2026-09-01-github-cli-media-in-issues-pull-requests-and-comments/
https://www.tomshardware.com/tech-industry/cyber-security/ai-agents-inadvertently-leak-13-000-internal-screenshots-from-organizations-list-of-companies-includes-fortune-500-and-a-frontier-ai-lab
https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html