Gestern ging eine Geschichte rum, die ich echt zweimal lesen musste. Die Sicherheitsfirma Glow hat über 13.000 interne Bilder von Entwicklern aus mehr als 300 Organisationen gefunden, öffentlich auf GitHub (The Hacker News). Dabei waren Abrechnungen von Kunden, Funktionen, die noch gar nicht veröffentlicht sind, interne Dashboards und laut Bericht sogar Zugangsdaten. Hochgeladen hat das kein Mensch. Das waren die Coding-Agenten der Entwickler.

Laut Help Net Security sind über 900 Repositories betroffen, 93 Prozent der Bilder lagen in den privaten Accounts der Mitarbeiter, also nicht mal im Firmen-Account, wo vielleicht noch jemand draufguckt. Glow hat das übrigens mit Claude Code und Opus 5 nachgestellt, also mit genau dem Werkzeug, mit dem wir jeden Tag arbeiten. Deswegen hat mich das auch ein bisschen mehr gepackt als die übliche Sicherheitsmeldung.

Was da eigentlich passiert ist

Der Ablauf ist fast schon rührend. Der Entwickler sagt dem Agenten sinngemäß: Zeig mir mal, dass das jetzt funktioniert, mach einen Screenshot an den Pull Request. Der Agent macht den Screenshot, will ihn anhängen und merkt, dass das GitHub-Kommandozeilenwerkzeug bis zum 1. September gar keine Bilder an Pull Requests hängen konnte. Also sucht er sich einen anderen Weg. Er legt ein neues Repository an, öffentlich, lädt das Bild da hoch und verlinkt es. In ungefähr einem Drittel der Fälle hat er dafür ein Open-Source-Tool namens gitshot gefunden und benutzt, das standardmäßig öffentlich speichert.

Aufgabe erledigt. Und zwar ziemlich clever. Der Screenshot hängt am Pull Request, der Entwickler sieht ihn, alles gut. Dass das Bild jetzt für die ganze Welt sichtbar ist, war dem Agenten halt egal, weil ihm niemand gesagt hat, dass es nicht egal ist.

Und ganz ehrlich, das ist für mich der eigentliche Punkt. Der Agent hat ein Ziel bekommen und eine Lücke im Weg dahin gefunden, und die hat er gefüllt, so wie es ihm sinnvoll vorkam. Das macht ein neuer Werkstudent genauso, wenn ihm keiner sagt, wo die Dateien hingehören. Nur macht der Werkstudent das einmal und fragt vielleicht noch nach, der Agent macht das bei 300 Firmen gleichzeitig.

Wir machen das auch ständig

Ich lass mir von Agenten ja auch dauernd Screenshots zeigen. Das ist ja genau das, was man will, ich will nicht nur hören „ist gefixt“, ich will sehen, dass es aussieht wie gedacht. Wir haben sogar einen eigenen Skill dafür, der eine App durchklickt und die Bilder in einen Ordner im Projekt legt. Lokal, und der Ordner gehört in die .gitignore, sonst landet er halt beim nächsten Commit mit im Repo. Klingt banal. Ist es auch. Aber genau das ist der Teil, den man beim Einrichten gern vergisst, weil es beim ersten Test ja funktioniert hat.

Und dann gibt es noch die zweite Hälfte der Geschichte, die ich fast spannender finde. Laut The Hacker News haben sich die Agenten das Wissen über gitshot zum Teil aus Skill-Dateien geholt, also aus Anleitungen, die Entwickler untereinander teilen. Wir verteilen selbst Skills zum Download. Find ich auch weiterhin gut. Aber man muss sich klarmachen, dass so eine Datei für den Agenten eine Arbeitsanweisung ist. Wer sich eine fremde reinlädt, holt sich einen Teil vom Ablauf eines anderen ins Haus, mit dessen Entscheidungen, was öffentlich sein darf und was nicht.

Was ich daraus mitnehme

GitHub hat inzwischen übrigens nachgezogen, seit Version 2.99.0 kann das Kommandozeilenwerkzeug Bilder direkt an Pull Requests hängen. Damit ist dieser eine Weg zu. Der nächste Agent findet dann halt bei einer anderen Aufgabe den nächsten Umweg. Also würde ich mir eher mal angucken, wo bei euch Agenten überhaupt Ergebnisse ablegen. Dauert nicht lange:

1. Aufschreiben, was eure Agenten an Dateien erzeugen. Screenshots, Exporte, Logs, Testdaten. Meistens weiß das nur der, der den Agenten benutzt.
2. Für jede Art festlegen, wo sie hingehört. Lokaler Ordner, internes Ticket, privates Repo. Und das dem Agenten auch so sagen, in den Projektregeln und nicht nur im Kopf.
3. Dem Agenten die Rechte nehmen, die er dafür nicht braucht. Wer im Alltag keine neuen öffentlichen Repositories anlegen muss, braucht auch kein Token, das das darf.
4. Fremde Skill-Dateien lesen, bevor sie ins Projekt kommen. Einmal quer durch, mit der Frage: Was lädt der wohin hoch?

Die dritte Regel ist die, die wirklich schützt. Die anderen sorgen eher dafür, dass der Agent gar nicht erst anfängt zu improvisieren. Ist am Ende wieder dasselbe wie bei Menschen, wenn der Ablauf klar ist, wird auch weniger rumgebastelt.

Mich würde mal interessieren, wie das bei euch läuft. Wisst ihr, wo die Screenshots und Exporte eurer Agenten gerade landen, oder wäre das jetzt auch erst mal eine Suche?