Zum Hauptinhalt springen
Sie haben eine Firewall-Regel geschrieben — ein deny auf shell.exec, eine Egress-Allow-List, eine Argument-Klausel, die nur auf rm -rf feuert — und nun wollen Sie wissen, dass sie genau das tut, was Sie denken, bevor sie einen einzigen Produktions-Tool-Call verändert. Die Firewall gibt Ihnen drei nicht-destruktive Wege, Firewall-Regeln zu testen, jeder beantwortet eine andere Frage:

Einen Aufruf dry-runnen

Die Test-Sandbox füttert einen synthetischen Tool-Call durch die echte Engine und gibt das Verdikt zurück — nichts dispatcht, nichts geloggt. Developer+.

Eine Haltung wiedergeben

Simulate gibt ein Autonomie-Level gegen Ihren jüngsten Traffic wieder und zählt, wie viele Aufrufe es blockieren würde. Member-lesbar.

Gegen Live-Traffic laufen lassen

Shadow-Mode wertet eine ganze Policy auf echten Aufrufen aus, stuft aber jedes durchsetzende Verdikt auf audit herab. Null Blast-Radius.
Alle drei konfigurieren über die Konsole (oder die /api/workspace/firewall/*-Management-Routen, die mit Ihrer Session / Ihrem Access-Token authentifizieren — nicht einem Relay-sk-orca-…-Key). Die /v1/*-Relay-Aufrufe Ihres Agenten ändern sich nie, während Sie testen.

​
1. Firewall-Regeln mit der Dry-Run-Test-Sandbox testen

Die Test-Sandbox ist die engste Schleife: Übergeben Sie ihr einen einzelnen synthetischen Tool-Call, und sie lässt die echte Auswertungs-Engine laufen — vollständige Policy-Auflösung, Regeln in Prioritätsreihenfolge durchlaufen, erster-Treffer-gewinnt — und gibt dann das Verdikt, die Regel, die es erzeugte, und den menschenlesbaren Grund zurück. Der Aufruf ist ein Dry-Run: Nichts wird an irgendein Tool dispatcht, und nichts wird in den Events-Feed oder das Discovered-Tools-Inventar geschrieben. Er beantwortet eine Frage präzise: Was entscheidet meine Policy bei genau diesem Tool-Namen und diesen Argumenten — und welche Regel entscheidet es?
Die Test-Sandbox ist Developer+. Sie kann gegen eine ungespeicherte Entwurfs-Policy nach ID vorschauen, und die Antwort fördert den gematchten Policy-Namen und das Regel-Label zutage, sodass sie näher an einer Write-Surface-Vorschau sitzt als an einem einfachen Read — anders als Simulate und die anderen Read-Ansichten, die für jedes Member offen sind.

​
Ein konkreter Dry-Run

Angenommen, Sie haben eine Regel hinzugefügt, die shell.exec nur dann verweigern soll, wenn der Befehl rm -rf enthält. Sie wollen zwei Dinge in einer Sitzung bestätigen: Der gefährliche Befehl wird verweigert, und ein harmloser geht weiterhin durch.
1

Den gefährlichen Aufruf testen

Öffnen Sie in Security → Firewall den Test-Tab, wählen Sie die response-Surface, geben Sie den Tool-Namen shell.exec und die Argumente {"command": "rm -rf /data"} ein und führen Sie aus. Die Antwort benennt das Verdikt und die gematchte Regel:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Den harmlosen Aufruf testen

Führen Sie es erneut mit {"command": "ls -la"} aus. Die Argument-Klausel matcht nicht mehr, sodass die Regel auf den Policy-Default durchfällt — Sie sollten allow oder audit und ein leeres rule_label sehen. Wenn rm -rf verweigert und ls -la nicht, ist Ihre Argument-Klausel korrekt gescoped.
3

Einen Entwurf vorschauen, bevor Sie ihn anhängen

Übergeben Sie ein policy_id, um gegen eine bestimmte Entwurfs-Policy auszuwerten statt gegen die, auf die Ihr Traffic aktuell auflöst — sodass Sie beweisen können, dass eine neue Policy korrekt ist, bevor Sie einen Key an sie anhängen oder sie zum Workspace-Default promoten.
Lesen Sie gap in der Antwort. gap: true bedeutet, eine Policy löste auf, aber keine Regel darin matchte den Aufruf (und der Workspace ist im Observe-Mode) — das Tool rutschte durch jede Regel und fiel auf den Default. Das ist eine Abdeckungslücke, die vor dem Ausliefern zu schließen ist, kein Verdikt, dem zu vertrauen ist.
Die Test-Sandbox verwendet dieselben Surfaces wie die Live-Auswertung — inbound, response, mcp, egress (Default inbound) — testen Sie also jede Regel auf der Surface, auf die sie gepinnt ist. Auf inbound gibt es keine Argumente zur Aufrufzeit, sodass eine sanitize-Regel dort genau zu einem Block eskaliert, wie sie es in Produktion täte; siehe Stages dafür, warum die Surface zählt.

​
2. Ein Autonomie-Level simulieren, bevor Sie es anwenden

Die Test-Sandbox prüft einen Aufruf. Simulate beantwortet die Frage auf Haltungsebene: Wenn ich diesen ganzen Workspace auf ein strengeres Autonomie-Level umschaltete, wie viel meines jüngsten Traffics würde es blockieren? Simulate gibt die Deny-Regeln eines Kandidaten-Levels gegen Ihre nachlaufenden Firewall-Events wieder und gibt die potenzielle Wirkung zurück — nur Tool-Namen und Zähler, niemals Argumente. Es ist read-only und Member-lesbar, sodass jeder im Team den Blast-Radius von tight vorschauen kann, bevor sich ein Developer dazu verpflichtet.
  • tight — Default-Deny, destruktive Shell verweigern, fetch-förmige Tools verweigern (der SSRF-Vektor), PII Shield + Secrets Blocker durchgesetzt. Simulate zeigt, wie viel Ihres echten Traffics dieser Boden abfangen würde.
  • balanced — Default audit, destruktive Shell verweigern, PII Shield nur-audit (flaggt PII). Die empfohlene Ausgangshaltung.
  • permissive — nur beobachten; nichts durchgesetzt.
Simulate ändert nichts — es ist ein Was-wäre-wenn über vergangene Events. Das Anwenden eines Autonomie-Levels (ein Developer+-Write) materialisiert echte, editierbare autonomy_*-Policy- und Guardrail-Zeilen, mit Ein-Klick-Undo aus dem Audit-Snapshot. Vorschauen Sie mit Simulate, dann wenden Sie an, wenn der Zähler richtig aussieht.

​
3. Shadow-Mode: gegen Live-Traffic testen ohne Blast-Radius

Die Test-Sandbox und Simulate sind Offline-Vorschauen. Shadow-Mode ist die Live-Variante: ein Pro-Policy-Flag, das die Policy auf echtem Agenten-Traffic auswertet, jede Regel durchläuft, ein Verdikt wählt — dann jedes durchsetzende Verdikt (deny, sanitize, pending_approval) auf audit herabstuft und dem Grund [shadow] would … voranstellt. Der Aufruf geht immer durch; nichts wird blockiert, redigiert oder zurückgehalten. Das lässt den Events-Feed wie einen Produktionslauf mit ausgeschalteter Durchsetzung lesen. Filtern Sie nach [shadow], und Sie haben eine vollständige Liste jedes Aufrufs, den die Policy gleich zu blockieren beginnt — bevor sie einen blockiert.
Test-MethodeLäuft gegenFrage, die sie beantwortet
Test-SandboxEinen synthetischen Aufruf„Welches Verdikt bekommt dieser exakte Aufruf, und welche Regel entscheidet?”
SimulateJüngste Events„Wie viele Aufrufe würde ein strengeres Autonomie-Level blockieren?”
Shadow-ModeLive-Traffic„Was würde diese Policy über echten Produktions-Traffic hinweg blockieren?”
Shadow-Mode ist der tiefste der drei — volle Live-Abdeckung mit null Blast-Radius. Er hat seine eigene Seite: Eine Firewall-Policy mit dem Shadow-Mode ausrollen durchläuft den Schalter, die [shadow] would …-Gründe und den Umschwung zum Durchsetzen.

​
4. Eine praktische Test-Reihenfolge

Die drei Werkzeuge komponieren zu einem sicheren Rollout-Pfad — günstigste Prüfung zuerst, breiteste Abdeckung zuletzt:
1

Die gerade geschriebenen Regeln dry-runnen

Verwenden Sie Test, um zu bestätigen, dass jede neue Regel auf den Aufrufen feuert, auf denen sie sollte, und die durchlässt, die sie nicht sollte — einschließlich der negativen Fälle. Schnell, Developer+, nichts persistiert.
2

Die Haltung abschätzen (optional)

Wenn Sie zu einem Autonomie-Level greifen statt zu handgeschriebenen Regeln, simulieren Sie das Level und lesen Sie den potenziell-blockierten Zähler gegen echten Traffic, bevor Sie es anwenden.
3

Gegen Live-Traffic shadowen

Schalten Sie den Shadow-Mode ein und lassen Sie ein repräsentatives Fenster echter Aufrufe fließen. Lesen Sie die [shadow] would …-Events; verschärfen Sie jede Regel, die einen False Positive zutage fördert — noch im Shadow, null Blast-Radius.
4

Durchsetzen

Wenn der Feed auf dem feuert, was Sie erwarten, und auf nichts, was Sie nicht erwarten, schalten Sie den Shadow aus. Der nächste Aufruf setzt wirklich durch.
Das Testen schaut die Policy vor, nicht gesteuerte Skills. Ein Skill im block- oder quarantine-Mode setzt auch unter einer geshadowten Policy durch — die Review-Disposition des Skills gewinnt. Eine Policy zu shadowen war nie eine Anfrage, einen Skill aus der Quarantäne zu nehmen.

​
5. API-Referenz

Diese Management-Routen verwenden Ihr Session- / Access-Token und sind workspace-bezogen:
Methode & PfadRolleZweck
POST /api/workspace/firewall/testDeveloper+Einen synthetischen Tool-Call gegen die aufgelöste (oder eine Entwurfs-policy_id-)Policy dry-runnen. Gibt Verdikt, policy_name, rule_label, reason, gap, shadow_mode zurück. Nichts dispatcht oder geloggt.
GET /api/workspace/firewall/simulate?level=MemberEin Autonomie-Level gegen jüngste Events wiedergeben; gibt potenziell-blockierte Zähler zurück.
GET /api/workspace/firewall/policies/:idMemberDas aktuelle shadow_mode-Flag einer Policy lesen.
PUT /api/workspace/firewall/policiesDeveloper+shadow_mode auf der Policy umschalten.
Der Test-Body nimmt surface (Default inbound), ein erforderliches tool_name, ein optionales args_json und ein optionales policy_id, um die Auflösung zu überschreiben.

​
Wohin als Nächstes

Shadow-Mode

Der Live-Traffic-Rollout: [shadow] would …, der Events-Filter und der Umschwung zum Durchsetzen.

Argumente validieren

Eine Regel auf welche Argumente scopen — die Klauseln, die die Test-Sandbox Sie gegen rm -rf vs. ls -la verifizieren lässt.

Verdikte

Was allow / audit / deny / sanitize / pending_approval / cap_cost jeweils tun, wenn ein Test aufhört, ein Test zu sein.

Events-Log

Wo geshadowte Verdikte landen — filtern, in Runs und gematchte Regeln eintauchen.
Für die Regel-Matching-Grammatik, die diese Tests ausüben, siehe die vollständige Firewall-Regeln-Referenz; dafür, wo Testen in das breitere Modell passt, siehe Enforcement-Modi.