Zum Hauptinhalt springen
Die meisten Teams greifen zu spät und eine Ebene nach der anderen zur Agenten-Sicherheit — hier ein Regex auf Prompts, dort eine Tool-Deny-Liste. Das Ergebnis ist eine Haltung mit Löchern: Text-Screening, das nie ein shell.exec sieht, oder eine Tool-Firewall, die nie eine Kreditkartennummer bemerkt, die in einem Prompt hinausgeht. Der schnellste Weg zu einer vollständigen Agenten-Sicherheits-Baseline ist, beide Ebenen auf einmal zu setzen. Die Autonomie-Kontrolle von OrcaRouter — die Secure-Agents-Baseline — tut genau das: ein einziger Schalter auf Workspace-Ebene, der eine Firewall-Policy und ein Guardrail zusammen schreibt, in einer Transaktion, mit Ein-Klick-Undo. Sie verfassen keine Regel, um geschützt zu sein; Sie wählen eine Stufe und tunen später.
Die beiden Ebenen sind komplementär, nicht redundant. Guardrails screenen den Prompt-/Response-Text (PII, Secrets, Jailbreak- und Injection-Intent); die Firewall steuert die Aktionen, die ein Agent vornimmt (welche Tools, MCP-Aufrufe und Hosts). Eine allein lässt eine Lücke, die die andere schließt — siehe Guardrails vs. Firewall.

​
1. Warum eine Baseline zwei Halbmaßnahmen schlägt

Ein echter Agentenlauf überquert beide Ebenen in einem einzelnen Request. Das Modell liest einen Prompt (Text), entscheidet, db.query aufzurufen (Aktion), und das Ergebnis des Tools fließt in den nächsten Zug zurück (wieder Text). Nur eine Ebene abzusichern lässt die andere ungeschützt:

Nur Firewall

Sie verweigern destruktive Shell, aber ein Prompt trägt immer noch die SSN eines Kunden direkt zum Modell — und ein Tool-Argument leakt immer noch einen API-Key.

Nur Guardrails

Sie maskieren PII in Prompts, aber der Agent ruft immer noch rm -rf auf, erreicht einen Cloud-Metadata-Endpunkt oder loopt auf einem außer Kontrolle geratenen Tool.
Die Autonomie-Kontrolle nimmt die Wahl weg. Eine Stufe setzt eine kohärente Haltung über beide Ebenen, sodass es kein Fenster gibt, in dem eine konfiguriert ist und die andere nicht.

​
2. Die Agenten-Sicherheits-Baseline: drei Stufen

Jede Stufe deckt dieselben zwei Ebenen ab. Wählen Sie eine; sie ist Ihr Boden, und Sie fügen später Präzision mit Regeln hinzu.
StufeFirewallGuardrailsObserve-Mode
tightDefault-Deny; destruktive Shell + fetch-förmige Tools verweigertPII Shield + Secrets Blocker durchgesetztAus
balancedDefault-Audit; destruktive Shell verweigertPII Shield audit-only (flaggt PII)Aus
permissiveKeine durchsetzende PolicyKeineAn — loggt jeden Aufruf als Lücke
Ein paar Spezifika, die festzunageln sich lohnt, da sie prägen, was jede Stufe tatsächlich abfängt:
tight stempelt das Default-Verdikt der Firewall-Policy auf deny, schichtet dann Deny-Regeln für die Shell-/Exec-Tool-Namen, die destruktive Befehle tragen — shell.*, bash, cmd, powershell, exec — und für die fetch-förmigen Tool-Namen, die SSRF tragen — http_fetch, web_search, fetch_url, request (und ihre <server>.*-MCP-namespaced Varianten). Es verweigert diese Tool-Namen; es liefert keine CIDR- oder Cloud-Metadata-Egress-Regel. Wenn Sie 169.254.169.254 oder RFC-1918-Bereiche per Ziel verweigern wollen, verfassen Sie Ihre eigene Egress-Regel — siehe Egress-Kontrolle.
Sowohl das PII Shield- als auch das Secrets Blocker-Guardrail sind aktiv und durchsetzend. PII Shield maskiert PII auf dem Request, bevor er das Modell erreicht; Secrets Blocker fängt Credentials im Request ab. Secrets in Tool-Argumenten werden von diesem Guardrail auf dem Request abgefangen — die Firewall strippt sie nicht standardmäßig.
balanced auditiert alles (Default-Verdikt audit), sodass Sie das echte Verhalten Ihres Agenten sehen, während es dennoch die einzelne destruktivste Klasse verweigert — destruktive Shell. PII Shield läuft im audit-only-Modus (flaggt PII, blockiert nicht). Sie bekommen eine volle Spur mit fast keinem Risiko eines unerwarteten Blocks, dann verschärfen Sie aus Sichtbarkeit statt aus Raterei.
permissive setzt nichts durch — es existiert, um einen brandneuen Agenten mit null Risiko versehentlicher Blocks zu beobachten. Der Observe-Mode bleibt an, sodass jeder Tool-Call weiterhin als Abdeckungslücke geloggt wird (sichtbar in Discovered Tools). Verwenden Sie es, um die Form eines Agenten zu lernen, dann wechseln Sie zu balanced oder tight.

​
3. Ein konkretes Beispiel: balanced anwenden, beide Feeds beobachten

Eine Stufe anzuwenden ist eine einzelne Konsolen-Aktion (Firewall → Posture) oder ein API-Aufruf. Die Route läuft unter Ihrer Session und erfordert Developer+. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
Die Antwort trägt eine audit_id — behalten Sie sie; sie ist es, was Sie zum Undo übergeben. Einmal angewendet, ist die Baseline beim nächsten Tool-Call aktiv. Kein Redeploy, keine Änderung im Agenten-Code. Nun beobachten Sie beide Ebenen auf einmal:
  • Firewall → Events — jedes Tool-Call-Verdikt (audit, die verweigerten destruktiven-Shell-Aufrufe). Siehe Events-Log.
  • Guardrails → Matches — jeder Content-Policy-Treffer (PII-Shield-Flags).
Weil balanced eine echte, editierbare Firewall-Policy und ein echtes Guardrail schreibt (jedes nach der Stufe benannt), können Sie danach beides öffnen und tunen — die Baseline ist ein Ausgangspunkt, kein gesperrtes Preset.
Vorschau, bevor Sie sich festlegen. GET /api/workspace/firewall/simulate?level=tight (Member, read-only) zeigt genau, was tight gegen Ihren aktuellen Zustand ändern würde — nichts wird angewendet. Führen Sie es nach ein, zwei Tagen auf balanced aus, um zu bestätigen, dass tight keine Aufrufe verweigert, die Teil Ihres normalen Traffics sind.

​
4. Undo ist ein Aufruf

Jede Autonomie-Änderung ist aus ihrem Audit-Snapshot reversibel und stellt den exakten vorherigen Zustand wieder her — Policies, Regeln, Guardrails und Einstellungen — kein generischer Reset. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Für einen sehr großen Workspace, dessen Snapshot die Audit-Log-Größenbegrenzung überschreitet, gelingt das Anwenden trotzdem, aber Ein-Klick-Undo ist nicht verfügbar für diese Änderung — Sie wenden stattdessen die gewünschte Stufe erneut an. Das ist selten, aber wert zu wissen, bevor Sie einen geschäftigen Produktions-Workspace verschärfen.

​
5. Der empfohlene Pfad

Breit starten, beobachten, dann aus einer Position der Sichtbarkeit verschärfen:
1

balanced anwenden

Volle Audit-Spur; nur destruktive Shell wird verweigert; PII wird geflaggt. Lassen Sie Ihre Agenten ein, zwei Tage normal laufen.
2

tight simulieren

GET /api/workspace/firewall/simulate?level=tight und vergleichen Sie seine Denies gegen das, was der Events-Feed tatsächlich zeigte. Wenn fetch-förmige oder destruktive-Shell-Aufrufe Teil Ihres normalen Flows sind, fixen Sie zuerst den Agenten.
3

tight anwenden

Sobald Simulate keine Überraschungen birgt, wechseln Sie zu tight. Undo ist einen Aufruf entfernt, falls Produktion bricht.
4

Mit Regeln tunen

Die Baseline ist Ihr Boden. Schnitzen Sie Ausnahmen oder fügen Sie Kontrollen hinzu, die sie nicht abdeckt, mit Firewall-Regeln und benannten Guardrails. Hängen Sie eine spezifische Policy oder ein Guardrail an einen einzelnen Key für feineren Scope.

​
6. Rollen für die kombinierte Baseline

Die Autonomie-Kontrolle spannt sich über beide Ebenen, aber jede Aktion ist rollengesteuert.
AktionMindestrolle
Eine Stufe simulieren / Guardrail-Matches ansehen / Discovered Tools ansehenMember
Firewall-Events & -Runs ansehenDeveloper+
Eine Autonomie-Stufe anwendenDeveloper+
Eine Autonomie-Änderung rückgängig machenDeveloper+
Die gesamte Konfiguration läuft in der Konsole unter Ihrer Session (/api/workspace/firewall/* und /api/guardrail/*). Nur /v1/*-Relay-Aufrufe nutzen einen sk-orca-…-Key; die Gateway-Key-Routen sind ein separater Scope. Siehe Scope: Keys, Policies, Workspaces.

​
7. Nach der Baseline: wo jede Ebene zu tunen ist

Die Baseline bringt Sie in den ersten 30 Minuten zum Schutz. Von dort aus hat jede Ebene ihre eigene Referenz für Präzisionsarbeit:

Firewall-Überblick

Verdikte, Surfaces, Argument-Prädikate, Approvals — die Aktionsebene.

Guardrails

Keyword-, Regex-, PII-, llm_judge- und Grounding-Regeln — die Inhaltsebene.

Shadow-Mode

Rollen Sie eine verschärfte Firewall-Policy in audit-only aus, bevor Sie durchsetzen.

Secure-Agents-Baseline

Die Konzeptseite für die Autonomie-Kontrolle und ihre Undo-Semantik.
Die Baseline ist der Boden, der beide Ebenen auf einmal schließt; Regeln sind, wie Sie die Decke anheben. Siehe KI-Agenten absichern und den Control-Stack dafür, wie die Ebenen sich komponieren, und Übermäßige Handlungsmacht für die Bedrohung, die diese Baseline am direktesten beantwortet.