Saltar para o conteúdo principal
Um agente que pode alcançar a rede pode ser transformado em um cano de dados. Um atacante planta instruções em um documento que o agente lê — uma página web, um chunk recuperado, um resultado de ferramenta — e essas instruções direcionam o agente para fazer POST de dados sensíveis para um host controlado pelo atacante, ou para sondar serviços internos (SSRF). O agente nunca “decide” exfiltrar; ele executa o que parece, para ele, uma instrução legítima. Esta página cobre como o Agent Firewall e os Guardrails do OrcaRouter permitem que você se defenda contra exfiltração de dados de IA — sem alterar o código do seu agente.
O firewall vê egress apenas para destinos roteados pelo gateway via o caminho de dispatch MCP ou o hook de avaliação. Uma ferramenta que seu agente executa inteiramente dentro do seu próprio processo está fora da sua visão. Roteie as chamadas de ferramenta de rede do seu agente pelo gateway e elas são governadas.

​
1. Como o ataque funciona

O caminho canônico por um agente roda em três passos:
  1. Injeção — o agente lê conteúdo não confiável carregando instruções embutidas (uma página web, um documento buscado, uma nota do CRM).
  2. Coleta — as instruções injetadas dizem ao agente para coletar material sensível — chaves de API, linhas de banco de dados, PII do usuário — usando ferramentas que ele já possui.
  3. Exfiltração — o agente é instruído a enviar esse material por uma ferramenta com formato fetch: http_fetch, web_search, fetch_url ou request. O destino é controlado pelo atacante.
SSRF tem o mesmo formato redirecionado internamente: em vez de um host externo, o agente é direcionado para 169.254.169.254 (metadados de nuvem), uma porta interna do Redis ou outro serviço privado. Veja Injeção de prompt para o passo de injeção; esta página foca no passo de rede.

​
2. Lista de permissão de egress — bloqueie destinos outbound

A defesa mais durável é uma lista de permissão de egress: 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 controla a polaridade — allow passa destinos listados; um deny catch-all de menor prioridade bloqueia o resto: 
[
  {
    "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 CIDR, um IP literal ou um hostname sem distinção de maiúsculas e minúsculas. Hostnames são resolvidos de forma best-effort e re-verificados contra entradas de IP/CIDR, então um destino como 169.254.169.254 retornado pelo DNS ainda é capturado por uma entrada de deny de CIDR 10.0.0.0/8. Uma chamada bloqueada retorna HTTP 400 com código de erro firewall_blocked. Para negar intervalos conhecidos como ruins sem uma lista de permissão explícita, escreva uma regra de deny de egress direcionada listando o endpoint de metadados de nuvem (169.254.169.254) e os intervalos privados RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Sobreponha sua lista de permissão em cima com um número de prioridade menor para que as regras de deny sejam avaliadas primeiro.

​
3. Bloqueie ferramentas com formato fetch na camada de nome

Antes que um destino de egress seja sequer avaliado, você pode remover a capacidade completamente. O nível de autonomia tight nega http_fetch, web_search, fetch_url e request por glob de nome de ferramenta como um backstop de SSRF e exfiltração. Se seu agente não precisa de nenhuma dessas ferramentas, tight remove a superfície de ataque em um passo: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Para negar ferramentas fetch sem adotar a postura completa de tight, escreva uma regra de deny na superfície inbound. inbound bloqueia a ferramenta antes que o modelo possa escolhê-la — o agente nunca recebe a capacidade em sua lista de ferramentas: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Repita para cada nome de ferramenta com formato fetch que seu stack de agente usa.

​
4. Guardrail Secrets Blocker — pare credenciais no prompt

O guardrail Secrets Blocker roda no estágio de entrada, escaneando o prompt por chaves de acesso no estilo AWS, chaves OpenAI, chaves Anthropic, tokens GitHub e padrões de credencial similares antes que a requisição saia do gateway. Se um segredo é detectado, a requisição é bloqueada — a credencial nunca alcança um modelo e nunca aparece em uma chamada de ferramenta. Habilite-o no painel de Guardrails, ou como parte do nível de autonomia tight. Ele é independente das regras de egress do firewall.
AmeaçaCamada que a para
Prompt carrega uma chave de APISecrets Blocker (guardrail de entrada)
Agente chama uma ferramenta fetch para um host do atacanteRegra de allow/deny de egress
Ferramenta com formato fetch anunciada ao modeloRegra de deny inbound ou autonomia tight
Agente alcança metadados de nuvem ou RFC-1918Regra de deny de egress listando esses CIDRs

​
5. Faça rollout com shadow mode

Se você não sabe quais hosts seu agente alcança legitimamente hoje, comece no shadow mode antes de aplicar enforcement:
  1. Crie as regras de egress com a lista de permissão pretendida e defina shadow_mode: true na política.
  2. Observe o feed de Events — chamadas que seriam bloqueadas aparecem como [shadow] would deny com o destino.
  3. Ajuste a lista allow até que apenas destinos alcançáveis pelo atacante seriam negados, depois desative o shadow mode para começar a aplicar enforcement.
Nenhum tráfego é bloqueado enquanto o shadow mode está ativo.

​
6. Para onde ir a seguir

Referência de regras do Firewall

Linguagem de correspondência completa — listas de egress, CIDRs, cláusulas de argumento e todos os vereditos.

Visão geral do Agent Firewall

Políticas, superfícies, níveis de autonomia e observabilidade.

Injeção de prompt

O passo de injeção que direciona agentes para a exfiltração.

Envenenamento de ferramenta MCP

Ferramentas MCP maliciosas que registram capacidades com formato fetch.