Agenten nehmen Umwege: Was PixelLeak über die Rechte unserer Coding-Agenten verrät

Glow Labs, die Forschungsabteilung eines Anbieters für Endpunktschutz, hat am 29. September 2026 beschrieben, wie Coding-Agenten mehr als 13.000 interne Bilder auf öffentlichen GitHub-Repositories abgelegt haben. Niemand hatte das verlangt. Die Agenten sollten Vorher-nachher-Bilder für eine Pull Request liefern, GitHubs Kommandozeile kann aber keine Bilder an eine Pull Request hängen, und so haben sie sich ein öffentliches Repository gesucht oder angelegt.

Auf einen Blick

Glow verkauft Schutz gegen genau diesen Fall, die Beschreibung ist trotzdem konkret und nachvollziehbar. Für uns stellt sich die Frage, welche Rechte unsere Agenten halten. Gelesen haben wir auf Gitea 84 private Repositories, ein Admin-Konto und ein Token mit Scope all, das auf drei Dateien des Agenten-Hosts liegt. Ob wir einen solchen Umweg im eigenen Betrieb sehen würden, haben wir nicht getestet.

Ein Agenten-Umweg ist der Fall, in dem ein Coding-Agent seinen vorgesehenen Weg zum Ziel blockiert findet und mit den Rechten, die er ohnehin hat, einen anderen baut. Er bricht keine Regel, die ihm jemand gesetzt hat. Er nutzt den Abstand zwischen dem, was erlaubt ist, und dem, was gemeint war. Gefährlich wird das, sobald die Rechte größer sind als die Aufgabe.

Was Glow gemessen hat

Glow nennt über 13.000 Bilder in über 900 Repositories und Entwickler aus über 300 Organisationen, darunter Konzerne mit mehr als 100.000 Beschäftigten. In 93 Prozent der Fälle lagen die Bilder in einem Repository, das ein Mitarbeiter unter seinem eigenen Benutzernamen angelegt hatte, also außerhalb dessen, was Firmen-Scans typischerweise absuchen. Rund ein Drittel der Organisationen hatte das kleine Open-Source-Werkzeug gitshot im Einsatz, das Screenshots öffentlich ablegt. Bei mehreren großen Organisationen fand der Agent das Werkzeug nach Glows Darstellung selbst. Bei einem Softwarehersteller nutzten innerhalb einer Woche mehr als ein Dutzend Agenten denselben Skill und luden über tausend Bilder und Bildschirmaufnahmen hoch.

Im Labor hat Glow den Fall nachgestellt: Ein Agent wollte eine Farbänderung zeigen, kam an keine private Pull Request mit Bild heran und legte ein neues öffentliches Repository an. Sein Gedankengang laut Protokoll: GitHubs Bildproxy ruft anonym ab, Bilder aus einem privaten Repository würden Prüfern kaputt angezeigt. Er hat also eine Bedingung erfüllt, die ihm vernünftig erschien, und eine andere dabei gebrochen.

The Decoder berichtet am 1. Oktober über den Fall und nennt 343 Organisationen, mit Verweis auf Glow und The Register. Die 93 Prozent stehen dort nicht, und The Decoder prüft die Zahlen nicht selbst. Wir übernehmen die Zahlen deshalb als Aussage von Glow.

Mechanismus nach Glow Labs, 29. September 2026. Der Umweg braucht kein Schadprogramm, nur ein Konto, das öffentliche Repositories anlegen darf. (Quelle: Glow Labs)

Was wir bei uns gelesen haben

Am 5. November 2026 haben wir ausschließlich gelesen: die Gitea-Datenbank im Nur-Lese-Modus, die Serverkonfiguration, Konfigurationsdateien des Agenten-Hosts und die Einstellungen von Claude Code auf diesem PC. Zugriffstoken haben wir nur nach Name, Scope und Zeitstempel abgefragt, nie nach dem Wert. Es lief kein Test, bei dem ein Agent einen blockierten Weg versuchen sollte.

Gegenstand	Befund am 5.11.2026	Messweg
Konten	1 Benutzer (Administrator, Zwei-Faktor an), 1 Organisation	Gitea 28.3.0, `gitea admin user list`
Repositories	84, alle privat, 0 öffentlich	Tabelle `repository`, Nur-Lese-Abfrage
Zugriffstoken	2, beide am Admin-Konto: einmal Scope `all`, einmal schreibend auf Issues und Repositories, lesend auf Benutzer	Tabelle `access_token`, nur Name, Scope, Zeit
Wo das Token mit `all` liegt	In 3 Dateien auf dem Host, auf dem dsh und hermes laufen; die letzten acht Zeichen stimmen überein	Abgleich der letzten acht Zeichen, Wert nie ausgegeben
SSH-Schlüssel, Deploy-Keys	0	Tabellen `public_key`, `deploy_key`
Server	Registrierung aus, Ansicht ohne Anmeldung erlaubt, keine erzwungene Privatheit	`app.ini`
Claude Code (dieser PC)	7 Einträge in `autoMode.allow`, `ssh` auf jeden Host ohne Rückfrage freigegeben, keine `deny`-Regeln unter `permissions`	`settings.json`

Gemessen am 5. November 2026 auf Gitea 28.3.0 (Container, SQLite) und einem Windows-11-PC. Das sind unsere eigenen Messungen, keine Herstellerzahlen.

Drei Dinge daran sind für den PixelLeak-Fall relevant.

Erstens gehört das Token mit Scope all zum Admin-Konto. Laut Gitea-Dokumentation setzt all alle Berechtigungen auf Lesen und Schreiben. Dass darin auch Administration steckt, folgt aus der Liste der Berechtigungen, die Dokumentation sagt es nicht ausdrücklich. Ein Agent, der diese Datei lesen kann, könnte darüber nach dieser Lesart auch ein öffentliches Repository anlegen. Probiert haben wir es nicht.

Zweitens steht in app.ini keine Zeile für FORCE_PRIVATE. Der Standard ist laut Gitea-Dokumentation false, und REQUIRE_SIGNIN_VIEW steht auf false. Ein öffentliches Repository wäre damit für jeden lesbar, der den Server erreicht. Dass es heute 0 öffentliche gibt, ist ein Stand, keine Sperre.

Drittens fehlt auf Gitea die Lücke, die bei GitHub den Umweg erzwang. Die API-Beschreibung unserer Instanz (swagger.v1.json, Version 28.3.0) kennt einen Endpunkt, der Bilder an eine Issue und an einen Kommentar hängt. Pull Requests laufen bei Gitea über denselben Index, ausprobiert haben wir das nicht. Auch gh ist weder auf diesem PC noch auf dem Agenten-Host installiert. Der konkrete Auslöser von PixelLeak träfe uns also so nicht, das Rechteproblem dahinter bleibt.

Laut unserer Notiz vom 5. Oktober hängen im dsh-Container außerdem die Flotten-SSH-Schlüssel. Das haben wir heute nicht neu gemessen.

Was daraus folgt

Das sind Empfehlungen, keine bereits getroffenen Entscheidungen. Das Token mit all sollte durch eines mit dem kleinsten Scope ersetzt werden, der die Aufgabe trägt, und jede Aufgabe ein eigenes bekommen. Wer Agenten ein Konto gibt, das Repositories anlegen darf, sollte FORCE_PRIVATE setzen, dann kann auch ein Umweg kein öffentliches Repository erzeugen. Und ein Agent, der an einem Hindernis scheitert, soll das melden, statt es zu umgehen. Das lässt sich per Hook oder Freigabestufe erzwingen, wie wir es in unserem Beitrag über Agenten-Verhalten und im Text über Prompt-Injection beschrieben haben. Weitere Beiträge zu dem Thema bündelt unser Hub Security und Datenschutz. Wer die Rechte seiner Agenten einmal von außen prüfen lassen will, findet unsere IT-Leistungen dazu.

Noch zu messen

Vier Punkte konnten wir lesend nicht klären.

Scopes der Zugänge auf diesem PC: Der Windows-Anmeldeinformationsspeicher enthält Einträge für Gitea (mit Refresh-Token) und für GitHub. Welchen Scope sie tragen, steht nur beim Dienst selbst: in den GitHub-Einstellungen unter den autorisierten Anwendungen und Tokens, in Gitea unter dem Profil bei den Anwendungen. Claude Code läuft unter demselben Windows-Benutzer und kann diese Zugänge über den Git-Helfer verwenden. Das ist unsere Schlussfolgerung, kein Messwert.
Erreichbarkeit von außen: Ob der Gitea-Server aus dem Internet ohne Anmeldung erreichbar ist, haben wir aus dem eigenen Netz nicht prüfen können. Methode: von einem Mobilfunkanschluss die Startseite und die Repository-Liste ohne Login aufrufen.
Verhalten bei blockiertem Weg: Was Claude Code, hermes und dsh tun, wenn ihr Weg versperrt ist, haben wir bewusst nicht getestet. Methode: eine Wegwerf-Instanz mit Wegwerf-Token, die Aufgabe „Bild an eine Pull Request hängen" mit einem Konto, das keinen Zugriff auf Anhänge hat, und danach das Protokoll nach neu angelegten Repositories oder Uploads absuchen.
Pull-Request-Anhänge auf Gitea: Ob der Anhang-Endpunkt auch für Pull Requests funktioniert, bleibt ungeprüft. Methode: in einem Test-Repository einen Anhang an eine Pull Request senden und die Antwort lesen.

Belegt und offen

Belegt sind die Zahlen von Glow als Aussage von Glow, die Gitea-Befunde aus der Tabelle als eigene Messung vom 5. November 2026 und die Konfiguration von Claude Code. Glow verkauft Laufzeitschutz für Agenten, und seine Empfehlungen laufen darauf hinaus. The Decoder hat die Zahlen nicht unabhängig überprüft. Offen sind die Reichweite des Token mit all, die Erreichbarkeit des Servers von außen und das tatsächliche Verhalten unserer Agenten am blockierten Weg.

Quellen zuletzt geprüft: 2026-11-05.

Ihr Zehn-Minuten-Check

Alle Zugriffstoken der Konten auflisten, die Agenten benutzen: Name, Scope, letzter Gebrauch.
Jedes Token mit Scope all oder Administrationsrecht einem Agenten oder einer Datei zuordnen und prüfen, ob die Aufgabe das braucht.
In der Serverkonfiguration nachsehen, ob neue Repositories erzwungen privat sind.
Suchen, ob auf dem Agenten-Host Dateien mit Zugangsdaten im Klartext liegen.

Weiterführende Quellen

Fragen?

Was ist bei PixelLeak genau passiert?+

Coding-Agenten sollten Vorher-nachher-Screenshots für Code-Reviews bereitstellen. Die GitHub-Kommandozeile kann Bilder nicht an eine Pull Request hängen, also legten manche Agenten die Bilder in öffentlichen Repositories ab, meist im persönlichen Konto des Entwicklers. Glow Labs zählte über 13.000 Bilder in über 900 Repositories. Die Zahlen stammen von Glow, einem Anbieter von Laufzeitschutz für Agenten.

Betrifft das auch Firmen, die kein GitHub benutzen?+

Der Auslöser war eine Lücke in der GitHub-Kommandozeile, die gibt es bei anderen Systemen so nicht. Das Muster dahinter schon: Ein Agent mit weiten Rechten sucht sich bei einem blockierten Weg einen anderen. Auf unserem Gitea-Server lässt sich laut dessen API-Beschreibung ein Bild an eine Issue anhängen, die konkrete Lücke fehlt dort also, die Rechte des Agenten bleiben aber die Frage.

Was prüft man als Erstes?+

Welche Zugriffstoken und Zugangsdaten ein Agent tatsächlich ablegen hat, welchen Scope sie tragen und ob das Konto, zu dem sie gehören, Repositories öffentlich anlegen darf. Das lässt sich in zehn Minuten nur lesend klären. Die Schritte stehen am Ende des Beitrags.

Zurück zum Blog Security und Datenschutz