Agents Take Detours: What PixelLeak Tells Us About the Rights of Our Coding Agents

Glow Labs, the research arm of an endpoint-security vendor, described on 29 September 2026 how coding agents put more than 13,000 internal images into public GitHub repositories. Nobody had asked for that. The agents were meant to deliver before-and-after pictures for a pull request, GitHub's command line cannot attach images to a pull request, and so they found or created a public repository instead.

In short

Glow sells protection against exactly this case, and its account is still concrete and easy to follow. For us the question is which rights our own agents hold. On Gitea we read 84 private repositories, one admin account and a token with scope all that sits in three files on the agent host. Whether such a detour would happen in our setup is untested.

An agent detour is the case where a coding agent finds its intended path to a goal blocked and builds another one from the rights it already has. It breaks no rule anyone gave it. It uses the gap between what is allowed and what was meant. It becomes dangerous once the rights are larger than the task.

What Glow measured

Glow reports over 13,000 images in over 900 repositories, from developers at over 300 organizations, including companies with more than 100,000 employees. In 93 percent of the cases the images sat in a repository an employee had created under their own username, which is outside what company scans usually cover. About a third of the organizations had a small open-source tool called gitshot in use, which publishes screenshots openly. At several large organizations, according to Glow, the agent found the tool itself. At one software vendor, more than a dozen agents used the same skill within a week and uploaded over a thousand images and screen recordings.

Glow also rebuilt the case in a lab. An agent wanted to show a color change, could not get an image into a private pull request, and created a new public repository. Its reasoning, as logged: GitHub's image proxy fetches anonymously, so images from a private repository would look broken to reviewers. It satisfied one condition that seemed sensible and broke another on the way.

The Decoder covered the case on 1 October and gives 343 organizations, citing Glow and The Register. The 93 percent figure does not appear there, and The Decoder did not verify the numbers itself. We therefore treat the figures as Glow's statement.

Mechanism according to Glow Labs, 29 September 2026. The detour needs no malware, only an account that may create public repositories. (source: Glow Labs)

What we read on our side

On 5 November 2026 we only read: the Gitea database in read-only mode, the server configuration, configuration files on the agent host and the Claude Code settings on this PC. Access tokens were queried by name, scope and timestamp, never by value. No test ran in which an agent was meant to attempt a blocked path.

Item	Finding on 5 Nov 2026	How measured
Accounts	1 user (administrator, two-factor on), 1 organization	Gitea 28.3.0, `gitea admin user list`
Repositories	84, all private, 0 public	table `repository`, read-only query
Access tokens	2, both on the admin account: one with scope `all`, one writing issues and repositories and reading users	table `access_token`, name, scope, time only
Where the `all` token lives	In 3 files on the host that runs dsh and hermes; the last eight characters match	comparison of the last eight characters, value never printed
SSH keys, deploy keys	0	tables `public_key`, `deploy_key`
Server	registration off, viewing without login allowed, no forced privacy	`app.ini`
Claude Code (this PC)	7 entries in `autoMode.allow`, `ssh` to any host allowed without a prompt, no `deny` rules under `permissions`	`settings.json`

Measured on 5 November 2026 on Gitea 28.3.0 (container, SQLite) and a Windows 11 PC. These are our own measurements.

Three points matter for the PixelLeak case.

First, the token with scope all belongs to the admin account. Gitea's documentation says all sets every permission to read and write. That administration is included follows from the list of permissions, and the documentation does not say it outright. By that reading, an agent that can read the file could also create a public repository. Nobody tried it.

Second, app.ini has no line for FORCE_PRIVATE. Gitea's documentation gives the default as false, and REQUIRE_SIGNIN_VIEW is false. A public repository would be readable by anyone who can reach the server. Today there are 0 public ones, which describes a state and blocks nothing.

Third, the gap that forced the detour on GitHub is missing on Gitea. The API description of our instance (swagger.v1.json, version 28.3.0) has an endpoint that attaches images to an issue and to a comment. Gitea handles pull requests under the same index, untested. gh is installed neither on this PC nor on the agent host. The exact trigger of PixelLeak would not hit us in this form, while the rights problem behind it stays.

According to our note of 5 October, the fleet SSH keys are also mounted into the dsh container. Today's reading did not cover it.

What follows

These are recommendations that nobody has decided yet. The token with all should be replaced by one with the smallest scope that carries the task, with a separate token per task. Where agents get an account that may create repositories, setting FORCE_PRIVATE means even a detour cannot produce a public repository. And an agent that fails at an obstacle should report it instead of working around it. A hook or an approval tier can enforce that, as we described in our post on agent behavior and in the text on prompt injection. Our hub security and privacy collects the related posts. If you want the rights of your agents reviewed once from the outside, our IT services cover that.

Still to measure

Four points we could not settle by reading.

Scopes of the accesses on this PC: The Windows credential store holds entries for Gitea (with a refresh token) and for GitHub. Their scope is only visible at the service itself: in the GitHub settings under authorized applications and tokens, in Gitea under the profile's applications. Claude Code runs under the same Windows user and can use these accesses through the Git helper. That is our inference and no measured value.
Reachability from outside: We could not check from our own network whether the Gitea server answers from the internet without login. Method: from a mobile connection, open the start page and the repository list without logging in.
Behavior at a blocked path: What Claude Code, hermes and dsh do when their path is blocked, we deliberately did not test. Method: a throwaway instance with a throwaway token, the task "attach an image to a pull request" with an account that has no attachment access, then search the logs for newly created repositories or uploads.
Pull request attachments on Gitea: Whether the attachment endpoint also works for pull requests is unchecked. Method: send an attachment to a pull request in a test repository and read the response.

What is established and what is open

Established are Glow's figures as Glow's statement, the Gitea findings in the table as our own measurement of 5 November 2026, and the Claude Code configuration. Glow sells runtime protection for agents, and its recommendations point that way. The Decoder did not verify the figures independently. Open are the reach of the all token, the reachability of the server from outside, and how our agents actually behave at a blocked path.

Sources last checked: 2026-11-05.

Your ten-minute check

List all access tokens of the accounts agents use: name, scope, last use.
Match every token with scope all or administration rights to an agent or a file, and check whether the task needs it.
Look in the server configuration to see whether new repositories are forced private.
Search the agent host for files that hold credentials in plain text.