KI-Agenten absichern – jeder Werkzeugaufruf braucht eine eigene Grenze

KI-Agenten sollten nicht als ein einziger privilegierter Prozess abgesichert werden. Jeder Pfad zu Dateien, APIs, Speicher oder externen Daten braucht eine eigene, technisch erzwungene Grenze: Identität und Nutzerkontext, minimale Rechte, eine passende Freigabeschwelle, ein verwertbares Protokoll und einen Negativtest.

Das Modell darf eine Aktion vorschlagen, sollte sie aber nicht selbst autorisieren. Unmittelbar vor der Ausführung muss eine deterministische Kontrollschicht Werkzeug, Operation, Parameter, Nutzerkontext und Zielressource prüfen. Eine Sandbox begrenzt zwar die Laufzeitumgebung, ersetzt diese Kontrolle einzelner Fähigkeiten jedoch nicht.

1. Daten- und Aktionspfade vollständig erfassen

Beginnen Sie nicht mit einer pauschalen Rolle wie „Der Agent darf das CRM verwenden“. Zerlegen Sie den Zugriff in konkrete Pfade: Datei lesen oder schreiben, Datensatz suchen oder ändern, Nachricht entwerfen oder versenden, URL abrufen, Code ausführen und Inhalt dauerhaft speichern. Zwei Funktionen desselben Connectors können völlig unterschiedliche Folgen haben und benötigen deshalb getrennte Regeln.

Halten Sie für jeden Pfad Quelle, Ziel, Datenklasse und mögliche Wirkung fest. Das Bedrohungsmodell muss mehr als bösartige Nutzereingaben abdecken: NISTs Beschreibung agentenspezifischer Risiken nennt indirekte Prompt Injection, durch Datenvergiftung beeinträchtigte Modelle und fehlgeleitete Ziele; außerdem behandelt sie die Begrenzung und Überwachung des Agentenzugriffs in der Ausführungsumgebung.

• Lesepfad: Welche Mandanten, Verzeichnisse, Tabellen, Felder oder Endpunkte sind erreichbar?
• Schreibpfad: Welche Objekte dürfen angelegt oder verändert werden, und ist die Änderung rückgängig zu machen?
• Externer Pfad: Können E-Mails, Webseiten, Tickets oder Dokumente spätere Aktionen beeinflussen?
• Persistenzpfad: Welche Inhalte gelangen in Langzeitspeicher, Retrieval-Index oder gemeinsame Sitzungen?

2. Werkzeuge auf Identität und Minimalrechte zuschneiden

Ein Agent sollte weder das persönliche Konto eines Entwicklers noch eine gemeinsame, weitreichend privilegierte Dienstidentität erben. Bevorzugen Sie kurzlebige Anmeldedaten, die auf Aufgabe, Nutzer, Mandant und Umgebung begrenzt sind. Ein Werkzeug zum Lesen von Rechnungsdaten benötigt keinen Schreibzugriff; eine Funktion für E-Mail-Entwürfe braucht keine Versandberechtigung.

Begrenzen Sie auch die Funktion selbst. Ein frei formulierbarer Shell-Befehl oder eine universelle Datenbankabfrage eröffnet mehr Handlungsspielraum als eine klar benannte Lese- oder Schreiboperation. Die OWASP-Empfehlungen zu Excessive Agency führen übermäßige Funktionalität, Berechtigungen und Autonomie als Ursachen an; empfohlen werden granulare Werkzeuge, minimale Rechte in nachgelagerten Systemen, Ausführung im Kontext des Nutzers und eine vollständige Autorisierungsprüfung.

Setzen Sie diese Prüfung im Werkzeug-Gateway oder im Zielsystem durch, nicht allein im Prompt. Die Entscheidung sollte mindestens Werkzeugname, Operation, normalisierte Parameter, handelnde Identität, Zielressource und Datenklasse berücksichtigen. Verweigert die Richtlinie den Aufruf, darf die Formulierung der Modellantwort daran nichts ändern.

3. Externe Inhalte von Aktionen und Speicher trennen

Webseiten, E-Mails, hochgeladene Dateien, API-Antworten und Retrieval-Treffer sind nicht vertrauenswürdige Daten, keine neuen Systemanweisungen. Kennzeichnen Sie Herkunft und Vertrauensstufe, begrenzen Sie Umfang und Datentypen und übergeben Sie möglichst nur validierte, strukturierte Felder an den planenden Agenten. Inhaltsfilter können verdächtige Muster erkennen, ersetzen aber keine Autorisierung.

Besonders kritisch ist der Übergang vom gelesenen Inhalt zur Aktion. Eine E-Mail darf beispielsweise die gewünschte Zusammenfassung beeinflussen, aber nicht eigenständig Empfänger, Anhang oder Versandfreigabe bestimmen. Prüfen Sie den vorgeschlagenen Aufruf deshalb erneut gegen den ursprünglichen Nutzerauftrag und lassen Sie nur Parameter passieren, die für diesen Auftrag erforderlich und zulässig sind.

Für den Speicher gilt eine weitere Grenze: Persistieren Sie Inhalte erst nach Validierung, Datenklassifizierung und Mandantenzuordnung. Speichereinträge benötigen Herkunft, Ablaufregel und zulässigen Verwendungszweck; Geheimnisse und unnötige personenbezogene Daten werden redigiert oder nicht gespeichert. Inhalte einer Sitzung dürfen nicht unbemerkt den Kontext anderer Nutzer verändern.

4. Freigaben an Wirkung und Parameter binden

Nicht jeder Aufruf benötigt einen Bestätigungsdialog. Lesende Zugriffe innerhalb eines engen Bereichs können automatisch ablaufen, während irreversible, finanzielle, administrative oder extern sichtbare Aktionen eine ausdrückliche Freigabe verlangen. Maßgeblich ist die Wirkung: Ein Entwurf ist anders zu behandeln als sein Versand, eine Vorschau anders als eine Löschung.

Die Freigabe muss die tatsächlich auszuführende Aktion verständlich anzeigen und technisch an deren normalisierte Parameter gebunden sein. Ändern sich danach Empfänger, Betrag, Zielsystem, Dateipfad oder Datenumfang, muss die Freigabe verfallen. Eine begrenzte Gültigkeitsdauer, eine eindeutige Aufruf-ID und Wiederholungsschutz verhindern, dass eine alte Zustimmung für einen veränderten oder wiederholten Aufruf verwendet wird.

Ergänzen Sie harte Betriebsgrenzen für Kettentiefe, Wiederholungen, Laufzeit, Kosten und externe Aufrufe. Ein Abbruchmechanismus muss die weitere Ausführung stoppen und kurzlebige Berechtigungen entziehen können. Diese Kontrollen begrenzen unbeabsichtigte Schleifen ebenso wie die Reichweite eines manipulierten Plans.

5. Die Kontrollmatrix als ausführbare Spezifikation

Die Matrix sollte pro Zeile genau einen Daten- oder Aktionspfad beschreiben. So wird aus einer allgemeinen Risikoliste eine Spezifikation, die Architektur, Richtlinien und Tests miteinander verbindet:

1. Identität: Welcher Nutzer oder Dienst handelt für welchen Mandanten und in welcher Umgebung?
2. Minimale Berechtigung: Welche Operation ist auf welchen Ressourcen und Datenfeldern erlaubt?
3. Bestätigungsschwelle: Läuft die Aktion automatisch, nach einer Vorschau oder erst nach parametergebundener Freigabe?
4. Protokollierung: Welche Entscheidung, Richtlinienversion, Parameterklassen und Ergebnisse werden ohne Geheimnisse erfasst?
5. Negativtest: Welcher verbotene Aufruf muss scheitern, und welches Signal belegt den korrekten Abbruch?

Ein ausdrücklich bedingtes Beispiel: Beim Werkzeug „Kundenakte lesen“ könnte ein kurzlebiges Token im Kontext des angemeldeten Nutzers als Identität dienen. Erlaubt wären nur dessen Mandant und die erforderlichen Felder; der Zugriff auf einen fremden Mandanten müsste am tatsächlichen Ausführungspunkt abgewiesen werden. Für „Kundenakte löschen“ wären eine separate Funktion, eine stärkere Rechteprüfung und eine parametergebundene Bestätigung nötig.

6. Protokolle und Negativtests zum Release-Gate machen

Protokollieren Sie nicht pauschal vollständige Prompts oder ungefilterte Werkzeugausgaben. Für die Nachvollziehbarkeit eignen sich Zeit, Agenten- und Richtlinienversion, pseudonymisierte Nutzer- und Sitzungskennung, Werkzeug, Parameterklassen, Freigabestatus, Autorisierungsentscheidung, Laufzeit und Ergebnis. Zugangsdaten, personenbezogene Inhalte und vollständige Dokumente gehören nicht ungeschützt in das Protokoll.

Das AI Agent Security Cheat Sheet von OWASP empfiehlt strukturierte Sicherheitstests vor dem Produktivbetrieb und nach wesentlichen Änderungen an Prompts, Werkzeugen, Speicher, Retrieval, Richtlinien oder Modellanbietern. Die dort beschriebene Testmatrix umfasst unter anderem Werkzeugmissbrauch, Rechteausweitung, Speichervergiftung, Datenabfluss, Umgehung von Freigaben und rekursive Werkzeugketten.

Leiten Sie für jede Matrixzeile mindestens einen erlaubten und einen verbotenen Test ab. Variieren Sie Mandant, Ressource, Datenklasse, Parameter und Herkunft externer Inhalte; testen Sie außerdem abgelaufene und nachträglich veränderte Freigaben. Eine Änderung passiert das Release-Gate erst, wenn erlaubte Aktionen weiterhin funktionieren und die vorgesehenen Negativtests am tatsächlichen Ausführungspunkt scheitern.

Lesen Sie auch:

• KI-Agenten sicher ausführen: Die Sandbox allein reicht nicht
• Eine SBOM erstellen: Die Stückliste hilft erst mit einem Arbeitsablauf
• Claude kostenlos nutzen: Das Fünf-Stunden-Limit ist nicht die einzige Grenze