Zum Hauptinhalt springen
Ein Agent, der das Netzwerk erreichen kann, kann in eine Datenleitung verwandelt werden. Injizierte Anweisungen sagen ihm, Secrets, Zeilen oder PII mit den Tools zu sammeln, die er bereits besitzt, und sie an einen Angreifer-Host zu POSTen — oder interne Dienste zu proben (SSRF). Der Agent „entscheidet” nie, zu exfiltrieren; er führt aus, was für ihn wie eine legitime Anweisung aussieht. Dieses Rezept verdrahtet drei Kontrollen, die den Kreis Ende-zu-Ende schließen — eine Egress-Allowlist, die eingrenzt, wohin ausgehende Aufrufe gehen können, das Secrets-Blocker-Guardrail, das Credentials stoppt, bevor sie je ein Modell erreichen, und einen Argument-Sanitizer, der Secrets aus den Tool-Calls streicht, die ein Modell doch ausgibt. Alles davon lebt im Gateway, sodass Sie es einmal in der Konsole konfigurieren, mit null Änderung an Ihrem Agenten-Code. Für die vollständige Angriffsanatomie lesen Sie Datenexfiltration über das Netzwerk; diese Seite sind die Aufbauschritte.
Alles hier bindet an Ihren Workspace und wird aus der Konsole konfiguriert. Ihr Agent ruft weiterhin https://api.orcarouter.ai/v1/... mit demselben sk-orca-...-Schlüssel auf — nur die Policy im Gateway ändert sich. Konfigurationsaktionen benötigen die pro Schritt genannten Rollen; Relay-Aufrufe verwenden den eingegrenzten Schlüssel. Die Firewall sieht Egress nur für Ziele, die durch das Gateway geroutet werden (den MCP-Dispatch-Pfad oder den Evaluate-Hook) — routen Sie Ihre netzwerkgebundenen Tool-Calls durch es, und sie werden gesteuert.

​
1. Die drei Ebenen, die KI-Datenexfiltration verhindern

Jede Ebene fängt den Angriff an einem anderen Punkt im Request-Lebenszyklus ab. Stapeln Sie alle drei — sie sind unabhängig und komplementär.

Credentials im Prompt

Ein Secret, das in den Request eingefügt (oder hineingezogen) wird, wird auf der Input-Stage vom Secrets-Blocker-Guardrail gefangen — bevor irgendein Modell es sieht.

Secrets in Tool-Args

Ein Modell, das einen Tool-Call ausgibt, der ein Credential trägt, wird von einer sanitize-Firewall-Regel gesäubert, die das gematchte Argument redigiert.

Ausgehendes Ziel

Der eigentliche Netzwerkschritt wird durch eine Egress-Allowlist begrenzt — nur aufgezählte Hosts passieren; alles andere wird abgelehnt.
Dieses Rezept verwendet beide Ebenen: Guardrails für den Text im Request, die Firewall für die Aktionen und das Netzwerk. Siehe Guardrails vs. Firewall für die Stelle, an der die Linie sitzt.

​
2. Credentials am Prompt stoppen — das Secrets-Blocker-Guardrail

Das Erste, was einzugrenzen ist, ist das Credential selbst. Das Secrets & API-Key Blocker-Guardrail läuft auf der Input-Stage und scannt den Request nach Credential-Mustern — Access-Keys im AWS-Stil, OpenAI-Keys, JWTs und ähnliche Tokens — bevor der Request das Gateway verlässt. Bei einem Treffer wird der Request blockiert: Das Credential erreicht nie ein Modell und landet nie in einem Tool-Call. Öffnen Sie in der Konsole Guardrails → Neues Guardrail (die Rolle Developer; Lesungen und die Test-Sandbox sind für jedes Mitglied offen), benennen Sie es exfil-shield und wenden Sie das Secrets & API-Key Blocker-Preset aus der Vorlagenbibliothek an (Kategorie secrets). Das Preset sät drei input-Stage-Regex-Block-Regeln, eine pro Credential-Form — AWS-Access-Keys, OpenAI-Stil-Keys und GitHub-Tokens: 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
Um die Abdeckung zu erweitern, fügen Sie eine pii-Regel auf den eingebauten Entitäten hinzu — der Detektor-Satz deckt email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt und bitcoin_address ab. Wählen Sie mask (auf einen typisierten Tag wie [EMAIL] redigieren) oder block pro Entität über entity_actions. Input-Stage-Masking ist live; es schreibt den Request um, bevor das Modell ihn sieht.
Ein blockierter Request gibt HTTP 400 guardrail_blocked zurück, kostet kein Kontingent (ein Input-Stage-Block feuert vor dem Metering) und ist als skip-retry markiert. Beweisen Sie es im Test-Tab — fügen Sie einen Beispiel-AWS-Key ein, wählen Sie die input-Stage und bestätigen Sie das Verdikt — bevor Sie einen Schlüssel anhängen.

​
3. Secrets aus Tool-Call-Argumenten bereinigen

Ein Guardrail prüft den Prompt; es sieht nicht die Tool-Calls, die ein Modell ausgibt. Wenn das Modell einen tool_call produziert, dessen Argumente ein Credential tragen, fängt eine Firewall-sanitize-Regel ihn. Sanitize redigiert die gematchten Teilstrings aus den Tool-Call-Argumenten und leitet den gesäuberten Aufruf weiter — das Tool läuft, aber mit herausgestrichenem Secret. Benennen Sie in Firewall → Policies → Neue Policy (Rolle Developer) sie exfil-firewall und fügen Sie eine sanitize-Regel auf der response-Surface hinzu — die tool_calls, die das Modell in seiner Antwort ausgibt: 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize redigiert nur Tool-Call-Argumente — niemals den Inhalt, den ein Tool zurückgibt. Es ist eine Verteidigung auf der ausgehenden Aufruf-Form, nicht auf eingehenden Tool-Ergebnissen. Auf der inbound-Surface (wo es noch keine Aufruf-Argumente gibt) eskaliert ein sanitize-Verdikt zu einem deny. Siehe die vollständige Matching-Sprache in Firewall-Regeln.

​
4. Ausgehende Ziele eingrenzen — die Egress-Allowlist

Die haltbarste Verteidigung ist die Netzwerkgrenze selbst: zählen Sie die Hosts auf, die Ihre Agenten legitim erreichen dürfen, und lehnen Sie alles andere ab. Eine Egress-Regel verwendet stage: egress und das egress-Feld; das Verdikt setzt die Polarität — allow lässt aufgelistete Ziele durch und ein deny-Catch-all niedrigerer Priorität blockiert den Rest. Fügen Sie diese Regeln zur selben exfil-firewall-Policy hinzu: 
[
  {
    "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 Hostname (case-insensitive). Um SSRF zu internen Diensten ohne explizite Allowlist zu stoppen, verfassen Sie Ihre eigene Egress-Deny-Regel, die den Cloud-Metadata-Endpunkt (169.254.169.254) und die privaten RFC-1918-Ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) auflistet. Ein abgelehnter Aufruf gibt HTTP 400 firewall_blocked zurück.
Kein Preset liefert CIDR-Egress-Regeln — Sie verfassen die Host-/CIDR-Allow- und Deny-Einträge selbst. Das tight-Autonomie-Level ist der angrenzende schnelle Weg: Es lehnt die fetch-förmigen Tool-Namen (http_fetch, web_search, fetch_url, request) ganz ab und entfernt die Netzwerkfähigkeit, bevor je ein Ziel ausgewertet wird. Verwenden Sie es, wenn Ihr Agent diese Tools gar nicht braucht.

​
5. Einen eingegrenzten Schlüssel anhängen

Eine Policy setzt nur auf Schlüsseln durch, die auf sie aufgelöst werden. Geben Sie dem Agenten seinen eigenen Schlüssel, eingegrenzt auf das Minimum, das er braucht — niemals Ihren kontoweiten Schlüssel. In API Keys → Neuer Schlüssel (Rolle Developer):
Wählen Sie exfil-shield aus dem Guardrail-Dropdown (setzt guardrail_id) und exfil-firewall aus dem Firewall policy-Dropdown (setzt firewall_policy_id). Beide Bindungen leben am Schlüssel im Gateway. Eine explizite Guardrail-Bindung fällt nie stillschweigend zurück — sie zu deaktivieren ist der Aus-Schalter. Eine deaktivierte Firewall-Policy hingegen fällt auf die Default-Policy des Workspaces zurück.
Setzen Sie credit_limit_usd auf eine vernünftige Obergrenze (0 = unbegrenzt), sodass ein kompromittierter Schlüssel kein Kontingent abschöpfen kann, und allow_ips auf die Egress-IPs Ihres Backends, wenn der Agent von einem festen Server aus aufruft. Setzen Sie ein expired_time für temporäre Schlüssel (-1 = läuft nie ab).
Der Schlüssel wird nach der Erstellung bei der Anzeige maskiert — kopieren Sie ihn einmal. Ihr Agent führt nun jeden Request durch exfil-shield und jeden Tool-Call durch exfil-firewall, ohne dass irgendein Code weiß, dass Durchsetzung stattfindet.

​
6. Mit Shadow-Mode ausrollen, dann beobachten

Wenn Sie noch nicht jeden Host kennen, den Ihr Agent legitim erreicht, setzen Sie nicht blind durch — beobachten Sie zuerst. Siehe Enforcement-Modi für den vollständigen Observe → shadow → enforce-Pfad.
1

Die Egress-Regeln shadowen

Setzen Sie shadow_mode: true auf exfil-firewall. Jedes durchsetzende Verdikt wird auf audit herabgestuft und als [shadow] would deny mit dem Ziel geloggt. Kein Traffic wird blockiert, solange der Shadow-Mode an ist.
2

Die Feeds beobachten

Firewall → Events / Runs (Developer+) zeigt jeden Tool-Call und jedes Egress-Ziel, das Ihr Agent traf, und was abgelehnt worden wäre. Guardrails → Matches (jedes Mitglied) zeigt jedes Secret, das das Input-Guardrail fing. Tunen Sie die Egress-allow-Liste, bis nur angreifer-erreichbare Hosts abgelehnt würden.
3

Durchsetzen

Schalten Sie shadow_mode aus. Der allernächste Request wird gesteuert — Credentials am Prompt blockiert, Secrets aus Tool-Args gestrichen, ausgehende Aufrufe auf Ihre Allowlist beschränkt. Keine Anwendungsänderung.
Der Matches-Feed zeichnet den gematchten Teilstring nur auf, wenn Log raw content für das Guardrail an ist (per Default aus — die datenschutzkonservative Haltung). Markieren Sie ein False Positive (Admin), um die Policy zu tunen. Jede Guardrail-Änderung schreibt eine Versionsverlaufszeile, die Sie diffen und reverten können; Firewall-Policy-Änderungen werden im Audit-Trail aufgezeichnet.

​
7. Abdeckung auf einen Blick

ExfiltrationsschrittEbene, die ihn stoppt
Credential gelangt in den RequestSecrets-Blocker-Guardrail (input)
Modell gibt einen Tool-Call aus, der ein Secret trägtsanitize-Firewall-Regel (response-Surface)
Tool dialt einen Angreifer-HostEgress-allow- / deny-Regel
Agent erreicht Cloud-Metadata oder RFC-1918Egress-Deny-Regel, die diese CIDRs auflistet
Fetch-förmiges Tool dem Modell angebotentight-Autonomie-Level (Tool-Namen-Deny)

​
8. Wohin als Nächstes

Firewall-Regeln-Referenz

Die vollständige Matching-Sprache — Egress-Listen, CIDRs, Sanitizer und alle Verdikte.

Datenexfiltrations-Bedrohung

Die Angriffsanatomie, gegen die sich dieses Rezept verteidigt, Ende zu Ende.

Einen MCP-Agenten härten

Jeden tools/call steuern, den ein Agent durch einen MCP-Server dispatcht.

PII-sicheres Logging

Sensible Daten aus Ihren Request-Logs und dem Matches-Feed heraushalten.