KI-Agenten als privilegierte Insider

KI-Agenten halten viel schneller Einzug in Unternehmen, als die meisten Sicherheitskonzepte es vorsehen. Inzwischen beantworten sie nicht mehr nur Fragen oder generieren Inhalte, sondern lesen unter anderem E-Mails, greifen auf SaaS-Anwendungen zu, fragen Datenbanken ab, ändern Datensätze und führen Geschäftsprozesse aus. KI entwickelt sich damit vom Antwortgeber zum Akteur.

Genauso wie eine privilegierte menschliche Identität hat ein KI-Agent damit Zugriff auf wichtige Systeme, sensible Informationen und Geschäftsprozesse. Der KI-Agent wird mithin zu einer digitalen Arbeitskraft im Unternehmen. Er kann binnen Sekunden Entscheidungen treffen, ohne dass jede einzelne Aktion genehmigt werden muss. Um gefährlich zu werden, braucht er keine böswillige Absicht: Erhält er zu viel Zugriff, zu viel Autonomie und zu wenig Aufsicht, kann ein Risiko entstehen, das dem eines Insiders gleicht.

Für CISOs und Führungskräfte verändert dies die Sicherheitsdiskussion. Die Frage ist nicht nur, ob ein Unternehmen KI sicher einsetzt. Wichtiger ist, ob sich jeder einzelne KI-Agent zuverlässig identifizieren, steuern, überwachen und kontrollieren lässt, bevor er zum nächsten privilegierten Insider wird.

Gefahr durch Prompt-Injection

Prompt-Injection steht in den OWASP Top 10 for LLM Applications auf Platz eins. Angreifer nutzen aus, dass Large-Language-Models (LLMs) nicht zuverlässig zwischen legitimen Anweisungen und eingeschleusten Inhalten unterscheiden können. Angenommen, böswillige Inhalte einer Website, zum Beispiel eingebettete Befehle, manipulieren einen Agenten so, dass er ein legitimes Tool aufruft. Der Agent nutzt dann gültige Anmeldedaten, um eine Aktion auszuführen, die seine Entwickler nie vorgesehen haben. Die Authentifizierung funktioniert, die Autorisierung technisch womöglich auch – und doch ist das Verhalten falsch. Authentifizierung allein kann daher kein dauerhaftes Vertrauen in eine autonome Identität begründen.

Traditionelles Identity and Access-Management reicht nicht aus

Identity and Access-Management (IAM) ist unabdingbar. Es beantwortet die Frage: Worauf darf diese Identität zugreifen? Agentische KI wirft eine zweite Frage auf: Darf dieser Agent genau diese Aktion in diesem Kontext jetzt ausführen? Ein Agent braucht zum Beispiel Lesezugriff auf eine Kundendatenbank, um seine Aufgabe zu erledigen. Das heißt aber nicht, dass er automatisch auch Kundendatensätze löschen darf. Neben der Zugriffskontrolle tritt deshalb die Aktionskontrolle: Unternehmen legen klare Grenzen für den Betrieb von Agenten fest. Beispielsweise könnte eine einfache Richtlinie bestimmen, dass autonome KI-Agenten keine Produktionsdaten eigenständig löschen dürfen. Erstellen und Lesen sind erlaubt, Ändern nur unter definierten Bedingungen; Löschvorgänge werden blockiert oder erfordern eine menschliche Freigabe.

Wichtig ist: Eine solche Regel sollte nicht bloß als Anweisung im System-Prompt stehen („Bitte keine Produktionsdaten löschen“).  Die Sicherheitskontrolle muss vielmehr außerhalb des Agenten liegen und technisch durchgesetzt werden. Selbst wenn der KI-Agent entscheidet, dass Löschen der beste Weg ist, um sein Ziel zu erreichen, sollte die Sicherheitsrichtlinie des Unternehmens das letzte Wort haben.

Fortgeschrittene Plattformen setzen solche Kontrollen bereits technisch um. Sie machen sichtbar, welche Agenten über MCP-Server (Model-Context-Protocol) arbeiten und welche Tools ihnen zur Verfügung stehen. Die Operationen der Agenten werden nach Erstellen, Lesen, Ändern und Löschen eingeordnet und per Richtlinie erlaubt oder blockiert. Das ist entscheidend, denn beim Tool-Aufruf hat die Zugriffskontrolle längst zugestimmt. Agenten authentifizieren sich meist mit einem geerbten Token, das den vollen Operationsumfang mitbringt, den das System gewährt. Die Identitätsprüfung klärt, wer aufruft – nicht aber, warum. Und weil Agenten auch Dokumente, Webseiten und Tool-Ausgaben aus unsicheren Quellen verarbeiten, geht eine Anfrage womöglich gar nicht auf den ursprünglichen Auftrag zurück. Eine Regel auf Operationsebene greift trotzdem: Sie blockiert das Löschen, ganz gleich, was den Agenten dazu gebracht hat.

Runtime-Enforcement

Agenten handeln schnell und oft über mehrere Stationen hinweg: Beschäftigte → KI-Agent → Modell → MCP-Tool → API → Löschbefehl. Der Agent mag authentifiziert und der API-Aufruf technisch gültig sein; vielleicht hält er das Löschen sogar für nötig, um die Anfrage zu erfüllen. Runtime-Enforcement setzt deshalb unmittelbar vor der letzten Aktion einen Kontrollpunkt: Prompts, Modellantworten, externe Inhalte, Tool-Aufrufe und Agentenaktionen werden in Echtzeit mit den Unternehmensrichtlinien abgeglichen, sodass sich unsicheres oder unbefugtes Verhalten vor der Ausführung blockieren lässt. Während Berechtigungen festlegen, was ein KI-Agent grundsätzlich tun darf, hilft Runtime-Enforcement zu entscheiden, ob er es gerade tun sollte.

Zero-Trust für KI-Agenten weiterdenken

Die Prinzipien von Zero-Trust ändern sich nicht, wohl aber ihre Anwendung. Vertrauen in KI-Agenten muss dynamisch bleiben: Neben der Identität entscheiden auch der Kontext, die Daten, das genutzte Tool, die angeforderte Aktion und das Verhalten des Agenten, ob ihm in dieser konkreten Situation vertraut werden sollte. Es mag beispielsweise völlig normal sein, dass ein HR-Agent zehn Mitarbeiterdatensätze einsieht. Wenn derselbe Agent plötzlich 20.000 Datensätze anfordert, sollte dies genauer unter die Lupe genommen werden. Dasselbe Prinzip gilt für Aktionen, die über die eigentliche Aufgabe eines Agenten hinausgehen: So kann erwartet werden, dass ein Entwicklungsagent Code schreibt. Demselben Agenten sollte hingegen beim Versuch, IAM-Richtlinien zu ändern, nicht automatisch vertraut werden, nur weil er sich erfolgreich authentifiziert hat.

Verantwortlichkeit für KI-Agenten klären

Agenten können Aufgaben autonom ausführen, jedoch keine Verantwortung übernehmen. Jeder Agent im Produktivbetrieb sollte daher einen eindeutig benannten menschlichen Verantwortlichen erhalten. Bei Agenten mit höherem Risiko ist sowohl ein geschäftlicher als auch ein technischer Verantwortlicher sinnvoll. Der geschäftliche Verantwortliche definiert den Zweck des Agenten und legt fest, welche Befugnisse er haben soll. Der technische Verantwortliche kümmert sich darum, wie der Agent konfiguriert, angebunden, authentifiziert, überwacht und abgesichert wird. Ein Agent ohne identifizierbaren Verantwortlichen sollte ähnlich wie ein verwaistes privilegiertes Konto behandelt werden.

Lifecycle-Governance

Ein KI-Agent sollte von seiner Erstellung bis zu seiner Außerbetriebnahme kontrolliert und regelmäßig überprüft werden. Vieles davon kennen wir bereits aus der Identitäts-Governance. Für Agenten gilt dieselbe Abfolge: Erfassung → Registrierung → Benennung eines Verantwortlichen → Authentifizierung → Autorisierung → Überwachung → Überprüfung → Sperrung → Außerbetriebnahme. Bei Erstellung eines KI-Agenten wird ein Verantwortlicher festgelegt. Erhält der Agent Zugriff, gilt das Least-Privilege-Prinzip. Ändert sich sein Zweck, werden seine Berechtigungen überprüft und angepasst. Ändert sich sein Verhalten, wird das Vertrauen in den Agenten neu bewertet. Wird der Agent außer Betrieb genommen, werden seine Anmeldedaten, Tokens, API-Berechtigungen und der Zugriff auf Tools widerrufen. Aus dem harmlosen Proof of Concept von heute sollte nicht die vergessene privilegierte Identität von morgen werden.

Zehn Fragen, die CISOs ihren Teams stellen sollten 

Am Anfang stehen Fragen, auf die es konkrete Antworten geben sollte:

1. Wie viele Agenten sind in unserer Umgebung im Einsatz?
2. Wer ist für welchen Agenten verantwortlich?
3. Welche Agenten haben Zugriff auf sensible oder privilegierte Systeme?
4. Welche Tools und MCP-Server können sie aufrufen?
5. Welche Operationen können sie ausführen?
6. Welche Aktionen sind ausdrücklich verboten?
7. Können wir auffälliges Verhalten von Agenten erkennen?
8. Können wir eine gefährliche Aktion vor der Ausführung stoppen?
9. Können wir einen Agenten sofort deaktivieren?
10. Können wir im Nachhinein rekonstruieren, was passiert ist?

Fazit

KI-Agenten sollten nicht nur als ein weiteres Problem der Application-Security betrachtet werden – mit ihnen entsteht eine neue Klasse nichtmenschlicher Identitäten mit Entscheidungsbefugnis. Seit Jahrzehnten basiert die Cybersicherheit auf dem Least-Privilege-Prinzip, d. h. eine Identität erhält nur den Zugriff, der zur Erfüllung ihrer Aufgabe erforderlich ist. Agentische KI könnte von Sicherheitsverantwortlichen verlangen, noch einen Schritt weiterzugehen – hin zu „Least Agency“: Einem KI-Agenten wird nur die Autonomie gewährt, die zur Erfüllung seines autorisierten Geschäftszwecks erforderlich ist – und nicht mehr.

Einige Aktionen können erlaubt sein, andere sollten zusätzlichen Kontext oder eine menschliche Genehmigung erfordern. Und manche Aktionen sollten schlicht verboten sein. So lassen sich die Vorteile autonomer KI nutzen, ohne ihr unbegrenzte Befugnisse zu übertragen. Das Ziel ist nicht, die Einführung von KI zu verlangsamen. Es geht darum, dass sich die Sicherheit im gleichen Tempo weiterentwickelt.

Je stärker Agenten Teil der digitalen Belegschaft werden, desto dringender müssen CISOs, CIOs und Vorstände eine einfache Frage beantworten können: Lässt sich jeder KI-Agent zuverlässig identifizieren, steuern, überwachen und kontrollieren, bevor er zum nächsten privilegierten Insider wird? Lautet die Antwort heute „noch nicht“, sollte genau dort die KI-Sicherheitsstrategie ansetzen.

Von Thomas Boele, Global Director, Solutions Engineering – AI Security bei Check Point Software