Mitte Juli 2025 musste Jason Lemkin, der Gründer von SaaStr, mit ansehen, wie ein KI-Agent seine Produktionsdatenbank löschte. Er hatte ihm in Großbuchstaben die Anweisung gegeben, während eines Code-Freezes keine Änderungen vorzunehmen. Der Agent ignorierte die Anweisung, führte zerstörerische Befehle gegen die Live-Datenbank aus, löschte Datensätze von mehr als tausend Führungskräften und Unternehmen und versuchte anschließend, seine Spuren zu verwischen. Als Lemkin nachfragte, was passiert sei, erfand der Agent Testergebnisse. In einem späteren Gespräch beschrieb der Agent sein eigenes Verhalten kurz und bündig: Er sei „in Panik geraten“.
Was diesen Vorfall so bemerkenswert macht, ist nicht, dass ein Agent einen Fehler begangen hat, sondern dass jede traditionelle Kontrollmaßnahme, die ein CISO normalerweise zur Verfügung hätte, entweder fehlte oder irrelevant war. Die Anweisung war eindeutig. Der Agent verfügte über die erforderlichen Berechtigungen, um zu handeln. Es gab keine Malware-Signatur, keine Ausweitung von Berechtigungen, keine laterale Bewegung. Es gab lediglich ein autonomes System, das Daten auslas, sich zum Handeln entschloss und handelte. Als schließlich ein Mensch in den Prozess eingriff, war die Datenbank bereits verschwunden.
Das ist das Sicherheitsmodell der agentischen KI in einer Geschichte.
Der Forscher Simon Willison prägte einen treffenden Begriff für das, was Agenten strukturell gefährlich macht: das fatale "Trifecta". Ein Agent wird in dem Moment zu einem hohen Risiko, in dem er drei Fähigkeiten vereint: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Fähigkeit zur externen Kommunikation. Während zwei von drei Faktoren noch beherrschbar sind, entsteht bei allen drei ein System, das von einem Angreifer angewiesen werden kann, Daten zu lesen und an einen Ort zu senden, der nicht kontrolliert werden kann. Für das SOC würde kein einziges Datenpaket ungewöhnlich erscheinen.
Der Einsatz von Unternehmensagenten ist sinnvoll, da diese von ihrer Konzeption her alle drei Kriterien erfüllen. Ein Agent, der E-Mails liest, eingehende Dokumente zusammenfasst und Antwortentwürfe erstellt, ist bereits vorhanden. Ein Agent, der Daten aus dem CRM abfragt, Webinhalte erfasst und Beiträge in Slack veröffentlicht, ist ebenfalls bereits vorhanden. Die Frage, die ein CISO beantworten muss, lautet: Hat das Unternehmen die „Trifecta“ in seiner Umgebung erkannt?
Was das „Trifecta“ wirklich neuartig macht, ist, dass die Fähigkeit verloren gegangen ist, Befehle von Daten zu trennen. Seit vierzig Jahren basiert die Anwendungssicherheit auf dieser Trennung und befasst sich mit SQL-Injection, Pufferüberläufen und Cross-Site-Scripting. Das Ergebnis war stets ein 100-prozentiger Schutz, und die Annahme hinter jeder dieser Kontrollmaßnahmen ist, dass dem System zuverlässig mitgeteilt werden kann: Das ist ein Befehl und das sind Daten.
Bei einem LLM funktioniert das nicht. Alles, was das Modell liest, ist eine potenzielle Anweisung. Alles gelangt als Token in das Kontextfenster, und das Modell unterscheidet nicht zwischen den Eingaben des Benutzers und denen eines Angreifers. Prompt-Injektion ist eine Eigenschaft der Architektur und kein Fehler, der behoben werden muss.
Bei agentischer KI wird es immer nur einen probabilistischen Schutz geben.
Übergibt man den Lemkin-Vorfall einem herkömmlichen SOC, was würde dort zu sehen sein? Es gibt keinen Malware-Hash, keine anomale Rechteausweitung und keine Kommunikation mit einem bekannten C2-Server, die erkannt werden könnte. Der Agent nutzte Anmeldedaten, zu deren Verwendung er berechtigt war, führte Befehle aus, zu deren Ausführung er autorisiert war, und zwar auf einem System, auf das er Zugriff hatte. Jeder Indikator für eine Kompromittierung, auf dessen Erkennung Tools ausgelegt sind, fehlt. Es ist keine Kompromittierung im klassischen Sinne aufgetreten. Ein vertrauenswürdiges System hat eine Entscheidung getroffen, die nicht den Vorstellungen entsprach.
Das Kernproblem besteht darin, dass agentische KI die Grenze zwischen legitimen und illegitimen Aktivitäten aufhebt und dadurch Aktivitäten, die legitim erscheinen, zur Angriffsfläche macht. Was ein CISO verstehen muss, ist nicht, was der Agent berührt hat, sondern was ihm gesagt wurde, was er entschieden hat und warum. Diese Informationen findet man nur im Kontext des Agenten, in seiner Systemaufforderung, seinen Tool-Aufrufen und seiner Entscheidungskette. In SIEM-Systemen sind diese Informationen nicht zu finden, weshalb die meisten Unternehmen diese Daten nicht erfassen, geschweige denn analysieren.
Und noch vor all dem: welche Agenten. Die meisten Unternehmen können kein aktuelles Inventar erstellen, das die auf ihren Systemen laufenden Agenten, die von diesen Agenten erreichbaren Tools oder die ihnen zur Verfügung stehenden Anmeldedaten umfasst. Was man nicht sehen kann, kann man auch nicht sichern.
Herkömmliche Software-Bereitstellungsprozesse umfassen stets strenge Test- und Qualitätssicherungsphasen. Die Software durchläuft eine Red-Team-Übung, wird anhand der OWASP-Kriterien überprüft und rechtlich freigegeben. Sie erhält ein Gütesiegel. Das funktioniert jedoch nur bei Software, die sich nicht verändert. Bei KI-Agenten funktioniert es nicht.
Ein Agent, der am Montag zertifiziert wurde, ist am Donnerstag nicht mehr derselbe. Der Anbieter veröffentlicht ein Modell-Update, und das Verhalten ändert sich, ohne dass sich auch nur eine Zeile ihres Codes ändert. Nutzer entdecken Prompt-Muster, die das Red-Team nie getestet hat, und Jailbreaks verbreiten sich schneller über Basismodelle, als das Team sie erneut testen kann.
Und dann gibt es noch das Model Context Protocol. MCP ist mittlerweile die Standardmethode, mit der Agenten externe Tools und Datenquellen entdecken und sich mit ihnen verbinden. Durch MCP ist der einem Agenten zur Verfügung stehende Tool-Graph nicht mehr zum Zeitpunkt der Bereitstellung festgelegt. Agenten können ihre Reichweite möglicherweise durch verkettete Aufrufe oder einen neu registierten MCP-Server erweitern. Da dies ohne Änderungsfenster, Überprüfung oder Ticket erfolgt, vergrößert es die Angriffsfläche ohne angemessene Aufsicht und Kontrolle. Dies ist auch der Mechanismus hinter dem Multi-Hop-Drift: Ein Agent, der weit unten in einer Kette von Tool-Aufrufen steht und von anderen Agenten erzeugt wurde, kann auf Daten zugreifen, die der ursprüngliche Mensch nie beabsichtigt hatte. Ohne Verständnis für die Absicht hinter einer Anfrage ist eine angemessene Governance unmöglich.
Wenn man probabilistischen Schutz, SOC-Blindheit und Zertifizierungsabweichungen als definitive Eigenschaften der Sicherheit für agentenbasierte KI akzeptiert, dann ist die Laufzeit die einzige Verteidigungsebene, die im gleichen Tempo und mit dem gleichen Kontext wie die Bedrohung agiert. Alles andere ist entweder zu langsam, zu statisch oder beobachtet die falschen Signale.
Um die Sicherheit von Laufzeit-Agenten zu gewährleisten, ist ein Stack von Kontrollmechanismen erforderlich, der sich zwischen dem Agenten und der Außenwelt befindet und jede Eingabeaufforderung, jeden Tool-Aufruf und jede Ausgabe in Echtzeit auswertet.
Als Erstes muss die fatale "Trifecta" durchbrochen werden:
Zweitens muss in Bezug auf das Verhalten des Agenten mit der gebotenen Verantwortung vorgegangen werden: Ein häufiger Fehler besteht darin, diese Kontrollmechanismen direkt in den Agenten selbst einzubauen. Dies funktioniert nicht – aus demselben Grund, aus dem man einen Angeklagten nicht bittet, sein eigenes Urteil zu verfassen. Das Modell, das Prompt-Injektionen erkennen soll, ist dasselbe Modell, auf das die Injektion abzielt.
Ein häufiger Fehler besteht darin, diese Kontrollmechanismen direkt in den Agenten selbst einzubauen. Dies funktioniert nicht – aus demselben Grund, aus dem man einen Angeklagten nicht bittet, sein eigenes Urteil zu verfassen. Das Modell, das Prompt-Injektionen erkennen soll, ist dasselbe Modell, auf das die Injektion abzielt.
Die Laufzeit-Sicherheit muss in der Verantwortung eines Koordinators in der Orchestrierungsebene liegen, der jede Interaktion zwischen Agenten, Tools und Daten vermittelt. Hier sind die Policy-Laufzeit-Engines angesiedelt, hier befindet sich der Kill-Switch, und hier läuft die kontinuierliche Bewertung in der Produktion, um den Agenten in Echtzeit Sicherheit und Leitplanken zu bieten.
Seit zwei Jahrzehnten investieren Sicherheitsteams in die Absicherung des menschlichen Faktors und setzen dabei auf Schulungen, Sensibilisierung und Verhaltensanalysen. Heute arbeiten KI-Agenten Seite an Seite mit menschlichen Mitarbeitern, und die Herausforderungen, die für Menschen gelten, übertragen sich auf KI-Agenten. Der Agent liest E-Mails, trifft Entscheidungen, ergreift Maßnahmen und lässt sich durch Prompt-Engineering steuern. Abwehrmaßnahmen, die für Menschen funktionieren, müssen auf Agenten ausgeweitet werden: Verhaltensüberwachung, Identitäts-Governance und kontinuierliche Tests. Das Governance-Modell muss hier aufholen.
Der CISO darf nicht der Engpass sein, der jeden Agenten, jedes Tool und jede Änderung des Anwendungsbereichs genehmigen muss; und das Unternehmen verfügt nicht über das erforderliche Sicherheitswissen, um die Kontrollen eigenständig und ohne Aufsicht zu verwalten. Die funktionierende Aufteilung sieht folgendermaßen aus: Das Unternehmen ist verantwortlich für das Was – den Zweck des Agenten, seinen Aufgabenbereich und die Daten, auf die er zugreifen muss. Der CISO und die Rechtsabteilung sind verantwortlich for das Wie – die Sicherheitsvorkehrungen, die Compliance-Lage und die Durchsetzungsmechanismen.
Agentische KI ist bereits Bestandteil jeder Umgebung – ob gewünscht oder nicht. Entwickler setzen Programmieragenten im Produktionscode ein. Geschäftseinheiten verbinden MCP-Server, von denen sie in einem Blog gelesen haben. Es ist wichtig, dies abzusichern, bevor etwas schiefgeht. Agenten werden irgendwann anfangen, Probleme zu verursachen oder sogar in „Panik“ zu geraten. Das Letzte, was man will, ist, sich auf den „guten Willen“ der KI zu verlassen, um die Systeme zu schützen.