Zum Hauptinhalt springen
Wenn ein Modell antwortet, gibt es nicht nur Text zurück — es gibt tool_calls aus: konkrete Aufrufe mit echten, vom Modell gewählten Argumenten. Die Response-Surface der Agent-Firewall inspiziert genau diese, in dem Moment, in dem sie das Modell verlassen, und bevor sie Ihre Agenten-Schleife erreichen. Es ist die Surface, auf der Sie filtern, was das Modell tatsächlich zu tun beschlossen hat, mit den Argumenten, die es tatsächlich gewählt hat. Diese Seite behandelt den Use-Case für das Filtern auf der Response-Surface — wann Sie dazu statt zu inbound greifen, die eine Verdikt-Wendung, die sie hinzufügt, und wie sie sich auf einem Stream verhält. Für das vollständige Regel-Vokabular und die Verdikt-Semantik siehe Regel-Schema und Verdikte.

​
1. LLM-Tool-Response-Aufrufe filtern, mit Argumenten im Scope

Die inbound-Stage sieht die Tools, die Sie anbieten — nur Namen, noch keine Argumente zur Aufrufzeit. Die Response-Stage sieht die tool_calls, die das Modell ausgibt, welche die vom Modell gewählten Argumente tragen. Das ist der ganze Grund, hier zu filtern: Es ist die einzige Surface, die den tatsächlichen Aufruf + die Argumente für ein client-ausgeführtes (Nicht-MCP-)Tool sieht, sodass Argument-Klauseln, Sequenzen und Run-State-Regeln alle auf response landen. Die Unterscheidung in einer Zeile:
StageSiehtVerwenden Sie sie, um
inboundAngebotene Tool-DefinitionenEin Tool für das Modell unsichtbar zu machen
responseAusgegebene tool_calls + ArgumenteDen Aufruf zu filtern, den das Modell tatsächlich gemacht hat
inbound beantwortet also welche Tools existieren; response beantwortet was das Modell mit einem getan hat. Greifen Sie zu response (oder lassen Sie stage leer, um beide abzudecken), wenn ein Tool in manchen Requests legitim auftaucht, aber ein bestimmter Aufruf davon gefährlich ist — oder wenn Sie nur die Agenten-Schleife kontrollieren, nicht die angebotene Tool-Menge.
Eine Regel ohne stage läuft auf jeder Surface, einschließlich response. Pinnen Sie auf response nur, wenn eine Regel nur ausgegebene Aufrufe inspizieren soll — zum Beispiel eine Argument-Klausel, die auf der inbound-Surface ohnehin nichts zum Matchen hat. Siehe Stages.

​
2. Ein konkretes Beispiel

shell.exec im Allgemeinen erlauben, es aber aus der Antwort des Modells entfernen, sobald sein command-Argument destruktiv aussieht. Öffnen Sie in Ihrer Workspace-Konsole eine Policy (oder erstellen Sie eine) und fügen Sie eine auf die Response-Surface gepinnte Regel hinzu: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Der Argument-Matcher lebt in args_match_json — ein JSON-String, der {"clauses":[…]} hält, wobei jede Klausel ein path / op / value-Tripel ist (op ist einer von eq, contains, regex, gt, lt). Das Konsolen-Formular baut es für Sie; die rohe Form wird hier gezeigt, damit der Feldname eindeutig ist. Das Tool bleibt angeboten — das Modell kann shell.exec weiterhin vorschlagen — aber wenn der ausgegebene Aufruf einen destruktiven command trägt, entfernt die Firewall diesen tool_call aus der Antwort, bevor Ihr Agent ihn je sieht. Ein gutartiges shell.exec (etwa ls -la) segelt unberührt durch. Das ist das „das Tool erlauben, den Aufruf gaten”-Muster, für das die Response-Surface existiert; die Argument-Klausel ist es, was es möglich macht.
Regeln werten in Prioritätsreihenfolge aus, erster Treffer gewinnt. Setzen Sie eine enge Allow-Ausnahme auf eine niedrigere priority-Zahl als ein breites deny, sodass die Ausnahme zuerst läuft. Siehe Regel-Priorität.

​
3. Was ein Verdikt auf der Response-Surface tut

Die Response-Surface inspiziert jeden ausgegebenen tool_call und schreibt die Antwort an Ort und Stelle um. Beibehaltene Aufrufe werden byte-für-byte weitergeleitet; nur ein gematchter Aufruf ändert sich:
Der gematchte tool_call wird aus der Antwort des Modells entfernt, bevor sie Ihren Agenten erreicht. Anders als ein inbound-deny — das HTTP 400 mit Code firewall_blocked zurückgibt — lässt ein Response-Surface-deny den Request nicht fehlschlagen; der Rest der Antwort (andere Tool-Calls, beliebiger Text) fließt durch, mit dem anstößigen Aufruf einfach abwesend.
Die gematchten Teilstrings in den Argumenten des Aufrufs werden durch die redigierten Argumente der Engine ersetzt, und der bereinigte Aufruf wird weitergeleitet — nützlich, wenn das Tool in Ordnung ist, aber das Modell einen Secret- oder PII-Wert in ein Argument gesetzt hat. Sanitize redigiert nur Tool-Call-Argumente; es rührt nie den Inhalt an, den ein Tool zurückgibt. Wenn die Engine nichts zu ersetzen hat, wird der Aufruf entfernt (fail-closed). Siehe Antworten bereinigen.
Human-in-the-Loop-Holds bleiben auf der inbound-Surface offen, nicht auf response. Eine pending_approval-Regel, die zuerst auf einem ausgegebenen Aufruf matcht, wird daher entfernt (fail-closed) — sie zu behalten würde einen ungeprüften Aufruf ohne menschliche Entscheidung weiterleiten. Verfassen Sie HITL-Holds so, dass sie inbound feuern; siehe Freigaben.
allow und audit leiten beide den Aufruf weiter; audit ist das übliche default_verdict — alles aufzeichnen, nichts blockieren, bis Sie bereit sind durchzusetzen.
cap_cost und pending_approval sind auf dieser Surface inbound-Konzepte. cap_cost ist auf response inert (das Modell ist bereits gelaufen), und pending_approval löst zu einem Entfernen statt einem Hold auf. Setzen Sie Kosten-Obergrenzen und HITL-Holds auf die inbound-Surface — siehe Kosten deckeln und Freigaben.

​
4. Streaming: zurückgehalten, dann gefiltert

Auf einer Nicht-Stream-Antwort wird die ganze Antwort auf einmal geparst und gefiltert. Auf einem Stream treffen die tool_calls eines Modells als Pro-Index-Deltas über viele SSE-Frames ein — und sobald ein Delta weitergeleitet ist, hat Ihr Agent es bereits, und es kann nicht zurückgezogen werden. Daher hält das Gateway Tool-Call-Frames zurück: Sie werden niemals mitten im Stream weitergeleitet. Am Stream-Ende setzt die Firewall jeden Aufruf zusammen (Name + vollständige Argumente), wertet ihn aus und gibt nur die überlebenden Aufrufe aus.
Content-Frames streamen weiterhin normal — Text-Tokens erreichen Ihren Client, während sie eintreffen. Nur tool_call-Frames werden zur Auswertung zurückgehalten, sodass ein verweigerter oder bereinigter Aufruf herausgefiltert wird, bevor der zusammengesetzte Tool-Call ausgeliefert wird. Die Verdikt- und Regel-Semantik ist identisch zur Nicht-Stream-Surface. Für die Frame-Level-Details siehe Streaming-Interna und Provider-Streaming.

​
5. Sicher ausrollen

Der Test-Tab der Konsole führt eine Policy gegen einen Beispiel-Tool-Call aus und gibt das Verdikt, die gematchte Regel und den Grund zurück — nichts wird dispatcht, nichts wird persistiert. Bestätigen Sie, dass Ihr Glob und Ihre Argument-Klausel den Aufruf matchen, den Sie meinten, bevor Sie einen Key anhängen. Siehe Regeln testen.
Schalten Sie den Shadow-Mode ein, und jedes durchsetzende Verdikt — einschließlich eines Response-Surface-deny — wird auf audit herabgestuft, Grund vorangestellt [shadow] would …. Sie messen genau, was die Regel gegen echten Traffic entfernen würde, bevor sie eine einzige Antwort verändert.
Jede Auswertung schreibt ein Firewall-Event mit dem Verdikt, der Surface, dem Tool und der gematchten Regel. Filtern Sie den Events-Log nach Surface response, um Ihre Regel auf den erwarteten ausgegebenen Aufrufen feuern zu sehen. Siehe Analytics.

​
6. Die Policy anhängen und wer sie konfigurieren kann

Eine Policy tut nichts, bis ein Key auf sie auflöst. Hängen Sie sie in der Konsole an, indem Sie firewall_policy_id auf dem Key setzen, oder machen Sie die Policy zum Workspace-Default. Auflösung: die angehängte Policy des Keys (wenn sie existiert und aktiviert ist), sonst der Workspace-Default — und eine deaktivierte angehängte Policy fällt auf den Workspace-Default zurück. Siehe Policies verwalten. Alle Konfiguration läuft in der Konsole unter Ihrer Session (/api/workspace/firewall/*):
AktionRolle
Policies, Presets, Discovered Tools, Simulate lesenMember
Dry-Run (Test), Events-Log und Run-Aggregate lesenDeveloper+
Regeln und Policies erstellen / bearbeiten / löschenDeveloper+

​
Verwandt

Argumente validieren

Die Argument-Klauseln, die Response-Surface-Filterung präzise machen.

Antworten bereinigen

Secrets aus den Argumenten eines Aufrufs redigieren, statt ihn zu entfernen.

Firewall-Stages

Wie response mit inbound, mcp und egress vergleicht.

Tools blockieren

Das inbound-Pendant: ein Tool verweigern, bevor es dem Modell angeboten wird.

Gefährliche Tool-Calls

Die Bedrohung, die Response-Filterung adressiert.

Firewall-Referenz

Die vollständige Regel- + Matching-Referenz.