Segurança e supervisãoAtualizado 2026-08-25 · Versão 1.1

Lista de Saída Permitida

Restrinja para onde o tráfego de um agente pode ir. O roubo de dados e a entrega de um payload de injeção terminam ambos em uma requisição de saída, então uma lista de destinos permitidos com negação por padrão é o controle que continua funcionando depois que todos os outros já falharam.

Evidência: Observação do setorConfiança: AltaFonte: Observação do setorFonte: Experiência pessoalFonte: Paper

Definição

Uma lista de saída permitida é uma política de rede ou de sandbox que autoriza as requisições de saída do agente apenas para um conjunto de destinos nomeados explicitamente e nega todo o resto por padrão, de modo que os dados não possam sair para um endpoint escolhido pelo atacante mesmo com o agente totalmente sequestrado.

Problema

Todo caminho de exfiltração termina em uma requisição de saída. Um agente que alcança hosts arbitrários pode ser instruído a enviar tudo o que leu para qualquer endereço, e nenhuma instrução no nível do prompt impede isso.

Quando usar

Use onde um agente processa conteúdo não confiável e também faz requisições de rede: baixar páginas, invocar ferramentas, renderizar imagens, executar código gerado. O padrão vale mais exatamente onde a injeção é mais provável.

Solução

Negue por padrão. A lista é a única saída; o que não estiver nomeado é recusado, e a recusa é registrada como sinal em vez de engolida como erro.

Enumere os destinos a partir da tarefa: as APIs que o agente precisa chamar, os domínios que precisa baixar, os registries de onde precisa instalar — cada um com responsável e motivo escrito.

Aplique a política abaixo do agente. Coloque-a no sandbox, no proxy ou na rede, nunca no código da ferramenta do qual o modelo pode ser convencido. Uma regra que o agente contorna conversando é documentação, não controle.

Feche os canais silenciosos. URLs de imagens renderizadas, pré-visualizações de links, resoluções DNS, webhooks, relatores de erro e instalações de pacotes são todos saída, e todos são usados.

Permita hosts sobre os quais você consiga raciocinar. Um curinga sobre um host que serve conteúdo de usuário — um CDN de arquivos crus, um site de pastes, um object store público — é um canal aberto fantasiado de lista de permitidos.

Derive a lista da medição e volte a derivá-la quando a tarefa mudar. Parta do que o agente realmente chama, não do que alguém supõe que ele chama.

Componentes

Um gateway de saída ou política de rede do sandbox que todo o tráfego precise atravessar.Uma regra de negação por padrão com um inventário de destinos explícito e com responsáveis.Políticas por papel, para que um agente de pesquisa e um de implantação não compartilhem uma mesma lista.Registro de negações ligado a alertas, porque uma negação é um evento de alto sinal.Restrições de método e de payload onde o destino sozinho não basta (somente GET, limites de tamanho de corpo).Uma cadência de revisão que remova os destinos que ninguém usou.

Benefícios

  • Limita a exfiltração mesmo após um comprometimento completo do raciocínio do agente.
  • Torna as tentativas visíveis: um destino negado é um dos poucos sinais de ataque inequívocos que uma pilha agêntica produz.
  • É independente do modelo: continua funcionando entre trocas de modelo, mudanças de prompt e migrações de framework.
  • É barata de estender depois que o gateway existe; cada agente novo herda o ponto de aplicação.

Riscos

  • O relé permitido: um host autorizado que por sua vez repassa os dados transforma a lista em formalidade.
  • Quebras quando uma dependência legítima muda de host, o que gera pressão para ampliar a lista com pressa.
  • Erosão por curingas: cada entrada ampla adicionada «temporariamente» é permanente até alguém auditá-la.
  • Aplicação na camada errada: uma verificação no próprio processo que o código gerado simplesmente contorna.

Quando não usar

  • Agentes totalmente sem rede, onde não há saída a limitar e o controle seria encenação.
  • Quando o design já permite exatamente um destino, então a lista é propriedade da arquitetura e não política a acrescentar.
  • Quando um proxy corporativo já aplica a mesma política e uma segunda lista dividiria a responsabilidade sem acrescentar restrição.

Tecnologias

Egress proxiesContainer network policiesService mesh policyDNS filteringDenial logging and alerting

Exemplos

  • Um agente de programação em um contêiner cuja política de saída nomeia o registry de pacotes e o host Git interno, e nada mais. Uma instrução injetada para dar POST do repositório a um coletor externo falha na camada de rede e aparece como negação.
  • Um agente de pesquisa autorizado a baixar amplamente, mas forçado por um proxy que permite apenas GET e limita o tamanho dos corpos de saída: consegue ler a web sem ter um canal para escrever nela.
  • O pacote stdio publicado para esta base de conhecimento: seu único destino de saída é o endpoint público do qual ele é proxy, então a lista de permitidos é propriedade do design e não política acrescentada depois.

KPIs

Tentativas de saída negadas
O sinal que o padrão existe para produzir. Uma alta sustentada é um ataque ou uma tarefa que ultrapassou sua lista; vale saber qual.
Tamanho da lista
Destinos permitidos por papel de agente. Crescer sem remover é a lista degradando para «permitir tudo».
Entradas com curinga
Número de entradas amplas. Cada uma é um canal sobre o qual você não consegue raciocinar; o alvo é zero.
Tempo de negação até triagem
Quanto uma negação espera até alguém olhar. Uma negação não lida é um alerta que você não tem de fato.

Modos de falha observados

  • O relé permitido: um host aprovado que repassa o que receber, então a verificação de destino passa e os dados saem do mesmo jeito.
  • Erosão por curingas: entradas amplas temporárias que sobrevivem ao motivo pelo qual foram adicionadas.
  • Aplicação no próprio processo: a verificação mora onde o código gerado roda, então o código consegue pulá-la.
  • Negações silenciosas: recusas registradas como erros de rede comuns, então o único sinal que o padrão gera nunca chega a ninguém.

Lições aprendidas

  • A saída é o último controle que ainda funciona depois que o modelo foi convencido. Construa antes de precisar.
  • Derive a lista de tráfego medido e não de suposição. Fazer exatamente isso para a regra de origem de entrada do nosso próprio endpoint MCP produziu uma regra diferente da que teríamos escrito a partir de um padrão.
  • Trate uma negação como alerta, não como erro. É o sinal de ataque mais barato de toda a pilha.
  • Todo curinga é uma promessa que você não consegue cumprir. Nomeie hosts, ou admita que não tem uma lista de permitidos.

FAQs

Uma lista de saída é realista para um agente que navega na web?
Sim, se você limitar a forma em vez do conjunto. Permita tráfego GET amplo através de um proxy que proíba corpos de requisição e limite tamanhos: o agente lê muito sem ter um canal largo o bastante para tirar o que leu.
O DNS precisa entrar na lista?
Precisa. Um resolvedor que o agente consulta livremente é um canal de exfiltração: dados codificados em consultas de subdomínio saem sem uma única requisição HTTP. Roteie o DNS pela mesma política.
Já temos ferramentas com privilégio mínimo. Isto é redundante?
Não; cobrem metades diferentes. O privilégio mínimo limita o que o agente pode fazer; o controle de saída limita para onde pode ir o que ele já leu. Um agente somente leitura com saída aberta ainda vaza tudo o que consegue ler.

Referências