Es gibt einen Moment, in dem sich ein KI-Projekt in ein Sicherheitsthema verwandelt. Die meisten Unternehmen bemerken ihn nicht.
Ein Assistent formuliert eine E-Mail — das ist ein Textproblem. Ein Agent versendet sie — das ist ein Geschäftsvorgang. Ein Copilot erkennt eine fehlerhafte Cloud-Konfiguration — das ist eine Empfehlung. Ein Agent korrigiert sie in der Produktion — das ist ein Eingriff in laufende Infrastruktur.
Zwischen diesen Paaren liegt kein Modellwechsel. Es liegt ein Häkchen in einer Konfiguration: darf Werkzeuge aufrufen.
Die Sicherheitsdiskussion der letzten Jahre hat sich auf Ausgaben konzentriert. Welche Daten dürfen in einen Prompt? Müssen Antworten gefiltert werden? Welcher Anbieter erfüllt unsere Anforderungen? Das sind notwendige Fragen, und sie bleiben es. Sie reichen nur nicht mehr, sobald das System handeln kann.
Genau an dieser Stelle versagen die meisten KI-Richtlinien. Sie regeln Inhalte — welche Daten hineindürfen, welche Ausgaben herausdürfen, welcher Anbieter zugelassen ist. Sie regeln nicht Handlungen: welche Aktion ein probabilistisches System in einem produktiven System tatsächlich auslösen darf.
Der Unterschied liegt nicht im Modell
Ein Sprachmodell nimmt Kontext entgegen und erzeugt Text. Ein KI-Agent leitet daraus einen nächsten Schritt ab: Er wählt ein Werkzeug, ruft eine Schnittstelle auf, verarbeitet das Ergebnis — und entscheidet auf dieser Grundlage über den übernächsten Schritt.
Diese Rückkopplung ist der sicherheitstechnisch entscheidende Teil. Das Ergebnis einer Aktion beeinflusst den nächsten Schritt. Ein Agent kann deshalb mehrere Aktionen hintereinander ausführen, ohne dass zwischen den Schritten ein Mensch steht.
Der Werkzeugaufruf selbst ist dabei gewöhnliche Software. Ein API-Endpunkt bleibt ein API-Endpunkt. Eine Datenbank führt SQL aus. Neu ist ausschließlich die Instanz, die auswählt: welches Werkzeug, welche Parameter, wann — und auf Basis welcher vorherigen Ausgabe.
"Die Ausgabe eines Sprachmodells ist Text. Der Aufruf eines Agenten ist ein Seiteneffekt in einem System, das ihn als legitim behandelt."
Der sicherheitsrelevante Unterschied ist nicht Determinismus, sondern Autorität. Das verändert nicht zwingend die Wahrscheinlichkeit eines Fehlers — es verändert seine Konsequenz. Ein halluzinierter Servername in einer Empfehlung ist ein Qualitätsproblem. Derselbe Servername als Parameter eines Isolationsbefehls ist ein Produktionsausfall.
In mehrstufigen Abläufen kommt hinzu, dass Fehler sich fortpflanzen: Das Ergebnis eines falschen Schritts wird zum Kontext des nächsten.
Was in Ihrer KI-Richtlinie steht — und was fehlt
Nehmen Sie Ihre KI-Richtlinie und lesen Sie sie mit einer einzigen Frage im Kopf: Was davon greift, wenn das System nicht antwortet, sondern handelt?
Die linke Spalte ist nicht falsch. Sie ist nur vollständig auf die Frage ausgerichtet, was ein Modell sagt. Sobald ein System tut, verschiebt sich die Sicherheitsgrenze an eine Stelle, über die in der Richtlinie kein Satz steht: dorthin, wo aus einer probabilistischen Entscheidung ein realer Systemzustand wird.
Warum ein Prompt keine Grenze ist
Ein Systemprompt kann sagen: Lösche niemals produktive Daten. Das ist eine Verhaltensbeschreibung — sie hält so lange, wie das Modell sich daran hält.
Eine Autorisierungsentscheidung außerhalb des Modells sieht anders aus. Sie stellt fest:
action = DELETE
environment = PRODUCTION
resource = CUSTOMER_DATABASE
agent = support-agent
→ DENYKein Unternehmen würde einen kritischen API-Endpunkt dadurch absichern, dass es den aufrufenden Client höflich anweist, bestimmte Operationen zu unterlassen. Bei einem Agenten sollte derselbe Grundsatz gelten.
Der Kernsatz. Ein Prompt formuliert gewünschtes Verhalten. Eine Grenze erzwingt es. Der Unterschied klingt akademisch und ist es nicht — er entscheidet darüber, ob ein manipuliertes Dokument, eine missverständliche Anweisung oder ein Modellfehler zu einem Vorfall wird oder zu einer abgelehnten Anfrage.
Ein Modell darf an einer Sicherheitsentscheidung beteiligt sein. Es sollte bei folgenreichen Aktionen nur nicht die einzige Instanz sein, die entscheidet.
Was folgenreich wirklich bedeutet
Der Begriff wird meist auf Zustandsänderungen verengt: schreiben, löschen, ausführen. Das ist zu eng. Ein Lesezugriff ändert zunächst nichts — und kann trotzdem der schwerwiegendste Schritt eines Angriffs sein, sobald der gelesene Inhalt in Speicher, Kontext oder einen Ausgangskanal gelangt.
Folgenreich ist jede Aktion, die Sicherheits-, Daten-, Geschäfts- oder Außenwirkung entfalten kann. Dazu gehören ausdrücklich auch: vertrauliche Daten lesen, Rechte vergeben, Werte übertragen, veröffentlichen, nach außen kommunizieren, verpflichten und freigeben.
Und die Wirkung endet nicht an externen Schnittstellen. Der unangenehmste Fall ist der zeitversetzte:
Tag 1. Ein Agent verarbeitet ein manipuliertes Lieferantendokument und schreibt einen vermeintlichen Fakt in sein Langzeitgedächtnis: Lieferant X darf Eilzahlungen freigeben.
Zu diesem Zeitpunkt ist nichts passiert. Keine Zahlung, keine Änderung, kein Alarm. Ein Audit würde nichts finden.
Drei Wochen später. In einem anderen Workflow wird derselbe Eintrag zur Grundlage einer Zahlungsfreigabe.
Persistente Änderungen an Gedächtnis, Kontextspeichern, Werkzeugkatalogen oder Agentenkonfigurationen beeinflussen künftige Entscheidungen. Sie sind deshalb je nach Wirkung selbst folgenreiche Aktionen — und weil der Angriff zeitversetzt wirkt, ist er im Nachhinein besonders schwer zuzuordnen.
Die Kombination, die aus einem Agenten ein Risiko macht
Nicht jeder manipulierbare Agent ist gefährlich. Gefährlich wird ein Agent, der drei Eigenschaften gleichzeitig besitzt — von Simon Willison als lethal trifecta beschrieben:
Zugriff auf vertrauliche Daten. Kundendaten, Quellcode, Verträge, Zugangsdaten.
Verarbeitung von Inhalten, die ein Angreifer beeinflussen kann. E-Mails, PDFs, Webseiten, Ticket-Kommentare, Werkzeugausgaben, fremde Repositories.
Ein Kanal nach außen. Die Möglichkeit, Informationen aus der Umgebung herauszubringen.
Jede dieser Eigenschaften ist für sich genommen alltäglich. Zusammen ergeben sie einen vollständigen Exfiltrationspfad, den ein Angreifer allein über Inhalte auslösen kann — ohne jemals ein System zu kompromittieren.
Der dritte Punkt wird dabei regelmäßig unterschätzt. Kanal nach außen bedeutet nicht nur send_email(). Es genügt oft erheblich weniger: eine Bildreferenz in einer gerenderten Antwort, deren URL Daten im Pfad transportiert. Ein Suchaufruf, dessen Suchbegriff frei wählbar ist. Eine Namensauflösung. Ein Link, den ein Mensch anschließend anklickt. Wer den Ausgangskanal begrenzen will, muss ihn zuerst vollständig kennen — und diese Liste ist fast immer länger als die Liste der Werkzeuge.
Die naheliegende Gegenmaßnahme ist eine Zerlegung: Ein Agent verarbeitet fremde Inhalte ohne Zugriff auf vertrauliche Daten, ein zweiter arbeitet auf vertraulichen Daten, sieht aber keine fremden Inhalte. Das löst das Problem nur, wenn die Grenze zwischen beiden hält. Reicht Agent A eine Nachricht an Agent B weiter, und darf B vertrauliche Daten lesen und nach außen kommunizieren, ist die Kombination über den Verbund wiederhergestellt — verteilt auf zwei Systeme, die einzeln unauffällig aussehen.
"Kein erreichbarer Pfad durch Agenten und Werkzeuge darf die drei Eigenschaften vereinen, ohne dass mindestens eine unabhängige technische Grenze den Daten- oder Aktionsfluss unterbricht."
Das ist eine Aussage über den gesamten erreichbaren Daten- und Aktionsgraphen, nicht über einzelne Komponenten. Beantworten lässt sie sich nur, wenn man diesen Graphen kennt. Die Risikokategorien für agentische Anwendungen — Goal Hijacking, Tool Misuse, Memory Poisoning, Rogue Agents — sind im OWASP GenAI Security Project systematisch beschrieben; konkrete Angriffstechniken gegen KI-Systeme sammelt MITRE ATLAS.
Die sechs Fragen, die Ihre Richtlinie beantworten muss
Bevor ein Agent eine folgenreiche Aktion ausführt, sollte die Architektur sechs Fragen beantworten können. Jede Frage korrespondiert mit einer Eigenschaft, die das System danach besitzen muss — die Frage ist der Prüfpunkt, die Eigenschaft das Ergebnis.
Warum Identität und Befugnis nicht dasselbe sind
Der häufigste Fehler in produktiven Agenten: Der Agent handelt unter dem Token seines menschlichen Auftraggebers. Damit ist im Nachhinein nicht unterscheidbar, ob der Mensch oder der Agent gehandelt hat — und der Agent erbt sämtliche Rechte des Menschen.
Für die saubere Darstellung dieser Beziehung existiert ein Standard: RFC 8693 (OAuth 2.0 Token Exchange) kennt mit dem act-Claim die Konstruktion X handelt im Auftrag von Y. Das Protokoll ist vorhandene Infrastruktur; die eigentliche Arbeit ist seine Integration in Agentenarchitekturen. Und: Dass ein Mensch eine Rückerstattung freigeben darf, bedeutet nicht, dass diese Fähigkeit an einen Agenten delegiert werden sollte.
Least Privilege reicht nicht — Least Capability schon eher
Least Privilege begrenzt die Rechte einer Identität. Least Capability begrenzt den Handlungsraum des Agenten. Ein Agent kann eine Funktion, die ihm gar nicht zur Verfügung steht, auch nach erfolgreicher Manipulation nicht aufrufen. Ein Agent zur E-Mail-Zusammenfassung braucht kein send_mail().
Diesen sechs Fragen ist eine siebte vorgelagert, die in den meisten Unternehmen unbeantwortet ist: Welche Agenten führen bei uns überhaupt schon Aktionen aus? Besonders relevant sind Assistenzfunktionen, die per Update in bereits genehmigter Software erschienen sind — sie durchlaufen keinen Beschaffungsvorgang und bekommen trotzdem Zugriff auf Systeme.
Wie die zugehörige Referenzarchitektur aussieht, welche Kontrollen an welcher Stelle greifen und wie sich Aktionen in Risikoklassen schneiden lassen, führt unser Whitepaper Von Model Security zu Agentic Action Security auf 33 Seiten aus.
Wo diese Grenze endet
Eine unabhängige Entscheidung vor dem Werkzeugaufruf ist eine wirksame Grenze. Sie ist keine vollständige. Vier Einschränkungen sollte kennen, wer sich darauf verlässt:
Eine Policy entscheidet nur so präzise, wie ihr Bedeutung bereitgestellt wird. send_email(to, body) trägt kaum Semantik. Der Empfänger lässt sich gegen eine Allowlist prüfen — ob der Textkörper Vertrauliches transportiert, nicht. Die Aktion ist erlaubt, die Absicht dahinter nicht.
Die Grenze sieht immer nur eine Aktion. Der Angriff kann in der Sequenz liegen. Jede Einzelentscheidung korrekt — und die Summe trotzdem ein Schaden. Deshalb gehören Budgets für Menge, Wert und Änderungsumfang dazu, nicht nur Einzelfallprüfungen.
Menschliche Freigabe wird zur Bestätigungsschleife. Ein Agent, der einem Analysten fünfzigmal pro Schicht denselben Dialog zeigt, erzeugt kein Vier-Augen-Prinzip. Freigabe, die zur Routine wird, ist Dokumentation, keine Kontrolle.
Eine Grenze, die man umgehen kann, ist keine. Wenn neben dem kontrollierten Pfad noch eine Shell, ein roher Netzwerkzugang oder ein direkt hinterlegtes Credential existiert, ist die Architektur auf dem Papier korrekt und in der Praxis wirkungslos.
Wer kontrolliert, was der freigebende Mensch zu sehen bekommt?
Diese Frage wird fast nie gestellt und ist die unangenehmste des Kapitels. Wenn der Agent dem Menschen mitteilt Ich möchte Lieferantenangebot #42 bestätigen. Auswirkung: keine — und genau dieser Agent ist kompromittiert —, dann ist die Freigabemaske Teil des Angriffs.
Bei folgenreichen Aktionen darf der Freigebende deshalb nicht ausschließlich eine vom Agenten erzeugte Zusammenfassung sehen. Die Maske sollte ihre Angaben aus vertrauenswürdigen Systemen beziehen:
AKTION Bestellung anlegen
LIEFERANT ACME GmbH [aus Lieferantenregister verifiziert]
BETRAG 47.250 EUR
HERKUNFT extrahiert aus externem PDF [nicht verifiziert]
BUDGETVERANTWORTUNG M. Beispiel [aus Kostenstellenstammdaten]
ZUSTANDSÄNDERUNG neue vertragliche Verpflichtung
UMKEHRBARKEIT gering
POLICY menschliche Freigabe erforderlichUnd die Freigabe sollte an genau diese Aktion gebunden sein — an Actor, Ressource, normalisierte Parameter und Policy-Version, mit Ablaufzeit. Ändert der Agent danach den Betrag von 5.000 auf 50.000, ist die Freigabe ungültig.
Der regulatorische Anschluss: AI Act, NIS2, DORA
Für Unternehmen im Anwendungsbereich europäischer Regulierung zeigen mehrere Anforderungen in dieselbe Richtung.
Der EU AI Act verlangt, dass Hochrisiko-KI-Systeme so konzipiert werden, dass sie während ihrer Nutzung wirksam durch natürliche Personen beaufsichtigt werden können; die Maßnahmen müssen dem Risiko, dem Autonomiegrad und dem Nutzungskontext angemessen sein (Art. 14). Eine rein formale Freigabeschaltfläche erfüllt diese Anforderung jedenfalls nicht von selbst.
Für NIS2-pflichtige Unternehmen läuft die Verbindung über Governance: Die Leitungsorgane müssen die Risikomanagementmaßnahmen billigen und ihre Umsetzung überwachen (Art. 20). Die Schlusskette ist kurz — unbekannte autonome Agenten sind unbekanntes Cyber-Risiko, und was nicht inventarisiert ist, lässt sich nicht steuern.
DORA verlangt von Finanzunternehmen, IKT-Drittparteienrisiken als integralen Bestandteil des IKT-Risikomanagements zu behandeln. Wird agentische Funktionalität durch einen SaaS-Anbieter in einen kritischen Geschäftsprozess eingebracht, verändert sie die bestehende Drittparteienabhängigkeit — auch dann, wenn die Agentenfunktion nie gesondert beschafft wurde.
Einordnung, keine Rechtsberatung. Anwendungsbereich, Fristen und Umsetzungsstand sind zum Zeitpunkt der Anwendung zu prüfen; die Geltung einzelner Teile des AI Acts ist zeitlich gestaffelt. Methodische Grundlagen liefern das NIST AI Risk Management Framework und für die Architekturseite NIST SP 800-207 (Zero Trust Architecture). Deutschsprachige Orientierung bietet das BSI zum Thema Künstliche Intelligenz.
Was Sie in den nächsten 30 Tagen tun können
Der praktische Blocker ist selten die Technologie. IAM, API-Gateways, Policy Engines, Protokollierung sind in den meisten Unternehmen vorhanden. Die Aufgabe besteht darin, sie an einer neuen Stelle zusammenzuführen — dort, wo aus einer probabilistischen Entscheidung eine reale Handlung wird.
Liste ziehen und markieren. Nehmen Sie Ihre Liste der KI-Anwendungen und markieren Sie jede, die etwas auslösen kann — eine Mail versenden, einen Datensatz ändern, ein Ticket schließen, eine Konfiguration anpassen. Wenn die Liste leer ist, prüfen Sie noch einmal: Assistenzfunktionen in bereits genehmigter Software werden selten als KI-Anwendung geführt.
Identität klären. Für jeden markierten Agenten festhalten, welcher technische Principal handelt und welche menschliche oder geschäftliche Autorität dahintersteht. Lautet die Antwort unter dem Token des Benutzers, ist das die erste Baustelle.
Fähigkeiten inventarisieren. Werkzeuginventare sind für Agenten so wichtig wie Berechtigungsinventare für Benutzer. Nicht benötigte Fähigkeiten gehören entfernt, nicht per Prompt untersagt.
Umgehbarkeit prüfen. Für die kritischen Aktionen feststellen, ob die Grenze tatsächlich der einzige Weg zum Zielsystem ist — oder ob daneben noch eine Shell, ein roher Netzwerkzugang oder ein direktes Credential existiert.
Not-Aus entwerfen und testen. Credential Revocation, Werkzeug-Abschaltung, Netzwerkisolation und Rollback müssen vor dem Vorfall funktionieren, nicht während seiner Bearbeitung.
Ein Unternehmen, das diese Punkte für seine kritischsten Agenten beantworten kann, steht besser da als eines mit umfangreicher KI-Richtlinie und unbekannten produktiven Agenten.
Von Model Security zu Agentic Action Security
33 Seiten zur Sicherheitsgrenze vor dem Werkzeugaufruf: Referenzarchitektur, Risikoklassen nach geschäftlicher Umkehrbarkeit, Delegation über RFC 8693 — und eine ehrliche Liste dessen, was diese Grenze nicht leistet.
Whitepaper als PDF laden →PDF, 1,5 MB · ohne Registrierung · Paper #01 der Reihe Agentic AI Security
Häufige Fragen
Ab wann ist eine KI-Anwendung ein Agent?
Wenn sie Werkzeuge aufrufen kann und ihre Aufrufe nicht vollständig aus vorab festgelegter Programmlogik ableitet. Ein Skript, das jede Nacht denselben Report erzeugt, fällt nicht darunter. Ein System, das aus einer Modellausgabe ableitet, welche Schnittstelle es mit welchen Parametern aufruft, schon.
Reicht es nicht, gute Prompts zu schreiben?
Für die Qualität der Ausgabe: ja. Für die Begrenzung von Handlungen: nein. Ein Prompt beschreibt gewünschtes Verhalten und ist keine technische Grenze. Er lässt sich durch manipulierte Inhalte, missverständliche Anweisungen oder schlicht durch einen Modellfehler aushebeln.
Brauchen wir dafür neue Sicherheitswerkzeuge?
Meist nicht. Die Bausteine — Identitätsverwaltung, Gateways, Policy Engines, Protokollierung — sind in den meisten Organisationen vorhanden. Neu ist die Stelle, an der sie ansetzen müssen: vor dem Werkzeugaufruf statt vor der Sitzung.
Gilt das auch für eingekaufte KI-Funktionen?
Besonders für die. Assistenzfunktionen in bereits genehmigter Software durchlaufen keinen Beschaffungsvorgang und bekommen trotzdem Zugriff auf Systeme. Sie sind der häufigste Fall von handelnden Agenten, die in keiner KI-Richtlinie auftauchen.
Muss dann jede Agentenaktion von einem Menschen freigegeben werden?
Nein — das würde den Nutzen autonomer Systeme vollständig aufheben. Das Ziel ist Automatisierung dort, wo das Risiko begrenzt ist, und menschliche Entscheidung dort, wo menschliches Urteil tatsächlich einen Sicherheitsgewinn erzeugt. Die aufschlussreichste Einzelgröße für diese Einstufung ist die geschäftliche Umkehrbarkeit: Kann die Wirkung rechtzeitig und vollständig rückgängig gemacht werden?
Ist das nicht einfach Zero Trust?
Zur Hälfte. Die Prinzipien — explizite Identität, minimale Autorität, kontextabhängige Entscheidungen, externe Enforcement Points — werden angewendet, nicht ersetzt. Der Unterschied liegt in der Granularität: von der Ressource und der Sitzung hin zur konkreten, agentisch gewählten Aktion und ihrem erwarteten Effekt. Hinzu kommt eine Eigenschaft, die klassische Architekturen nicht voraussetzen mussten: Der Handelnde ist nicht deterministisch.
Fazit: Nicht formulieren, sondern begrenzen
Das Modell bleibt wichtig — seine Sicherheit, seine Kontextdaten, seine Robustheit gehören weiterhin zu einer belastbaren Architektur. Die entscheidende Veränderung beginnt dort, wo das System handeln kann. Von diesem Moment an reicht die Frage Wie sorgen wir dafür, dass das Modell das Richtige tut? nicht mehr aus.
Ein Agent darf weder wie ein Benutzer noch wie ein klassischer Dienst behandelt werden. Er ist ein Workload mit dynamisch gewähltem Handlungsverlauf und delegierter Autorität. Seine Identität muss explizit, seine Autorität begrenzt, jede folgenreiche Aktion unabhängig vermittelt und seine kumulative Wirkung budgetiert sein.
Wir müssen nicht jede Fehlentscheidung eines Agenten verhindern können. Wir müssen kontrollieren, was aus ihr werden darf.