Zum Hauptinhalt springen
Ein Agent, der das Netzwerk erreichen kann, kann in eine Daten-Pipeline verwandelt werden. Ein Angreifer platziert Anweisungen in einem Dokument, das der Agent liest — eine Webseite, ein abgerufenes Chunk, ein Tool-Ergebnis — und diese Anweisungen lenken den Agenten dazu, sensible Daten an einen angreiferkontrollierten Host zu POSTen, oder interne Dienste zu erkunden (SSRF). Der Agent „entscheidet” sich nie zur Exfiltration; er führt aus, was für ihn wie eine legitime Anweisung aussieht. Diese Seite beschreibt, wie der Agent-Firewall- und Guardrails-Stack in OrcaRouter Ihnen ermöglicht, sich gegen KI-Datenexfiltration zu verteidigen — ohne Ihren Agenten-Code zu ändern.
Die Firewall sieht Egress nur für Ziele, die über das Gateway geroutet werden via den MCP-Dispatch-Pfad oder den Evaluate-Hook. Ein Tool, das Ihr Agent vollständig innerhalb seines eigenen Prozesses ausführt, liegt außerhalb seiner Sicht. Routen Sie die netzwerkgebundenen Tool-Calls Ihres Agenten durch das Gateway, und sie werden gesteuert.

​
1. Wie der Angriff funktioniert

Der kanonische Pfad durch einen Agenten läuft in drei Schritten:
  1. Injection — der Agent liest nicht vertrauenswürdige Inhalte mit eingebetteten Anweisungen (eine Webseite, ein abgerufenes Dokument, eine CRM-Notiz).
  2. Sammlung — die injizierten Anweisungen sagen dem Agenten, sensibles Material zu sammeln — API-Keys, Datenbankzeilen, Benutzer-PII — mit Tools, die er bereits besitzt.
  3. Exfiltration — dem Agenten wird gesagt, dieses Material über ein fetch-förmiges Tool zu senden: http_fetch, web_search, fetch_url oder request. Das Ziel ist angreiferkontrolliert.
SSRF hat dieselbe Form, nach innen umgeleitet: anstatt eines externen Hosts wird der Agent auf 169.254.169.254 (Cloud-Metadaten), einen internen Redis-Port oder einen anderen privaten Dienst gelenkt. Siehe Prompt-Injection für den Injektionsschritt; diese Seite konzentriert sich auf den Netzwerkschritt.

​
2. Egress-Allowlist — ausgehende Ziele sperren

Die dauerhafteste Verteidigung ist eine Egress-Allowlist: zählen Sie die Hosts auf, die Ihre Agenten legitim erreichen dürfen, und verweigern alles andere. Eine Egress-Regel verwendet stage: egress und das egress-Feld. Das Verdikt steuert die Polarität — allow lässt gelistete Ziele durch; ein niederprioritäter deny-Catch-All blockiert den Rest: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Einträge matchen als CIDR, IP-Literal oder case-insensitiver Hostname. Hostnamen werden best-effort aufgelöst und gegen IP/CIDR-Einträge gegengeprüft, sodass ein Ziel wie 169.254.169.254, das von DNS zurückgegeben wird, trotzdem von einem 10.0.0.0/8-CIDR-Deny-Eintrag abgefangen wird. Ein blockierter Aufruf gibt HTTP 400 mit dem Fehlercode firewall_blocked zurück. Um bekannte böse Bereiche ohne explizite Allowlist zu verweigern, schreiben Sie eine gezielte Egress-Deny-Regel, die den Cloud-Metadaten-Endpunkt (169.254.169.254) und die RFC-1918-Privatbereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) auflistet. Schichten Sie Ihre Allowlist obendrauf bei einer niedrigeren Prioritätsnummer, sodass die Deny-Regeln zuerst ausgewertet werden.

​
3. Fetch-förmige Tools auf der Namensebene blockieren

Bevor ein Egress-Ziel überhaupt ausgewertet wird, können Sie die Fähigkeit vollständig entfernen. Das tight-Autonomie-Level verweigert http_fetch, web_search, fetch_url und request durch Tool-Name-Glob als SSRF- und Exfiltrations-Backstop. Wenn Ihr Agent keines dieser Tools benötigt, entfernt tight die Angriffsfläche in einem Schritt: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Um fetch-Tools ohne Übernahme der vollständigen tight-Haltung zu verweigern, schreiben Sie eine inbound-Surface-Deny-Regel. inbound blockiert das Tool bevor das Modell es wählen kann — der Agent empfängt die Fähigkeit nie in seiner Tool-Liste: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Wiederholen Sie für jeden fetch-förmigen Tool-Namen, den Ihr Agenten-Stack verwendet.

​
4. Secrets-Blocker-Guardrail — Credentials auf dem Prompt stoppen

Das Secrets-Blocker-Guardrail läuft auf der Input-Stage und scannt den Prompt auf AWS-ähnliche Access-Keys, OpenAI-Keys, Anthropic-Keys, GitHub-Tokens und ähnliche Credential-Muster, bevor der Request das Gateway verlässt. Wenn ein Secret erkannt wird, wird der Request blockiert — die Credential erreicht nie ein Modell und erscheint nie in einem Tool-Call. Aktivieren Sie es vom Guardrails-Panel, oder als Teil des tight-Autonomie- Levels. Es ist unabhängig von den Firewall-Egress-Regeln.
BedrohungEbene, die sie stoppt
Prompt trägt einen API-KeySecrets-Blocker (Input-Guardrail)
Agent ruft ein fetch-Tool auf ein Angreifer-Host aufEgress-Allow/Deny-Regel
Fetch-förmiges Tool dem Modell angebotenInbound-Deny-Regel oder tight-Autonomie
Agent erreicht Cloud-Metadaten oder RFC-1918Egress-Deny-Regel, die diese CIDRs auflistet

​
5. Mit Shadow-Mode ausrollen

Wenn Sie nicht sicher sind, welche Hosts Ihr Agent heute legitim erreicht, starten Sie im Shadow-Mode, bevor Sie durchsetzen:
  1. Erstellen Sie die Egress-Regeln mit Ihrer beabsichtigten Allowlist und setzen Sie shadow_mode: true auf der Policy.
  2. Beobachten Sie den Events-Feed — Aufrufe, die blockiert worden wären, erscheinen als [shadow] would deny mit dem Ziel.
  3. Passen Sie die allow-Liste an, bis nur angreifererreichbare Ziele verweigert würden, dann deaktivieren Sie Shadow-Mode, um mit der Durchsetzung zu beginnen.
Kein Traffic wird blockiert, während Shadow-Mode an ist.

​
6. Weiterführende Themen

Firewall-Regeln-Referenz

Vollständige Matching-Sprache — Egress-Listen, CIDRs, Argument-Klauseln und alle Verdikte.

Agent-Firewall-Übersicht

Policies, Surfaces, Autonomie-Level und Observability.

Prompt-Injection

Der Injektionsschritt, der Agenten zur Exfiltration lenkt.

MCP-Tool-Poisoning

Bösartige MCP-Tools, die fetch-förmige Fähigkeiten registrieren.