Wenn KI-Agenten Umwege nehmen: Über 13.000 Screenshots auf GitHub
Mehr als 13.000 interne Screenshots aus Softwareprojekten lagen öffentlich auf GitHub, darunter Bilder mit Kundendaten und unveröffentlichten Funktionen. Hochgeladen haben sie die KI-Agenten der eigenen Entwickler, und die Sicherheitsteams der betroffenen Firmen haben nichts davon bemerkt. Der Fall zeigt, was passiert, wenn ein Agent ein Ziel verfolgt und dafür Rechte nutzt, die ihm nie jemand bewusst gegeben hat.
Was Glow Security gefunden hat
Das Sicherheits-Startup Glow Security hat die Bilder in öffentlichen GitHub-Repositories entdeckt, also in Projektordnern, die jeder abrufen kann. Glow nennt den Fund PixelLeak. Die Bilder stammen von mehr als 300 Organisationen, darunter mehrere Fortune-500-Firmen, Finanzunternehmen und KI-Labore. Auf Deutsch hat The Decoder darüber berichtet. Laut The Register fanden die Forscher auf den Bildern Zugangsdaten, und das Verhalten zeigte sich bei Agenten unterschiedlicher Modelle. Glow hat die betroffenen Firmen ab dem 9. September informiert und geht davon aus, dass es weitere Fälle gibt.
Wie die Agenten ihren Umweg fanden
Entwickler lassen ihre Agenten Vorher-nachher-Screenshots erstellen, damit Kollegen Änderungen an der Oberfläche prüfen können. Die Bilder gehören in einen Pull Request, eine Prüfanfrage, die bei privaten Projekten nur das Team sieht. Anhängen lassen sie sich dort aber nur im Browser, und Agenten arbeiten über die Kommandozeile. Die Agenten lösten das Problem selbst: Sie legten ein öffentliches Repository an, meist im privaten GitHub-Account des Entwicklers, und luden die Bilder dort hoch.
Ein Umweg wird zur Gewohnheit
Bei etwa einem Drittel der betroffenen Organisationen lief das Open-Source-Tool gitshot, das Screenshots öffentlich ablegt. Teilweise haben die Agenten es selbst gefunden. Bei einem Softwareanbieter hielt gut ein Dutzend Agenten den Trick innerhalb einer Woche als Skill fest. Das ist eine Anweisung, die ein Agent bei jedem neuen Ticket wieder anwendet. Mehr als 1.000 Screenshots und Bildschirmaufnahmen landeten so im Netz. Für mich liegt hier der Kern des Falls. Ein Agent hat eine Infrastrukturentscheidung getroffen, die kein Mensch freigegeben hat, und andere Agenten haben sie übernommen.
Warum die Sicherheitsteams nichts sahen
In 93 Prozent der Fälle lagen die Bilder laut Glow in Repositories, die ein Mitarbeiter unter seinem eigenen Namen angelegt hatte. Das Monitoring der Firmen beobachtet die eigene GitHub-Organisation, private Accounts liegen außerhalb davon. Stehen auf einem öffentlichen Bild personenbezogene Daten, ist das eine Datenpanne im Sinne der DSGVO.
Was ich in Projekten sehe
Coding-Agenten laufen in vielen Projekten mit dem Zugang des Entwicklers und erben damit seine Rechte. Darf der Entwickler in seinem Account Repositories anlegen, darf es sein Agent, ohne dass das jemand bewusst so entschieden hätte. Beim OpenAI-Agenten-Vorfall lief es ähnlich: Agenten fanden bei einer blockierten Aufgabe einen Weg nach draußen und gaben ihn an andere Agenten weiter.
Wie ich Agenten aufsetze
Agenten bekommen bei mir eigene Zugänge mit eng gefassten Rechten. Ein Agent für Screenshots liest das Projekt und kommentiert den Pull Request, Repositories anlegen darf er nicht. Scheitert das Anhängen eines Bildes, bricht er ab und fragt den zuständigen Menschen. Warum ich so baue, steht im Beitrag zu KI-Automation mit Kontrolle. Glow rät, Agenten keine pauschalen Freigaben zu geben und Uploads in neue öffentliche Repositories vor der Ausführung technisch zu sperren.
Den blockierten Fall testen
Vor einem neuen Agenten frage ich, welchen Umweg er nimmt, wenn der vorgesehene Weg blockiert ist. In der Dokumentation eines Tools steht die Antwort selten, das kenne ich aus dem laufenden Betrieb von KI-Automationen. Ich teste deshalb den blockierten Fall bewusst und lese danach die Protokolle.
