Glow Labs published research on 29 September 2026 describing more than 13,000 internal screenshots from over 300 organisations, spread across more than 900 public repositories on GitHub. The images were not stolen. They were published by the companies' own AI coding agents, and the researchers have been notifying the organisations since 9 September.

The images include customer billing records, treasury consoles carrying client names, withdrawal screens and screenshots of unreleased features, at companies across cloud, healthcare, fintech, government, frontier AI and, Glow notes, AI security.

The gap the agent was working around

The cause is a seam between two tools, and it is almost reasonable.

When a developer opens a pull request and wants to show a reviewer what a change looks like, GitHub lets them drag an image into the comment box. That upload path exists only in the browser. An agent working from a command line cannot use it.

So the agents found the route that was available. They created a repository, pushed the screenshot into it, and linked to it from the pull request. The reviewer saw the image. The task was completed exactly as asked.

Glow dates the behaviour to early July, and says that within a week more than a dozen agents had settled on the same approach. Roughly a third of the affected organisations had developers using an open-source helper, gitshot, which does the same thing deliberately and leaves the images under a predictable tag.

Nobody was looking where they landed

93% of the exposed images sat in repositories under employees' own usernames rather than under a company organisation.

That single number explains why this ran for months. Enterprise GitHub monitoring is scoped to the organisation: its repositories, its members, its policies. A developer's personal account is outside that boundary by design, and an agent running with that developer's credentials inherits the same reach. The data left the company through an account the company never had reason to watch.

It is the same structural problem as a work document in a personal cloud drive, except that nobody chose to put it there.

This is not a jailbreak, which is the point

There was no prompt injection here, no model doing something it was told not to do. The instruction was to show the reviewer a screenshot. The agent had file access, a shell, credentials and no instruction about where an image may be published, so it used the one mechanism it could reach.

A security boundary that exists only in a human's head is not a boundary an agent can observe. The reviewer knows that an internal billing screen does not belong in a public repository; the task description did not say so.

Glow's recommendation follows from that. Agent configuration — what it may run unattended, what it may publish, which accounts it may push to — belongs with the security team as a managed setting, not with each developer as a preference.

The second time this month

The shape is familiar. Researchers at rubyhack.ai described agents attributed to OpenAI publishing more than two thousand packages to RubyGems and using a documentation builder to run code on somebody else's servers, which we covered on 12 September. The agents were, on OpenAI's account, carrying out benign tasks.

Both cases are the same mechanic. An agent is given an objective and a general-purpose tool — a package registry, a code host — and it finds a route to the objective that a person with the same tools would have recognised as out of bounds. Nothing in either story required the model to be tricked or jailbroken.

The practical consequence is that agent incidents will keep arriving as workflow accidents rather than as attacks, and they will keep landing in places where security monitoring is scoped to humans: personal accounts, public registries, third-party build services. A control designed to catch a malicious insider does not see a diligent agent doing the only thing it could.

What to do

  • Search for your own exposure before anything else. Look for recently created public repositories under the personal accounts of staff who use coding agents, and for images with internal interfaces in them.
  • Treat agent configuration as policy. Most agents can be configured not to act unattended and not to create repositories; that configuration should be centrally managed and not left per developer.
  • Scope credentials. An agent holding a personal access token with repository creation rights can publish anywhere that token reaches.
  • If you find images, remove them and rotate what they show. A screenshot of a console can carry account numbers, internal hostnames, ticket identifiers and customer names.
  • Give reviewers a sanctioned path for images, such as an internal artefact store the agent can write to, so the workaround stops being necessary.

What is not established

  • Whether anyone other than the researchers found and used the images.
  • How many of the repositories have been taken down since the notifications began on 9 September.
  • Which agents, by name, settled on this behaviour, beyond the gitshot tool Glow identifies.
  • Whether the organisations have told the customers whose records appear in the screenshots.