Zum Hauptinhalt springen
Der schnellste Weg, einen Agenten davon abzuhalten, etwas Gefährliches zu tun, ist, das Tool zu benennen und es abzulehnen. Ein deny-Verdikt auf einem Tool-Namen-Glob ist das Deny-List-Primitiv der Agent-Firewall: eine Regel, ein Glob, Verdikt deny, an einen Key angehängt — und von da an verweigert das Gateway dieses Tool bei jedem Aufruf, ohne Änderung an Ihrem Agenten-Code. Diese Seite behandelt den Deny-List-Anwendungsfall und die eine Entscheidung, die er erzwingt: auf welcher Surface Sie blockieren — den Tools, die Sie anbieten (inbound), oder den Tool-Calls, die das Modell ausgibt (response). Für das vollständige Matching-Vokabular und die Verdikt-Semantik siehe Regel-Schema und Verdikte.

​
1. Einen Tool-Call blockieren, den ein KI-Agent macht

Eine Deny-List-Regel ist das Einfachste, was eine Firewall-Policy ausdrücken kann: ein Tool per Namen matchen, deny zurückgeben. Verwenden Sie sie, wenn ein Tool für einen gegebenen Key niemals feuern soll — shell.exec, *.delete, ein Community-Plugin, dem Sie nicht trauen — ungeachtet der Argumente. Öffnen Sie in Ihrer Workspace-Konsole eine Policy (oder erstellen Sie eine) und fügen Sie eine Regel hinzu: 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
Der tool_name_glob ist ein kleiner, case-sensitiver Glob — shell.* fängt eine ganze Familie, *.delete fängt ein Verb über Server hinweg, * fängt alles. Es ist keine Argument-Klausel nötig: ein bloßer Glob + deny blockiert das Tool bedingungslos. Fügen Sie eine Argument-Klausel nur hinzu, wenn Sie das Tool generell erlauben, aber eine Aufruf-Form ablehnen wollen.
Die Engine durchläuft die Regeln einer Policy in Prioritätsreihenfolge und der erste Treffer gewinnt. Setzen Sie schmale Allow-Ausnahmen auf eine niedrigere priority-Zahl (sie laufen zuerst) und Ihr breites Deny darunter — z. B. shell.exec von einem vertrauenswürdigen builtin.*-Skill erlauben, es überall sonst ablehnen. Siehe Regel-Priorität.

​
2. Inbound vs. response: die Surface wählen

Ein Deny kann an zwei verschiedenen Punkten im Request-Lebenszyklus landen, und der Unterschied zählt. Pinnen Sie die Regel mit dem stage-Feld, oder lassen Sie es leer, um beide abzudecken.

inbound

Die Tools, die Ihr Agent dem Modell auf dem Request anbietet (die Tool-Definitionen). Ein Deny hier entfernt das Tool, bevor das Modell es überhaupt wählen kann — das Modell sieht es nie als Option.

response

Die tool_calls, die das Modell in seiner Antwort ausgibt. Ein Deny hier fängt den Aufruf, den das Modell bereits zu machen beschlossen hat, bevor er das Tool erreicht.
Bevorzugen Sie inbound, wenn Sie wollen, dass ein Tool unsichtbar ist — das Modell kann nicht aufrufen, was ihm nie angeboten wurde, sodass Sie verschwendete Turns vermeiden, in denen es ein Tool wählt, nur um abgewiesen zu werden. Verwenden Sie response (oder lassen Sie stage leer), wenn das Tool legitim in manchen Requests auftaucht und Sie den tatsächlich ausgegebenen Aufruf fangen wollen, oder wenn Sie nur die Agenten-Schleife steuern und nicht den angebotenen Toolset.
Eine Regel mit keinem stage trifft auf alle Surfaces zu — dasselbe Deny deckt ein Tool ab, ob es angeboten, ausgegeben oder durch MCP dispatcht wird. Das ist der Gürtel-und-Hosenträger-Default; pinnen Sie eine Surface nur, wenn ein Deny auf eine gescoped sein soll. Siehe Stages.

​
3. Die Policy anhängen und beim Feuern beobachten

Eine Policy tut nichts, bis ein Key auf sie aufgelöst wird. Hängen Sie in der Konsole an, indem Sie firewall_policy_id auf dem Key setzen, oder machen Sie die Policy zum Workspace-Default. Die Auflösung ist: die am Key angehängte Policy (wenn sie existiert und aktiviert ist), sonst der Workspace-Default. (Eine deaktivierte angehängte Policy fällt auf den Default zurück — siehe Policies verwalten.) Einmal angehängt, gibt ein abgelehnter Aufruf auf der inbound-Surface HTTP 400 mit dem Fehlercode firewall_blocked und einem Grund zurück, der das Tool benennt — z. B. tool "shell.exec" blocked by firewall. Der Fehler ist als skip-retry markiert (das erneute Ausführen des identischen Aufrufs würde einfach wieder blockieren) und kostet keine Modell-Tokens, da ein Inbound-Block vor dem Upstream-Aufruf feuert. Ein durch das MCP-Gateway dispatchtes Deny taucht stattdessen als Tool-Fehler auf, sodass das Modell die Ablehnung sieht und reagieren kann.
Ein Deny auf der inbound-Surface entfernt das Tool aus dem, was dem Modell angeboten wird. Wenn Ihr Agenten-Framework erfordert, dass ein angebotenes Tool aufrufbar ist, kann das Blockieren auf inbound die Schleife verwirren — in diesem Fall blockieren Sie stattdessen auf response, sodass das Tool angeboten bleibt, aber der tatsächliche Aufruf abgewiesen wird. Testen Sie den Unterschied, bevor Sie ausrollen (siehe §5).

​
4. Deny ist eines von mehreren Verdikten

Deny ist das stumpfste Werkzeug auf der Deny-List. Wenn ein harter Block zu viel ist, kann derselbe Glob ein sanfteres Verdikt tragen:
VerdiktWann man stattdessen statt deny dazu greift
auditSie wollen das Tool feuern sehen, aber es noch nicht blockieren.
sanitizeDas Tool ist in Ordnung, aber seine Argumente könnten Secrets/PII tragen — redigiert Args, nie Tool-Ergebnisse.
pending_approvalEin Mensch soll jeden Aufruf out-of-band genehmigen.
cap_costErlauben, bis die Ausgaben eines Agentenlaufs eine Cent-Obergrenze überschreiten.
All diese sind unter Verdikte dokumentiert. Eine Deny-List ist nur die Teilmenge, in der das Verdikt deny ist. Für eine Allow-List-Haltung (alles ablehnen, ein benanntes Set erlauben) drehen Sie das default_verdict der Policy auf deny und fügen Sie schmale Allow-Regeln hinzu — siehe Tool-Allow-Listing.

​
5. Es sicher ausrollen

Der Konsolen-Tab Test dry-runnt eine Policy gegen einen Beispiel-Tool-Call und gibt das Verdikt, die gematchte Regel und den Grund zurück — nichts wird dispatcht, nichts wird persistiert. Bestätigen Sie, dass Ihr Glob das Tool matcht, das Sie meinten (und nur dieses Tool), bevor Sie einen Key anhängen. Siehe Regeln testen.
Schalten Sie Shadow-Mode auf der Policy ein, und jedes durchsetzende Verdikt — einschließlich Ihres Deny — wird auf audit herabgestuft, Grund mit [shadow] would … präfixiert. Sie messen genau, was das Deny gegen echten Traffic blockieren würde, schalten dann Shadow aus, um durchzusetzen.
Nicht sicher über den exakten Tool-Namen zum Globben? Die Discovered-Tools-Ansicht listet jedes Tool, das der Workspace gesehen hat, geflaggt als covered oder gap. Verfassen Sie Ihr Deny direkt aus den Namen, die tatsächlich auftauchten. Siehe Analytics.
Jede Auswertung schreibt ein Firewall-Event mit Verdikt, Surface, Tool und gematchter Regel. Nachdem Sie durchgesetzt haben, filtern Sie das Events-Log nach dem Verdikt deny, um die Regel auf den Aufrufen feuern zu sehen, die Sie erwartet haben.

​
6. Wer was tun darf

Alle Deny-List-Konfiguration läuft in der Konsole unter Ihrer Session (/api/workspace/firewall/*):
AktionRolle
Policies, Presets, Discovered Tools, Simulate lesenMember
Eine Policy dry-runnen (Test)Developer+
Regeln und Policies erstellen / editieren / löschenDeveloper+
Das Events-Log und Run-Aggregate lesenDeveloper+
Das Verfassen oder Ändern einer Deny-Regel ist ein Developer+-Schreibvorgang, und so auch der Konsolen-Test-Dry-Run. Das Lesen einer Policy und die schreibgeschützte Simulate-(„What-if”)-Ansicht sind für jedes Mitglied offen.

​
Verwandt

Glob-Syntax

Wie genau shell.*, *.exec und *.shell.* matchen.

Tool-Allow-Listing

Die umgekehrte Haltung: Default-Deny, ein benanntes Set erlauben.

Argumente validieren

Nur eine Form des Aufrufs ablehnen, nicht das ganze Tool.

Gefährliche Tool-Calls

Die Bedrohung, die eine Deny-List adressiert.

Verdikte

Was Deny und seine sanfteren Geschwister auf der Leitung tun.

Firewall-Referenz

Die vollständige Regel- + Matching-Referenz.