Agent-Schutzmechanismen gemapped auf das NIST AI RMF

Warum ich AgentGuard entwickelt habe

Ich habe AgentGuard entwickelt, nachdem ich gesehen hatte, wie ein Team einen LLM-aktivierte Agenten ausgeliefert hat, der eine Datenbank lesen, eine Zahlungs-API aufrufen und eine E-Mail senden konnte, alles mit einem einzigen Prompt. Der Agent funktionierte im Demo, aber ein einfacher Tippfehler in der Benutzerabfrage verursachte, dass er Geld auf das falsche Konto überwies. Niemand hatte überprüft, was der Agent durfte, bevor der Anruf erfolgte, und es gab keine Möglichkeit, ihn aufzuhalten, nachdem der Fehler passiert war.

Ich erkannte, dass das Problem nicht das Modell selbst war, sondern die fehlenden Grenzen um seine Aktionen. Ich wollte eine wiederholbare Möglichkeit haben, jede Werkzeug aufzulisten, das ein Agent erreichen kann, zu entscheiden, wer jedes Werkzeug aktivieren darf, den Agent gegen die Berechtigungen zu testen, die wir glauben, dass er hat, und zu reagieren, wenn etwas schief geht. Der NIST AI Risk Management Framework gab mir die vier Funktionen, die genau mit diesen Schritten übereinstimmen.

Kernkonzepte: Eingabefilter, Werkzeugberechtigungen, Ausgabekontrollen

Eingabefilter

Dies sind Prüfungen, die auf dem Benutzereingabe oder der internen Argumentation des Agents vor der Aufruf eines Werkzeugs ausgeführt werden. Beispiele umfassen:

- Erkennung von Eingabemustern, die versuchen, vorherige Anweisungen zu ignorieren. - Überprüfung auf nicht zugelassene Schlüsselwörter oder Phrasen, die einen Zugriff auf ein restricted System signalisieren. - Validierung, dass die Eingabe ein erforderliches Genehmigungstoken enthält, wenn ein Werkzeug mit hohem Risiko referenziert wird.

Wir implementieren Eingabefilter als leichte Regex-Engines in Kombination mit einer kleinen Liste sicherer Muster. Sie addieren weniger als zwei Millisekunden Latenz pro Aufruf.

Werkzeugberechtigungen

Werkzeugberechtigungen definieren, welche Daten ein Werkzeug lesen, schreiben oder löschen kann und welche externen Dienste es kontaktieren darf. Wir speichern jede Berechtigung als Tupel:

- Werkzeugkennung - Zugelassene Datenquellen (z.B. lesender Zugriff auf Kunden-Tabelle, Schreibzugriff auf Audit-Log) - Netzwerkziele (z.B. api.paymentprovider.com auf Port 443) - Erforderliches Genehmigungsniveau (keines, Peer-Review, Manager-Unterschrift)

Wenn der Agent die Verwendung eines Werkzeugs anfordert, prüft der Berechtigungsdienst das Tupel gegen den aktuellen Kontext und erlaubt den Aufruf, modifiziert die Parameter oder blockiert ihn.

Ausgabekontrollen

Nachdem ein Werkzeug ein Ergebnis zurückgegeben hat, überprüfen Ausgabekontrollen, ob die Antwort innerhalb der erwarteten Grenzen bleibt. Beispiele:

- Sicherstellung, dass eine SQL-Abfrage nicht mehr als 100 Zeilen zurückgibt. - Bestätigung, dass eine E-Mail-Nutzlast keine externen URLs enthält. - Scannen auf geleakte Geheimnisse wie API-Schlüssel oder Passwörter in der Antwort.

Wenn eine Prüfung fehlschlägt, kann das System das Ergebnis kürzen, sensible Teile schwärzen oder eine Warnung auslösen.

Zuordnung von Sicherheitsvorkehrungen zu NIST-AI-RMF-Funktionen

Das Frameworks vier Funktionen bieten eine klare Struktur für die Organisation von Sicherheitsvorkehrungen. Im Folgenden ist eine Tabelle aufgeführt, die zeigt, welche Sicherheitsvorkehrung zu jeder Funktion gehört, das konkrete Artefakt, das wir produzieren, und ein kurzes Beispiel.

NIST-Funktion | Sicherheitsvorkehrungstyp | Artefakt | Beispiel Govern | Genehmigungsworkflow | Tool-Aktivierungsprotokoll | Ein unterzeichnetes Dokument, das auflistet, wer das send_email-Tool genehmigt hat, das Datum und die erforderliche Zwei-Faktor-Authentifizierung für den Genehmiger. Map | Tool-Inventar | Berechtigungsmatrix | Ein Spreadsheet, das jedes Tool auflistet, die Tabellen, die es lesen/schreiben kann, und die externen Endpunkte, die es aufrufen darf. Measure | Test-Suite | Adversarial-Prompt-Satz | Eine Sammlung von Prompts, die darauf ausgelegt sind, Privilegien-Eskalation, Daten-Exfiltration oder nicht autorisierte externe Anrufe auszulösen. Manage | Laufzeitreaktion | Kill-Switch-Protokoll | Ein timestampeter Eintrag, der aufzeichnet, wann der Agent versucht hat, einen Produktionsdatensatz zu löschen, die Aktion, die blockiert wurde, und den Operator, der benachrichtigt wurde.

Jede Funktion baut auf der vorherigen auf. Govern entscheidet, wer ein neues Tool zum Inventar hinzufügen darf. Map erstellt das Inventar, gegen das Measure testet. Measure produziert Beweise, auf die Manage reagieren kann. Der Kreislauf wiederholt sich, sobald sich die Tool-Liste oder der Prompt des Agents ändert.

Wie wir einen Werkzeugaufruf bewerten

Schritt 1: Identifizieren des Werkzeugs und seiner Berechtigungsklasse

Wir beginnen damit, das Werkzeug in der Berechtigungsmatrix nachzuschlagen. Die Matrix weist einen Basis-Risikolevel zu:

- Nur-Lese-Zugriff (z. B. Abrufen eines Produktkatalogs) → niedrig - Schreiben in ein internes Log → mittel - Externe Aktion mit Nebeneffekten (z. B. Geld senden, einen Datensatz löschen) → hoch

Wenn das Werkzeug ein Genehmigungstoken erfordert, addieren wir einen Level zum Basis-Risiko.

Schritt 2: Analyse des Prompts auf Injektionsrisiko

Wir führen das Benutzerprompt durch den Input-Filter-Motor aus. Wenn der Motor ein Muster aus der OWASP-Prompt-Injektions-Cheat-Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) erkennt, erhöhen wir das Risiko um einen Level.

Schritt 3: Überprüfen der Datensensitivität

Wir untersuchen die Datenquellen, die das Werkzeug berühren kann. Wenn eine Quelle personenbezogene Daten (PII) oder Finanzdaten enthält, addieren wir einen weiteren Level.

Schritt 4: Erzeugen der endgültigen Bewertung und empfohlener Filter

Die endgültige Bewertung ist die Summe des Basis-Levels, Prompt-Levels und Daten-Levels-Anpassungen. Basierend auf der Bewertung empfehlen wir:

- Niedrig → kein zusätzlicher Filter, nur Loggen des Aufrufs. - Mittel → Hinzufügen eines Input-Filters, der nicht zugelassene Schlüsselwörter entfernt und einer Ausgabeprüfung, die die Zeilenanzahl begrenzt. - Hoch → Erfordernis einer menschlichen Überprüfung, Durchsetzen einer strengen Zulassungsliste von Parametern und Aktivieren der vollständigen Ausgaberedaktion.

Was dies nicht ist

Ich möchte klarstellen, was die Grenzen von Guardrails sind, damit Sie sie nicht für eine Wunderlösung halten.

- Guardrails gewährleisten nicht, dass ein Agent niemals Schaden anrichten wird. Sie reduzieren den Schadensradius eines Fehlers, aber ein entschlossener Angreifer oder ein schlecht konfiguriertes Tool kann immer noch unerwünschte Effekte innerhalb der zulässigen Grenzen produzieren. - Sie ersetzen nicht sichere Codierungspraktiken. Wenn das zugrunde liegende Tool eine Schwachstelle aufweist (z. B. eine SQL-Injection-Schwachstelle, wie im SQL-Injection-Präventions-Cheat-Sheet der OWASP https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html beschrieben), kann die Guardrail diese Schwachstelle nicht beheben. - Sie bieten keine 100 %-Sicherheitszertifizierung. Denken Sie an sie als Entscheidungshilfen, die Ihnen helfen, informierte Entscheidungen über die Tool-Nutzung zu treffen. - Sie sind keine Konfiguration, die man einrichten und vergessen kann. Jedes Mal, wenn sich die Prompt des Agents, die Tool-Liste oder die Daten, auf die ein Tool zugreifen kann, ändern, müssen Sie den Überprüfungsprozess erneut durchführen.

In der Praxis umsetzen: ein schrittweiser Überprüfungsworkflow

1. Sammeln des Systemprompts und der Toolliste des Agents

Exportieren Sie den genauen Text, den der Agent bei der Startzeit erhält, und die JSON- oder YAML-Datei, die jedes Tool deklariert, das es aufrufen kann.

2. Ausfüllen der Berechtigungsmatrix

Für jedes Tool aufzeichnen:

- Erlaubte Leseziele - Erlaubte Schreibziele - Externe Endpunkte und erforderliche Authentifizierung - Jedes erforderliche Genehmigungstoken oder Rolle

3. Durchführen der Basis-Risikobewertung

Anwenden des vierstufigen Bewertungsprozesses, der zuvor beschrieben wurde. Aufzeichnen des initialen Risikolevels für jedes Tool.

4. Generieren von Eingabe- und Ausgabefiltersuggestions

Basierend auf dem Risikolevel konkrete Filterregeln (Regex-Muster, Zeilenanzahlbegrenzungen, Schwärzungsregeln) erstellen. Diese neben der Tooldefinition speichern.

5. Ausführen des adversarialen Test-Sets

Den Agent gegen das Prompt-Set aus der Messspalte der Tabelle ausführen. Überprüfen, ob die Filter die erwarteten Fehlermodi blockieren oder mildern.

6. Dokumentieren des Ergebnisses

Ein kurzes Report erstellen, das folgende Punkte auflistet:

- Toolname - Initiales Risikolevel - Angewandte Filter - Testergebnisse (Bestehen/Fehlschlagen) - Erforderliche manuelle Genehmigungsschritte

7. Einrichten von Überwachung und Alarmen

Die Laufzeitumgebung des Agents konfigurieren, um jeden Toolaufruf, die angewandten Filter und die Ausgabekontrollergebnisse zu protokollieren. Anomalien an den Incident-Response-Kanal weiterleiten.

8. Planen eines Überprüfungs-Triggers

Den Workflow markieren, um zu wiederholen, wenn einer der folgenden Punkte auftritt:

- Ein neues Tool zur Liste hinzugefügt wird - Das Systemprompt bearbeitet wird - Die Berechtigung eines Tools geändert wird (z. B. eine Datenbank erhält eine neue Spalte mit PII)

Häufige Fallstricke und wie wir sie vermeiden

Fallstrick 1: Übermäßige Abhängigkeit von einem einzigen Filtertyp

Teams denken manchmal, dass das Hinzufügen eines Keyword-Blockers ausreicht. Wir vermeiden dies, indem wir sowohl Eingabe- als auch Ausgabekontrollen für jedes Medium- oder Hochrisikotool erfordern und protokollieren, wenn eine der Kontrollen ausgelöst wird.

Fallstrick 2: Vergessen, die Berechtigungsmatrix zu aktualisieren

Wenn ein Tool eine neue Funktion erhält (z. B. unterstützt eine Zahlungs-API nun Rückerstattungen), muss die Matrix vor der Verwendung durch den Agenten bearbeitet werden. Wir erzwingen dies, indem wir die Matrix als versionierte Datei machen, die die CI-Pipeline bei jedem Push validiert.

Fallstrick 3: Ignorieren von Low-Risiko-Tools, die im Kontext zu High-Risiko-Tools werden

Eine schreibgeschützte Lookup, die die E-Mail-Adresse eines Benutzers zurückgibt, kann gefährlich werden, wenn der Agent diese Adresse später in einem Passwort-Reset-Fluss verwendet. Wir behandeln die Datenempfindlichkeit als separaten Bewertungsfaktor, sodass ein Low-Level-Tool, das PII berührt, automatisch upgegradet wird.

Fallstrick 4: Überspringen des Human-in-the-Loop-Schritts für High-Risiko-Tools

Für Tools, die Geld bewegen oder Aufzeichnungen löschen können, verlangen wir einen expliziten Genehmigungsschritt, der nicht durch Automation umgangen werden kann. Die Genehmigung wird in einem unveränderlichen Protokoll aufgezeichnet.

Fallstrick 5: Behandeln der Guardrail-Konfiguration als einmalige Aufgabe

Wir integrieren den Überprüfungsworkflow in die Definition von Done des Teams für jede Funktion, die das Verhalten des Agents ändert. Dies macht den Prozess wiederholbar, anstatt ein vergessenes Checklist-Element zu sein.

Quellen

- https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Häufig gestellte Fragen

Machen Schutzrailings einen Agenten sicher?

Nein. Sie beschränken den Radius eines Fehlers. Ein entschlossener Angreifer, ein falsch konfiguriertes Tool oder eine schlechte Aufforderung können immer noch Schaden innerhalb der von Ihnen zugelassenen Grenzen verursachen.

Was benötigen wir, um eine Überprüfung durchzuführen?

Die Systemaufforderung des Agents und dessen Toolliste. Das reicht aus, um Anrufe zu bewerten und Filter vorzuschlagen.

Ist die EU-KI-Verordnung eine Rechtsberatung?

Nein. Sie ist eine Zuordnung, um Ihnen zu helfen, die richtigen Verpflichtungen zu finden. Die Klassifizierung Ihres Systems und die Erfüllung der Verpflichtungen erfordern immer noch einen qualifizierten Prüfer.

Wie oft sollten wir es erneut ausführen?

Jedes Mal, wenn sich die Toolliste, die Systemaufforderung oder die Daten ändern, auf die ein Tool zugreifen kann.

Testet es den Agenten bei der Laufzeit?

Es überprüft die Aufforderung und die Toolkonfiguration. Laufzeitüberwachung ist eine separate Ebene, die Sie immer noch benötigen.

Was ist, wenn ein Tool ein echtes Hochrisiko darstellt?

Erfordern Sie einen Genehmigungsschritt, verengen Sie dessen Parameter und protokollieren Sie jeden Aufruf. Hochrisikotools benötigen normalerweise einen Menschen im Entscheidungsprozess anstelle eines Filters.

Quellen

- OWASP — Top 10 für Large Language Model-Anwendungen

Probieren Sie das Produkt: AgentGuard

2026-09-20 · nur primäre Quellen · keine erfundenen Traffic-Metriken · Entscheidungsunterstützung nur

Verwandte Artikel

- Allowlists für AI-Agent-Tools: Warum deny-by-default die bessere Wahl ist - Erforschen Sie die vollständige AI-Micro-SaaS-Themenmatrix →