Cyberimmunität für KI-Agenten

Schon der Schutz herkömmlicher IT ist eine Wissenschaft für sich. Viel schwieriger ist es jedoch bei KI-Systemen – egal, ob es um Bedienungsfehler, böswillige Eingriffe oder instabiles Verhalten geht. Die zwei Hauptgründe: Erstens hängen die Antworten der KI von Wahrscheinlichkeiten ab: Ein- und derselbe Prompt kann bei jedem Durchlauf unterschiedliche Ergebnisse liefern. Zweitens können LLMs nach wie vor nicht zuverlässig zwischen Befehlen und Daten unterscheiden. Wir haben schon mehrfach über offensichtliche Sicherheitsprobleme von KI-Systemen berichtet. Trotz aller Schwierigkeiten lässt sich jedoch der potenzielle wirtschaftliche Nutzen der KI nicht bestreiten. Deshalb wechseln jetzt viele Unternehmen von einfachen KI-Assistenten zu KI-Agenten. Diese Agenten erledigen Aufgaben selbstständig, können direkt auf dieselben Tools wie menschliche Mitarbeiter zugreifen und dadurch beispielsweise Datenbanken auslesen oder die Einstellungen für Produktionsprozesse ändern. Unsere Experten haben in einer neuen Studie untersucht, wie sich die damit einhergehenden Risiken klar definieren und minimieren lassen, um potenzielle Probleme aufs Äußerste zu reduzieren. Dabei wurden die Prinzipien der Cyberimmunität und des Secure-by-Design-Ansatzes verwendet und entsprechend angepasst.

Die Grundprinzipien von Secure by Design

Alle Prinzipien dieses Konzepts lassen sich universell auf die Planung beliebiger Computersysteme anwenden. Auch bei KI-Agenten. Unterschiede bestehen lediglich darin, wie stark die einzelnen Prinzipien für KI-Szenarien angepasst und überarbeitet werden müssen.

1. Sicherheit ist bereits in der Planungsphase ein separater und wichtiger Faktor. Ziele und Grundsätze der Sicherheit werden ganz zu Beginn festgelegt und müssen in jeder Entwicklungsphase berücksichtigt werden. Bei KI-Agenten sollten diese Voraussetzungen drei zentrale Punkte umfassen: (a) Das Sprachmodell wird als nicht vertrauenswürdig betrachtet, (b) beliebige externe Daten gelten als potenziell bösartig, und (c) irreversible Aktionen dürfen nicht autonom ausgeführt werden, sondern setzen eine Genehmigung durch Menschen voraus.
2. Beim Entwurf eines Systems gilt die Prämisse, dass es unbedingt angegriffen wird.
3. Trusted Computing Base und Angriffsfläche werden auf ein Minimum beschränkt. Agenten erhalten nur die tatsächlich benötigten Tools, eingeschränkte Berechtigungen und möglichst wenig Kontext. Die Durchsetzung von Sicherheitsrichtlinien wird vollständig von deterministischen Komponenten übernommen: von einem Richtlinienmonitor, der Steuerungsumgebung des Agenten (harness) und Isolationsmechanismen (Sandboxen).
4. Es gilt das Prinzip der minimalen Berechtigungen. Jeder Agent verfügt über eigene Anmeldeinformationen und Zugriffsberechtigungen (identity). Diese beschränken sich auf ein absolutes Minimum. Wenn ein Agent vorübergehend erweiterte Berechtigungen benötigt, erhält er diese erst nach externer Genehmigung. Solche Ausnahmen gelten nur für die Dauer der jeweiligen Aufgabe.
5. Komponenten werden isoliert. In agentenbasierten Systemen ist dies eines der komplexesten und vielschichtigsten Architekturprobleme. Die Steuerungsumgebung des Agenten sollte in einer isolierten Umgebung (Sandbox oder virtuelle Maschine) ausgeführt werden, und die Agenten sollten so weit wie möglich voneinander isoliert sein. Ebenso bleibt auch die Datenverarbeitung in vertrauenswürdigen und nicht vertrauenswürdigen Kontexten getrennt. Beispiel: Ein Agent liest einen Pull-Request und erstellt einen Codeentwurf, während ein anderer Agent die Ergebnisse überprüft, ohne den potenziell schädlichen Anfragetext zu sehen.
6. Es gilt das „Default Deny“-Prinzip. Sicherheitsrichtlinien folgen der Regel: Alles, was nicht ausdrücklich erlaubt ist, ist verboten. Dies bezieht sich auch auf Tool-Aufrufe, Interaktionen zwischen Agenten und den Netzwerkverkehr.
7. Der Schutz besteht aus mehreren Schichten (defense in depth). Verschiedene Maßnahmen werden synchron eingesetzt und verstärken einander. Schutzmaßnahmen, die von Wahrscheinlichkeiten abhängen – wie KI-Leitplanken (sozusagen die „Firewall“ des Sprachmodells) oder Alignment (das Verständnis des Modells davon, was akzeptabel ist und was nicht) – können keine formalen Sicherheitsgarantien bieten. Dennoch erhöhen sie die Sicherheit des Gesamtsystems und liefern wertvolle Telemetriedaten.
8. Die Lieferkette wird geschützt. Einige Agenten können Skills, Bibliotheken und andere Softwarekomponenten ohne fremde Hilfe installieren. Deshalb sind strenge Regeln unerlässlich. Diese Fähigkeiten müssen entweder vollständig gesperrt oder auf eine vorab genehmigte Liste für konkrete Versionen bestimmter Komponenten beschränkt werden. Systeme, die auf cloudgestützten LLMs basieren, unterliegen aufgrund von Modellaktualisierungen einem zusätzlichen Risiko. Es könnte sein, dass eine API-Anfrage von einem anderen Sprachmodell mit anderen Sicherheitseigenschaften beantwortet wird.

Fallstricke der KI-Sicherheit

Die Grundprinzipien von Secure by Design sind allgemein bekannt und sind theoretisch ganz einfach. Die Anwendung auf KI-Systeme ist jedoch knifflig, da Agenten unglaublich flexibel sind. Ein Sicherheitsteam könnte beispielsweise annehmen, dass ein Agent auf dem Computer eines Entwicklers in einer Sandbox läuft und nicht auf externe Geräte zugreifen kann. Aber nicht nur ein Angreifer, sondern sogar der Agent selbst hat Dutzende von Möglichkeiten, um diesen scheinbar soliden Schutz zu umgehen: von der Befehlsausführung über einen lokalen MCP-Server, der nicht den Sandbox-Beschränkungen unterliegt, bis hin zur Neukonfiguration eines anderen KI-Agenten, der auf dem System installiert ist. Erschwerend kommt hinzu, dass die Bandbreite der Angriffsvektoren enorm ist: Sie reicht von beliebigen Feldern in der Konfiguration des Agenten bis hin zu harmlos wirkenden Textzeichenfolgen in einer Skill-Datei.

Ein ernstes, von Entwicklern oft unterschätztes Problem ist die Ermüdung von Nutzern. Ein stark ausgelasteter KI-Agent kann jede Minute Dutzende von Anfragen anzeigen, die den Nutzer auffordern, potenziell gefährliche Aktionen zu bestätigen. Irgendwann klickt der Nutzer nur noch mechanisch auf Zulassen und liest Abfragetexte gar nicht mehr. Deshalb müssen Häufigkeit und Formulierung solcher Anfragen sorgfältig bedacht werden. Sind die Beschreibungen zu lang, werden sie ignoriert. In einer kurzen Beschreibung können dagegen wichtige Details fehlen, die der Nutzer zur richtigen Entscheidung benötigt.

Schwachstellen in Agenten und den zugehörigen Tools sind ein akutes Problem. Es wird dadurch verschärft, dass diese Softwarekategorien rasant weiterentwickelt und laufend aktualisiert werden. In branchenüblichen Plattformen und Apps wie LangGraph, MS Semantic Kernel und Claude Code mussten bereits mehrfach kritische Schwachstellen behoben werden. Architekten sollten nicht auf ein großes multifunktionales Framework setzen, sondern ein kompaktes, schlankes System in Betracht ziehen, das nur die Funktionen bietet, die ein konkreter Agent tatsächlich benötigt.

Darüber hinaus können in die eingesetzten Tools bewährte Sicherheitsmaßnahmen implementiert werden, wodurch sich Fälle, bei denen ein Agent angegriffen wird oder sich unerwartet verhält, erheblich entschärfen lassen. Beispiel: eine strenge Allow-Liste mit Domänen, für die WebFetch das Öffnen auf Anforderung des Agenten erlaubt. Häufig lassen Entwickler diese verborgenen Probleme jedoch unberücksichtigt und wollen zusätzlichen Aufwand vermeiden, der mit der Pflege dieser Liste einhergeht. Eine veraltete Liste bietet Angreifern Schlupflöcher. Der EchoLeak-Angriff ist ein eindrückliches Beispiel dafür. Obwohl Microsoft 365 Copilot über eine korrekt implementierte und wirksame Allow-Liste für den Zugriff auf externe Websites verfügte, gelang es Angreifern, die Liste mithilfe einer Funktion in einem sekundären Tool und der MS Teams-Domäne zu umgehen.

Praktische Tipps für Architekten und Sicherheitsteams

KI-Systemarchitekten und Leiter von Entwicklungs- und Sicherheitsteams sollten bereits in der Planungsphase ernsthaft über die Sicherheit von Agenten nachdenken. Überprüfbare, auf Eindeutigkeit ausgelegte Mechanismen sollten bevorzugt werden: Isolierung von Komponenten, Kontrolle von Interaktionen und maximale Beschränkung der Trusted Computing Base.

Zu den wichtigsten Architekturentscheidungen gehören die Definition des zulässigen Autonomiegrads von Agenten, die Beschränkung des Zugriffs auf vertrauliche Daten und riskante Kombinationen von Fähigkeiten sowie der Einsatz von Sandboxen, getrennten Rollen für verschiedene Modelle und Gateways für die Zugriffskontrolle. Nachträglich eingeführte Beschränkungen mindern die Risiken zwar, können eine sichere Architektur jedoch nicht ersetzen.

Auf organisatorischer und operativer Ebene müssen Unternehmen ihre Agenten kontinuierlich inventarisieren, ihre Sicherheits- und Bereitstellungsteams koordinieren, Container-Umgebungen schützen, die Lieferkette verwalten (AIBOM) und eine mehrschichtige Abwehr integrieren.

Besonders wichtig ist die Beobachtbarkeit. Bei KI-Systemen sollte dies die Protokollierung von Prompts, Antworten und Schlussfolgerungen des LLM sowie detaillierte Telemetriedaten von den Hosts und Cloud-Umgebungen umfassen, in denen das Agenten-Framework ausgeführt wird.

Die größte Herausforderung beim Entwurf von Agenten besteht darin, Sicherheit, Leistung und Nutzen unter einen Hut zu bringen. Wie sich dieses Gleichgewicht mithilfe von Bedrohungsmodellierung und klar definierten Sicherheitszielen erreichen lässt, erfährst du in der vollständigen Version der Studie.