Wenn die Agenten Einzug halten, hat Ihr Sicherheitsmodell ausgedient

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die meisten heutigen Sicherheitstools für Unternehmen basieren auf einer Reihe sehr spezifischer Annahmen. Das ist keineswegs schlecht, denn diese Annahmen wurden in den vergangenen zwanzig Jahren unzählige Male erprobt und bestätigt. Zu den wichtigsten gehört, dass Software tut, was man ihr sagt, sich Nutzer anhand von Profilen einordnen lassen und Systeme sich unter bekannten Bedingungen vorhersehbar verhalten. Das funktionierte gut, solange es darum ging, APIs, Webserver oder Menschen mit unsicheren Passwortgewohnheiten zu schützen.

Doch all das funktioniert nicht mehr, sobald autonome Agenten ins Spiel kommen.

Agenten folgen nicht immer vorgegebenen Skripten. Sie bewegen sich nicht immer auf statisch definierten Pfaden. Sie schlussfolgern, planen, passen sich an und können sich – wenn man nicht aufpasst – unerwünscht verhalten. Das bedeutet, dass sich Ihr klassisches Sicherheitskonzept im Nachhinein als zu optimistisch erweist.

Glücklicherweise beginnen Sicherheitsforscher, sich mit dieser Realität auseinanderzusetzen. Ein deutliches Zeichen dafür war ein Forschungspapier mit dem Titel „Agentische KI absichern: Bedrohungsmodellierung für LLM-Agenten“. Es entwirft nicht einfach nur eine Reihe neuer beängstigender Szenarien, sondern bietet tatsächlich einen neuen operativen Rahmen, der auf die agentische Welt zugeschnitten ist, in die wir uns kopfüber hineinbewegen.

SHIELD: Ein Framework für Agenten, nicht für APIs

Die Autoren stellen SHIELD vor, einen mehrschichtigen Ansatz zur Verwaltung autonomer Agenten in realen Umgebungen. Dabei handelt es sich nicht nur um eine Liste von Angriffsvektoren, sondern um einen Leitfaden für die Governance. SHIELD umfasst:

• Sandboxing: Legen Sie genau fest, worauf ein Agent zugreifen darf (Tools, Dateien, APIs), bevor er aktiv wird. Verwenden Sie eine Form strenger Zugriffskontrolle. Die Grundidee ist schlüssig, und es gibt bereits zahlreiche Bestrebungen, die Nutzung von Tools durch KI im Allgemeinen zu regulieren.
• Menschliche Kontrolle: Fügen Sie Kontrollpunkte oder Eskalationswege ein, bevor unumkehrbare Aktionen ausgeführt werden. Das erscheint ziemlich selbstverständlich, da es ein wesentlicher Bestandteil der meisten Automatisierungsmaßnahmen ist.
• Schnittstellenbeschränkungen: Strikte Ein-/Ausgaberegeln für die Interaktion des Agenten mit dem System. Klingt nach Eingabebereinigung und Überprüfung der Antworten. Hm.
• Ausführungsverfolgung: Überwachen Sie Werkzeugaufrufe, Änderungen des Speicherzustands und Planungsschleifen. Beobachtbarkeit. Beobachtbarkeit. Beobachtbarkeit.
• Protokollierung: Erfassen Sie nicht nur die Ergebnisse, sondern auch die einzelnen Schlussfolgerungsschritte und die Nutzung von Tools. Dieser Punkt ist zwar für ein griffiges Akronym erforderlich, gehört aber eigentlich zur oben genannten Nachverfolgung und ist Teil einer übergreifenden Observability-Strategie.
• Deterministische Wiedergabe: Inferenzsitzungen rekonstruieren, um nachzuvollziehen, warum etwas passiert ist, und nicht nur, was. Ich kann mir nur schwer vorstellen, dass das möglich ist, da es nahezu unmöglich ist, den „Zustand“ eines Agenten – oder eigentlich jeder KI – wiederherzustellen. Aber wenn es machbar wäre, wäre das schon ziemlich cool.

Es ist zwar noch früh, doch die zentrale Erkenntnis von SHIELD ist entscheidend: Agentische KI erfordert neue Kontrollpunkte, neue Annahmen und neue Denkmodelle. Darauf haben wir vielleicht kürzlich schon hingewiesen, zum Beispiel in diesem Whitepaper. Doch fassen wir zunächst zusammen, was das für Sicherheitsverantwortliche und Entwickler wirklich bedeutet.

Die fünf Veränderungen, die die IT-Sicherheit für agentische KI vollziehen muss

1. Von statischen Bedrohungsmodellen zur dynamischen Verhaltensüberwachung
Herkömmliche Bedrohungsmodelle gehen davon aus, dass Angreifer bekannten Mustern folgen, darunter laterale Bewegungen, Rechteausweitung und die Bereitstellung von Schadsoftware. Doch Agenten folgen keinen bekannten Mustern. Sie können improvisieren.

Sicherheitsteams müssen damit beginnen, emergentes Verhalten zu überwachen. Das bedeutet, Telemetriedaten darüber zu erfassen, was Agenten tun, wie sie denken und wann sie von den vorgesehenen Pfaden abweichen. Semantische Beobachtbarkeit. Mehr gibt es dazu nicht zu sagen.

2. Von Perimeterkontrollen zur Durchsetzung von Richtlinien zur Laufzeit
Firewalls und Schutzmaßnahmen auf Gateway-Ebene helfen nicht, wenn sich der LLM-Agent bereits innerhalb des Systems befindet und selbstständig Tools aufruft, auf Dateien zugreift oder API-Anfragen sendet.

Sicherheitsmaßnahmen müssen näher an die Laufzeitumgebung rücken und aufgabenspezifische Berechtigungen, die Isolierung von Umgebungen sowie die Validierung von Absichten in Echtzeit durchsetzen. Man kann sich das als „Policy-as-Inference“ vorstellen: Was ein Agent tun darf, muss genau in dem Moment überprüft werden, in dem er sich dafür entscheidet, es zu tun. Daten- und Steuerungsebene verschmelzen hier miteinander – und die IT-Sicherheit muss dabei einbezogen werden.

3. Von der Protokollierung von Ereignissen zur Erfassung des Kontexts
Was man nicht versteht, kann man nicht absichern. Und um Agenten zu verstehen, braucht es mehr als nur Protokolle. Prompt-Ketten, Metadaten zu Tool-Aufrufen, Momentaufnahmen des Speichers und der Ausführungskontext müssen vollständig protokolliert und nachvollziehbar sein. Der Kontext ist der neue Perimeter.

Warum hat der Agent fünf Meetings angesetzt und um 2 Uhr morgens eine E-Mail an einen Anbieter geschickt? Das lässt sich nur herausfinden, wenn sein Entscheidungsbaum nachvollzogen werden kann. Hier geht es nicht um Observability, sondern um Agentenforensik.

4. Von Code-Reviews zu Verhaltenstests
Die Logik eines Agenten steckt nicht im Code, sondern in der Kombination aus Gewichtungen, Prompts, Tools und Kontext. Dadurch sind statische Reviews nutzlos.

Was benötigt wird, ist eine verhaltensbasierte Qualitätssicherung in einer Sandbox: Dabei werden Grenzfälle, bösartige Eingaben und Berechtigungsgrenzen simuliert. Behandeln Sie Agenten wie Junior-Entwickler in der Einarbeitung und nicht wie deterministische Codemodule.

Red-Teaming muss sich vom „Eindringen in das System“ hin zum „Manipulieren des Agenten“ weiterentwickeln – wiederholt und mit einem geschärften Blick für Fehlerkaskaden.

5. Von der Benutzeridentität zur Agentenidentität und zum Geltungsbereich
Die Zugriffskontrolle ist heute größtenteils benutzerzentriert: Wer sind Sie und welche Rollen haben Sie? Bei Agenten funktioniert das nicht. Künftig müssen Sie KI-Akteuren eine Identität, einen Berechtigungsumfang und Aufgabengrenzen zuweisen sowie eine automatische Ablaufzeit (Stichwort TTL), die Isolierung vom gemeinsam genutzten Speicher und lückenlose Audit-Protokolle vorsehen.

Kurz gesagt: Zero Trust gilt jetzt auch für nichtmenschliche Akteure. Und dieses Vertrauen muss jedes Mal neu erworben werden, wenn sie ein Tool aufrufen oder auf eine Ressource zugreifen.

Die Sicherheit muss sich anpassen

Agentische KI ist nicht nur eine Neuheit, sondern ein grundlegender Wandel auf Systemebene. Wenn Modelle autonomer werden, nimmt die Entropie Ihres Systems zu und Ihre bisherigen Annahmen werden zu Risiken.

Was SHIELD richtig macht, ist nicht nur seine Liste von Kontrollmechanismen. Es ist die Philosophie, die zwei zentrale Annahmen umfasst:

• Gehen Sie davon aus, dass Agenten vom vorgesehenen Ablauf abweichen werden – sei es von sich aus oder durch Manipulation.
• Gehen Sie davon aus, dass Denkfehler systemweite Nebenwirkungen verursachen können

Sicherheitsteams, die diese Prinzipien jetzt beherzigen, schaffen skalierbare Leitplanken. Und diejenigen, die es nicht tun? Sie werden hinter den Agenten aufräumen müssen, die „doch nur helfen wollten“.

Nein, Ihre bestehenden Frameworks reichen also nicht aus. Die Agenten sind da. Es ist an der Zeit, ihnen mit einer Governance zu begegnen, die wirklich versteht, was sie sind.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie