AI-Agenten-Sicherheit

Was AI-Agenten zu einem anderen Sicherheitsproblem macht

Eine traditionelle Anwendung hat eine definierte Menge an Operationen, die sie ausführen kann. Ein AI-Agent verfügt über eine Schlussfolgerungs-Engine, die dynamisch bestimmen kann, was zu tun ist und wie — unter Nutzung aller Tools, auf die ihm Zugriff gewährt wurde. Das schafft ein Sicherheitsproblem, das in traditioneller Software keine direkte Entsprechung hat.

Autonome Entscheidungsfindung: Der Agent bestimmt seine eigene Aktionssequenz, um ein Ziel zu erreichen. Ein Entwickler kann das Ziel vorgeben und die Tools bereitstellen, aber der Agent entscheidet, welches Tool er mit welchen Parametern und in welcher Reihenfolge aufruft. Unerwartete oder feindselig beeinflusste Entscheidungen können erhebliche unbeabsichtigte Konsequenzen erzeugen.

Breiter Tool-Zugriff: Produktive Agenten erhalten zunehmend Zugriff auf E-Mail, Dateisysteme, Datenbanken, APIs, Webbrowser und Code-Ausführungsumgebungen. Jedes Tool ist eine potenzielle Wirkungsfläche. Ein Agent mit Schreibzugriff auf eine Datenbank und Sendezugriff auf E-Mail kann erheblichen Schaden anrichten, wenn sein Verhalten kompromittiert wird.

Persistenter Zustand: Anders als ein Chatbot, der eine Nachricht verarbeitet und eine Antwort erzeugt, halten Agenten einen Zustand über Schritte und über Sitzungen hinweg aufrecht. Früh in einem Agenten-Lauf vorgenommene Aktionen können Konsequenzen haben, die lange nach Abschluss des Laufs bestehen bleiben. Irreversible Aktionen — das Senden von E-Mails, das Festschreiben von Transaktionen, das Löschen von Datensätzen — lassen sich nicht rückgängig machen.

Indirekte Steuerungsfläche: Agenten werden nicht nur durch ihren System-Prompt beeinflusst, sondern durch alle Inhalte, die sie verarbeiten — Dokumente, die sie abrufen, Webseiten, die sie durchsuchen, E-Mails, die sie lesen. Das schafft eine große indirekte Angriffsfläche, insbesondere durch Prompt Injection.

Das Bedrohungsmodell für AI-Agenten

Die Sicherheitsanalyse von AI-Agenten identifiziert typischerweise vier Kategorien von Bedrohungen:

1. Prompt Injection und indirekte Manipulation

Ein Angreifer bettet bösartige Anweisungen in Inhalte ein, die der Agent verarbeiten wird — ein Dokument, das der Agent zusammenfassen soll, eine Webseite, die er durchsucht, eine E-Mail, die er liest. Die eingeschleusten Anweisungen lenken das Verhalten des Agenten um und können Datenexfiltration, nicht autorisierte Aktionen oder Privilegien-Eskalation verursachen. Da Agenten große Mengen an Inhalten aus unterschiedlichen Quellen verarbeiten, ist indirekte Prompt Injection der primäre externe Angriffsvektor.

2. Privilegien-Eskalation und Scope Creep

Ein Agent, dem Zugriff auf ein System gewährt wurde, kann seinen Zugriff möglicherweise durch die Aktionen erweitern, die er vornimmt — indem er Anmeldedaten entdeckt, Links zu verbundenen Systemen folgt oder Tokens und Schlüssel verwendet, die ihm in den verarbeiteten Daten begegnen. Ohne strikte Durchsetzung des Umfangs auf der Infrastrukturschicht kann der effektive Zugriff eines Agenten deutlich breiter sein als sein beabsichtigter Zugriff.

3. Datenexfiltration

Ein Agent mit Zugriff auf sensible Daten und einem ausgehenden Kommunikationskanal — E-Mail-API, Webhook, HTTP-Aufruf — kann angewiesen werden, Daten zu exfiltrieren. Dies kann durch erfolgreiche Prompt Injection, durch falsch konfigurierte Tool-Berechtigungen oder durch eine kompromittierte Agenten-Lieferkette geschehen (ein kompromittiertes Modell, ein bösartiges Tool oder eine manipulierte Prompt-Vorlage).

4. Ausführung irreversibler Aktionen

Agenten, die reale Aktionen vornehmen — Transaktionen einreichen, Mitteilungen senden, Datensätze ändern, Code bereitstellen — erzeugen Risiko durch Irreversibilität. Anders als ein Mensch, der erkennen kann, wenn eine Aktion außerhalb seiner Befugnis liegt, und innehalten kann, fährt ein Agent im Allgemeinen fort, wenn er die technische Fähigkeit dazu hat. Das Fehlen menschlicher Freigabe-Gates für wirkungsstarke Aktionen ist eine der häufigsten Lücken in der AI-Agenten-Sicherheit bei produktiven Bereitstellungen.

Kernkontrollen der AI-Agenten-Sicherheit

Tool-Zugriff nach Least-Privilege

Jedem Agenten sollte der minimale Tool-Zugriff gewährt werden, der zur Erfüllung seiner Aufgabe notwendig ist. Ein Agent, der E-Mails lesen muss, sollte keine Sendeberechtigungen haben. Ein Agent, der eine Datenbank abfragen muss, sollte keine Schreibberechtigungen haben. Einzuschränken, was ein Agent auf der Infrastrukturschicht tun kann, ist die dauerhafteste Sicherheitskontrolle — sie begrenzt den Wirkungsradius jedes Fehlers, jeder Injection oder jeder Fehlkonfiguration, unabhängig von der Ursache.

Dies ist das AI-Äquivalent des Least-Privilege-Prinzips in der traditionellen Zugriffskontrolle, angewandt auf Agenten-Fähigkeiten statt auf Nutzerberechtigungen.

Laufzeit-Durchsetzung von Richtlinien

Eine Schicht zur Durchsetzung von Richtlinien sitzt zwischen dem Agenten und den Tools, die er aufruft, und bewertet jede vorgeschlagene Aktion vor der Ausführung anhand einer definierten Richtlinie. Die Richtlinie kann Folgendes festlegen:

• Welche Tools der Agent aufrufen darf
• Welche Parameterwerte innerhalb der Grenzen liegen (z. B. welche Endpunkte der Agent aufrufen darf, welche Datenkategorien an externe Dienste übermittelt werden dürfen)
• Welche Aktionen eine menschliche Freigabe erfordern, bevor fortgefahren wird
• Welche Datenklassifizierungen die Systeme der Organisation verlassen dürfen

Die Laufzeit-Durchsetzung von Richtlinien arbeitet auf der Infrastrukturschicht — sie hängt nicht vom Prompt des Agenten oder seiner selbst berichteten Absicht ab. Das macht sie auch dann wirksam, wenn das Verhalten des Agenten durch Prompt Injection oder andere feindselige Manipulation beeinflusst wird.

Menschliche Freigabe-Gates

Für hochriskante Aktionen — Aktionen, die irreversibel sind, einen erheblichen Umfang haben oder sensible Daten betreffen — sollte eine ausdrückliche menschliche Freigabe erforderlich sein, bevor der Agent fortfährt. Häufige Kategorien für Freigabe-Gates umfassen:

• Externe Kommunikation (Senden von E-Mails, Posten an externe APIs)
• Datenänderung (Schreiben in Datenbanken, Ändern von Dateien)
• Finanzaktionen (Initiieren von Überweisungen, Festschreiben von Transaktionen)
• Privilegien-eskalierende Aktionen (Erstellen von Konten, Ändern von Berechtigungen)

Human-in-the-Loop-(HITL-)Freigabe beseitigt nicht den Wert autonomer Agenten — sie richtet Freigabeanforderungen gezielt auf Aktionen aus, bei denen menschliches Urteilsvermögen das Risiko spürbar reduziert.

Manipulationssichere Audit-Protokollierung

Jede Agenten-Aktion sollte auf der Infrastrukturschicht protokolliert werden mit: der angeforderten Aktion, dem aufgerufenen Tool, den übermittelten Parametern, der angewandten Richtlinienentscheidung und dem Ergebnis. Protokolle sollten manipulationssicher sein und für den gesamten Aufbewahrungszeitraum vorgehalten werden.

Die Protokollierung auf der Infrastrukturschicht ist wichtig, weil die Protokollierung auf der Agentenschicht (ein Protokoll, das der Agent selbst erzeugt) durch dieselben feindseligen Eingaben manipuliert werden kann, die das Verhalten des Agenten beeinflussen. Ein unabhängiges Protokoll, das der Agent nicht kontrolliert, ist eine verlässlichere Grundlage für die Untersuchung von Vorfällen und für Compliance-Nachweise.

Agenten-Identität und Isolation

Jede Agenten-Instanz sollte mit einer eng gefassten, prüfbaren Identität arbeiten — nicht mit geteilten Anmeldedaten oder ambientem Zugriff, der vom bereitstellenden Nutzer geerbt wurde. Agenten-Identität ermöglicht: die Zuordnung von Aktionen zu bestimmten Agenten-Instanzen; Zugriffskontrolle auf Basis der Agentenrolle statt des bereitstellenden Nutzers; und den Entzug des Zugriffs eines bestimmten Agenten, ohne andere Systeme zu beeinträchtigen.

In Multi-Agenten-Architekturen sollte die Agent-zu-Agent-Kommunikation authentifiziert und autorisiert sein — ein orchestrierender Agent sollte einen Subagenten nicht anweisen können, Aktionen über die definierte Autorisierung des Subagenten hinaus auszuführen.

AI-Agenten-Sicherheit vs. LLM-Sicherheit

LLM-Sicherheit und AI-Agenten-Sicherheit adressieren überlappende, aber unterschiedliche Belange. Eine Organisation, die einen AI-Agenten in Produktion einsetzt, benötigt beides: Kontrollen auf Modellebene zur Abwehr von Prompt-Angriffen und Kontrollen auf Agentenebene, um zu regeln, was der Agent mit dem ihm gewährten Zugriff tut.

Wo AI-Agenten-Sicherheit im Stack angesiedelt ist

Ein vollständiger AI-Agenten-Sicherheits-Stack umfasst drei Schichten:

1. Eingabekontrollen — Welche Inhalte den Agenten erreichen und wie sie vor der Verarbeitung validiert werden. Umfasst die Erkennung von Prompt Injection, Inhaltsklassifizierung und Quellenverifizierung.

2. Laufzeitkontrollen — Was der Agent während der Ausführung tun kann. Umfasst Tool-Zugriff nach Least-Privilege, Durchsetzung von Richtlinien bei jedem Tool-Call und menschliche Freigabe-Gates für hochriskante Aktionen.

3. Ausgabe- und Audit-Kontrollen — Was die Aktionen des Agenten erzeugen und wie sie aufgezeichnet werden. Umfasst manipulationssichere Protokollierung, Ausgabeüberwachung und Anomalieerkennung.

Die meisten produktiven Agenten-Bereitstellungen verfügen über Eingabekontrollen (über die Inhaltsfilterung des Modellanbieters) und partielle Audit-Kontrollen (über Anbieterprotokolle). Die Laufzeit-Kontrollschicht — unabhängige Durchsetzung von Richtlinien auf der Aktionsebene — ist die häufigste Lücke.

Verwandt: Prompt Injection · Agentic-AI-Risiko · LLM-Sicherheit · AI-Governance