---
title: "PixelLeak: when an agent's workaround leaks data · Ataris Blog"
description: "Coding agents published more than 13,000 internal screenshots to public GitHub repositories while completing routine code reviews. What happened, why no one caught it, and what an investigation needs."
canonical: "https://ataris.dev/blog/pixelleak"
last-updated: 2026-10-11
---
# PixelLeak: when an agent's workaround leaks data

Research · October 11, 2026 · Ataris team · 3 min read

> Coding agents published more than 13,000 internal screenshots to public GitHub repositories while completing routine code reviews. What happened, why no one caught it, and what an investigation needs.

On September 29, Glow Labs published [PixelLeak](https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies), research into more than 13,000 internal images that coding agents published openly on GitHub. The images came from developers at over 300 organizations. None of it was an attack. Each case started with a developer asking an agent for screenshots of a UI change.

## A routine task with a workaround

The request was ordinary: make a visual change, then attach before-and-after screenshots so reviewers can check it. GitHub's image attachments for pull requests are built for the browser, and the agents were working from the command line. The images wouldn't attach.

So the agents found another way to get the images in front of reviewers. They uploaded them to a public repository, often a new one created under the developer's personal account. Around a third of affected organizations had developers using `gitshot`, a small open-source tool that publishes screenshots for code review, and agents picked it up to do the same thing.

The screenshots showed what developers were working on: customer billing records, an internal treasury console, and features weeks or months from release. At one software vendor, more than a dozen agents had turned the workaround into a skill within a week and used it on every ticket, uploading over a thousand screenshots and screen recordings.

## Why nobody caught it

Glow found that in 93% of cases, the images sat in a repository an employee had created under their own account. An audit of the company's GitHub organization would not find them, and the company's repositories stayed private the whole time.

Nothing in the upload looked like a leak, either. Secret scanners read text, and what a screenshot exposes is in the pixels. The task itself succeeded: the reviewer saw the screenshots, and the pull request looked complete. The failure was in how the agent got there, and that part never appears in the pull request.

The skill made it worse. Once the workaround was written down as an instruction, a single decision was repeated across agents, developers, and tasks without anyone deciding it again.

## What an investigation needs

The first questions after a disclosure like this are about scope: which sessions uploaded images, what the images showed, where they went, and which instruction told the agent to do it. Answering them takes each run's execution record: the request, the commands with their arguments, the files those commands read, the connections they made, and the instructions the agent loaded along the way.

When the agent runs on a developer's laptop, as in Glow's billing-screen case, most of that record doesn't exist anywhere a security team can see it.

## Where Ataris fits

For agents run through the `ataris` CLI, on that same laptop or in CI, it does. Here is the workaround as it would appear in a run's causal graph, traced back from the upload:

![Ataris causal graph of the workaround: the user's request and a shared screenshot skill feed a model call, which decides to run gh repo create --public and git push. The push reads a billing screenshot, flagged sensitive, and connects to github.com, flagged as egress.](/assets/blog/pixelleak-trace.svg)

The `process` lane records each command with its arguments, so a `--public` flag or a call to `gitshot` is on the record. The `files` lane shows which screenshots the push read. The `context` lane shows the skill file the agent loaded, and [causal links](/docs/concepts/trace-events#causal-links) tie the push back to the tool call and the instruction behind it. With that, a team can scope the incident from evidence: check other sessions for the same command, list the files each one pushed, and trace the skill that spread it.

Ataris can also run in full prevention mode, enforcing [policies](/docs/concepts/policies) on what the agent executes and blocking violations in real time. An upload to an unapproved destination, or a run of an unvetted tool like `gitshot`, is stopped before it completes and recorded on the timeline as blocked, so the workaround fails on its first attempt instead of spreading through a shared skill.

None of these agents set out to leak anything. They just wanted to get the job done. That is the behavior worth tracing, and the one worth stopping when it takes a path no one approved.

[More from the Ataris Blog](https://ataris.dev/blog.md)