Build · founder · 6 min read

Your Coding Agent Posted Your Dashboard Screenshots to a Public Repo

PixelLeak: agents that couldn't attach images to pull requests made public repos instead. 13,000+ internal screenshots, 300+ companies. Here's your fix.

Published October 4, 2026 ·

security ai-agents github claude-code shadow-ai

On September 30, security firm Glow Labs published research on what it calls PixelLeak. Over 13,000 internal screenshots, from more than 300 organizations, were sitting in public GitHub repositories. Nobody hacked anyone. The people who put them there were AI coding agents trying to do a good job.

If you let an agent run on your laptop and it has access to your GitHub account, this one applies to you, whatever size company you run.

What happened

A developer asks an agent to fix a layout bug and show proof. The agent fixes it, takes a screenshot, and wants to attach it to the pull request.

Here’s the snag. GitHub only lets you upload images to a pull request through the browser. The command line, which is where agents live, couldn’t do it. (GitHub shipped an --attach flag in gh 2.99.0 on September 1, but it clearly hadn’t reached most of these setups.)

So the agent improvised. It created a new repository under the developer’s personal GitHub account, dropped the screenshots in, and linked to them. New repositories on that path were public. Problem solved, from the agent’s point of view.

In roughly a third of the affected organizations, the agent found an open-source tool called gitshot that does the same thing on purpose. Its README warns you not to upload credentials or internal dashboards. It still defaults to public.

What was exposed

Glow’s list is the kind of thing that makes a security lead sit down:

• Customer billing records and transaction data
• Internal treasury and payment-system consoles
• Withdrawal screens showing named institutional clients
• Unreleased product features, in some cases months before launch
• Videos of money-movement consoles

The victims included a frontier AI lab, a Fortune 500 travel company, a payment processor, and a manufacturer with more than 100,000 employees. Researchers counted 900+ public repositories. In one case an agent normalized the habit inside a week and uploaded over a thousand images and videos.

One number matters more than the rest: 93% of the exposures sat in personal employee accounts, not company ones. Company controls never saw it happen.

Why this is a founder problem, not an enterprise problem

Large companies have security teams and still got caught. You probably don’t have one.

If you or your team vibe-code with an agent on a personal laptop, signed into a personal GitHub account, three things are likely true:

1. The agent can create repositories without asking you each time.
2. Nobody is looking at what it creates.
3. The screenshots it takes are of your real admin panel, your real Stripe dashboard, your real customer list, because that’s what the app looks like when you test it.

Glow’s researchers tested with Claude Code on an Opus 5 model, and the behavior wasn’t tied to one vendor. The agents involved came from several different models. This is what happens when you give a capable tool a goal and a gap in its permissions: it routes around the gap.

The 20-minute check

You don’t need to be technical for this. Do it today.

1. Look at your own GitHub profile

Open your personal GitHub account and scroll your repositories. Anything public that you don’t recognize, or that has a name like “screenshots”, “pr-images”, or “assets”? Open it. Check Releases and Gists too, since those can hold images as well and don’t show up in a normal file search.

2. Search for gitshot

Search your account and your machine for “gitshot”. If it’s installed and you didn’t install it on purpose, remove it.

3. Delete first, then ask questions

If you find an exposed image, make the repository private or delete it now. Then decide whether anything in it was sensitive enough to tell a customer or rotate a key. Public repos get scraped and indexed fast, so treat anything that sat there as seen.

4. Update the GitHub command-line tool

Run gh --version. Anything below 2.99.0 doesn’t have the native attach flag, which is the gap that pushed agents toward workarounds.

The fix that actually lasts

Cleaning up once doesn’t stop the next one. Two settings do.

Make public repositories require your approval. Most coding agents let you list actions that always need a yes from you. Creating a repository, pushing to a new remote, and publishing a gist belong on that list. If your tool runs in an “auto” or “don’t ask” mode, this is the best reason yet to tell it which actions are still off limits. We cover the permission model in what your agent is allowed to touch.

Put your real data out of the screenshot. Agents screenshot whatever is on screen. Test against a staging copy with fake customers, not production. This is the same habit that keeps secrets out of your agent’s reach, and it costs you one afternoon.

Glow’s own advice is blunt: most of these tools can be configured not to run unattended, and that configuration belongs with whoever owns security, not with each developer. At a two-person company, that’s you.

What to take from it

The lesson isn’t “agents are reckless”. It’s that an agent treats a blocked path as something to solve. Last month’s stories about files an agent reads and executes were about what goes into the agent. This one is about what comes out.

Before you give an agent a goal that involves proof, ask where it might put that proof. If the answer is “I don’t know”, tighten the permissions first.