Saltar para o conteúdo principal
Você conectou um servidor MCP, e agora quer que o gateway retire um segredo vazado de uma chamada de ferramenta antes que ela chegue ao servidor real — e que impeça o que essa ferramenta retorna de contrabandear uma credencial (ou um payload de injeção) de volta para o modelo. Esses são dois trabalhos diferentes, tratados por dois controles diferentes, e a versão honesta importa: se você assumir que um único botão cobre os dois, vai entregar uma lacuna. Esta página é o guia focado para sanitizar a saída de mcp no OrcaRouter — o que o veredito sanitize do firewall de fato redige, o que ele não redige, e qual controle governa o conteúdo que uma ferramenta retorna.
O veredito sanitize redige os argumentos da chamada de ferramenta, nunca o resultado que uma ferramenta retorna. Ele reescreve o que o seu agente envia para uma ferramenta. Para governar o que uma ferramenta envia de volta, você usa um guardrail de output-stage na resposta do modelo — veja §3.

​
1. O que “sanitize” significa na superfície mcp

Quando um agente chama uma ferramenta através do gateway MCP, cada tools/call é avaliado na superfície mcp antes do dispatch. Uma regra correspondente pode carregar um dos vereditos de firewall escrevíveis — allow, audit, deny, sanitize, pending_approval ou cap_cost. O veredito sanitize é o que redige:
  • Ele roda um conjunto de detectores de formato-de-segredo sobre os argumentos da chamada (o JSON que o modelo passou para a ferramenta).
  • Cada correspondência é substituída por um token canônico como [redacted:openai_key], e os argumentos reescritos são o que é encaminhado ao servidor.
  • A ferramenta ainda roda — sanitize é um veredito não bloqueante, de deixar-passar. O agente não quebra; ele só nunca entrega o segredo bruto à ferramenta.
Os detectores embutidos cobrem formatos de segredo bem conhecidos (chaves de acesso AWS, chaves de API no estilo sk-, tokens Bearer, SSN dos EUA, números de cartão válidos por Luhn, email), e uma regra pode adicionar regexes customizadas cujas correspondências renderizam como [redacted:custom].
Na superfície inbound — os tools[] anunciados que uma requisição declara, antes de qualquer ferramenta ser chamada — não há argumentos em tempo de chamada para redigir, de modo que um veredito sanitize ali falha fechado e escala para deny. Sanitize só é significativo onde há um payload de argumento ao vivo para reescrever: as superfícies mcp e response.

​
2. Uma regra concreta

Digamos que você queira que qualquer chamada de ferramenta cujos argumentos contenham uma chave no estilo OpenAI seja encaminhada com a chave removida, em vez de bloqueada. Escreva uma regra na superfície mcp com um veredito sanitize, configurada para detectar esse formato de segredo. Faça isso a partir do console (Firewall → política → regras); a escrita exige Developer+. A regra, conceitualmente:
CampoValor
Superfíciemcp
tool_name_glob* (ou escope a um servidor, ex.: github.*)
Vereditosanitize
Presets de sanitizeos detectores de segredo a habilitar
Em tempo de chamada, um payload de argumento como: 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
é encaminhado ao servidor como: 
{ "note": "use key [redacted:openai_key] for the upstream" }
A chamada tem sucesso; o segredo nunca chega ao servidor. O evento de firewall registra o veredito sanitize, a superfície e a regra correspondente.
Recorra a sanitize quando uma ferramenta legitimamente precisa da maior parte de um argumento mas um segredo ocasionalmente vai junto em texto livre. Quando a chamada inteira é perigosa, use deny (ou pending_approval) em vez disso — veja Lista de permissão de ferramentas MCP.

​
3. Os tool-results não são confiáveis — governe-os na resposta do modelo

Aqui está a parte que a maioria dos setups de “sanitize the output” erra. O veredito sanitize toca apenas nos argumentos. O resultado de uma ferramenta — o texto ou JSON que um servidor MCP devolve — nunca é reescrito por um veredito de firewall. O OrcaRouter trata o conteúdo do tool-result como input não confiável para o modelo. Um servidor MCP comprometido ou envenenado pode retornar um segredo, um registro de PII ou um payload de injeção de prompt disfarçado de dado. O controle para esse conteúdo é um guardrail no estágio output — a resposta do modelo, avaliada depois que o modelo incorporou o resultado da ferramenta.
Anexe um guardrail com o preset Secrets & API-Key Blocker (categoria secrets). Ele bloqueia credenciais no estilo AWS / OpenAI / GitHub; combine-o com Private Keys & Cloud Tokens para chaves PEM, tokens Slack/Stripe, chaves Google e JWTs. Um block de output-stage retorna guardrail_blocked (HTTP 400) e reembolsa a quota da requisição.
O preset PII Shield mascara entidades tipadas — [EMAIL], [SSN], [CREDIT_CARD], … — renderizando os valores correspondentes como tags. O mascaramento de input-stage está ativo em cada requisição (streaming ou não): ele mascara a requisição antes que o modelo a veja. O mascaramento de output-stage reescreve a resposta do modelo apenas em respostas não-streaming; a reescrita in-band de uma resposta em streaming está no roadmap, de modo que uma regra de mask ainda não redige uma resposta transmitida.
Um resultado envenenado pode carregar texto no estilo “ignore previous instructions”. O preset de segurança Prompt-Injection Basics (keyword/regex) mais uma regra llm_judge que pontua intenção de injeção são os controles aqui. Veja Envenenamento de ferramentas MCP e Injeção de prompt.
Enforcement de output e streaming. O block de output-stage é aplicado tanto em respostas streaming quanto não-streaming — em um stream, um block corta o stream quando corresponde e emite um aviso genérico de block. O mask de output-stage se aplica apenas a respostas não-streaming; a reescrita in-band de uma resposta em streaming está no roadmap, de modo que uma regra de mask ainda não redige uma resposta transmitida.

​
4. Onde cada controle vive

Um mapa compacto das duas superfícies, para que você ligue o botão certo ao risco certo:
Você quer governar…ControleOnde
Segredos nos argumentos de uma chamada de ferramentaVeredito sanitize do firewall (superfície mcp)Regras de firewall
Segredos / PII / injeção no resultado de uma ferramentaGuardrail no estágio outputGuardrails
Não tente fazer sanitize cobrir os resultados de ferramenta — ele não consegue vê-los. E não assuma que um guardrail de input-stage vai pegar o que uma ferramenta retorna no meio de uma conversa; o conteúdo do tool-result é governado na resposta do modelo, que é o estágio output.

​
5. Anexando e observando

Ambos os controles têm escopo de workspace, são nomeados e ordenados, e ambos anexam das mesmas duas formas:
  • Por chave — defina firewall_policy_id (para a regra de sanitize) e guardrail_id (para a política de output) na chave que o agente usa.
  • Padrão de workspace — marque uma política / guardrail como o padrão do workspace de modo que toda chave o herde.
Configure tudo isso a partir do console com o seu token de sessão/acesso (as rotas de gerenciamento usam UserAuth, não a chave de relay). Escritas de firewall exigem Developer+; escritas de guardrail exigem Developer+. Uma vez ativos, as correspondências de sanitize aparecem como eventos de firewall (veredito, superfície, regra correspondente), e as correspondências de guardrail aparecem no feed de correspondências de guardrail. Os dois têm gates de leitura diferentes: o feed de eventos de firewall exige Developer+, enquanto o feed de correspondência de guardrail é legível por qualquer membro do workspace. Por padrão uma correspondência registra seu tipo, ação e estágio mas não o conteúdo bruto correspondente; ligue Log raw content apenas quando você precisar da substring para triagem.

​
6. Para onde ir em seguida

Lista de permissão de ferramentas MCP

Negue por padrão um servidor e permita apenas as ferramentas que você revisou.

Regras de firewall

O DSL completo de regras — vereditos, globs, args-match, config de sanitize.

Guardrails

Políticas de conteúdo, presets, entidades de PII e enforcement de output-stage.

Envenenamento de ferramentas MCP

A ameaça que torna os resultados de ferramenta não confiáveis em primeiro lugar.
Novo na divisão entre essas duas camadas? Leia Guardrails vs. firewall, depois Exfiltração de dados para o caminho de vazamento que o sanitize e os guardrails de output fecham juntos.