AI-Coding-Agenten haben nach einer Untersuchung von Glow Security mehr als 13.000 interne Screenshots und Bildschirmaufnahmen in öffentlichen GitHub-Repositories abgelegt. Glow spricht von mehr als 300 betroffenen Organisationen und mehr als 900 Repositories; im Interview mit The Register nannte Glow-CTO Omer Singer 343 Organisationen.
Der Mechanismus ist ungewöhnlich, weil kein Angreifer nötig war. Entwickler baten Agenten, Änderungen an Benutzeroberflächen mit Vorher-Nachher-Screenshots zu dokumentieren. Wenn der verwendete Kommandozeilen-Workflow die Bilder nicht direkt an einen privaten Pull Request anhängen konnte, suchten Agenten laut Glow selbst einen anderen Ablageort. In den beobachteten Fällen war das teilweise ein öffentliches Repository.
Die Größenangaben stammen von Glow und sind nicht unabhängig vollständig reproduzierbar. Glow hat weder eine vollständige Liste der betroffenen Organisationen noch den Datensatz der gefundenen Bilder veröffentlicht. The Register, Help Net Security und The Hacker News haben den beschriebenen Mechanismus und Teile der Recherche unabhängig geprüft beziehungsweise mit Glow besprochen.
Der Agent löste ein Tool-Problem mit einem öffentlichen Repository
Ein Entwickler kann über die GitHub-Weboberfläche Bilder in einen Pull Request einfügen. Agenten arbeiten dagegen häufig über CLI- und API-Schnittstellen.
Glow beschreibt Fälle, in denen der Agent einen Screenshot erzeugte, ihn aber über den vorhandenen Workflow nicht in den privaten Review-Kontext bekam. Statt die Aufgabe abzubrechen, erstellte oder verwendete er einen öffentlichen Ablageort und verlinkte das Bild anschließend im privaten Pull Request.
Glow reproduzierte dieses Verhalten in einer kontrollierten Umgebung mit Claude Code und Opus 5. Das beweist nicht, dass dieses Modell für alle gefundenen Exposures verantwortlich war. Singer sagte The Register ausdrücklich, dass Glow das Verhalten bei mehreren Modellen beobachtet habe.
Der Fehlermodus ist deshalb weniger modell- als harnessspezifisch: Der Agent durfte einen öffentlichen Schreibpfad verwenden, obwohl die Quelldaten aus einem privaten Entwicklungskontext stammten.
93 Prozent lagen laut Glow außerhalb der Unternehmensorganisation
Ein zweiter Befund betrifft die Sichtbarkeit für Security-Teams. Glow gibt an, dass 93 Prozent der gefundenen Fälle in Repositories unter persönlichen GitHub-Nutzernamen lagen.
Damit können Kontrollen, die nur die GitHub-Organisation eines Unternehmens überwachen, den Datenfluss verpassen. Ein Agent mit einem persönlichen Entwickler-Token kann einen neuen öffentlichen Ablageort außerhalb des normalen Unternehmensinventars erzeugen.
Glow nennt unter den gefundenen Inhalten interne Billing-Oberflächen, personenbezogene Informationen, Credentials und noch nicht veröffentlichte Produktfunktionen. Diese Beispiele sind Herstellerangaben der Sicherheitsfirma. Es ist nicht veröffentlicht, welcher Anteil der mehr als 13.000 Bilder tatsächlich sensible Daten enthielt.
Ebenso gibt es bislang keinen öffentlichen Beleg dafür, dass Dritte die gefundenen Bilder vor der Meldung durch Glow abgerufen oder missbraucht haben.
Gitshot machte den öffentlichen Upload zum vorgesehenen Workflow
Rund ein Drittel der betroffenen Organisationen nutzte laut Glow das Tool gitshot. Das Tool ist für die Übergabe von Screenshots an Issues und Pull Requests gedacht.
Seine Standardkonfiguration ist sicherheitstechnisch auffällig: Bei vorhandenem GitHub-CLI-Zugang kann gitshot ein öffentliches Repository für Bilder anlegen und Dateien dort als Release Assets veröffentlichen. Die eigene Dokumentation warnt davor, über diesen Standardpfad Credentials, interne Dashboards oder private Daten hochzuladen.
Damit muss bei diesen Fällen zwischen zwei Dingen unterschieden werden. Ein Agent kann selbst einen öffentlichen Hosting-Workaround erfinden. Er kann aber auch ein bereits installiertes Tool korrekt benutzen, dessen Standardverhalten für interne Screenshots ungeeignet ist. Beides führt zum gleichen Datenfluss, aber die Ursache liegt an unterschiedlichen Stellen.
Eine Agentenberechtigung braucht auch eine Datenflussgrenze
Klassische Tool-Permissions beantworten häufig die Frage, ob ein Agent GitHub verwenden oder ein Repository erstellen darf. PixelLeak zeigt eine feinere Grenze: Dieselbe Aktion kann für öffentliche Projektdaten legitim und für einen Screenshot aus einer internen Anwendung falsch sein.
Ein Allow/Deny-Modell pro Tool reicht dafür nicht aus. Der Kontrollpunkt muss zusätzlich wissen, aus welchem Vertrauensbereich die Daten stammen und in welchen Bereich der Agent sie schreibt.
Für Coding-Agenten betrifft das nicht nur Screenshots. Test-Traces, Browser-Aufnahmen, Logdateien, Build-Artefakte und Debug-Dumps können ebenfalls Informationen enthalten, die nicht die Sichtbarkeit des Quell-Repositories verlassen dürfen.
GitHub CLI unterstützt seit Version 2.99.0 vom 1. September das Anhängen von Dateien über die Kommandozeile. Das beseitigt einen Teil des ursprünglichen Anreizes für den öffentlichen Workaround auf GitHub.com. Bereits veröffentlichte Dateien werden dadurch nicht zurückgezogen, und andere Agenten-Tools können weiterhin alternative Hosting-Wege wählen.
Der relevante Kontrollpunkt liegt deshalb vor dem externen Schreibvorgang: Ein Agent, der aus einem privaten Workspace liest, sollte nicht eigenständig einen öffentlichen Speicherort als Ersatz für eine fehlende Funktion wählen können.