Vai al contenuto principale
Hai connesso un MCP server, e ora vuoi che il gateway tolga un segreto trapelato da una chiamata a tool prima che raggiunga il server reale — e che impedisca a qualsiasi cosa quel tool restituisca di contrabbandare una credenziale (o un payload di injection) di ritorno nel modello. Questi sono due lavori diversi, gestiti da due controlli diversi, e la versione onesta conta: se assumi che una sola manopola copra entrambi, spedirai una lacuna. Questa pagina è la guida mirata a sanitize mcp output su OrcaRouter — cosa il verdetto sanitize del firewall redige davvero, cosa non redige, e quale controllo governa il contenuto che un tool restituisce.
Il verdetto sanitize redige gli argomenti di una chiamata a tool, mai il risultato che un tool restituisce. Ri-scrive ciò che il tuo agent invia dentro un tool. Per governare ciò che un tool rimanda, usi un guardrail di stage output sulla risposta del modello — vedi §3.

​
1. Cosa significa “sanitize” sulla superficie mcp

Quando un agent chiama un tool attraverso il gateway MCP, ogni tools/call viene valutato sulla superficie mcp prima del dispatch. Una regola che matcha può portare uno dei verdetti del firewall scrivibili — allow, audit, deny, sanitize, pending_approval, o cap_cost. Il verdetto sanitize è quello che redige:
  • Esegue un insieme di detector a forma di segreto sugli argomenti della chiamata (il JSON che il modello ha passato nel tool).
  • Ogni match viene sostituito con un token canonico come [redacted:openai_key], e gli argomenti ri-scritti sono ciò che viene inoltrato al server.
  • Il tool gira comunque — sanitize è un verdetto non-bloccante, di lasciapassare. L’agent non va in crash; semplicemente non consegna mai il segreto grezzo al tool.
I detector integrati coprono forme di segreto ben note (AWS access key, API key in stile sk-, token Bearer, US SSN, numeri di carta validi-Luhn, email), e una regola può aggiungere regex custom i cui match rendono come [redacted:custom].
Sulla superficie inbound — i tools[] pubblicizzati che una richiesta dichiara, prima che qualsiasi tool sia chiamato — non ci sono argomenti al momento della chiamata da redigere, quindi un verdetto sanitize lì fallisce closed ed escala a deny. Sanitize è significativo solo dove c’è un payload di argomenti live da ri-scrivere: le superfici mcp e response.

​
2. Una regola concreta

Diciamo che vuoi che qualsiasi chiamata a tool i cui argomenti contengono una chiave in stile OpenAI venga inoltrata con la chiave ripulita, anziché bloccata. Scrivi una regola sulla superficie mcp con un verdetto sanitize, configurata per rilevare quella forma di segreto. Fallo dalla console (Firewall → policy → regole); la scrittura richiede Developer+. La regola, concettualmente:
CampoValore
Superficiemcp
tool_name_glob* (o dai scope a un server, es. github.*)
Verdettosanitize
Preset di sanitizei detector di segreti da abilitare
Al momento della chiamata, un payload di argomenti come: 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
viene inoltrato al server come: 
{ "note": "use key [redacted:openai_key] for the upstream" }
La chiamata riesce; il segreto non raggiunge mai il server. L’evento del firewall registra il verdetto sanitize, la superficie e la regola matchata.
Ricorri a sanitize quando un tool ha legittimamente bisogno della maggior parte di un argomento ma un segreto occasionalmente viaggia con esso in testo libero. Quando l’intera chiamata è pericolosa, usa deny (o pending_approval) invece — vedi Allow-list dei tool MCP.

​
3. I tool-result sono non attendibili — governali sulla risposta del modello

Ecco la parte che la maggior parte dei setup “sanitizza l’output” sbaglia. Il verdetto sanitize tocca solo gli argomenti. Il risultato di un tool — il testo o il JSON che un MCP server rimanda — non viene mai ri-scritto da un verdetto del firewall. OrcaRouter tratta il contenuto del tool-result come input non attendibile al modello. Un MCP server compromesso o avvelenato può restituire un segreto, un record di PII, o un payload di prompt-injection travestito da dati. Il controllo per quel contenuto è un guardrail sullo stage output — la risposta del modello, valutata dopo che il modello ha incorporato il risultato del tool.
Allega un guardrail con il preset Secrets & API-Key Blocker (categoria secrets). Blocca credenziali in stile AWS / OpenAI / GitHub; abbinalo a Private Keys & Cloud Tokens per chiavi PEM, token Slack/Stripe, chiavi Google e JWT. Un blocco di stage output restituisce guardrail_blocked (HTTP 400) e rimborsa la quota della richiesta.
Il preset PII Shield maschera entità tipizzate — [EMAIL], [SSN], [CREDIT_CARD], … — rendendo i valori matchati come tag. Il masking di stage input è live su ogni richiesta (streaming o no): maschera la richiesta prima che il modello la veda. Il masking di stage output ri-scrive la risposta del modello solo sulle risposte non-streaming; la ri-scrittura in-band di una risposta in streaming è sulla roadmap, quindi una regola mask non redige ancora una risposta in streaming.
Un risultato avvelenato può portare testo in stile “ignora le istruzioni precedenti”. Il preset di safety Prompt-Injection Basics (keyword/regex) più una regola llm_judge che valuta l’intento di injection sono i controlli qui. Vedi Avvelenamento dei tool MCP e Prompt injection.
Enforcement di output e streaming. Il block di stage output è applicato sia sulle risposte in streaming che non-streaming — su uno stream, un block taglia lo stream quando matcha ed emette un avviso di blocco generico. Il mask di stage output si applica solo alle risposte non-streaming; la ri-scrittura in-band di una risposta in streaming è sulla roadmap, quindi una regola mask non redige ancora una risposta in streaming.

​
4. Dove vive ciascun controllo

Una mappa compatta delle due superfici, così cabli la manopola giusta sul rischio giusto:
Vuoi governare…ControlloDove
Segreti negli argomenti di una chiamata a toolVerdetto sanitize del firewall (superficie mcp)Regole del firewall
Segreti / PII / injection nel risultato di un toolGuardrail sullo stage outputGuardrails
Non cercare di far coprire i tool-result a sanitize — non può vederli. E non assumere che un guardrail di stage input coglierà ciò che un tool restituisce a metà conversazione; il contenuto del tool-result è governato sulla risposta del modello, che è lo stage output.

​
5. Attaccare e osservare

Entrambi i controlli hanno scope a livello di workspace, sono nominati e ordinati, ed entrambi si attaccano negli stessi due modi:
  • Per chiave — imposta firewall_policy_id (per la regola di sanitize) e guardrail_id (per la policy di output) sulla chiave che l’agent usa.
  • Default del workspace — marca una policy / guardrail come default del workspace così ogni chiave la eredita.
Configura tutto questo dalla console con il tuo session/access token (le route di gestione usano UserAuth, non la chiave relay). Le scritture del firewall richiedono Developer+; le scritture dei guardrail richiedono Developer+. Una volta live, i match di sanitize compaiono come eventi del firewall (verdetto, superficie, regola matchata), e i match dei guardrail compaiono nel feed dei match dei guardrail. I due hanno gate di lettura diversi: il feed eventi del firewall richiede Developer+, mentre il feed match dei guardrail è leggibile da qualsiasi membro del workspace. Per default un match registra il suo tipo, azione e stage ma non il contenuto grezzo matchato; attiva Log raw content solo quando ti serve la substring per il triage.

​
6. Dove andare dopo

Allow-list dei tool MCP

Default-deny su un server e permetti solo i tool che hai revisionato.

Regole del firewall

Il DSL completo delle regole — verdetti, glob, args-match, config di sanitize.

Guardrails

Policy sui contenuti, preset, entità PII, ed enforcement di stage output.

Avvelenamento dei tool MCP

La minaccia che rende i tool-result non attendibili in primo luogo.
Nuovo alla separazione tra questi due layer? Leggi Guardrails vs. firewall, poi Esfiltrazione dei dati per il percorso di leak che sanitize e i guardrail di output chiudono insieme.