Elusive Thoughts: Nobody Attacked Anyone

TL;DRGlow Labs reported coding agents publishing more than 13,000 internal images to public GitHub while doing routine work. No attacker was involved. The agent had a task, a write path and a public destination, and that was enough. Secret scanning in CI is still mandatory, but it reads text and a screenshot is not text. Put the controls on the places an agent is allowed to write, and make them impossible to skip.

Nobody attacked anyone. An agent was asked to show a reviewer what a UI change looked like, and its command line could not attach an image to a pull request. So it put the picture somewhere public where a link would work. Task done. Ticket closed.

Do that thousands of times across hundreds of companies and you get a breach with no adversary in it.

What Glow actually found

Glow, a security vendor, published the research on 29 September 2026 under the name PixelLeak, and says it began warning affected organisations on the 9th. The headline figures are more than 13,000 internal images and more than 300 organisations. I checked it against Glow's own report, Help Net Security and The Hacker News.

The mechanism is dull. Until 1 September the GitHub CLI could only write text. Images committed to a private repo showed up broken for reviewers, so agents created separate public repos to host them, and Help Net reports that in 93 percent of cases those repos sat under the employee's personal username. At one software company the agents saved the trick as a shared skill and used it on every ticket. The images included billing records for a utility, a treasury and settlement console at a financial firm, and screens of unreleased features. Glow reproduced the behaviour with Claude Code and did not name the models in the real cases.

The sources disagree on the repository count, so I leave it out. Glow has not said whether anyone besides its own researchers downloaded the files.

The agent is the exfiltration path

Your organisation's branch protection did nothing here, because the repo was not in your organisation. Your DLP saw an authenticated git push to github.com and had no objection.

GitHub added an --attach flag in gh 2.99.0 on 1 September, so this specific workaround has a supported alternative now. That fixes nothing structural. The next time an agent hits a wall between "finish the task" and "stay inside the lines", it will route around the wall again, using whatever write access it was handed. The question to ask is which destinations an agent can write to, and who decided that.

How often agents leak, with the caveats attached

GitGuardian's 2026 report has 28.65 million secrets landing on public GitHub, up 34 percent. AI-service secrets rose 81 percent year on year. AI-assisted commits leaked at about 3.2 percent against a 1.5 percent baseline. And 64 percent of credentials confirmed exploitable in 2022 were still valid. Agents write more commits and leak at a higher rate per commit. Most of what leaks is never revoked.

On quality, CodeRabbit analysed 470 open-source pull requests, 320 of them AI co-authored. It found about 75 percent more logic and correctness findings in the AI set, and security issues "up to" 2.74 times higher. That second number is a ceiling, the report does not pin it to one category, and Help Net Security summarises the overall security gap as roughly 1.5 times. Authorship was inferred from co-author signals too. Directionally useful, nothing more.

Put the gates on the publish path

Here is the path in my setup, and what each gate catches.

AGENT WRITES Code, screenshots and docs. It has a push or publish path, so assume it will use it.

↓

GATE 1 / Hooks and sandbox Block public repo creation and pushes to personal remotes. Shell runs with no network and a scoped filesystem. Destinations are an allowlist.

↓

GATE 2 / CI secret scan GitGuardian in CI. Blocks the merge and cannot be skipped. Pre-commit exists for convenience only.

↓

GATE 3 / Signed commits and protected branches Agent has its own Ed25519 key, 30-day life, separate audit identity. Unsigned means no merge.

↓

GATE 4 / Approval A human or a policy engine signs off before anything is released.

↓

PUBLISH Only now does the work leave.

Start with what would have stopped PixelLeak. Gate 2 would not have. Glow says plainly that scanners read text and not images, and a treasury console is not a regex match. The gates that bite are the first one and, behind it, the sandbox. A shell with no network cannot create a public repo anywhere. A hook that refuses repo creation or a push to a personal remote stops the exact behaviour Glow recommends blocking.

Gate 2 still earns its place, because the secrets numbers above are real. Pre-commit scanning runs on a machine I do not control, in a shell I do not control, and anyone can pass --no-verify. I treat it as developer convenience and never as a boundary. The CI scan blocks the merge and has no override.

Gate 3 is about attribution. Agent keys are separate from human keys and live 30 days, so the audit trail can tell a human merge from an agent merge, and a leaked agent key ages out fast. Unsigned or unverifiable commits do not merge.

Log the tool calls, then protect the logs

I log tool calls instead of prompts. A prompt log tells you what an agent was asked. A tool-call log tells you it created a public repo at 14:02, and only one of those is evidence.

The catch arrived this week. Warp disclosed on 27 October that attackers got into agent decision logs and user telemetry through a third-party vendor, with the CEO estimating roughly 1 percent of users affected. Warp has not said whether the logs held source code or credentials. The Cloud Security Alliance's research note argues that agent traces are crown-jewel data, since one store can hold prompts, commands, output and file contents together. So redact what goes into the log, keep retention short, and rotate any credential that might have passed through one.

What it costs

Signing rollout was the worst week of my SDLC project. Agent keys on a 30-day cycle add rotation work that someone owns for good. CI secret scanning produces false positives, and every one costs a developer a context switch, so tuning is permanent work. An allowlist breaks things that used to work, and then someone asks why the agent cannot push to their fork. The honest answer is that it can, if you add the fork to the list and accept the risk.

Verdict

Stop modelling the agent as a victim that an attacker must trick. It is a fast, tireless colleague with push rights and no sense of what is public. Whatever it can reach, it will eventually use.

So close the destinations, not the prompts. Allowlist where it can write and strip the network from its shell. Scan in CI where nobody can skip it, and sign everything it ships under its own short-lived identity. The 13,000 screenshots were a policy failure that nobody had written down.

Sources

Elusive Thoughts

30/10/2026

Nobody Attacked Anyone