Sicherheit von KI-Agenten: Grenzen, Human-Gate und Logs

Der Unterschied zwischen einem Chatbot und einem Agenten ist die Handlungsfähigkeit: Ein Agent endet nicht bei einer Antwort, sondern bei einer Zustandsänderung – einer gesendeten E-Mail, einem aktualisierten Datensatz, einem bearbeiteten Lead. Das ist ein enormer Wert, aber auch eine Verantwortung. Handlungsfähigkeit ohne Grenzen ist ein Risiko, daher entwerfen wir die Grenzen gemeinsam mit der Handlungsfähigkeit.

Drei Säulen der Agentensicherheit#

• Allow-Liste der Tools – Der Agent hat einen Katalog zugelassener Tools (z. B. Navigation, Suche, Reservierung), keinen beliebigen Systemzugriff. Was nicht auf der Liste steht, führt er nicht aus.
• Human-Gate – Irreversible Aktionen (Versand, Zahlung, Datenänderung) erfordern einen serverseitigen Bestätigungstoken, signiert mit HMAC. Die bloße Entscheidung des Modells reicht nicht – es braucht ein „Ja“ des Menschen, wo es kein Zurück gibt.
• Vollständiges Log – Jeder Schritt (Gedanke → Tool → Ergebnis) wird protokolliert, sodass sich im Nachhinein nachvollziehen lässt, was und warum der Agent getan hat. Ohne Spur keine Verantwortung.

Wie die Allow-Liste in der Praxis funktioniert#

Den Tool-Umfang beschreiben wir ausdrücklich und unterscheiden dabei zwischen reinen Lese-Operationen und Operationen, die den Zustand verändern (diese laufen über das Human-Gate). Eine Beispielliste für einen Kundenservice-Agenten:

• navigation – nur Lesen (Bewegen auf der Seite, ohne Schreibzugriff),
• angebotssuche – nur Lesen (Prüfung von Verfügbarkeit und Preisen),
• termin-buchen – Schreiben mit Gate (schlägt vor, führt nach Bestätigung aus),
• mail-senden – Schreiben mit Gate (Inhalt zur Freigabe durch den Menschen).

Was nicht auf der Liste steht: Zugriff auf die Datenbank mit Daten anderer Kunden, Löschen von Datensätzen, Zahlungsrückerstattungen, Datenexport. Ein fehlender Eintrag ist eine harte Ablehnung auf Serverseite, keine Empfehlung im Prompt – das Modell mag ein Tool außerhalb der Liste „aufrufen wollen“, aber die Ausführungsschicht weist es ab.

Human-Gate Schritt für Schritt#

Das Bestätigungs-Gate ist ein serverseitiger Mechanismus, kein Versprechen des Modells. Der Ablauf für eine irreversible Aktion:

1. Der Agent schlägt eine Aktion vor (z. B. „sende eine Buchungsbestätigung an die Adresse des Kunden“),
2. Der Server stellt einen kurzlebigen, mit HMAC signierten Token aus, gebunden an das konkrete Tool und die Argumente (eine Änderung der Adresse oder des Inhalts macht den Token ungültig),
3. Der Mensch sieht die vorgeschlagene Aktion und bestätigt oder lehnt sie ab,
4. Der Server verifiziert den Token (Signatur, Gültigkeit, Übereinstimmung der Argumente) und führt das Tool erst dann aus,
5. Das Ergebnis landet im Log, zusammen damit, wer wann bestätigt hat.

Der Token ist kurzlebig (in der Größenordnung von Minuten, nicht Stunden) und einmalig nutzbar – das begrenzt das Zeitfenster, in dem eine abgefangene Bestätigung ausgenutzt werden könnte.

Was ein gutes Log enthält#

Ein „vollständiges Log“ wird erst nützlich, wenn sich aus einer Zeile die Entscheidung rekonstruieren lässt. Der Mindestsatz an Feldern für einen einzelnen Schritt:

• Zeitstempel und Anfrage-Kennung (request-id, um die Schritte eines Durchlaufs zu verknüpfen),
• die Argumentationsspur als Gedanke → Tool → Ergebnis,
• der Name des aufgerufenen Tools und ein Hash seiner Argumente, mit maskierten personenbezogenen Daten,
• die Human-Gate-Entscheidung (bestätigt / abgelehnt, durch wen),
• der Ergebnisstatus (Erfolg, Fehler, durch die Allow-Liste blockiert).

Personenbezogene Daten gelangen nicht im Klartext ins Log – wir protokollieren einen Hash und maskierte Werte, damit die Audit-Spur nicht selbst zur Leck-Quelle wird.

Worin unterscheidet sich das Risiko eines Agenten von dem eines Chatbots#

Deshalb werden Agenten nicht „auf gut Glück“ eingesetzt. Die Grenze zwischen Gespräch und Ausführung beschreiben wir auch im Beitrag Agent vs. Chatbot.

Schrittweise Lockerung der Aufsicht#

Wir beginnen nicht mit voller Autonomie. Der Agent startet mit einem engen Human-Gate (fast alles muss bestätigt werden), und je mehr Vertrauensbeweise vorliegen – das Log ist sauber, die Entscheidungen treffend – desto mehr lockern wir die Gates auf bewährten Pfaden. Derselbe Ansatz wie beim Prompt Injection: Sicherheit ist eingebaut, nicht nachgerüstet.

Diese drei Säulen reagieren direkt auf die Risiken, die der Katalog OWASP Top 10 für LLM-Anwendungen auf Agentenebene beschreibt: übermäßige Handlungsfähigkeit (wenn ein Agent mehr tun kann, als er sollte) und unsichere Tool-Nutzung (wenn ein Tool-Aufruf Kontrollen umgeht). Die Allow-Liste begrenzt den Umfang der Handlungsfähigkeit, das Human-Gate nimmt dem Modell die Möglichkeit, eine irreversible Aktion eigenständig auszuführen, und das Log liefert die Spur, um Missbrauch zu erkennen. Die Vertrauensgrenze lockern wir genau deshalb schrittweise, weil diese beiden Risikoklassen mit zunehmender Autonomie am schnellsten wachsen.

Live ausprobieren#

Den Agenten starten wir in einer sicheren Sandbox mit transparenter Spur (Playground: PII maskiert, keine Retention). Bitte das Modell, die Schritte einer Aufgabe zu skizzieren:

FAQ#

Ist ein KI-Agent sicher, wenn er selbstständig handelt?#

Er ist sicher, wenn er klare Grenzen hat: eine Allow-Liste der Tools, ein Human-Gate für irreversible Aktionen und ein Log jedes Schritts. Handlungsfähigkeit ohne diese Barrieren ist ein Risiko, daher entwerfen wir sie von Anfang an. Der Agent handelt autonom in einem engen, klar definierten Rahmen – nicht „einfach so“.

Was ist ein Human-Gate?#

Ein Punkt, an dem eine irreversible Aktion (Versand, Zahlung, Datenänderung) eine menschliche Bestätigung erfordert – technisch ein serverseitiger Token, signiert mit HMAC, nicht nur die Modellentscheidung. Selbst wenn der Agent „meint“, etwas tun zu müssen, passiert es nicht ohne grünes Licht.

Wo fängt man mit Agenten an?#

Bei einem engen, wiederholbaren Prozess mit strenger Aufsicht – fast alles muss bestätigt werden, das Log ist vollständig. Wenn die Vertrauensbeweise wachsen, lockert man die Gates auf bewährten Pfaden. So gibt man KI schrittweise Handlungsfähigkeit – sicher.

Wie testet man die Allow-Liste vor dem Einsatz?#

Mit einem Negativtest: Bevor der Agent in die Produktion geht, prüfen wir, dass der Aufruf eines Tools außerhalb der Liste mit einer serverseitigen Ablehnung endet und nicht mit einem Ausführungsversuch. Sinnvoll ist auch ein kurzes Red-Team – das Modell gezielt (auch über Inhalte in den Eingabedaten) dazu bringen, nach einem verbotenen Tool zu greifen, und bestätigen, dass die Ausführungsschicht es blockiert und die Blockade im Log landet. Der Test besteht, wenn jedes nicht erlaubte Tool abgewiesen wird und die erlaubten innerhalb ihres Umfangs funktionieren.

Worin unterscheidet sich ein Human-Gate von einer gewöhnlichen Bestätigung in der Oberfläche?#

Eine gewöhnliche Bestätigung in der UI ist ein clientseitiges Signal – sie lässt sich umgehen, und das Modell kann die Aktion trotzdem versuchen. Ein Human-Gate wird auf dem Server durchgesetzt: Eine irreversible Aktion wird nicht ohne einen gültigen, kurzlebigen, mit HMAC signierten und an das konkrete Tool sowie die Argumente gebundenen Token ausgeführt. Der Unterschied ist praktisch – bei einer gewöhnlichen Bestätigung beruht das Vertrauen auf einer Erklärung, beim Human-Gate auf einem verifizierbaren Token, den das Modell selbst nicht fälschen kann.