Zum Hauptinhalt springen
Sie haben einen MCP-Server verbunden, und nun wollen Sie, dass das Gateway ein geleaktes Secret aus einem Tool-Call entfernt, bevor er den echten Server erreicht — und verhindert, dass alles, was dieses Tool zurückgibt, ein Credential (oder eine Injection-Payload) zurück ins Modell schmuggelt. Das sind zwei verschiedene Aufgaben, gehandhabt von zwei verschiedenen Controls, und die ehrliche Version zählt: wenn Sie annehmen, ein Knopf decke beides ab, liefern Sie eine Lücke. Diese Seite ist der fokussierte Leitfaden zum mcp-Ausgaben-Sanitisieren auf OrcaRouter — was das firewall-sanitize-Verdikt tatsächlich redigiert, was nicht, und welches Control den Inhalt steuert, den ein Tool zurückgibt.
Das sanitize-Verdikt redigiert Tool-Call-Argumente, nie das Ergebnis, das ein Tool zurückgibt. Es schreibt um, was Ihr Agent in ein Tool sendet. Um zu steuern, was ein Tool zurücksendet, verwenden Sie ein Output-Stage-Guardrail auf der Modell-Antwort — siehe §3.

​
1. Was „sanitize” auf der mcp-Oberfläche bedeutet

Wenn ein Agent ein Tool über das MCP-Gateway aufruft, wird jeder tools/call vor dem Dispatch auf der mcp-Oberfläche ausgewertet. Eine matchende Regel kann eines der verfassbaren Firewall-Verdikte tragen — allow, audit, deny, sanitize, pending_approval oder cap_cost. Das sanitize-Verdikt ist das redigierende:
  • Es führt einen Satz von Secret-Form-Detektoren über die Argumente des Aufrufs (das JSON, das das Modell in das Tool übergeben hat).
  • Jeder Match wird durch ein kanonisches Token wie [redacted:openai_key] ersetzt, und die umgeschriebenen Argumente sind das, was an den Server weitergeleitet wird.
  • Das Tool läuft trotzdem — sanitize ist ein nicht blockierendes, durchlassendes Verdikt. Der Agent stürzt nicht ab; er übergibt dem Tool nur nie das rohe Secret.
Eingebaute Detektoren decken bekannte Secret-Formen ab (AWS-Access-Keys, sk--förmige API-Keys, Bearer-Tokens, US-SSN, Luhn-valide Kartennummern, E-Mail), und eine Regel kann benutzerdefinierte Regexes hinzufügen, deren Matches als [redacted:custom] gerendert werden.
Auf der inbound-Oberfläche — den beworbenen tools[], die eine Anfrage deklariert, bevor ein Tool aufgerufen wird — gibt es keine Aufruf-Zeit-Argumente zu redigieren, sodass ein sanitize-Verdikt dort fail-closed schließt und auf deny eskaliert. Sanitize ist nur dort sinnvoll, wo es eine Live-Argument-Payload zum Umschreiben gibt: den mcp- und response-Oberflächen.

​
2. Eine konkrete Regel

Angenommen, Sie wollen, dass jeder Tool-Call, dessen Argumente einen OpenAI-förmigen Key enthalten, mit dem herausgeschrubbten Key weitergeleitet wird, statt blockiert zu werden. Verfassen Sie eine Regel auf der mcp-Oberfläche mit einem sanitize-Verdikt, konfiguriert, um diese Secret-Form zu erkennen. Tun Sie dies aus der Konsole (Firewall → Policy → Regeln); der Schreibvorgang erfordert Developer+. Die Regel, konzeptionell:
FeldWert
Oberflächemcp
tool_name_glob* (oder auf einen Server scopen, z. B. github.*)
Verdiktsanitize
Sanitize-Presetsdie zu aktivierenden Secret-Detektoren
Zur Aufrufzeit wird eine Argument-Payload wie: 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
an den Server weitergeleitet als: 
{ "note": "use key [redacted:openai_key] for the upstream" }
Der Aufruf gelingt; das Secret erreicht nie den Server. Das Firewall-Event zeichnet das sanitize-Verdikt, die Oberfläche und die gematchte Regel auf.
Greifen Sie zu sanitize, wenn ein Tool legitimerweise die meisten Argumente braucht, aber gelegentlich ein Secret im Freitext mitreitet. Wenn der ganze Aufruf gefährlich ist, verwenden Sie stattdessen deny (oder pending_approval) — siehe MCP-Tools per Allow-List freigeben.

​
3. Tool-Results sind nicht vertrauenswürdig — steuern Sie sie auf der Modell-Antwort

Hier ist der Teil, den die meisten „sanitize the output”-Setups falsch machen. Das sanitize-Verdikt berührt nur Argumente. Das Ergebnis eines Tools — der Text oder das JSON, das ein MCP-Server zurückgibt — wird nie von einem Firewall-Verdikt umgeschrieben. OrcaRouter behandelt Tool-Result-Inhalte als nicht vertrauenswürdigen Input für das Modell. Ein kompromittierter oder vergifteter MCP-Server kann ein Secret, einen PII-Datensatz oder eine als Daten verkleidete Prompt-Injection-Payload zurückgeben. Das Control für diesen Inhalt ist ein Guardrail auf der output-Stage — der Modell-Antwort, ausgewertet, nachdem das Modell das Tool-Result integriert hat.
Hängen Sie ein Guardrail mit dem Secrets & API-Key Blocker-Preset an (Kategorie secrets). Es blockiert AWS / OpenAI / GitHub-förmige Credentials; paaren Sie es mit Private Keys & Cloud Tokens für PEM-Keys, Slack/Stripe-Tokens, Google-Keys und JWTs. Ein Output-Stage-Block gibt guardrail_blocked (HTTP 400) zurück und erstattet die Quota der Anfrage.
Das PII Shield-Preset maskiert typisierte Entitäten — [EMAIL], [SSN], [CREDIT_CARD], … — und rendert gematchte Werte als Tags. Die Input-Stage-Maskierung ist bei jeder Anfrage live (gestreamt oder nicht): sie maskiert die Anfrage, bevor das Modell sie sieht. Die Output-Stage-Maskierung schreibt die Modell-Antwort nur bei nicht-gestreamten Antworten um; das In-Band-Umschreiben einer gestreamten Antwort ist auf der Roadmap, sodass eine Maskierungs-Regel eine gestreamte Antwort noch nicht redigiert.
Ein vergiftetes Ergebnis kann „ignore previous instructions”-artigen Text tragen. Das Prompt-Injection Basics-Safety-Preset (Keyword/Regex) plus eine llm_judge-Regel, die auf Injection-Absicht scort, sind hier die Controls. Siehe MCP-Tool-Poisoning und Prompt-Injection.
Output-Durchsetzung und Streaming. Der Output-Stage-Block wird sowohl bei gestreamten als auch bei nicht-gestreamten Antworten durchgesetzt — bei einem Stream schneidet ein Block den Stream ab, wenn er matcht, und gibt einen generischen Block-Hinweis aus. Die Output-Stage-Maske gilt nur für nicht-gestreamte Antworten; das In-Band-Umschreiben einer gestreamten Antwort ist auf der Roadmap, sodass eine Maskierungs-Regel eine gestreamte Antwort noch nicht redigiert.

​
4. Wo jedes Control lebt

Eine kompakte Karte der zwei Oberflächen, damit Sie den richtigen Knopf an das richtige Risiko verdrahten:
Sie wollen steuern…ControlWo
Secrets in den Argumenten eines Tool-CallsFirewall-sanitize-Verdikt (mcp-Oberfläche)Firewall-Regeln
Secrets / PII / Injection im Ergebnis eines ToolsGuardrail auf der output-StageGuardrails
Versuchen Sie nicht, sanitize Tool-Results abdecken zu lassen — es kann sie nicht sehen. Und nehmen Sie nicht an, ein Input-Stage-Guardrail werde abfangen, was ein Tool mitten im Gespräch zurückgibt; Tool-Result-Inhalte werden auf der Antwort des Modells gesteuert, was die output-Stage ist.

​
5. Anhängen und Beobachten

Beide Controls sind workspace-bezogen, benannt und geordnet, und beide hängen sich auf dieselben zwei Arten an:
  • Pro Key — setzen Sie firewall_policy_id (für die sanitize-Regel) und guardrail_id (für die Output-Policy) auf dem Key, den der Agent verwendet.
  • Workspace-Default — markieren Sie eine Policy / ein Guardrail als Workspace-Default, sodass jeder Key sie erbt.
Konfigurieren Sie all dies aus der Konsole mit Ihrer Session/Ihrem Access-Token (die Management-Routen verwenden UserAuth, nicht den Relay-Key). Firewall-Schreibvorgänge erfordern Developer+; Guardrail-Schreibvorgänge erfordern Developer+. Sobald live, tauchen sanitize-Matches als Firewall-Events auf (Verdikt, Oberfläche, gematchte Regel), und Guardrail-Matches tauchen im Guardrail-Match-Feed auf. Die beiden haben verschiedene Lese-Gates: der Firewall-Events-Feed erfordert Developer+, während der Guardrail-Match-Feed von jedem Workspace-Mitglied lesbar ist. Standardmäßig zeichnet ein Match seinen Typ, seine Aktion und seine Stage auf, aber nicht den rohen gematchten Inhalt; schalten Sie Log raw content nur ein, wenn Sie den Substring für die Triage brauchen.

​
6. Wohin als Nächstes

MCP-Tools per Allow-List freigeben

Default-Deny eines Servers und nur die geprüften Tools zulassen.

Firewall-Regeln

Das vollständige Regel-DSL — Verdikte, Globs, Args-Match, Sanitize-Config.

Guardrails

Content-Policies, Presets, PII-Entitäten und Output-Stage-Durchsetzung.

MCP-Tool-Poisoning

Die Bedrohung, die Tool-Results überhaupt erst nicht vertrauenswürdig macht.
Neu bei der Aufteilung zwischen diesen zwei Ebenen? Lesen Sie Guardrails vs. Firewall, dann Datenexfiltration für den Leak-Pfad, den sanitize und Output-Guardrails zusammen schließen.