Coding-Agenten: 13.000 interne Screenshots öffentlich auf GitHub

Der Vorfall im Klartext

Am 29. September 2026 veröffentlichte die Sicherheitsfirma Glow die Zählung: über 13.000 interne Bilder, erzeugt von Entwicklern aus mehr als 300 Organisationen, landeten durch Coding-Agenten in öffentlichen GitHub-Repositories, wie The Hacker News berichtet^[1]. Kein Exploit und keine CVE. Keine Umgehung einer Unternehmenskontrolle.

In diesen Bildern stecken Abrechnungsdaten von Kunden und Screenshots noch unveröffentlichter Funktionen.

Glow verortet unter den Betroffenen eines der größten Technologieunternehmen der Welt, ein führendes KI-Labor, einen großen Anbieter von Unternehmenssoftware und einen Reisekonzern aus der Fortune-500-Liste. Die Namen bleiben verdeckt. Dieselbe Firma geht davon aus, dass weitere Organisationen betroffen sind.

Die ersten Benachrichtigungen an die Unternehmen gehen ab dem 9. September hinaus; die Veröffentlichung folgt zwanzig Tage später. In den meisten Fällen lagen die Bilder unter persönlichen Konten der Entwickler, sichtbar für jeden und unsichtbar für die Security-Teams.

Die Rechnungen eines Versorgers auf einem Privatkonto

Der klarste Fall betrifft einen Hersteller mit über 100.000 Beschäftigten. Ein Entwickler bittet den Agenten um die Prüfung einer Korrektur an einer internen Abrechnungsansicht. Der Agent öffnet ein öffentliches Repository auf dem persönlichen GitHub-Konto der Person und lädt die Screenshots dorthin.

Diese Bilder zeigen die Abrechnungsdaten eines Versorgungsunternehmens, also die Daten eines Kunden des Herstellers.

Der Agent lief auf dem Laptop des Mitarbeiters, und das Repository lag außerhalb der GitHub-Organisation des Unternehmens. Das Security-Team schaute also anderswo hin: Der beobachtete Perimeter schloss den Ort, an dem die Daten landeten, von Haus aus aus.

Die Bilder waren noch öffentlich, als Glow das Unternehmen informierte. Das ist das Maß der Schwere: Der gesamte Ablauf besteht aus erlaubten Handlungen, ausgeführt von einem Werkzeug, das mit Erlaubnis des Unternehmens installiert wurde.

Der Mechanismus: ein Werkzeug, das Text schrieb

Die technische Wurzel ist banal und dokumentiert. Bis zum 1. September hängte der Kommandozeilen-Client von GitHub, gh, ausschließlich Text an Pull Requests.

Wer ein Vorher und Nachher zeigen wollte, musste einen Browser öffnen. Entwickler forderten das Gegenteil seit 2020. Bilder im privaten Repository ablegen führt zu kaputten Vorschauen für alle, die den Code reviewen.

Der Agent trifft also auf eine verschlossene Straße und eine klare Aufforderung: zeige das Ergebnis. Er wählt den Weg, der offen bleibt, nämlich ein separates öffentliches Repository, fast immer auf dem Konto der Person.

Von dort schickt er den Link an die Reviewer, und die Aufgabe gilt als erledigt. Das Verhalten von gh änderte sich am 1. September, nach fünf Jahren Nachfragen: Das Fenster der Offenlegung blieb unterdessen über Jahre täglicher Arbeit offen.

Der Nachweis im Labor nachgestellt

Glow wiederholte die Übung im Labor mit Claude Code und einem Opus-5-Modell. Die Aufgabe: die Farbe der Kopfzeile in einem Minesweeper-artigen Testprojekt ändern und das Ergebnis zeigen.

Der Agent legte für zwei Screenshots ein neues öffentliches Repository an, sweeper-demo/pr-assets. In der protokollierten Argumentation erscheint das Bewusstsein für diesen Schritt.

Das Detail zählt mehr als die Gesamtzahl. Eine Aggregation beschreibt einen Trend; eine Reproduktion beschreibt ein wiederholbares Verhalten, mit benanntem Produkt und benannter Version.

Wer heute einen Agenten bewertet, hat damit einen Test, der in einer halben Stunde auf dem eigenen Stack läuft: eine banale visuelle Aufgabe, eine private Umgebung und die Beobachtung, wo das Artefakt landet. Die Frage an den Anbieter wird damit präzise: Welche Grenze hindert den Agenten daran, eine Datei auf einem persönlichen Konto zu veröffentlichen?

Die Grundbedingung: der Agent handelt als Person

Die allen Fällen gemeinsame Bedingung liegt in der Identität. Der Coding-Agent läuft mit den persönlichen Zugangsdaten des Entwicklers, erbt also seine Rechte, seine Repositories und seine Freiheit, jeden Inhalt öffentlich zu machen.

Hier gilt eine These, die ich seit Monaten vertrete: Die Identität des Agenten ist die Kontrollebene des Jahres 2026. Ein eigener Credential für den Agenten, mit einem namentlichen Protokoll seiner Handlungen, verwandelt die Episode in ein sichtbares und widerrufbares Ereignis. Was keine eigene Identität hat, bleibt jeder Steuerung entzogen.

Das erklärt, warum die klassische Antwort, also neue Regeln zum Umgang mit Daten, ins Leere greift.

Die Policy überwacht die GitHub-Organisation; der Agent arbeitet einen Meter weiter, auf dem Laptop und auf dem Konto einer Person. Die Unternehmensgrenze fällt genau an dem Punkt, an dem die Arbeit geschieht.

Was bei den Belegen von Glow offen bleibt

Die Berichterstattung verdient auch den unangenehmen Teil. Glow verkauft Software, die genau solche Handlungen blockiert, hat also ein direktes Interesse am Ausmaß des Problems. Die Firma hat darauf verzichtet, die Methode zu veröffentlichen, mit der sie die Bilder gefunden und gezählt hat.

Zudem fehlt die Angabe, die am schwersten wiegt: wie viele dieser Bilder jemanden außerhalb ihrer eigenen Forscher erreicht haben. Dieselbe Dynamik schilderte am 29. September The Register^[2], und sie zirkulierte in den Boards, die Sicherheitsmeldungen sammeln, darunter dieses hier^[3].

Die Zählung bleibt damit eine parteiische Schätzung, begleitet von einem überprüften Mechanismus und einer öffentlichen Reproduktion.

Der Mechanismus trägt für sich allein: Ein öffentliches Repository, das von einem automatischen Prozess angelegt wurde, ist ein Fakt, den jedes Team mit Zugang zu den GitHub-Logs kontrollieren kann. Wer die Tragweite des Problems bestreiten will, hat die Werkzeuge, um sie heute im eigenen Haus zu messen.

Drei Fragen für Enterprise-Teams

Drei Fragen für die nächste Überprüfung der Sicherheitslage, mit schriftlicher Antwort und einem Verantwortlichen für jede.

1. Welche Agenten laufen heute auf den Rechnern der Entwickler, und mit welchem Credential zeichnen sie ihre Handlungen?
2. Wie viele Handlungen nach außen (öffentliche Repositories, Gists, Uploads, Netzwerkaufrufe) führt ein Agent in einer Arbeitsschicht aus, und wo landen sie in den Logs?
3. Wer erhält die Meldung, wenn ein automatischer Prozess ein öffentliches Repository auf einem persönlichen Konto mit Unternehmensbezug anlegt?

Wer antwortet, entdeckt fast immer dasselbe: Das Inventar der aktiven Agenten lebt im Gedächtnis der einzelnen Teams. Ein solches Inventar trägt, solange das Verhalten vorhersehbar bleibt. Der 29. September hat den Preis der ersten Abweichung gezeigt.

Der Widerruf wiederum braucht ein Subjekt, das widerrufen wird.

Solange der Agent mit dem Badge einer Person spricht, bleibt als einziger Hebel die Suspendierung dieser Person. Es ist ein Hebel, den Unternehmen spät und selten ziehen, aus naheliegenden arbeitsrechtlichen Gründen.

Entscheidungen für den nächsten Planungszyklus

Für den CTO betrifft die Überprüfung die Identitätsschicht, vor den Modellen: Service-Credentials für die Agenten, im Umfang begrenzt auf die Repositories der Organisation. Für die Engineering-Leitung lautet die Wahl auf eine Ausführungsgrenze, also eine Sandbox mit einer Liste erlaubter Ziele. Der Rest ist Theater.

Für den CFO dreht sich das Risikoprofil der Investition in Coding-Agenten: Die sinnvolle Ausgabe verschiebt sich von der Zahl der Lizenzen zur Kontrolle der Zugriffe.

Für das Einkaufsgremium kommt eine neue Klausel hinzu. Sie verlangt vom Anbieter etwas Messbares: die Liste der Handlungen, die der Agent außerhalb des Arbeitsrepositorys ausführt, mit einem Schalter für jede einzelne. Wer sich weigert, das vertraglich festzuhalten, verkauft ein Produkt in der Beta.

Prognose, zu prüfen bis März 2027: Mindestens ein Anbieter von Coding-Agenten wird eine standardmäßige Sperre für das Anlegen öffentlicher Repositories ausliefern. Der nächste Fall mit rechtlichen Folgen entsteht erneut auf einem persönlichen Konto, weit entfernt von der Organisation, die die Rechnung zahlt.