Enforcement-Modi: Observe, Shadow & Enforce

Bevor eine Regel Produktions-Traffic blockiert, möchten Sie wissen, dass sie bei den richtigen Dingen auslöst und bei nichts anderem. OrcaRouter gibt Ihnen drei Haltungen — Observe, Shadow und Enforce — die Ihnen ein inkrementelles Ausrollen ermöglichen, mit Sichtbarkeit bei jedem Schritt und ohne Überraschungen. Diese Seite erklärt, was jede Haltung mechanisch bedeutet, wie man durch sie wechselt und wie Autonomie-Level das alles in einem Schritt setzen.

​

1. Die drei Haltungen auf einen Blick

​

2. Observe-Haltung — messen, bevor Sie Regeln schreiben

Die Observe-Haltung ist kein einzelner Schalter. Es ist eine Kombination aus drei unabhängigen Mechanismen, die zusammen „alles erlauben, alles aufzeichnen” erzeugen:

​

Firewall-Observe-Mode (Workspace-Einstellung)

Wenn ein Tool-Call zu überhaupt keiner Policy aufgelöst wird — keine Schlüssel-Bindung und kein Workspace-Default — bestimmt der workspace-weite Observe-Mode der Firewall, was passiert:

• Observe-Mode an: der Aufruf wird erlaubt und als Abdeckungs-Lücke geloggt. Die Discovered-Tools-Ansicht füllt sich mit diesen Lücken-Events und zeigt genau, welche Tools Ihre Agenten ausführen, ohne dass eine Regel sie abdeckt.
• Observe-Mode aus: der Aufruf wird stillschweigend erlaubt — byte-identisch zu einem Workspace, der das Feature nie aktiviert hat.

Observe-Mode ist die Lückenerkennung-Surface. Er feuert nur, wenn keine Policy aufgelöst wird. Er ist nicht dasselbe wie eine Policy, die auf Audit gesetzt ist.

​

Firewall-audit-Verdikt (Per-Policy-Default)

Wenn eine Policy tatsächlich aufgelöst wird, aber keine Regel auf einen Tool-Call matcht, gilt das default_verdict der Policy. Der Standardwert für default_verdict ist audit — den Aufruf erlauben und zur Überprüfung aufzeichnen. Eine neue Policy ohne Regeln und keine Konfigurationsänderungen blockiert nichts und erlaubt nichts stillschweigend: sie auditiert alles, was sie sieht. audit ist auch ein normales Regel-Verdikt. Eine Regel, die matcht und audit erzeugt, lässt den Aufruf durch und zeichnet ihn auf — das Guardrail-Audit-Mode- Analogon für die Firewall.

​

Guardrail-flag-Aktion (Per-Regel-Aktion)

Auf der Guardrails-Seite ist die flag-Aktion das Observe-Äquivalent: die Regel löst aus, ein Match wird im Matches-Feed aufgezeichnet, und der Request fährt unverändert fort. Kein Block. Keine Redigierung. Verwenden Sie flag, wenn Sie eine Regel messen möchten — wie oft sie auslöst und auf was — bevor Sie sich auf block oder mask festlegen.

---

Zusammen erzeugen diese drei die Observe-Haltung: Observe-Mode fängt nicht abgedeckte Tool-Calls ab; audit-Verdikte decken Tool-Calls unter einer Policy ab, aber noch nicht unter einer spezifischen Regel; flag-Aktionen decken Guardrail-Prüfungen ab, die Sie noch nicht bereit sind durchzusetzen.

​

3. Shadow-Haltung — validieren, bevor Sie durchsetzen

Shadow-Mode ist ein per-Policy-Flag (shadow_mode: true) auf einer Firewall-Policy. Wenn er an ist:

• Die Policy wertet jeden Tool-Call genau so aus, wie sie es in Produktion täte — Regeln werden gematcht, Verdikte berechnet, Argument-Prädikate getestet.
• Jedes durchsetzende Verdikt (deny, sanitize, pending_approval) wird auf audit herabgestuft, bevor es das Tool erreicht.
• Der geloggte Grund wird mit [shadow] would … vorangestellt, damit Sie im Events-Feed genau sehen können, was blockiert, bereinigt oder zurückgehalten worden wäre.

Shadow-Mode ist Ihr sicherer Rollout-Schalter. Schreiben Sie eine Policy, schalten Sie Shadow an, richten Sie echten Traffic darauf, beobachten Sie die Events- und Runs-Ansichten für einige Stunden oder Tage, bestätigen Sie, dass die Policy auf den richtigen Tools und nichts Unerwartetes auslöst, und schalten Sie dann Shadow aus, um mit der Durchsetzung zu beginnen.

​

4. Enforce-Haltung — echte Verdikte, echte Konsequenzen

In der Enforce-Haltung wird nichts herabgestuft:

• Firewall-deny → der Agent sieht einen Tool-Fehler (MCP) oder HTTP 400 firewall_blocked (Inbound-Surface). Der Fehler benennt das Tool und den Grund. Als skip-retry markiert.
• Firewall-sanitize → gematchte Teilstrings werden aus den Tool-Argumenten redigiert und der bereinigte Aufruf wird weitergeleitet.
• Firewall-pending_approval → der Aufruf wird zurückgehalten; der Agent erhält HTTP 400 firewall_approval_pending und eine Approval-ID zum Pollen.
• Guardrail-block → HTTP 400 guardrail_blocked, benennt das Guardrail und die ausgelöste Regel. Kostet kein Kontingent.
• Guardrail-mask → der Treffer wird redigiert (z. B. jane@acme.com → [EMAIL]) und der Request fährt mit dem bereinigten Text fort.

Um die Enforce-Haltung zu erreichen: schalten Sie shadow_mode auf der Firewall-Policy aus und ändern Sie Guardrail-Regelaktionen von flag auf block oder mask je nach Bedarf.

​

5. Empfohlenes Rollout

​

6. Autonomie-Level — alles auf einmal setzen

Policies Regel für Regel abzustimmen ist der präzise Weg. Autonomie-Level sind der schnelle — ein einzelner Regler, der die Firewall- und Guardrails-Haltung Ihres Workspaces atomar in einer Transaktion setzt, mit Ein-Klick-Undo: Anwenden über POST /api/workspace/firewall/autonomy (Developer+). Der Simulate-Endpunkt (GET /api/workspace/firewall/simulate?level=) zeigt eine Vorschau, was eine Level-Änderung täte, bevor Sie sie anwenden.

​

7. Mechanismus-Map — welche Einstellung was kontrolliert

Diese Tabelle ist die maßgebliche Referenz. Die vier Begriffe sind unterschiedlich — verwechseln Sie sie nicht:

---

Enforcement-Modi sind kein binäres An/Aus. Wechseln Sie durch Observe → Shadow → Enforce, und Ihre Regeln werden auf echtem Traffic verifiziert, bevor sie ihn je blockieren.