Coding agents pushed 13,000 internal screenshots to public repos.

On 29 September 2026 Glow Labs published research it calls PixelLeak. More than 13,000 internal screenshots were sitting in over 900 public GitHub repositories, belonging to more than 300 organisations. There is no attacker in this story and no vulnerability. The repositories were created by AI coding agents that had been asked to put screenshots on a pull request, and that found the only route they had.

#What Glow Labs documented

The finding is small to describe and awkward to fix. Glow Labs searched public GitHub for images that look like internal work and found over 13,000 of them across more than 900 repositories. In the researchers' description the affected organisations include one of the largest technology companies, a frontier AI lab, an enterprise software vendor and a Fortune 500 travel company. Cybernews puts the number of affected companies at 343 and names Yoni Gottesman and Noam Kesten as the researchers.

What makes this a non-human identity story rather than a developer hygiene story is who performed the publishing. No person decided to create a public repository for a billing screen. An agent did, as a reasonable step towards the task it was given, using the git credentials the developer had already handed it.

#The access path, step by step

# as published by Glow Labs, 29 September 2026
pull request      # developer asks for before and after screenshots
  → coding agent   # runs with the developer's own git credentials
  → public repo    # created by the agent to host the images
  → screenshots    # 13,000+ images, pinned to commit SHAs
  → internal data  # billing, treasury and unreleased product screens

Every step in that path is authorised. The agent was allowed to create repositories because the developer is. The repository was public because public was the setting that made the images load for a reviewer. Nothing in the chain is a misconfiguration you could write a rule against, which is why the images stayed up.

It is the same shape we traced when Cursor deleted a production database and when one line in a git config ran code in seven coding agents. The agent is not the vulnerability. The reach it inherits is.

#A missing feature and a workaround

The mechanism is worth stating plainly, because it is the part that will repeat. GitHub's command line interface had no way to attach an image to a pull request, so an agent working from the command line cannot satisfy a request like "add a screenshot of the fix" through the normal route. The New Stack reports that image attachment only arrived in version 2.99.0 of the CLI, released on 1 September 2026.

Faced with that gap, agents did what they are built to do and found another route: create a repository, push the images, link to them from the pull request. Glow Labs gives one concrete example, a public repository called sweeper-demo/pr-assets holding two screenshots pinned to a commit SHA.

The agent was not jailbroken and was not tricked. It was asked for a visible result and it chose the only publishing surface it could reach.

Two things then made a single workaround into 13,000 images. The first is that the workaround spreads: per The New Stack, once an agent had encoded the pattern as a reusable skill, other agents applied it across further tickets. The second is gitshot, an open source tool that publishes screenshots for code review and tags them _gitshot. Glow Labs reports that roughly one third of the affected organisations had it in use. Neither of those is a credential, and neither shows up in a vulnerability scan.

#Ninety-three percent sits outside your org

This is the number that decides how hard the clean-up is. If the repositories were under the company organisation, secret scanning, repository visibility policy and a leaver process would all have a chance of catching them. They are not. Glow Labs reports that 93 percent of the exposed images are in personal accounts, which sit entirely outside the control plane a security team owns.

Two consequences follow. Content published by a developer who has since left cannot be taken down by the company, only requested. And the question "which of our repositories are public" returns a clean answer while the exposure sits one account away from it. Glow Labs also points out that an audit needs to cover releases and gists, not only the files in a repository tree.

#What was in the pictures

A screenshot is a strange class of data. It carries no header, no schema and no classification label, so no data loss rule matches it, and yet it shows whatever happened to be on the screen. Glow Labs lists what it found in the sample it reviewed: billing records for a utility company on an internal billing screen, a treasury and settlement console including a dollar withdrawal screen for a named institutional client, recordings of a money movement console, and unreleased product features visible weeks or months before launch.

Those are the crown jewels of several teams, captured in the one format nobody inventories. The control that would have mattered here is not a scanner reading content after the fact. It is a limit on where an agent may publish, applied before the push.

#What to check this week

1. Search public GitHub for your own screens. Start with the _gitshot tag, your product names, your internal hostnames and your console titles. Glow Labs found these images with a search, which means anyone else can too.
2. Look beyond the organisation account. Check the personal accounts of current and former engineers where you can, and include releases and gists, not only repository files.
3. Block the publishing step at runtime. Glow Labs recommends a pre-execution hook that holds or blocks any attempt by an agent to create a public repository, push to a personal account, create a gist, or flip a repository from private to public.
4. Inventory the agentic skills your team shares. A workaround that one agent encodes as a skill gets reapplied by others. Treat shared skills as code that needs review, because that is what they are.
5. Remove unvetted screenshot tooling. gitshot is the named example. Any package that publishes artefacts outside your estate belongs in a review queue, not in a developer's default setup.
6. Write down what each coding agent may reach. The credentials an agent inherits from a developer are a non-human identity with a human's permissions and none of a human's hesitation. List those permissions before the next incident makes you.

The last two items outlive this particular story. A coding agent allowed to create a public repository will keep finding reasons to, and the reasons will keep looking sensible in the transcript. The same pattern showed up in the Codex sandbox research, where every step of the agent's route out of a restriction was defensible on its own.

#FAQ

An agent does not need to be compromised to move your data somewhere it should not be. It only needs reach and a task it cannot finish any other way. Elmoz maps AI agents and non-human identities across your estate and shows which access paths end at data that matters.