Zum Hauptinhalt springen
Sie haben eine Policy, die Sie vor die Produktion setzen wollen. Die Angst ist nicht die Policy — sie ist, sie einzuschalten und zu entdecken, dass sie ein Tool blockiert, das Ihr Agent tatsächlich braucht, oder ein Feld maskiert, von dem Ihre App abhängt. Der Fix ist nicht mehr Testen in einer Sandbox; er ist das Ausrollen gegen echten Traffic in einer Haltung, die nichts brechen kann, und dann das Verschärfen erst, nachdem Sie gesehen haben, was feuert. Dieses Rezept ist diese Ausrollung: observe → shadow → enforce, mit Autonomie balanced vor tight. Sie bleiben den ganzen Weg in der Konsole (oder der REST-API); der Agent ruft weiterhin https://api.orcarouter.ai/v1/... exakt wie zuvor auf.
Neu beim Modell? Lesen Sie Enforcement-Modi dafür, was jede Haltung mechanisch tut, und die Secure-Agents-Baseline dafür, was jedes Autonomie-Level setzt. Diese Seite ist die Sequenz — die Reihenfolge, in der Sie die Schalter umlegen.

​
1. Die KI-Sicherheits-Ausrollung in drei Schritten

Die ganze Ausrollung tauscht Autonomie gegen Sicherheit in drei Schritten, jeder gegen Live-Traffic verifiziert, bevor der nächste folgt:

Observe

Alles erlauben, alles loggen. Nicht abgedeckte Tool-Calls landen in Discovered Tools; Guardrail-flag-Regeln zeichnen Matches auf, ohne den Traffic zu ändern. Sie lernen die echte Form Ihres Agenten.

Shadow

Eine echte Policy wertet jeden Aufruf aus, aber jedes durchsetzende Verdikt wird auf audit herabgestuft und [shadow] would … geloggt. Sie sehen genau, was blockieren würde — mit nichts tatsächlich blockiert.

Enforce

Shadow aus. deny blockiert, mask redigiert, pending_approval hält zurück. Die Autonomie geht von weit (balanced) zu eng (tight), und Ihr Agent ist gesteuert.
Die Disziplin ist der Sinn: Sie setzen nie eine Regel durch, die Sie nicht zuerst im Shadow gegen Ihren eigenen Traffic haben feuern sehen.

​
2. Schritt eins — observe (Autonomie = permissive)

Starten Sie so weit, wie es geht. Wenden Sie das permissive-Autonomie-Level aus Firewall → Posture an (Developer+) — oder POST /api/workspace/firewall/autonomy. Es aktiviert den Workspace-Observe-Mode und lässt keine durchsetzende Policy, sodass jeder Aufruf erlaubt ist und jeder nicht abgedeckte Aufruf als Abdeckungs-Lücke geloggt wird. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
Die /api/workspace/firewall/*-Routen laufen auf Ihrer Konsolen-Session / Ihrem Access-Token, nicht auf einem sk-orca-...-Relay-Schlüssel. Ein Autonomie-Level anzuwenden ist ein Workspace-Schreibvorgang — Developer+. Nur /v1/*-Modellaufrufe verwenden den Relay-Schlüssel.
Richten Sie nun echten Traffic darauf und lassen Sie es laufen. Beobachten Sie zwei Feeds:
  • Firewall → Discovered Tools (Member) — jedes Tool, das Ihr Agent aufruft, geflaggt als covered oder gap. Das ist der Input für Ihre Regeln: Sie sind dabei, Policy für Traffic zu schreiben, der tatsächlich passiert, nicht für Hypothetisches.
  • Guardrails → Matches (Member) — wenn Sie flag-Aktions-Regeln hinzugefügt haben, jeder Match, den sie aufzeichnen, ohne den Request zu berühren.
Lassen Sie es laufen, bis Discovered Tools keine neuen Tools mehr offenlegt. Diese stabile Liste ist Ihre Regel-Verfassungs-Spezifikation.

​
3. Schritt zwei — shadow (eine echte Policy, null Blockieren)

Verfassen Sie nun die Policy, die Sie tatsächlich wollen — Tool-Globs, Argument-Klauseln, Egress-Listen, eine cap_cost-Obergrenze — und schalten Sie shadow_mode ein, bevor Sie sie anhängen. (Bauen Sie Regeln aus Firewall-Regeln; das vollständige Policy-Modell steht in der Firewall-Referenz.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
Mit shadow_mode: true werden dieses deny und dieses cap_cost beide zur Auswertungszeit auf audit herabgestuft — die Engine berechnet das echte Verdikt, loggt es vorangestellt mit [shadow] would … und lässt den Aufruf durch. Hängen Sie die Policy an die Schlüssel an, die Sie ausrollen (setzen Sie firewall_policy_id auf dem Schlüssel), oder machen Sie sie zum Workspace-Default. Lesen Sie dann Firewall → Events / Runs (Developer+) gefiltert auf das [shadow]-Präfix und bestätigen Sie beide Seiten:
Jeder shell.exec-Aufruf zeigt [shadow] would deny. Jeder Run, der Ihre Obergrenze überschreitet, zeigt [shadow] would cap_cost. Die Policy sieht den Traffic, für den Sie sie gebaut haben.
Kein legitimes Tool taucht mit einem Would-block-Verdikt auf. Das ist die False-Positive-Prüfung — der Grund, warum Shadow existiert. Wenn ein Tool, das Sie brauchen, geflaggt ist, fixen Sie die Regel und beobachten Sie erneut, bevor Sie je durchsetzen.
Guardrails haben keinen Shadow auf Policy-Ebene. Das Äquivalent ist die Pro-Regel-flag-Aktion: Sie zeichnet einen Match im Matches-Feed auf und ändert nichts, sodass Sie eine Content-Regel messen können, bevor Sie sie auf block oder mask umstellen. Führen Sie Ihre Guardrail-Regeln in diesem selben Schritt als flag aus.

​
4. Schritt drei — enforce (Autonomie balanced, dann tight)

Wenn das Shadow-Log richtig aussieht, setzen Sie in zwei Stufen durch, nicht in einer. Springen Sie nicht direkt zu Default-Deny. Zuerst balanced. Das ist die empfohlene erste durchsetzende Haltung: Das Firewall-Default-Verdikt ist audit, aber die destruktivsten Aktionen (wie destruktive Shell) werden abgelehnt, und das PII-Shield-Guardrail läuft audit-only — es flaggt PII, ohne sie noch zu maskieren. Sie blockieren nun das Schlimmste, während Sie den Rest noch beobachten. Schalten Sie im selben Schritt shadow_mode aus auf Ihrer eigenen Policy, sodass ihre deny- / cap_cost-Verdikte neben der Baseline live gehen. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Beobachten Sie Events eine Stunde lang. Echte Blocks erscheinen nun ohne das [shadow]-Präfix. Ein abgelehnter Tool-Call gibt HTTP 400 firewall_blocked zurück; er ist skip-retry und kostet keine Modell-Tokens. Dann tight. Sobald balanced ruhig ist, gehen Sie zu Default-Deny. Das tight-Level lehnt per Default ab, lehnt destruktive Shell und SSRF-Egress ab und setzt PII Shield + Secrets Blocker durch — PII wird auf dem Request maskiert, bevor das Modell ihn sieht, und Secrets in Ihren Requests werden blockiert. Ein blockierter Prompt gibt HTTP 400 guardrail_blocked zurück, kostet kein Kontingent und ist skip-retry.
StufeFirewall (Aktionen)Guardrails (Text)Was Sie beweisen
permissiveObserve; nichts blockiertnur flagEchte Traffic-Form
balancedDefault audit; destruktive Shell abgelehntPII geflaggtWorst Case ist gestoppt
tightDefault-Deny; Shell + fetch-förmige Tools (SSRF) abgelehntPII maskiert, Secrets blockiertVolles Zero Trust
Streaming-Vorbehalt für PII. Unter tight maskiert PII Shield PII auf dem Request, bevor das Modell ihn sieht — das ist live. Output-seitiges Masking einer Streaming-Antwort ist noch nicht live; ein Output-block wird auf Streaming durchgesetzt (der Scanner kappt den Stream). Wenn Sie auf das Redigieren von Modell-Output angewiesen sind, verifizieren Sie Ihre Stage-/Stream-Kombination zuerst im Guardrail-Test-Tab. Siehe Guardrails.

​
5. Die Notluke — Ein-Klick-Undo

Jede Autonomie-Änderung ist eine einzelne Transaktion, die Ihre vorherige Haltung snapshottet, sodass Sie direkt aus Firewall → Posture zurückrollen können (oder POST /api/workspace/firewall/autonomy/undo/:audit_id). Sie können auch einfach ein weicheres Level erneut anwenden — tight zurück auf balanced, oder balanced zurück auf permissive — jederzeit.
Undo stellt aus dem Audit-Snapshot des jüngsten Apply wieder her. Wenn Sie seit dem Apply, das Sie rückgängig machen, manuelle Policy-Bearbeitungen vorgenommen haben, ist dieser Snapshot nicht mehr der jüngste ungenutzte, und Undo verweigert sich, statt diese Bearbeitungen still wegzurollen. Wenn das passiert, wenden Sie stattdessen ein weicheres Level erneut an — es ist immer verfügbar.

​
6. Woher die Verdikte jedes Schritts kommen

Die Ausrollung blockiert nie etwas, worum Sie nicht gebeten haben, weil jede Haltung auf einen expliziten, beobachtbaren Mechanismus abbildet:
HaltungMechanismusErgebnis
ObserveWorkspace firewall_observe_mode an + Guardrail flagErlauben + Lücken / Matches loggen
ShadowPro-Policy shadow_modeEchtes Verdikt berechnet, auf audit herabgestuft, [shadow] would … geloggt
Enforceshadow_mode aus + tight/balanced-Autonomiedeny / mask / cap_cost gehen live
Die vier Begriffe — Observe-Mode, das audit-Verdikt, die flag-Aktion und shadow_mode — sind distinkte Schalter, Seite an Seite dokumentiert in Enforcement-Modi.

​
7. Nächste Schritte

Enforcement-Modi

Die Mechanismus-Karte hinter Observe, Shadow und Enforce.

Secure-Agents-Baseline

Was jedes Autonomie-Level setzt und wie man es zuerst simuliert.

Einen autonomen Agenten zähmen

Der nächste Schritt, sobald Sie durchgesetzt haben: Kosten-Caps, Anomalieerkennung und Freigaben.

Agent-Firewall

Policies, Regeln, Verdikte, Shadow-Mode und das MCP-Gateway in Gänze.
Ein Go-live, dem Sie vertrauen können, ist eine Ausrollung, kein Schalter. Beobachten Sie, was Ihr Agent tut, shadowen Sie die Policy gegen seinen echten Traffic, dann setzen Sie durch — balanced vor tight — und jede Regel ist auf der Produktion verifiziert, bevor sie sie je blockiert.