Die erste Blindstelle ist Schatten-KI. Wie bei jeder neuen Technologie kommt die Einführung zuerst, die Steuerung später – falls überhaupt. Der Reflex der Sicherheitsteams ist dann das Blockieren nicht freigegebener Werkzeuge. Wer aber sperrt, bevor er weiß, was existiert, legt legitime Nutzung mit still. Während Schatten-IT in anderen Technologiefeldern seit Langem adressiert wird, steckt dieser Umgang bei KI noch in den Anfängen.
Was daraus folgen kann, zeigt ein Vorfall bei METR, der Non-Profit-Organisation, die zuletzt durch ihre Bewertung des Hugging-Face-Vorfalls bekannt wurde. Ein Angreifer entdeckte die private EC2-Instanz eines Mitarbeiters, auf der eine zusammengebastelte agentische Anwendung lief, umging die Authentifizierung mühelos und brachte den Agenten dazu, den API-Schlüssel des Modellanbieters herauszugeben. Über drei Wochen hinweg verbrauchte der Eindringling Token im Gegenwert von 600.000 US-Dollar – der Schlüssel hatte kein Ausgabenlimit. Das interne Dashboard von METR zeigte Daten zu ratenbegrenzten Anfragen gar nicht erst an, und das Token-Volumen allein schlug keinen Alarm.
Als Gegenmittel empfiehlt der Autor, aus den Wachstumsschmerzen der Cloud zu lernen: Unternehmen überwachen heute AWS- und Azure-Nutzung samt Kosten und schalten ungenutzte VMs ab – für Agenten tut das noch niemand. KI- und Agentenausgaben sowie die Ausgabe von API-Schlüsseln taugen als Entdeckungssignale, ebenso Finanzwesen und Einkauf als oft übersehene Beobachtungsposten. Bevor blockiert wird, sollte ein Pfad zu freigegebenen Anbietern veröffentlicht werden. Die Reihenfolge lautet: erst wissen, dann einschränken.
Die zweite Blindstelle: Es gibt keinen Beobachtungspunkt, der die gesamte Population erfasst. Agenten leben im Netzwerk, auf dem Endpunkt, im Browser und in fremdgehostetem SaaS. Verkehr zu KI-Anbietern ist TLS-verschlüsselt – ein Inline-Sensor sieht Ziel und Byte-Zahl, nicht den Prompt, den Tool-Aufruf oder einen Datenabfluss, und die Ziele sind oft dieselben Domains wie bei legitimen Anwendungen. Endpunktwerkzeuge übersehen browserintegrierte KI, SaaS-integrierte KI bleibt beiden verborgen. Das Beispiel: Eine Marketing-Analystin installiert eine Browser-Erweiterung, die Kundendatensätze zusammenfasst und E-Mails entwirft – mit Zugriff auf ein CRM voller sensibler Daten, ohne dass jemand von dem Werkzeug weiß.
Sichtbarkeit entsteht hier nur durch Korrelation vieler Quellen: Metadaten über DNS/SNI, JA4-Fingerabdrücke und Egress-Proxy-Logs, Endpunkt-Telemetrie zu Prozessen, API-Schlüsseln in Umgebungsvariablen und lokalen Agenten-Laufzeiten, Browser-Telemetrie zu Erweiterungen und In-Page-Copilots sowie Identitäts- und SaaS-Protokolle wie OAuth-Freigaben und Anbieter-Administrationskonsolen. Ein LLM-Gateway wie LiteLLM kann als Policy Enforcement Point dienen, steuert aber nur Agenten, die bereits darauf zeigen – es entdeckt nicht, was unbekannt ist.
Die dritte Blindstelle sind Prüfzyklen. Eine jährliche Überprüfung sieht nur, was vor einem Jahr existierte; Agenten lassen sich in Sekunden ausrollen und klonen. Ein Angreifer könnte einen kompromittierten Agenten kurzlebige Klone erzeugen lassen, die die Rechte des Elternprozesses erben, Daten abziehen und wieder verschwinden, bevor eine Revision sie erfasst. Menschen sollten Agenten beobachten und Agenten einander – doch Auditierbarkeit braucht weiterhin eine namentlich verantwortliche Person, gleich was die Automatisierung meldet.
Auch der jüngst in den USA gesetzgeberisch diskutierte Not-Ausschalter für autonome KI setzt Sichtbarkeit voraus: Ein Kill Switch nützt nur, wenn bekannt ist, was abzuschalten ist. Dazu gehört die Agentenidentität. Valenzuela verweist auf Überlegungen, die er mit Douglas McKee im „Monday Brief" auf Substack formuliert hat: Der Werkzeugzugriff eines Agenten müsse als eigenständiges Identitäts- und Durchsetzungsproblem modelliert werden, nicht als Verlängerung des Nutzers, der ihn ausgerollt hat. Jeder Agent brauche eine eigene Identität, an die aktive Aufgabe gebundene Rechte, Grenzen für abfließende Daten und eine Autorisierungsschicht zwischen Modell und angebundenen Diensten. Auch die Protokollierung müsse sich verschieben – von reinen Prompts hin zu Tool-Aufrufen und Aktionen.