Zum Hauptinhalt springen
Sie haben eine Firewall-Policy geschrieben — eine Default-Deny-Haltung, ein deny auf shell.exec, eine Egress-Allow-List — und Sie glauben, sie ist richtig. Aber sie gegen produktiven Agenten-Traffic einzuschalten ist ein Vertrauenssprung: Eine zu breite Regel, und Sie blockieren Aufrufe, die Ihre Agenten legitim machen. Der Firewall-Shadow-Mode ist der Schalter für sicheres Ausrollen. Es ist ein Pro-Policy-Flag, das dem Gateway sagt, die Policy genau so auszuwerten, wie es in Produktion täte, alles zu loggen, aber nichts zu blockieren. Jedes durchsetzende Verdikt wird auf audit herabgestuft, und dem Event-Grund wird [shadow] would … vorangestellt, sodass Sie genau ablesen können, was die Policy getan hätte — ohne dass sie bereits irgendetwas getan hat.
Shadow-Mode ist ein Flag auf der Policy, in der Konsole gesetzt (oder über die /api/workspace/firewall/policies-Management-Routen, die Ihre Session bzw. Ihr Access-Token verwenden — nicht einen Relay-sk-orca-…-Key). Das Umschalten ist eine Developer+-Aktion. Die /v1/*-Relay-Aufrufe Ihres Agenten ändern sich nicht.

​
1. Was der Firewall-Shadow-Mode tut

Wenn das shadow_mode-Flag einer Policy an ist, führt das Gateway die volle Auswertung aus — löst die Policy auf, durchläuft die Regeln in Prioritätsreihenfolge, wählt ein Verdikt — und stuft dann, kurz bevor das Verdikt wirkt, alles herab, was den Aufruf verändert hätte:
Aufgelöstes VerdiktUnter Shadow-Mode
deny→ audit, Grund [shadow] would deny — …
sanitize→ audit, Grund [shadow] would sanitize — …
pending_approval→ audit, Grund [shadow] would pending_approval — …
allow / auditunverändert (bereits nicht-blockierend)
Der Aufruf läuft immer durch. Nichts wird blockiert, keine Argumente werden redigiert, kein menschlicher Hold wird geöffnet — aber das Event wird mit dem Verdikt aufgezeichnet, das die Policy erzeugt hätte, sodass der Events-Feed wie ein Produktionslauf mit abgeschalteter Durchsetzung liest.
Das [shadow] would …-Präfix ist Ihr Schlagzeilen-Filter. Sortieren Sie den Events-Feed danach, und Sie haben eine vollständige Liste jedes Aufrufs, den diese Policy gleich zu blockieren beginnt, bevor sie einen blockiert.

​
2. Ein konkretes Ausrollen

Angenommen, Sie haben eine Policy prod-agents mit einer deny-Regel auf destruktive Shell-Befehle und wollen bestätigen, dass sie bei nichts Legitimem auslöst.
1

Shadow-Mode einschalten

In Security → Firewall → Policies öffnen Sie prod-agents, schalten Shadow mode an und speichern. Die Policy behält ihre Bindung und ihre Regeln — sie hört nur auf durchzusetzen.
2

Echten Traffic fließen lassen

Ihre Agenten rufen das Gateway weiterhin genau wie zuvor auf. Jeder Tool-Call wird ausgewertet; nichts wird blockiert. Geben Sie ihm ein repräsentatives Fenster — lang genug, um Ihren echten Tool-Mix abzudecken.
3

Die Beinahe-Ablehnungen lesen

Öffnen Sie Events und filtern Sie nach dem [shadow]-Grund. Jede Zeile zeigt das Tool, die Surface, den Run und die Regel, die matchte — sodass ein [shadow] would deny — destructive shell command auf einem shell.exec-Aufruf genau das ist, was Sie in Produktion sehen würden, minus dem HTTP 400.
4

Shadow-Mode ausschalten

Sobald der Feed zeigt, dass die Policy auf das feuert, was Sie erwarten, und auf nichts, was Sie nicht erwarten, schalten Sie Shadow mode aus. Ab dem nächsten Aufruf werden diese [shadow] would deny-Events zu echten firewall_blocked-Ablehnungen.
Wenn der Shadow-Mode doch ein False Positive zutage förderte — ein legitimer Aufruf, der eine deny-Regel matchte — beheben Sie die Regel (verschärfen Sie den Glob oder fügen Sie eine Argument-Klausel hinzu), während Sie noch im Shadow sind, und beobachten Sie den Feed erneut. Sie iterieren gegen echten Traffic mit null Blast-Radius.

​
3. Was der Shadow-Mode nicht abmildert

Der Shadow-Mode ist eine Vorschau der Policy, kein Master-Aus-Schalter.
Gesteuerte Skills setzen unter einer Shadow-Policy weiterhin durch. Ein Skill im block-Mode lehnt weiterhin ab, und ein Skill im quarantine-Mode hält weiterhin zur Freigabe zurück, selbst wenn die gematchte Policy geshadowt ist. Der Skill-Enforcement-Mode ist eine Eigenschaft des Review-Zustands des Skills, nicht der Policy, die Sie in der Vorschau betrachten — eine Policy zu shadowen war nie eine Aufforderung, einen Skill zu ent-quarantänieren. Die Policy bleibt in den Events als geshadowt gebadged, aber die Disposition des Skills gewinnt.
Ein paar weitere Grenzen, die zu kennen sich lohnt:
Nur durchsetzende Verdikte (deny, sanitize, pending_approval) werden herabgestuft. Ein allow oder audit lässt den Aufruf bereits durch, also gibt es nichts abzumildern — diese Events tragen trotzdem das Shadow-Badge, sodass Sie erkennen, dass die Policy im Shadow war, als sie aufgezeichnet wurden.
Eine cap_cost-Regel wird basierend auf den kumulierten Ausgaben des Runs zu einem konkreten allow oder deny aufgelöst, und dieses aufgelöste Verdikt ist, was der Shadow-Mode dann herabstuft — eine Beinahe-Cap-Trip-Ablehnung taucht wie jede andere als [shadow] would deny auf.
Der Shadow-Mode lebt auf jeder Policy unabhängig. Sie können eine brandneue Policy shadowen, während eine kampferprobte weiter durchsetzt — es gibt keinen workspace-weiten Shadow-Schalter, den man vergessen könnte auszuschalten.

​
4. Shadow-Mode vs. die anderen Ausroll-Regler

Die Firewall gibt Ihnen drei verschiedene „noch nichts kaputt machen”-Kontrollen. Sie lösen verschiedene Probleme:
KontrolleScopeFrage, die sie beantwortet
Shadow-ModeEine Policy„Was würde diese Policy blockieren, wenn ich sie durchsetzte?”
audit-Default-VerdiktEine Policy„Alles loggen, was keine Regel benennt, nichts blockieren.”
Observe-ModeWorkspace„Welche Tools laufen, ohne dass eine Policy sie abdeckt?”
Der Shadow-Mode ist der, zu dem man greift, wenn man eine echte, durchsetzende Policy hat und ihre genaue Wirkung messen will, bevor sie den Traffic verändert. Ein Default-Verdikt von audit ist für den ungematchten Schwanz einer Policy; der Observe-Mode dreht sich um Abdeckungslücken über den Workspace hinweg, nicht um die Durchsetzung einer spezifischen Policy.
Sie können sie stapeln. Eine neue Default-Deny-Policy unter Shadow-Mode ist das sanftest mögliche Ausrollen: Selbst der Default-Deny-Boden loggt nur [shadow] would deny, statt zu blockieren, sodass Sie die volle Menge der Aufrufe sehen, die Ihre Allow-Regeln noch nicht abdecken, bevor das Deny live ist.

​
5. Compliance-Packs landen zuerst im Shadow

Wenn Sie ein Compliance-Pack installieren im Observe-Modus (nicht durchsetzend), werden die Firewall-Policies, die es materialisiert, mit Shadow-Mode an erstellt — sie werten aus und loggen gegen Ihren Traffic, ohne etwas zu blockieren. Das Promoten des Packs zur Durchsetzung holt diese Policies aus dem Shadow. Derselbe Mechanismus, für Sie angewandt: die Kontrollen dry-runnen, die Beinahe-Verdikte lesen, dann durchsetzen.

​
6. Es umschalten

In der Konsole ist der Shadow-Mode ein Toggle im Policy-Editor. Dasselbe Flag wird auf der Management-API als shadow_mode auf dem Policy-Objekt exponiert — diese Routen verwenden Ihr Session- bzw. Access-Token und erfordern Developer+:
Methode & PfadRolleHinweis
PUT /api/workspace/firewall/policiesDeveloper+shadow_mode: true / false auf der Policy im Body setzen.
GET /api/workspace/firewall/policies/:idMemberDen aktuellen shadow_mode-Zustand einer Policy lesen.
Jede Änderung schreibt eine Audit-Zeile und erhöht den version-Integer der Policy, sodass das Ein- und Ausschalten von Shadow selbst nachverfolgt wird.

​
Wohin als Nächstes

Eine Policy erstellen & anhängen

Die zweistufige Einrichtung, die der Shadow-Mode ausrollt — die Policy erstellen, einen Key anhängen.

Events-Log

Wo [shadow] would … auftaucht — filtern, in Runs und Regeln eintauchen.

Verdikte

Die durchsetzenden Verdikte, die der Shadow-Mode herabstuft, und was jedes live tut.

Enforcement-Modes

Wie Shadow, Audit und Observe in das umfassendere Enforcement-Modell passen.
Für die Bedrohungen, die eine Policy stoppt, sobald Sie Shadow ausschalten, siehe gefährliche Tool-Calls und übermäßige Handlungsmacht.