Picture a normal afternoon with a coding agent. It fixes a broken table layout, runs the checks, and opens a PR. To make review easy, it attaches a before/after screenshot. You glance at it, the table looks right, you approve.
Now the question nobody asked in that review: where is that screenshot hosted?
What PixelLeak found
Glow Labs published research they call PixelLeak this week. The mechanism is almost boring.
GitHub lets you attach an image to a PR comment by dragging it into the browser. There is no equivalent for a CLI, which is where coding agents live. An agent that wants to show the reviewer a screenshot hits a wall. Rather than fail, agents found a workaround: create a public repository under the developer's personal account, push the image there, and link to it from the PR. Some teams used an open source helper that does the same thing.
Glow counted over 13,000 internal images in 900+ public repositories, from more than 300 organizations. The screenshots showed customer billing records, internal treasury and settlement consoles, money movement screens, and features that hadn't shipped yet.
The agent did its job
What bothers me most: there is no villain in this story. Nobody told the agent to publish anything. It was told, more or less, "show the reviewer what you changed". A public repo is a place where an image URL works without authentication. From the agent's point of view, that is a perfectly good solution.
We spend a lot of energy on what an agent may change in the code: which files, which commands, which branches. We spend much less on where its byproducts go. Screenshots, logs, HAR files, screen recordings, test fixtures dumped from a real database. None of those are code, so none of them go through the same review. And a screenshot of an internal tool is often more sensitive than the diff it documents.
What I'd put in place
1. Treat review evidence as data. A screenshot of a billing screen is customer data, the same as a database dump. It falls under the same rules about where it may be stored and who may see it.
2. Give the agent a sanctioned place. If there is a private, approved location for evidence (an artifact store of your CI, a folder inside the project that never leaves your infrastructure), the agent has no reason to improvise. Agents improvise when the obvious path is blocked.
3. Make "I couldn't attach it" a valid outcome. The workaround happened because failing felt worse than succeeding creatively. Say in your agent instructions, and ideally enforce in tooling, that "here is the local path, I could not upload it" is a complete answer.
4. Restrict what the agent's credentials can do. If the token the agent uses cannot create public repositories, this whole class of leak is gone. That is a much stronger guarantee than a sentence in a prompt.
5. Audit today. Look at your GitHub account and your team's accounts for repositories nobody remembers creating, especially ones full of PNGs.
Where this sits in my own work
I'm building Semitexa, a PHP framework designed for working with AI agents. There, the agent's work log (what it planned, what it ran, what it verified) is kept as local files inside the project rather than on an external host. That was a design choice for reviewability, but PixelLeak made me realize it matters for leakage too. Screenshots and other visual evidence are not covered yet; they are on our list now, with the same rule: evidence stays where the code is. The longer version, with a test matrix for the refusal path, is on semitexa.com.
Your turn
How does your team handle visual evidence from agents today? Do you let them post screenshots to PRs at all, and if so, where do the files actually live?
Top comments (0)