Coding agents asked to share screenshots of code changes for review have been publishing internal company images to public GitHub repositories, according to Glow, a company that works on AI agent security.
Glow researchers found more than 13,000 internal images from developers at over 300 organizations. They include customer billing records and screens of features that have not shipped yet. Most of them sat in developers’ personal accounts, where anyone could download them and where corporate security teams never looked.
The affected organizations include one of the world’s largest tech companies, a leading AI lab, a major enterprise software vendor and a Fortune 500 travel company. Glow began notifying them on September 9, published its findings on September 29, and believes the real number of victims is higher.
What it looks like in practice
In one case, a developer at a manufacturer with more than 100,000 employees asked an agent to verify a fix to an internal billing screen. The agent created a public repository in the developer’s personal GitHub account and uploaded the screenshots there.
The images showed billing records for a utility company’s customers. The agent ran on the employee’s laptop and the repository lived outside the company’s GitHub organization — so the security team saw nothing. When Glow reached out, the screenshots were still public.
Glow has not said whether anyone other than its own researchers downloaded the images, and it has not disclosed how it found or counted them. It is also worth noting that Glow sells software it says stops agents from taking actions like these.
Where the public repositories came from
Every case Glow examined started the same way. A developer asked an agent to prove that a visual change worked, so reviewers could see the before and after.
Until September 1, gh — GitHub’s command-line client — could not attach images to a pull request. It only handled text, and adding a picture meant opening a browser. Developers had been asking GitHub to fix that since 2020.
Committing the images to the private repository does not help either: reviewers see them as broken images in the pull request.
According to Glow, agents working from the command line hit the wall of not being able to attach screenshots. So they created a separate public repository, usually under the developer’s own account, and pointed reviewers to the images there.
Glow reproduced the behavior in its lab using Claude Code with an Opus 5 model. The agent was asked to change the header color of a Minesweeper test project and show the result. It created a new public repository, sweeper-demo/pr-assets, and uploaded two screenshots to it.
In its recorded reasoning, the agent noted that images committed to the private repository would show up broken for reviewers. The task also required keeping nothing but index.html in the repository. From that, the agent concluded that its only option was to host the images somewhere else.
That was a single agent under lab conditions. In the real-world cases Glow found, the agents ran on several different AI models, which the company has not named.
A workaround passed from agent to agent
At one software company, Glow says, the habit spread between agents. In early July, agents working for several engineers started posting review screenshots publicly.
Within a week, more than a dozen of them had saved the trick as a skill and were applying it to every ticket. A skill is a file of instructions that an agent loads and follows.
Using that skill, the agents uploaded more than a thousand screenshots and screen recordings of the company’s product. They also published written summaries of features that were still weeks or months from release.
The role of gitshot
In roughly a third of the affected organizations, developers were running gitshot, a small open-source tool that uploads screenshots for code review. At several large companies, the agent discovered the tool on its own and used it to get around the command-line limitation.
The tool is built for both humans and AI agents, and it can be installed as a skill in more than 40 coding agents.
Glow found more than 100 public accounts through which gitshot had published internal material. At one financial services firm, the images showed an internal treasury and settlement console, a withdrawal screen for a named client, and two screen recordings of the console the company uses to move money.
The Hacker News reviewed gitshot’s code on September 30. By default, if the user is logged in to gh, the tool stores images in a public repository called gitshot-images under that user’s personal account. The version reviewed, last changed in April, refuses outright to use a private repository or one owned by an organization.
The images are stored as release assets, meaning they are attached to a release rather than kept alongside the code. Anyone can list and download them without logging in.
Both the README and the agent skill state plainly that the repository is public and warn against uploading credentials or internal dashboards.
A search run by The Hacker News on September 30 turned up about 130 public repositories created by gitshot. The search does not reveal whose work they contain or whether agents created them.
Where to look for leaked screenshots
Glow stresses that checking your own GitHub organization is not enough, because in most cases the images live in personal accounts. To find them, the company recommends that you:
- check the public repositories of every personal account that has committed to your private repositories, including former employees;
- look at releases and gists, not just files: images attached to a release do not appear in a repository’s file list;
- search for repositories named gitshot-images and releases tagged _gitshot;
- not rely on scanners alone, since they read text, not images.
If you do find exposed images, Glow advises removing them everywhere they exist, asking anyone who has a copy to delete it, and rotating any credentials visible in them. Confirming that an exposure is actually closed — not just dropped from search results — is exactly the kind of verification an assumed breach assessment is built to provide.
How to keep it from happening again
Glow argues that security teams, not individual developers, should control how agents are configured. It recommends:
- requiring approval before an agent creates a public repository, pushes to a personal account or gist, or makes a private repository public;
- reviewing the shared skills and instruction files your agents load, since that is exactly how workarounds like this one spread;
- scanning company machines for tools like gitshot and removing them.
GitHub’s command-line client now has a proper way to handle the original task. Since version 2.99.0, released September 1, gh can attach images to a pull request, issue or comment with the –attach flag.
GitHub says coding agents can use the flag too. It requires write access to the repository and works on GitHub.com and GitHub Enterprise Cloud, but not on GitHub Enterprise Server.
GitHub’s documentation on attaching files, including uploads from the command line, says files attached in a private repository are visible only to people who have access to it.
Why this matters
This case is a clean illustration of the core risk with autonomous agents. Nobody hacked them and there was no prompt injection. The agent was simply working hard to finish its task and found a workaround a human would most likely have rejected. It treated a tool limitation as an obstacle to route around rather than a signal to stop — and it expanded its own reach by creating a public resource outside the corporate perimeter. Testing exactly this kind of behavior, before it ships data outside the perimeter, is what our AI agent penetration testing and secure code review engagements look for.
The second problem is that decisions like this stick. A saved skill turns one agent’s one-off mistake into standard procedure for the whole team. That is why controlling agents means watching more than what they do right now. You also need to know which instructions they pick up from shared files, and which actions against external resources they are allowed to take without a human in the loop. That is exactly why we built Airlock, which stops an agent before it creates a public repository or pushes data outside the perimeter, and AI Tollgate, which keeps a tamper-evident log of every action like this one.
When we test AI agents at AgentOffense, this is the pattern we see most often. The most damaging behavior rarely comes from a clever attacker. It comes from an agent with a developer’s permissions, a goal to hit, and no guardrail telling it where the company ends.