AI security

Researchers at Glow Security, whose research appears under the Glow Labs name, found more than 13,000 internal screenshots that AI coding agents had published to public GitHub repositories. The images came from developers at more than 300 organisations and sat in more than 900 repositories. Glow's CTO, Omer Singer, gave The Register a precise count of 343 organisations; the published research says "more than 300". Glow named no companies, but says they include one of the largest tech companies, a frontier AI lab and a Fortune 500 travel company.

Nobody hacked anything. Developers asked their agents for before and after screenshots of interface changes, and the agents, unable to attach images to a private pull request from the command line, found a public place to put them. If your developers use coding agents on anything with a user interface, check for this. In 93% of cases the images sat in repositories under employees' own GitHub usernames, where an organisation audit does not look.

How it works

A developer who changes a billing page wants a pull request (PR) that shows the screen before and after. In the browser, GitHub lets you drag an image into a PR description and hosts it for you. From the command line there was no equivalent. GitHub has no API for uploading images to PRs, issues or comments, and its CLI, gh, only gained an --attach flag in version 2.99.0 on September 1, 2026.

An agent that cannot attach an image will still try to finish the task. The Register quotes one agent's reasoning: GitHub cannot render images from a private repository in a PR description because its image proxy fetches them anonymously. So the agent created a public repository to host the images, often under the developer's personal account, linked them into the private PR and showed the developer a result that rendered. The developer approved it.

Glow reproduced this with Claude Code on an internal Minesweeper build kept in a private repository named internal_sweeper. Unable to attach screenshots, the agent created a new public repository, sweeper-demo/pr-assets, to hold them. Singer told The Register the behaviour comes from "multiple models", not one vendor.

About a third of the affected organisations had developers using gitshot, an open-source tool that publishes screenshots for code review. Its default backend creates a public repository under the user's account and stores the images as release assets under a tag called _gitshot. The tool warns users not to upload private data with that backend, yet agents found it and used it anyway.

At one software vendor, more than a dozen agents saved the method as a reusable skill within a week, and later sessions used it to upload more than 1,000 screenshots and screen recordings, including unreleased features. A saved skill keeps running after the original limitation is fixed.

What leaked

Glow describes billing records for a utility company, captured from an internal billing screen at a manufacturer with more than 100,000 employees. The agent there ran on an employee's laptop and published to the employee's personal account, so the company's security team did not know until Glow told it, and the images were still online at that point. At a financial services firm, screenshots showed a treasury and settlement console, including a withdrawal screen for a named institutional client. Glow also found personal information and credentials in some images. More than 100 public accounts leaked internal work this way.

Glow began notifying affected organisations on September 9 and expects that others it has not identified are affected. The counts are Glow's own: it has not published its full counting method, and nothing published so far shows whether anyone other than the researchers downloaded the images.

Text-based data loss prevention (DLP) tools were unlikely to catch this, because the customer records were rendered inside images.

What to do

1. Find what is already public

Start with members' personal accounts. List members with gh api --paginate orgs/ORG/members --jq '.[].login', then for each login run gh repo list LOGIN --visibility public --json name,createdAt,description and open anything recent that holds images, such as repositories named like *-assets, *-demo or anything mentioning gitshot. Check for a _gitshot release on suspect repositories with gh release view _gitshot -R LOGIN/REPO, and look at public gists too. Then search your private repositories' PR descriptions and comments for image links that point to a repository under a personal account, including raw.githubusercontent.com and /releases/download/ links. Developers who use a personal account that is not in your organisation will not show up in the member list, so ask them directly.

2. Take it down and rotate

Delete the public repository or release, not just the PR comment that links to it. Read every image before deleting it, and rotate any credential, API key or session token visible in one. If an image shows customer records, such as the billing data Glow found, treat it as a possible data exposure and involve whoever owns your breach notification decisions.

3. Restrict public repositories

In the organisation, go to Settings, Member privileges, Repository creation, and allow private repositories only (on GitHub Enterprise Cloud you can limit members to private). That setting covers repositories inside the organisation, not personal accounts. Only Enterprise Managed Users stops personal public repositories: managed user accounts cannot create public repositories or gists at all. Without it, the controls for personal accounts are policy and the agent configuration below.

4. Give agents a private route

Update gh to 2.99.0 or later so agents can use gh pr create --attach ./after.png or gh pr comment --attach, which keeps the image with the repository and needs write access to it. GitHub Enterprise Server is not supported by --attach yet, so teams on Server need another approved internal image host. Then add deny rules for the commands that make data public. In Claude Code, for example, a managed settings file can deny Bash(gh repo create *), Bash(gh gist create *) and Bash(gh repo edit *). Claude Code's documentation says such rules do not match the same program run another way, such as by full path or inside sh -c, and gh api can create a repository too, so treat them as guardrails backed by the GitHub settings in step 3.

5. Audit saved instructions and tools

Search CLAUDE.md, AGENTS.md, .cursor/rules and every saved skill or workflow for "screenshot", "gitshot", "public" and "pr-assets", and remove workarounds written before September 1. Remove gitshot and similar tools that have not been through a security review. Glow's advice is to make these settings the security team's job, rather than each developer's, and to require human approval before an agent creates a repository or changes one from private to public.

The wider lesson

Most agent controls focus on what an agent can read: repositories, secrets, production systems. PixelLeak came from the other direction, from where an agent was allowed to publish. Before you approve an agent workflow, run it in a test environment, ask it to screenshot a change and attach it to a private PR, and trace every place it sends data.

Our attack surface management work includes looking for your data in public places like personal GitHub accounts, and our safeguarding and hardening team can set up GitHub and agent policies that hold. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Help Net Security, The Register, eSecurity Planet, Let's Data Science, GitHub changelog: media in the GitHub CLI, GitHub Docs: restricting repository creation, GitHub Docs: managed user accounts, Claude Code permissions.