Saltar para o conteúdo principal
Um agente que pode alcançar a rede pode ser transformado em um cano de dados. Instruções injetadas dizem a ele para reunir segredos, linhas ou PII com as ferramentas que ele já possui e fazer POST delas para um host atacante — ou sondar serviços internos (SSRF). O agente nunca “decide” exfiltrar; ele executa o que parece, para ele, uma instrução legítima. Esta receita conecta três controles que fecham o ciclo de ponta a ponta — uma allow-list de egress que trava para onde as chamadas outbound podem ir, o guardrail Secrets Blocker que para credenciais antes que elas cheguem a um modelo, e um sanitizer de argumentos que remove segredos das chamadas de ferramenta que um modelo de fato emite. Tudo isso vive no gateway, então você o configura uma vez no console com zero mudança no código do seu agente. Para a anatomia completa do ataque, leia Exfiltração de dados pela rede; esta página são os passos de construção.
Tudo aqui se vincula ao seu workspace e é configurado a partir do console. Seu agente continua chamando https://api.orcarouter.ai/v1/... com a mesma chave sk-orca-... — apenas a política no gateway muda. As ações de configuração precisam dos papéis indicados por etapa; as chamadas de relay usam a chave com escopo. O firewall vê egress apenas para destinos roteados através do gateway (o caminho de dispatch de MCP ou o hook de evaluate) — roteie suas chamadas de ferramenta ligadas à rede por ele e elas estão governadas.

​
1. As três camadas que previnem a exfiltração de dados de IA

Cada camada captura o ataque em um ponto diferente do ciclo de vida da requisição. Empilhe as três — elas são independentes e complementares.

Credenciais no prompt

Um segredo colado (ou puxado) na requisição é capturado no stage input pelo guardrail Secrets Blocker — antes que qualquer modelo o veja.

Segredos nos args de ferramenta

Um modelo que emite uma chamada de ferramenta carregando uma credencial é limpo por uma regra de firewall sanitize, que redige o argumento correspondente.

Destino outbound

O passo de rede real é limitado por uma allow-list de egress — apenas hosts enumerados passam; todo o resto é negado.
Esta receita usa ambos os planos: Guardrails para o texto na requisição, o Firewall para as ações e a rede. Veja guardrails vs. firewall para onde a linha fica.

​
2. Pare credenciais no prompt — o guardrail Secrets Blocker

A primeira coisa a travar é a própria credencial. O guardrail Secrets & API-Key Blocker roda no stage input e escaneia a requisição em busca de padrões de credencial — chaves de acesso no estilo AWS, chaves OpenAI, JWTs e tokens similares — antes que a requisição deixe o gateway. Em uma correspondência a requisição é bloqueada: a credencial nunca chega a um modelo e nunca cai em uma chamada de ferramenta. No console, abra Guardrails → New guardrail (o papel Developer; leituras e o sandbox de Test estão abertos a qualquer membro), dê o nome exfil-shield e aplique o preset Secrets & API-Key Blocker da biblioteca de templates (categoria secrets). O preset semeia três regras regex de block no stage input, uma por formato de credencial — chaves de acesso AWS, chaves no estilo OpenAI e tokens GitHub: 
[
  { "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}" }
]
Para estender a cobertura, adicione uma regra pii nas entidades embutidas — o conjunto de detectores cobre email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt e bitcoin_address. Escolha mask (redigir para uma tag tipada como [EMAIL]) ou block por entidade via entity_actions. A máscara no stage input está disponível; ela reescreve a requisição antes que o modelo a veja.
Uma requisição bloqueada retorna HTTP 400 guardrail_blocked, custa nenhuma cota (um block no stage input dispara antes da medição) e é marcada como skip-retry. Prove na aba Test — cole uma chave AWS de amostra, escolha o stage input e confirme o veredito — antes de vincular uma chave.

​
3. Sanitize segredos para fora dos argumentos de chamada de ferramenta

Um guardrail filtra o prompt; ele não vê as chamadas de ferramenta que um modelo emite. Quando o modelo produz um tool_call cujos argumentos carregam uma credencial, uma regra de firewall sanitize a captura. O sanitize redige as substrings correspondentes dos argumentos da chamada de ferramenta e encaminha a chamada limpa — a ferramenta roda, mas com o segredo removido. Em Firewall → Policies → New policy (papel Developer), dê o nome exfil-firewall e adicione uma regra de sanitize na superfície response — os tool_calls que o modelo emite em sua resposta: 
{
  "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,}"]
  }
}
O sanitize redige apenas os argumentos da chamada de ferramenta — nunca o conteúdo que uma ferramenta retorna. É uma defesa no formato da chamada outbound, não nos resultados de ferramenta inbound. Na superfície inbound (onde ainda não há args em tempo de chamada) um veredito de sanitize escala para um deny. Veja a linguagem de correspondência completa em Regras de firewall.

​
4. Trave os destinos outbound — a allow-list de egress

A defesa mais durável é a própria fronteira de rede: enumere os hosts que seus agentes têm permissão legítima de alcançar e negue todo o resto. Uma regra de egress usa stage: egress e o campo egress; o veredito define a polaridade — allow deixa passar os destinos listados e um catch-all deny de prioridade menor bloqueia o resto. Adicione estas regras à mesma política exfil-firewall: 
[
  {
    "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"
  }
]
As entradas correspondem como um CIDR, um literal de IP ou um hostname insensível a maiúsculas. Para parar SSRF em direção a serviços internos sem uma allow-list explícita, crie a sua própria regra de deny de egress listando o endpoint de cloud-metadata (169.254.169.254) e os ranges privados RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Uma chamada negada retorna HTTP 400 firewall_blocked.
Nenhum preset entrega regras de egress de CIDR — você mesmo cria as entradas de allow e deny de host/CIDR. O nível de autonomia tight é o caminho rápido adjacente: ele nega os nomes de ferramenta no formato de fetch (http_fetch, web_search, fetch_url, request) de imediato, removendo a capacidade de rede antes que um destino seja sequer avaliado. Use-o quando seu agente não precisa dessas ferramentas de jeito nenhum.

​
5. Vincule uma chave com escopo

Uma política só aplica enforcement em chaves que resolvem para ela. Dê ao agente sua própria chave, escopada ao mínimo de que ele precisa — nunca sua chave para toda a conta. Em API Keys → New key (papel Developer):
Escolha exfil-shield no dropdown Guardrail (define guardrail_id) e exfil-firewall no dropdown Firewall policy (define firewall_policy_id). Ambos os vínculos vivem na chave dentro do gateway. Um vínculo explícito de guardrail nunca cai de volta silenciosamente — desabilitá-lo é o interruptor de desligar. Uma política de firewall desabilitada, por contraste, cai de volta para a política padrão do workspace.
Defina credit_limit_usd em um teto sensato (0 = ilimitado) para que uma chave comprometida não possa drenar cota, e allow_ips para os IPs de egress do seu backend se o agente chama de um servidor fixo. Defina um expired_time para chaves temporárias (-1 = nunca expira).
A chave é mascarada na exibição após a criação — copie-a uma vez. Seu agente agora roda cada requisição através de exfil-shield e cada chamada de ferramenta através de exfil-firewall sem nenhum código ciente de que o enforcement está acontecendo.

​
6. Faça o rollout com shadow mode, depois observe

Se você ainda não conhece cada host que seu agente alcança legitimamente, não aplique enforcement às cegas — observe primeiro. Veja modos de enforcement para o caminho completo observe → shadow → enforce.
1

Faça shadow das regras de egress

Defina shadow_mode: true em exfil-firewall. Todo veredito de enforcement é rebaixado para audit e registrado como [shadow] would deny com o destino. Nenhum tráfego é bloqueado enquanto o shadow mode está ligado.
2

Observe os feeds

Firewall → Events / Runs (Developer+) mostra cada chamada de ferramenta e destino de egress que seu agente atingiu e o que teria sido negado. Guardrails → Matches (qualquer Member) mostra cada segredo que o guardrail de input capturou. Ajuste a lista allow de egress até que apenas hosts alcançáveis pelo atacante seriam negados.
3

Aplique enforcement

Desligue shadow_mode. A próxima requisição é governada — credenciais bloqueadas no prompt, segredos removidos dos args de ferramenta, chamadas outbound confinadas à sua allow-list. Nenhuma mudança na aplicação.
O feed de Matches registra a substring correspondente apenas quando Log raw content está ligado para o guardrail (desligado por padrão — a postura conservadora de privacidade). Marque um falso positivo (Admin) para ajustar a política. Toda mudança de guardrail escreve uma linha de version-history que você pode comparar e reverter; mudanças de política de firewall são registradas na trilha de auditoria.

​
7. Cobertura num relance

Passo de exfiltraçãoCamada que o para
Credencial entra na requisiçãoGuardrail Secrets Blocker (input)
Modelo emite uma chamada de ferramenta carregando um segredoRegra de firewall sanitize (superfície response)
Ferramenta disca um host atacanteRegra de egress allow / deny
Agente alcança cloud-metadata ou RFC-1918Regra de deny de egress listando esses CIDRs
Ferramenta no formato de fetch oferecida ao modeloNível de autonomia tight (deny de nome de ferramenta)

​
8. Para onde ir a seguir

Referência de regras de firewall

A linguagem de correspondência completa — listas de egress, CIDRs, sanitizers e todos os vereditos.

Ameaça de exfiltração de dados

A anatomia do ataque contra o qual esta receita defende, de ponta a ponta.

Endureça um agente MCP

Governe cada tools/call que um agente despacha através de um servidor MCP.

Logging seguro de PII

Mantenha dados sensíveis fora dos seus logs de requisição e do feed de Matches.