Wenn über sichere KI-Agenten gesprochen wird, geht es erstaunlich oft zuerst um das Modell. Kann es manipuliert werden? Wird der Auftrag richtig verstanden? Das sind berechtigte Fragen. Aber ein guter Prompt ist keine Sicherheitskontrolle. Sobald ein Agent nicht nur antwortet, sondern Tools auswählt und über APIs auf Systeme zugreift, beginnt das eigentliche Risiko häufig erst hinter dem Modell: dort, wo ein Aufruf reale Wirkung entfaltet.
Ein Beispiel: Ein Agent bearbeitet eine Lieferantenrechnung. Die Rechnung wird gelesen, das Lieferunternehmen mit den Stammdaten abgeglichen und die Zahlung vorbereitet. Vielleicht dürfen bei Abweichungen sogar Kontodaten aktualisiert werden. Jeder Schritt kann erlaubt und plausibel sein. Trotzdem kann am Ende Geld auf dem falschen Konto landen.
Das Risiko liegt in der Handlungskette
Agenten arbeiten selten isoliert. Sie wählen ein Tool, das über eine API eine Änderung im Zielsystem auslöst. Das Ergebnis wird zur Grundlage für den nächsten Schritt. Das Risiko steckt nicht nur in den einzelnen Komponenten, sondern auch darin, wie sie zusammenspielen. Auftrag, Kontext, Berechtigung und mögliche Wirkung können sich an jedem Übergang verändern.
Ein Toolname beschreibt nur eine Funktion. „E-Mail senden“ kann heißen, einen Entwurf intern zu teilen oder sensible Daten nach außen zu übertragen. Das Risiko ist ein völlig anderes.
Identität ist der Anfang
Agenten brauchen verlässliche Identitäten. Sonst lässt sich kaum nachvollziehen, wer einen Vorgang ausgelöst hat. Das gilt erst recht, wenn weitere Agenten oder Dienste beauftragt werden.
Identität allein reicht aber nicht. Zu wissen, welcher Agent handelt, sagt noch nichts darüber aus, was in diesem Moment erlaubt ist. Es ist ein Unterschied, ob eine Zahlung vorbereitet, ausgelöst oder ob Stammdaten verändert werden. Auftraggebende Stelle, Ziel, Betrag und mögliche Folgen gehören ebenfalls in die Entscheidung.
In vielen Architekturen wird der Zugriff zu früh und zu pauschal festgelegt. Ein Agent erhält ein Token für mehrere Funktionen eines Dienstes, obwohl für den konkreten Auftrag vielleicht nur eine benötigt wird. Ändern sich Auftrag, Ziel oder Kontext, kann diese Berechtigung bereits zu weit reichen.
Secure the Chain
Secure the Chain bedeutet nicht, Agenten bei jedem Schritt anzuhalten. Sie sollen ihre Aufträge erledigen können. Dafür brauchen sie den geringsten ausreichenden Kontext, um zu entscheiden, und die geringste ausreichende Berechtigung, um zu handeln. Ändern sich Auftrag, Ziel, Kontext, Risiko oder mögliche Wirkung, muss diese Berechtigung am nächsten relevanten Übergang neu bewertet werden. Das ist der praktische Kern von Continuous Authorization: neu entscheiden, wenn sich die Grundlage der nächsten Handlung verändert hat.
APIs spielen dabei eine besondere Rolle. An ihnen wird aus dem Auftrag eines Agenten eine konkrete Handlung im realen System. Sie sind dabei Kontroll- und Durchsetzungspunkte. Je nach Architektur kann die Durchsetzung auch am Gateway stattfinden. Entscheidend ist, dass dieselben Regeln dort greifen, wo die Handlung erfolgt.
Sehen, entscheiden, unterbrechen
Nicht jeder Kontrollpunkt ist ein Break Point. Trace Points machen den Weg einer Handlung sichtbar. Sie verbinden Auftrag, Entscheidung und Wirkung im Zielsystem. Es geht nicht um möglichst viele Logdaten, sondern darum, erkennen zu können, wer in wessen Auftrag gehandelt hat und was daraus geworden ist.
Zugriffskontrollen prüfen den Kontext und begrenzen die Berechtigung. Ein Break Point geht weiter und hält die Ausführung an, blockiert den nächsten Aufruf oder entzieht eine Berechtigung. Eine Warnung reicht nicht, wenn im Hintergrund die Zahlung bereits ausgeführt wird.
Break the Chain
Fehlt entscheidender Kontext, gehen Agenten über den jeweiligen Auftrag hinaus oder ist der nächste Schritt nicht mehr vertretbar, muss die Kette warten können. Dann wird eine Berechtigung enger gefasst, ein Token widerrufen oder ein Aufruf blockiert. Manchmal ist eine menschliche Entscheidung nötig.
Hier gilt es, die Balance zu finden. Wer Dutzende Agenten betreibt und jeden Schritt freigeben lässt, hat keine Kontrolle gebaut, sondern eine Warteschlange. Menschen werden dort gebraucht, wo eine Handlung kaum rückgängig zu machen ist oder ein Restrisiko bewusst übernommen werden soll.
Dafür braucht es verständlichen Kontext. Ein roter Warnhinweis ohne Zusammenhang hilft wenig. Die entscheidenden Personen müssen erkennen können, wer handelt, in wessen Auftrag und was unmittelbar passieren würde. Bis die Entscheidung gefallen ist, darf der Prozess nicht weiterlaufen.
Was passiert nach dem Stopp?
Auch das Unterbrechen kann Folgen haben. In einem kritischen Prozess darf nicht vorsorglich alles zum Stillstand kommen. Ein brauchbarer Break Point begrenzt den betroffenen Teil und lässt sichere Abläufe weiterlaufen. Hier treffen Zugriffskontrolle, Resilienz und Business Continuity aufeinander.
Im eingeschränkten Betrieb dürfen Agenten vielleicht noch Informationen lesen, aber keine Änderungen mehr vornehmen. Möglicherweise übernimmt ein vorbereiteter manueller Ablauf eine wichtige Funktion.
Eine Organisation muss im Vorhinein festlegen, wer den Krisenbetrieb ausruft, wer Berechtigungen sofort entziehen darf und welche Funktionen weiterlaufen müssen. Auch für die Übernahme eines Restrisikos und den Wiederanlauf braucht es klare Zuständigkeiten. Agenten können bereits handeln. Sicherer werden sie, wenn ihre Handlungsketten sichtbar, begrenzt und an den richtigen Stellen unterbrechbar sind.
Secure the Chain heißt, Kontext und Berechtigung vor dem nächsten Schritt zu prüfen und eng zu begrenzen. Break the Chain heißt, die Ausführung rechtzeitig anzuhalten, wenn diese Grundlage nicht mehr trägt.
Unternehmen werden nicht jedes Modellverhalten perfekt kontrollieren können. Aber sie können kontrollieren, worauf Agenten zugreifen dürfen, wie weit ihre Wirkung reicht und ob sie noch rechtzeitig eingreifen können.