Allowlists für AI-Agent-Tools: Warum eine Verweigerung standardmäßig der bessere Ansatz ist

Warum eine Verweigerungsstrategie per Voreinstellung besser funktioniert als der Versuch, jeden schlechten Anruf zu blockieren

Wenn Sie mit einer Verweigerungsstrategie per Voreinstellung beginnen, müssen Sie nur darüber nachdenken, was der Agent wirklich benötigt. Jeder andere Anruf wird automatisch gestoppt, ohne dass Sie jeden möglichen Missbrauch vorhersagen müssen. Dies reduziert die kognitive Belastung des Prüfers und verringert die Wahrscheinlichkeit, dass ein vergessener gefährlicher Fehler durchkommt.

Betrachten Sie einen Agenten, der Berichte erstellt. Er muss eine Vorlagendatei lesen, Daten aus einer Datenbank abrufen und das fertige PDF an ein internes Postfach senden. Wenn Sie nur diese drei Anrufe auflisten, wird jeder Versuch, einen Shell-Befehl auszuführen, eine externe API abzufragen oder eine Tabelle zu löschen, sofort abgelehnt. Sie müssen nie eine Regel schreiben, die sagt: „Blockiere rm -rf“, „Blockiere curl zu evil.com“ oder „Blockiere DROP TABLE“. Die Verweigerungsregel per Voreinstellung deckt sie alle ab.

In der Praxis habe ich gesehen, wie Teams Wochen damit verbringen, lange Blocklisten zu erstellen, die immer noch einen neuen Angriffsvector verpassen, während eine kurze Zulassungsliste von fünf Einträgen die gleichen Angriffe am ersten Tag stoppte. Der durch die Wartung eingesparte Aufwand ist real: Sie überprüfen die Zulassungsliste, wenn ein Tool geändert wird, und nicht, wenn ein neuer Bedrohungsszenario auftritt.

Wie baue ich eine Allowlist für einen neuen Agenten

Ich folge einer wiederholbaren Checkliste, die die Liste kompakt und überprüfbar hält.

- Ich schreibe die exakten Aufgaben auf, die der Agent heute ausführen muss. Ich ignoriere Ideen, die „vielleicht später nützlich“ sein könnten. - Für jede Aufgabe finde ich das einzelne Tool, das den Job mit den engsten möglichen Parametern erledigt. Wenn ein Tool eine Flag bietet, die den Umfang erweitert, aktiviere ich es nicht, es sei denn, die Aufgabe benötigt es explizit. - Ich zeichne den Toolnamen, den exakten Befehl oder API-Endpunkt und die erlaubten Parameterwerte in einer einfachen YAML-Datei auf. Diese Datei liegt neben dem Agenten-Code, damit Reviewer sie auf einen Blick sehen können. - Ich führe den Agenten in einer Sandbox aus und überprüfe, dass jeder aufgeführte Aufruf erfolgreich ist und dass jeder Aufruf, der nicht in der Datei aufgeführt ist, einen Fehler zurückgibt. - Ich bitte einen Kollegen, die Liste zu überprüfen. Die Aufgabe des Reviewers besteht darin, zu bestätigen, dass jeder Eintrag einer realen Aufgabe entspricht und dass keine zusätzliche Funktion hinter Standardwerten versteckt ist. - Ich speichere die Datei in der Versionskontrolle. Ich markiere jeden Commit mit der Agenten-Version, damit ich nachverfolgen kann, welche Allowlist mit welcher Version ausgeliefert wurde. - Ich richte einen CI-Schritt ein, der den Build fehlschlagen lässt, wenn die YAML-Datei fehlt oder wenn sie ein Tool enthält, das nicht im Tool-Register des Projekts genehmigt ist.

Dieser Prozess dauert etwa eine Stunde für einen einfachen Agenten und produziert ein Dokument, das jeder überprüfen kann.

Klassifizierung von Tools nach ihrem Änderungspotenzial

Nicht alle Tools bergen das gleiche Risiko. Ich teile die zugelassenen Tools in drei Auswirkungsklassen ein, um zu wissen, wo ich zusätzliche Kontrollen hinzufügen muss.

Auswirkungsklasse | Bedeutung | Beispieltool | Typischer Schutz Nur Lesen | Kann Daten abrufen, aber nicht den Zustand ändern | Dateilesen, Datenbank-SELECT, öffentliche API-GET | Aufruf protokollieren, keine zusätzliche Genehmigung erforderlich Schreiben oder veränderbar | Kann Daten erstellen, aktualisieren oder löschen | Dateischreiben, Datenbank-INSERT/UPDATE/LOESCHEN, interne Nachrichtenveröffentlichung | Erfordert einen zweiten Genehmiger für die erste Verwendung, Protokollierung mit Benutzer-ID Unwiderrufliche externe Auswirkung | Kann Systeme außerhalb der Vertrauensgrenze beeinflussen | E-Mail senden, auf soziale Medien posten, Zahlung initiieren, externen Webhook aufrufen | Obligatorische manuelle Genehmigung, detaillierte Audit-Trail, Timeout für den Aufruf

Wenn ich ein neues Tool überprüfe, frage ich: „Was ist das Schlimmste, was passieren könnte, wenn dieser Aufruf ausgeführt wird?“ Die Antwort sagt mir, welche Zeile der Tabelle anwendbar ist. Für Tools mit Lesezugriff füge ich nur eine Protokollzeile hinzu. Für Schreibtools füge ich einen leichten Genehmigungsworkflow hinzu. Für unwiderrufliche Auswirkungen erzwinge ich ein manuelles Tor und halte das Aufruf-Fenster kurz.

Kombination von Zulassungslisten mit Eingabe- und Ausgabefiltern

Eine Zulassungsliste entfernt unnötige Funktionen. Filter fangen schlechte Daten, die durch die zugelassenen Anrufe hindurchschleichen. Ich behandele sie als komplementäre Schichten, nicht als Ersatz.

Auf der Eingabeseite verwende ich einen Prompt-Injektions-Prüfer, der nach bekannten Jailbreak-Mustern sucht. Ich verwende die OWASP LLM Prompt Injection Prevention Cheat Sheet (Link) als Referenz für die Regeln, die ich aktiviere. Wenn der Prüfer einen Prompt markiert, lehne ich ihn entweder ab oder bereinige den betroffenen Abschnitt, bevor der Agent ihn sieht.

Auf der Ausgabeseite scanne ich den vom Agenten generierten Text auf Geheimnisse, SQL-Injektionsversuche oder nicht zugelassene URLs. Die Secrets Management Cheat Sheet (Link) hilft mir, Regex-Muster für API-Schlüssel, Passwörter und Token zu erstellen. Die SQL Injection Prevention Cheat Sheet (Link) leitet die Muster, die ich verwende, um gefährliche Abfragen zu erkennen, die möglicherweise in einer Antwort zurückgegeben werden.

Beide Filtersets laufen als leichte Middleware. Sie verursachen einige Millisekunden Latenz, stoppen aber viele Angriffe mit geringem Aufwand, bevor sie die Tool-Ebene erreichen. Da die Zulassungsliste bereits ganze Klassen von Anrufen entfernt hat, haben die Filter eine kleinere Oberfläche zur Inspektion, was die falsch-positiven Ergebnisse niedrig hält.

Was dies nicht ist

Ich möchte klarstellen, wo die Grenzen einer Allowlist liegen, damit Sie nicht erwarten, dass sie Probleme löst, die sie nie adressieren sollte.

- Es ist keine Garantie, dass der Agent niemals schlecht handelt. Ein entschlossener Angreifer, der einen Weg findet, ein erlaubtes Tool mit bösartigen Parametern aufzurufen, kann immer noch Schaden anrichten. - Es ersetzt nicht sichere Codierungspraktiken. Wenn der Code des Agents selbst eine Schwachstelle enthält, kann die Allowlist diese Schwachstelle nicht stoppen. - Es ist kein Ersatz für eine ordnungsgemäße Verwaltung von Geheimnissen. Selbst wenn der Agent kein Tool zur Geheimnisexfiltration aufrufen kann, stellen Geheimnisse, die in Protokollen oder Ausgaben geleakt werden, immer noch ein Risiko dar. - Es stoppt nicht die indirekte Prompt-Injektion, die den Agenten manipuliert, ein erlaubtes Tool auf unerwartete Weise zu verwenden. Sie benötigen immer noch Eingabevalidierung und Ausgabefilterung. - Es ist keine einmalige Aufgabe. Jedes Mal, wenn ein Tool hinzugefügt wird, sich seine Parameter ändern oder der Zweck des Agents sich ändert, müssen Sie die Liste überarbeiten. - Es ist kein Allheilmittel für die Einhaltung von Vorschriften. Vorschriften wie der EU-AI-Gesetz erfordern Dokumentation, Risikobewertungen und menschliche Aufsicht, die über eine einfache Allowlist hinausgehen.

Das Verständnis dieser Grenzen hilft Ihnen, Ihre Anstrengungen dort zu konzentrieren, wo sie einen echten Sicherheitswert haben.

Häufige Fallstricke, die ich gesehen habe und wie ich sie vermeide

Trotz eines klaren Prozesses verfallen Teams manchmal in Gewohnheiten, die die Allowlist schwächen. Hier sind die Muster, auf die ich achte, und die konkreten Schritte, die ich unternehme, um die Liste ehrlich zu halten.

- Zu breite Parameter – Jemand fügt ein Tool mit einer Flag wie „--recursive“ oder „--all“ hinzu, weil es bequem erscheint. Ich vermeide dies, indem ich frage: „Was ist die kleinste Menge an Optionen, die die Aufgabe erfüllt?“ Wenn die Antwort eine Teilmenge ist, sperre ich die Flag auf diese Teilmenge in der YAML-Datei. - Vergessene Tool-Updates – Eine Bibliothek aktualisiert sich und fügt einen neuen Befehl hinzu, der automatisch verfügbar ist. Ich mindere dies, indem ich die genaue Version des Tools in der Abhängigkeitsdatei des Agents pinne und einen CI-Schritt hinzufüge, der fehlschlägt, wenn eine neue Version ungedokumentierte Befehle einführt. - Vermischung von Richtlinie und Prompt – Ein Entwickler versucht, Grenzen durch Hinzufügen von Anweisungen wie „rufen Sie delete nicht auf“ innerhalb des Prompts durchzusetzen. Ich erinnere das Team daran, dass Prompt-Steuerungen durch geschickte Umformulierung umgangen werden können; der eigentliche Schutz muss auf der Ebene des Tool-Registers oder der Ausführungsebene sitzen. - Fehlende Protokollierung – Die Allowlist blockiert einen Aufruf, aber niemand weiß, dass es passiert ist. Ich stelle sicher, dass jeder blockierte Versuch einen strukturierten Protokolleintrag mit Timestamp, Agent-ID und abgelehntem Toolnamen schreibt. Dieses Protokoll wird in unser Alarmierungssystem eingefüttert, damit wir Aufklärung über potenzielle Angriffe erhalten können.

Referenzen

- OWASP LLM Prompt Injection Prevention Cheat Sheet - OWASP SQL Injection Prevention Cheat Sheet - OWASP Secrets Management Cheat Sheet - AgentGuard Squads – Konfigurationsdateien Anleitung

Häufig gestellte Fragen

Reicht eine Prompt-Anweisung aus, um Tools einzuschränken?

Nein. Einschränkungen auf Prompt-Ebene können umgangen werden. Die Allowlist sollte auf der Tool-Registrierung oder der Ausführungsebene durchgesetzt werden.

Was zählt als unwiderrufliche externe Auswirkung?

Das Senden von E-Mails oder Nachrichten, das Verschieben von Geld, das Löschen von Aufzeichnungen, das Veröffentlichen von Inhalten - alles, was Sie nicht rückgängig machen können.

Wie viele Tools sind zu viele?

Es gibt keine bestimmte Zahl. Der Test ist, ob Sie für jedes Tool auf der Liste erklären können, welche Aufgabe es erfordert und was es zerstören kann.

Ersetzen Filter eine Allowlist?

Nein. Filter fangen schlechten Inhalt ab; Allowlists entfernen unnötige Fähigkeiten. Verwenden Sie beide.

Deckt dies indirekte Prompt-Injektionen ab?

Es begrenzt den Schaden, den man anrichten kann. Das Erkennen und Blockieren der Injektion selbst ist eine separate Eingabe-Seiten-Steuerung.

Ist die Überprüfung eine Sicherheitsprüfung?

Nein. Es handelt sich um Entscheidungshilfen, die Anrufe bewerten und Filter vorschlagen. Eine vollständige Bewertung der Bereitstellung benötigt immer noch eine Sicherheitsprüfung.

Referenzen

- OWASP — Top 10 für Large Language Model-Anwendungen - NIST — AI-Risikomanagement-Framework

Probieren Sie das Produkt: AgentGuard

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

Verwandte Artikel

- AgentGuard-Leitplanken abgebildet auf das NIST AI RMF - Erkunden Sie die vollständige AI-Micro-SaaS-Themenmatrix →