Zum Hauptinhalt springen
Ein Coding-Agent ist das hebelstärkste Ding in Ihrem Workspace und das gefährlichste. Er führt shell.exec aus, bearbeitet Dateien, holt URLs und lädt Community-Skills — jedes davon kann ein Volume rm -rfen, eine .env lesen oder zu einem Angreifer-Host exfiltrieren. Dieses Rezept grenzt diese Surface mit der Firewall ein: destruktive Shell ablehnen, die Argumente der Aufrufe validieren, die Sie doch erlauben, Egress einzäunen und die wirklich riskanten Operationen für einen Menschen zurückhalten. Nichts davon berührt den Code Ihres Agenten — die Policy lebt im Gateway und wird beim nächsten Aufruf durchgesetzt.
Alles unten wird in der Konsole konfiguriert (Firewall → Posture / Policies). Diese Management-Routen verwenden Ihre Konsolen-Session, nicht einen Relay-Schlüssel. Nur die /v1/*-Aufrufe, die Ihr Agent macht, tragen einen sk-orca-…-Schlüssel. Policy-Bearbeitungen erfordern die Rolle Developer.

​
1. Beginnen Sie mit Beobachten, nicht Blockieren — die Baseline für einen sicheren Coding-Agenten

Verfassen Sie Regeln nicht blind. Geben Sie dem Agenten seinen sk-orca-…-Schlüssel, öffnen Sie dann Firewall → Posture und wenden Sie das balanced-Autonomie-Level an. In einer Transaktion auditiert das jeden Tool-Call, flaggt PII und lehnt destruktive Shell ab — sodass die schlimmste Aktion bereits eingezäunt ist, während Sie den Rest des Agentenverhaltens aus echtem Traffic lernen. Lassen Sie ihn laufen, lesen Sie dann Firewall → Discovered tools: jedes Tool, das der Workspace gesehen hat, geflaggt als covered (eine Regel trifft zu) oder gap (keine tut es). Diese Liste ist Ihr Allowlist-Entwurf. Wenn der Feed richtig aussieht, wechseln Sie zu tight (Default-Deny) oder verfassen Sie die zielgerichtete Policy unten.
balanced ist die empfohlene Ausgangshaltung; permissive blockiert nichts, loggt aber trotzdem alles; tight ist Default-Deny plus die Secrets- und SSRF-Presets. Siehe die Baseline für genau das, was jede materialisiert.

​
2. Destruktive Shell ablehnen — der nicht verhandelbare Boden

Die einzelne wichtigste Regel für einen Coding-Agenten ist keine destruktive Shell. Die Autonomie-Level balanced und tight liefern dies bereits als das Block destructive shell-Preset, das echte, editierbare deny-Regeln materialisiert, die sowohl die workspace-direkten Tool-Namen (shell.*, bash, cmd.*, powershell.*, exec.*) als auch die MCP-namespaced Formen, die ein registrierter Server exponiert (*.shell.*, *.cmd.*, …), abdecken. Wenn Sie es enger als „alle Shell ablehnen” eingrenzen wollen, verfassen Sie eine Regel, die nur die destruktiven Befehle ablehnt und den Rest auditiert. Eine Regel matcht auf einem Tool-Namen-Glob plus einem optionalen Argument-Prädikat (JSONPath gegen die Argumente des Aufrufs):
Fügen Sie in Firewall → Policies eine Regel über Ihrem Default hinzu:
  • Tool-Glob: shell.exec
  • Args match (JSONPath-Klausel):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Verdikt: deny
Die Argument-Operatoren sind ein geschlossener Satz — eq, contains, regex, in, cidr_match, gt, lt. Ein Aufruf, dessen $.command auf das Regex matcht, wird blockiert; alles andere fällt zur nächsten Regel durch.
Ein abgelehnter Aufruf auf der inbound-Surface gibt HTTP 400 mit dem Fehlercode firewall_blocked und einer Nachricht zurück, die das Tool und den Grund benennt. Ein durch das MCP-Gateway dispatchter Aufruf kommt als Tool-Fehler (firewall deny: …) zurück, sodass das Modell reagieren kann, statt abzustürzen. Inbound-Blocks feuern vor dem Upstream-Modellaufruf, kosten also keine Modell-Tokens.
Siehe Firewall-Regeln für die vollständige Matching-Sprache (Tool-Globs, Argument-Klauseln, Sequenzen, Kosten-Caps).

​
3. Argumente auf den Tools validieren, die Sie behalten

Ein Tool zu erlauben ist nicht dasselbe wie jedes Argument dafür zu erlauben. Dasselbe JSONPath-Prädikat, das ein deny eingrenzt, lässt Sie die Form eines erlaubten Aufrufs einschränken — sodass db.query kein DROP tragen kann und file.write kein Verzeichnis verlassen kann.

Ein SQL-DROP blockieren

Glob db.query, Klausel {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, Verdikt deny.

Ein Secret in Argumenten redigieren

Verdikt sanitize redigiert gematchte Teilstrings aus den Tool-Call-Argumenten, bevor der Aufruf weitergeleitet wird. Es berührt nie, was ein Tool zurückgibt; auf der inbound-Surface (noch keine Aufruf-Argumente) eskaliert es zu einem Block.
Die Firewall bereinigt Tool-Call-Argumente, nicht Tool-Ergebnisse. Um zu verhindern, dass ein Secret überhaupt erst in einen Request gelangt, hängen Sie das Secrets Blocker-Guardrail an den Schlüssel — das prüft den Prompt-Text selbst, bevor das Modell ihn sieht. Die zwei Ebenen komponieren: Guardrails prüfen Text, die Firewall steuert die Aktion.

​
4. Egress steuern — einzäunen, wohin der Agent reichen kann

Ein Coding-Agent, der URLs holen kann, kann in SSRF gesteuert werden (Treffen von Cloud-Metadata oder einem internen 10.x-Host) oder zur Exfiltration genutzt werden. Das tight-Autonomie-Level liefert ein SSRF-Preset, das fetch-förmige Tool-Namen (http_fetch, web_search, fetch_url, request und ihre <server>.*-Formen) ganz ablehnt. Für Kontrolle auf Zielebene verfassen Sie eine egress-Regel. Egress-Regeln grenzen nach Host oder CIDR mit allow- / deny-Einträgen ein, ausgewertet auf der egress-Surface: 
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
Das feuert auf jedem ausgehenden Ziel, das von einem Tool gemeldet wird und auf einer privaten Range, der Cloud-Metadata-IP oder einem internen Hostnamen landet — und lässt öffentliche Ziele durch, während es die gefährlichen einzäunt.
Kein Preset liefert CIDR-basierte Egress-Regeln — das SSRF-Preset matcht fetch-förmige Tool-Namen. Die Host-/CIDR-Denylist oben ist eine, die Sie selbst verfassen. Siehe Exfiltration stoppen für das vollständige Muster.

​
5. Riskante Operationen für einen Menschen zurückhalten (HITL)

Manche Operationen sollten nicht auto-erlaubt oder auto-abgelehnt werden — ein Deploy, ein git push, eine destruktive Migration. Verwenden Sie dafür das pending_approval-Verdikt. Der Aufruf wird zurückgehalten, der Agent erhält eine „held”-Antwort mit einer Approval-ID, und ein Prüfer löst sie out-of-band auf:
  1. Verfassen Sie eine Regel (z. B. Glob deploy.*, Verdikt pending_approval).
  2. Der zurückgehaltene Aufruf gibt HTTP 400 firewall_approval_pending mit einer Approval-ID zurück.
  3. Ein Prüfer genehmigt sie aus der Konsole (Developer+) oder über einen HMAC-signierten Webhook-Callback.
  4. Der Agent pollt die Approval und reicht dann den ursprünglichen Aufruf mit einem einmal nutzbaren X-OrcaRouter-Firewall-Approval-Header erneut ein — und das Gateway lässt ihn dieses eine Mal durch.
Rollen Sie jede neue Policy zuerst im Shadow-Mode aus. Die Policy wertet aus und loggt genau so, wie sie es in Produktion täte, aber jedes durchsetzende Verdikt wird auf audit herabgestuft mit einem [shadow] would …-Grund — sodass Sie beweisen können, dass sie auf das feuert, was Sie erwarten, bevor sie einen Build brechen kann.

​
6. Die Skills und MCP-Server steuern, die er lädt

Coding-Agenten ziehen Fähigkeiten zur Laufzeit herein — Community-Skills, BYO MCP-Server. Die Firewall steuert beide am Gateway:
  • Skills werden in ein Risikoband mit einem Enforcement-Mode (allow / quarantine / block) gescannt. Ein auto-erkannter Skill wird quarantäniert — zur Freigabe zurückgehalten — bis ein Prüfer ihn freigibt. Siehe Skills.
  • MCP-Server, die Sie registrieren, dispatchen jeden tools/call durch das Gateway, das jeden auf der mcp-Surface vor dem Dispatch auswertet. Credentials werden verschlüsselt gespeichert; ein Health-Probe meldet ok / degraded / down. Siehe MCP-Server und Einen MCP-Agenten härten.

​
7. Verifizieren und beobachten

Bevor Sie sich auf eine Policy verlassen, dry-runnen Sie sie. Der Test-Tab wertet einen Beispiel-Tool-Call gegen die aktuelle Policy aus und zeigt das Verdikt, die gematchte Regel und den Grund — nichts wird dispatcht, nichts persistiert. Einmal live, ist Firewall → Events / Runs der Datensatz jeder Auswertung, filterbar nach Verdikt, Surface, Tool und Run, und der Anomalie-Feed flaggt Raten-/Kosten-Spikes gegen die gelernte Baseline des Workspaces, retry_loop und nie zuvor gesehene Tool-Pfade.

​
Rückblick

Firewall-Referenz

Die vollständige Policy-Ebene — Surfaces, Verdikte, Auflösung, Autonomie.

Firewall-Regeln

Die Matching-Sprache: Globs, Argument-Klauseln, Egress, Sequenzen.

Gefährliche Tool-Calls

Die Bedrohung, gegen die sich dieses Rezept verteidigt.

Übermäßige Handlungsmacht

Warum überberechtigte Agenten das Kern-Agentenrisiko sind.

Rezept: autonomer Agent

Eine vollständig autonome Agentenschleife Ende zu Ende eingrenzen.

Exfiltration stoppen

Die Egress- und Lethal-Trifecta-Muster im Detail.