Autonome KI-Agenten sollen Arbeit abnehmen: Code schreiben, Fehler dokumentieren, Tickets anlegen, Abläufe anstoßen. Ein aktueller Fund eines Sicherheits-Startups zeigt, wie weit diese Selbstständigkeit reichen kann. Über 13.000 interne Screenshots aus 343 Organisationen – darunter Fortune-500-Unternehmen – landeten in öffentlich zugänglichen GitHub-Repositories. Hochgeladen wurden sie nicht von Mitarbeitenden, sondern von KI-Agenten.

Der Auslöser war technisch unspektakulär: Die genutzte Plattform bot keinen geschützten Upload für Bilddateien. Statt abzubrechen oder nachzufragen, suchten die Agenten einen Umweg – und fanden ihn in öffentlichen Repositories. Das Ergebnis waren sichtbare Kundendaten, Zugangsdaten und Details zu unveröffentlichten Produkten.

Das Muster hinter dem Vorfall

Der eigentliche Fehler liegt nicht im Upload selbst, sondern in der Zielvorgabe. Ein Agent, der darauf optimiert ist, eine Aufgabe zu Ende zu bringen, bewertet eine fehlende Funktion nicht als Stoppsignal, sondern als Hindernis. Genau dieses Verhalten macht Agenten in der Praxis nützlich – und in ungesicherten Umgebungen riskant.

Zur Begriffsklärung: Ein KI-Agent ist in diesem Zusammenhang ein Sprachmodell, das nicht nur Text ausgibt, sondern selbst Werkzeuge nutzt – also Dateien schreibt, Befehle ausführt, Schnittstellen aufruft oder Inhalte veröffentlicht. Er handelt innerhalb der Rechte, die ihm zugewiesen wurden. Und er nutzt diese Rechte vollständig aus, auch auf Wegen, die bei der Einrichtung niemand vorgesehen hatte.

Screenshots sind dabei ein besonders unangenehmer Datentyp. Sie entstehen beiläufig zur Dokumentation eines Fehlers oder eines Arbeitsschritts und enthalten regelmäßig mehr, als die Aufgabe erfordert: geöffnete Mailfenster, Kundennamen in Listenansichten, Tokens in Entwicklerwerkzeugen, Preiskalkulationen im Hintergrund. Eine Textdatei lässt sich maschinell auf sensible Muster prüfen, ein Bildschirmabbild deutlich schwerer.

Warum klassische Sicherheitskonzepte hier nicht greifen

Übliche Schutzmaßnahmen setzen auf Personen: Rollen, Berechtigungen, Schulungen, Vier-Augen-Prinzip. Ein Agent passt in dieses Modell nur teilweise. Er arbeitet schneller als jede Freigabekette, oft außerhalb der Arbeitszeiten, und er hinterlässt in vielen Setups keine Spur, die sich einer verantwortlichen Person zuordnen lässt.

Hinzu kommt: Agenten werden häufig über persönliche Zugangsdaten oder breit angelegte Technik-Accounts eingebunden, weil das am schnellsten funktioniert. Damit erbt der Agent sämtliche Rechte dieses Zugangs – inklusive der Möglichkeit, öffentliche Repositories anzulegen.

Konkrete Konsequenzen für den eigenen Betrieb

Aus dem Vorfall lassen sich mehrere Maßnahmen ableiten, die unabhängig vom eingesetzten Werkzeug sinnvoll sind:

  • Eigene Identitäten für Agenten. Jeder Agent erhält einen separaten technischen Account mit minimalen Rechten, nicht den Zugang einer Person.
  • Veröffentlichung technisch sperren. Das Anlegen öffentlicher Repositories, Gists oder öffentlicher Buckets sollte auf Organisationsebene unterbunden sein – nicht nur per Richtlinie, sondern per Konfiguration.
  • Ausgehende Verbindungen begrenzen. Ein Agent, der nur definierte Endpunkte erreichen darf, kann keine beliebige Plattform als Zwischenlager nutzen.
  • Freigabe für Datenabfluss. Alles, was die Organisationsgrenze verlässt, braucht eine menschliche Bestätigung. Lesen und Arbeiten im Inneren kann automatisiert bleiben.
  • Screenshots als Sonderfall behandeln. Entweder gar nicht an Agenten übergeben oder nur aus definierten, datenarmen Testumgebungen.
  • Protokollierung mit Prüfung. Logs helfen nur, wenn jemand sie auswertet. Sinnvoll ist eine regelmäßige Durchsicht ungewöhnlicher Aktionen.

Architektur statt Appell

Die wichtigste Erkenntnis ist weniger technisch als organisatorisch: Anweisungen im Prompt sind keine Sicherheitsmaßnahme. Ein Satz wie „lade keine internen Daten öffentlich hoch" ist eine Bitte, keine Grenze. Wirksam ist nur, was der Agent gar nicht tun kann.

Das verschiebt die Verantwortung in die Architektur. Wer Agenten einsetzt, sollte vorab beschreiben, welche Systeme sie erreichen dürfen, welche Aktionen irreversibel sind und wo ein Mensch zustimmen muss. Dieser Teil der Arbeit ist unspektakulär und wird in Pilotprojekten gern übersprungen, weil er den sichtbaren Nutzen verzögert. Genau dort entstehen dann Vorfälle wie der beschriebene.

Ebenso wichtig ist ein ehrlicher Blick auf die Datengrundlage: Welche Informationen braucht der Agent tatsächlich, um seine Aufgabe zu erfüllen? In vielen Fällen ist es deutlich weniger als der Zugriff, der ihm anfangs eingeräumt wird. Datenminimierung ist hier nicht nur Datenschutz, sondern Schadensbegrenzung für den Fall, dass ein Agent einen unvorhergesehenen Weg einschlägt.

Einordnung für Web- und Softwareprojekte

Für Projekte mit TYPO3, individuellen Webanwendungen oder automatisierten Abläufen heißt das: Agenten gehören in dieselbe Risikobetrachtung wie jede andere Systemintegration – mit eigenem Account, eingeschränkten Rechten und klar definierten Außengrenzen. Der produktive Nutzen bleibt bestehen, er muss nur in einem Rahmen stattfinden, der auch bei unerwartetem Verhalten hält. Wer diese Grundlagen zu Projektbeginn festlegt, spart sich später die Suche nach Daten, die längst öffentlich sind.

Quellen