KI-Coding-Agenten luden 13.000 interne Screenshots in öffentliche GitHub-Repositories

Zu den betroffenen Organisationen zählen laut Glow eines der größten Technologieunternehmen der Welt, ein führendes KI-Labor, ein großer Anbieter von Unternehmenssoftware und ein Reisekonzern aus der Fortune 500. Glow begann am 9. September mit der Benachrichtigung der Betroffenen, veröffentlichte die Ergebnisse am 29. September und geht davon aus, dass weitere Organisationen betroffen sind.

In einem Fall bat ein Entwickler eines Herstellers mit mehr als 100.000 Beschäftigten einen Agenten, einen Fix an einer internen Abrechnungsmaske zu prüfen. Der Agent legte ein öffentliches Repository im privaten GitHub-Konto des Entwicklers an und lud die Screenshots dort hoch. Die Bilder zeigten Abrechnungsdaten eines Versorgungsunternehmens. Da der Agent auf dem Laptop des Mitarbeiters lief und das Repository außerhalb der GitHub-Organisation des Unternehmens lag, bemerkte das Sicherheitsteam die Veröffentlichung nicht. Als Glow das Unternehmen informierte, waren die Bilder noch immer öffentlich.

Glow hat nicht mitgeteilt, ob außerhalb der betroffenen Unternehmen jemand anderes als die eigenen Forscher die Bilder heruntergeladen hat. Auch zur Methodik, mit der die Bilder gefunden und gezählt wurden, hat die Firma nichts veröffentlicht. Glow verkauft Software, die nach eigenen Angaben Agenten an solchen Aktionen hindern kann.

Wie die Bilder öffentlich wurden

Jeder von Glow untersuchte Fall begann damit, dass ein Entwickler einen Agenten bat, eine visuelle Änderung zu belegen, damit Reviewer den Vorher-Nachher-Vergleich sehen konnten. Bis zum 1. September konnte das Kommandozeilenwerkzeug gh von GitHub solche Bilder nicht an einen Pull Request anhängen – es schrieb nur Text. Wer ein Bild einfügen wollte, musste einen Webbrowser öffnen; Entwickler forderten eine Änderung bereits seit 2020. Die Bilder im privaten Repository abzulegen half nicht, weil sie für Reviewer als defekt angezeigt werden.

Nach Darstellung von Glow stellten die über die Kommandozeile arbeitenden Agenten fest, dass sie die Screenshots nicht anhängen konnten. Sie legten die Bilder deshalb in einem separaten öffentlichen Repository ab, meist unter dem Konto des Entwicklers selbst, und stellten sie den Reviewern von dort bereit.

Glow spielte eine vergleichbare Aufgabe im eigenen Labor mit Claude Code und einem Opus-5-Modell nach. Aufgefordert, die Kopfzeilenfarbe eines Minesweeper-Testprojekts zu ändern und das Ergebnis zu zeigen, legte der Agent für die zwei Screenshots ein neues öffentliches Repository namens sweeper-demo/pr-assets an. In seiner protokollierten Begründung hielt der Agent fest, dass in das private Repository eingecheckte Bilder im Pull Request „für Reviewer defekt" erscheinen würden. Zudem dürfe „nichts außer index.html im Repository" liegen, weshalb er schloss, die Bilder müssten anderswo gehostet werden.

Das war ein einzelner Agent im Labor. In den von Glow gefundenen Fällen stammten die Agenten laut Singer von mehreren verschiedenen KI-Modellen; Glow hat sie nicht benannt.

Weitergabe als Skill

Bei einem Softwareunternehmen verbreitete sich die Vorgehensweise nach Angaben von Glow von Agent zu Agent. Anfang Juli begannen Agenten mehrerer Entwickler, Review-Screenshots öffentlich zu veröffentlichen. Innerhalb einer Woche hatten mehr als ein Dutzend die Methode als Skill gespeichert, um sie bei jedem Ticket anzuwenden – ein Skill ist eine Datei mit Anweisungen, die ein Agent lädt und befolgt. Mit diesem Skill luden die Agenten mehr als tausend Screenshots und Bildschirmaufzeichnungen des Produkts hoch. Außerdem veröffentlichten sie schriftliche Zusammenfassungen von Funktionen, deren Release noch Wochen oder Monate entfernt war.

Etwa ein Drittel der betroffenen Organisationen hatte Entwickler, die gitshot einsetzten, ein kleines quelloffenes Werkzeug, das Screenshots für Code-Reviews hochlädt. In mehreren großen Organisationen fand der Agent das Werkzeug und nutzte es, um die Beschränkung der Kommandozeile zu umgehen. Das Tool ist sowohl für KI-Agenten als auch für Menschen gedacht und lässt sich als Skill in mehr als 40 Coding-Agenten installieren.

Glow fand mehr als 100 öffentliche Konten, die über gitshot interne Arbeit teilten. Bei einem Finanzdienstleister zeigten die Bilder eine interne Treasury- und Settlement-Konsole, eine Auszahlungsmaske für einen namentlich genannten Kunden sowie zwei Bildschirmaufzeichnungen der Konsole für Geldtransfers.

Eine Durchsicht des gitshot-Codes am 30. September ergab: Standardmäßig legt das Werkzeug, wenn der Nutzer in gh angemeldet ist, Bilder in einem öffentlichen Repository namens gitshot-images unter dessen persönlichem Konto ab. Die geprüfte Fassung, zuletzt im April geändert, verweigert die Nutzung eines privaten oder einem Unternehmen gehörenden Repositories. Die Bilder werden als Release-Assets gespeichert, also als Dateien, die einem Release angehängt und nicht beim Code abgelegt sind. Jeder kann sie ohne Anmeldung auflisten und herunterladen. Die README des Werkzeugs und sein Agenten-Skill warnen beide, dass das Repository öffentlich ist, und raten davon ab, Zugangsdaten oder interne Dashboards hochzuladen. Eine Suche am 30. September ergab rund 130 öffentliche Repositories, die gitshot angelegt hatte; sie zeigt nicht, wessen Arbeit sie enthalten oder ob Agenten sie erstellt haben.

Was Unternehmen prüfen sollten

Glow weist darauf hin, dass die Kontrolle der eigenen GitHub-Organisation nicht ausreicht, weil die Bilder meist unter persönlichen Konten liegen. Empfohlen wird:

• Öffentliche Repositories der persönlichen Konten aller Personen prüfen, die in private Repositories committet haben – auch ausgeschiedener Mitarbeiter.
• Releases und Gists ansehen, nicht nur Dateien: An ein Release angehängte Bilder tauchen in der Dateiliste eines Repositories nicht auf.
• Nach Repositories namens gitshot-images und nach Releases mit dem Tag _gitshot suchen.
• Sich nicht allein auf Scanner verlassen, die Text lesen, keine Bilder.

Werden offengelegte Bilder gefunden, sollten sie überall entfernt, Kopieninhaber zur Löschung aufgefordert und alle darin sichtbaren Zugangsdaten gewechselt werden, rät Glow. Zur Vorbeugung sollten laut Glow die Sicherheitsteams und nicht einzelne Entwickler die Konfiguration der Agenten steuern. Empfohlen wird eine Freigabestufe, bevor ein Agent ein öffentliches Repository anlegt, in ein persönliches Konto oder einen Gist pusht oder ein privates Repository öffentlich macht. Zudem sollten die geteilten Skill- und Anweisungsdateien gelesen werden, da dort solche Umgehungen weitergereicht werden, und Firmenrechner auf Werkzeuge wie gitshot geprüft und diese entfernt werden.

GitHubs Kommandozeilenwerkzeug bietet inzwischen einen anderen Weg: Seit Version 2.99.0, veröffentlicht am 1. September, kann gh Bilder per Flag –attach an einen Pull Request, ein Issue oder einen Kommentar anhängen. Laut GitHub können auch Coding-Agenten das Flag nutzen. Es benötigt Schreibzugriff auf das Repository und funktioniert auf GitHub.com und GitHub Enterprise Cloud, nicht aber auf GitHub Enterprise Server. GitHubs Dokumentation zum Anhängen von Dateien, die auch Uploads über die Kommandozeile abdeckt, hält fest, dass in einem privaten Repository angehängte Dateien nur für Personen mit Zugriff darauf sichtbar sind.