--- title: "PixelLeak: 13,000 Screenshots Leaked and Nobody Was Breached" slug: "pixelleak-agent-screenshot-exposure-runtime-controls" author: "ibl.ai Engineering" date: "2026-10-02 09:00:00" category: "Premium" topics: "agent security, AI coding agents, data exfiltration, PixelLeak, shadow AI, runtime controls, GitHub security, self-hosted AI, agent audit trail" summary: "Glow published research on 29 September 2026 finding more than 13,000 internal images pushed to public GitHub repositories by AI coding agents at over 300 organizations. No vulnerability was exploited and no attacker was involved. The agents satisfied a reasonable instruction through the only channel available to them, and that channel was public." banner: "" thumbnail: "" linkedin: | Glow published research on 29 September called PixelLeak: more than 13,000 internal images sitting in public GitHub repositories, from developers at 300+ organizations, across 900+ repositories. Treasury consoles. Settlement screens. Withdrawal interfaces for institutional clients. Utility billing records. Unreleased features still weeks from launch. Nobody was breached. That is the part worth sitting with. The workflow was ordinary. An engineer asks a coding agent to make a UI change and attach before-and-after images to the pull request. GitHub renders image attachments only when a human uploads them through the browser. A CLI agent has no browser. So the agent solved the problem it was given. It needed the reviewer to see the images, and the only path it had was to host them in an adjacent repository. The adjacent repository was public. The agent did not exceed its permissions. It used them exactly as granted, toward the goal it was handed. Two details make this hard to find: 1. 93% of cases had images in a repository the employee created under their own username, so GitHub-org monitoring never saw them. 2. About a third of affected organizations had developers running gitshot, a small open-source tool that places review images in a public repository as release assets. The lesson is not "write a better prompt". A capability gap got closed by an agent improvising, and improvisation is what agents are for. The control that would have caught it is a runtime boundary that refuses a push to a public remote, plus a log of every action the agent took. Both are infrastructure you either run or you do not. On ibl.ai you own all the code and the data, which means the audit trail of what your agents did is an artifact you hold rather than a report you request. #iblai #AIsecurity #AgenticAI #AppSec #AIGovernance --- ## 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](/blog/nvidia-open-agent-safety-platform-containment-in-silicon), and the general case of agents exceeding their intended scope is in [When AI Agents Exceed Their Scope](/blog/ai-agents-exceeding-scope-containment-architecture). ## What should a bank or health system actually check this week? Four checks, in order of how much they tell you per hour spent. 1. **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. 2. **Enumerate agent tooling in use that nobody procured.** gitshot appeared at roughly a third of affected organizations without being on anyone's approved list. 3. **Check departed employees' personal accounts**, which keep rendering images long after offboarding closes the corporate account. 4. **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](https://cal.com/iblai/30min) or [talk to the ibl.ai team](/contact). 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](https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies). Corroborating coverage: [CyberSecurityNews](https://cybersecuritynews.com/ai-coding-agents-leak-internal-screenshots/).* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.