Riscos de Exfiltração de DNS em Sandboxes de Agentes de IA

O risco de exfiltração de DNS é importante quando o código em sandbox pode resolver domínios controlados por atacantes ou usar DNS como um canal de dados de saída, portanto, as equipes devem avaliar a política de DNS, o registro em log, os caminhos de busca de pacotes e as evidências de incidentes antes de confiar uma sandbox de agente de IA com fluxos de trabalho sensíveis.

Por que o DNS é importante nos modelos de ameaça de sandbox

As sandboxes de agentes de IA são construídas para autonomia útil. Um agente de codificação pode executar testes, instalar pacotes, chamar APIs, iniciar um navegador, inspecionar arquivos e produzir artefatos sem que um humano aprove cada comando. Essa flexibilidade é exatamente a razão pela qual o comportamento de rede precisa de sua própria revisão, separada do isolamento de CPU, memória, sistema de arquivos e processos.

O DNS muitas vezes recebe menos atenção do que a saída HTTP porque parece ser infraestrutura básica. As aplicações precisam de resolução de nomes para alcançar APIs, registros, páginas web e endpoints de atualização. Mas o DNS ainda é comunicação de saída. Uma sandbox que pode resolver domínios arbitrários pode revelar informações através de nomes de consulta, contatar infraestrutura controlada por atacantes ou criar um ponto cego se o tráfego DNS não for registrado com o mesmo cuidado que as solicitações web.

Isso não é uma categoria teórica inventada para agentes de IA. O MITRE ATT&CK documenta o DNS como um protocolo de camada de aplicação que os adversários podem usar para comunicação de comando e controle, e documenta separadamente a exfiltração sobre protocolos alternativos quando os dados saem por um canal que não é o protocolo principal da aplicação. Para avaliadores de sandbox, a lição é direta: não trate o DNS como inofensivo só porque não é um HTTP POST.

Para agentes de IA, o risco geralmente vem de uma cadeia de pequenas permissões, em vez de um erro óbvio:

Capacidade da sandbox	Por que as equipes permitem	Pergunta relacionada ao DNS
Instalação de pacotes	Permitir que agentes instalem dependências ausentes	Quais registros e caminhos de resolução são permitidos?
Acesso à web	Permitir que agentes de navegador coletem contexto público	O código pode resolver qualquer domínio ou apenas domínios aprovados?
Chamadas de API	Permitir que agentes integrem com backends de aplicativos	Os domínios internos e endpoints de metadados estão bloqueados?
Ferramentas de construção	Permitir que agentes de codificação executem testes realistas	Scripts pós-instalação podem acionar consultas inesperadas?
Sessões de longa duração	Permitir que agentes continuem tarefas de várias etapas	Os logs de DNS são retidos durante todo o ciclo de vida da sessão?

O objetivo não é proibir toda chamada de rede. Muitas cargas de trabalho de agentes precisam de acesso de rede controlado. O objetivo é saber quais caminhos existem, quais caminhos estão bloqueados e quais evidências você teria se uma tarefa se comportasse inesperadamente.

Onde a resolução de DNS aparece nos fluxos de trabalho dos agentes

As revisões de segurança frequentemente perguntam se uma sandbox tem acesso à internet. Essa pergunta é muito ampla. Uma revisão melhor começa mapeando todos os lugares onde código, ferramentas, gerenciadores de pacotes ou navegadores podem acionar a resolução de nomes.

Caminhos comuns de DNS incluem:

• Solicitações diretas de código de Python, JavaScript, scripts de shell, SDKs e suítes de teste.
• Automação de navegador que carrega páginas, subrecursos, fontes, imagens, scripts de análise e redirecionamentos.
• Gerenciadores de pacotes como npm, pip, uv, pnpm, apt, cargo ou instaladores de plugins específicos de linguagem.
• Ferramentas de construção que buscam binários, modelos, drivers de navegador, arquivos de modelo ou fixtures de teste.
• Ferramentas de agente que chamam APIs de terceiros ou endpoints de webhook.
• Trabalhos em segundo plano que continuam em execução após a etapa visível do agente ter retornado.

Esse mapeamento deve incluir tráfego intencional e incidental. Um desenvolvedor pode apenas pedir a um agente para executar um teste unitário, mas o comando de teste pode instalar um pacote, o gerenciador de pacotes pode resolver um domínio de registro e um script de ciclo de vida pode contatar um host separado. Uma tarefa de navegador pode ser limitada a um site público, enquanto recursos incorporados resolvem muitos domínios adicionais.

Para um provedor de sandbox, a resposta mais forte não é apenas “o acesso à rede está disponível” ou “o acesso à rede está isolado”. A resposta útil explica o caminho de resolução:

• O DNS da sandbox usa um resolvedor controlado pelo provedor, controlado pelo cliente, resolvedor VPC ou resolvedor público?
• O cliente pode restringir domínios, faixas de IP, portas ou protocolos?
• As solicitações de DNS são registradas por sandbox, por sessão, por comando ou apenas em uma camada de rede agregada?
• As consultas negadas são registradas, ou apenas as consultas permitidas?
• Os clientes podem separar o DNS de busca de pacotes do DNS de tempo de execução?

Se esses detalhes não estiverem disponíveis, trate-os como itens de avaliação em aberto, não como prova de que a sandbox é insegura. O risco prático depende da sensibilidade da carga de trabalho, dos segredos disponíveis dentro da sandbox, da política de saída e da qualidade das evidências forenses.

Como avaliar a política de saída

A política de saída é a superfície de controle que decide se o DNS se torna um encanamento de rotina ou um caminho de fuga não revisado. Uma política madura deve responder a três perguntas: o que é permitido, por que é permitido e como as exceções são aprovadas.

Comece com a postura padrão. Uma sandbox usada para código gerado por IA não confiável não deve herdar o mesmo acesso de rede amplo que um laptop de desenvolvedor. Se o padrão for saída aberta, pergunte se o produto suporta restringir esse acesso para cargas de trabalho de maior risco. Se o padrão for saída restrita, pergunte como os desenvolvedores habilitam os domínios exatos necessários para uma tarefa.

Em seguida, separe a política de DNS da política de HTTP. Alguns sistemas impõem listas de permissão HTTP, mas deixam a resolução de nomes ampla. Isso pode criar uma incompatibilidade: uma solicitação para um host não aprovado pode falhar na camada HTTP, mas a consulta DNS ainda sai do ambiente e ainda pode carregar metadados no nome consultado. Um design mais rigoroso avalia a resolução e as tentativas de conexão juntas.

Para revisões de segurança, use uma matriz de política como esta:

Área de avaliação	O que perguntar	Evidência mais forte
Saída padrão	O acesso à rede de saída é aberto, negado ou limitado por modelo?	Política padrão por escrito mais um resultado de teste no nível da sandbox
Caminho do resolvedor DNS	Qual resolvedor lida com o DNS da sandbox?	Diagrama de arquitetura ou prova de configuração
Listas de permissão de domínio	As equipes podem permitir apenas registros e APIs aprovados?	Exemplo de configuração e exemplo de log de negação
Bloqueios de IP e rede privada	As faixas internas e serviços de metadados são bloqueados por padrão?	Regras de negação documentadas e evidência de teste
Controles de protocolo	DNS, HTTP, HTTPS e sockets brutos são controlados separadamente?	Modelo de política, não apenas redação de marketing
Fluxo de exceção	Quem pode adicionar domínios ou relaxar a política?	Aprovação baseada em função e registro de auditoria

Para a maioria das equipes, o primeiro alvo prático não é um ambiente de saída zero perfeito. É um perfil de saída mínima documentado: registros de pacotes aprovados, domínios de API aprovados, sem acesso a redes internas a menos que explicitamente roteado, e logs para tentativas permitidas e negadas.

Buscas de pacotes e DNS orientado por dependências

A instalação de pacotes é uma das maneiras mais fáceis de subestimar a saída da sandbox. O código gerado por agente frequentemente falha em dependências ausentes, e a experiência de desenvolvedor mais rápida é deixar o agente instalar o que precisa. Essa conveniência cria um segundo problema de cadeia de suprimentos: nomes de pacotes, redirecionamentos de registro, scripts de instalação e downloads binários podem acionar DNS e atividade de rede que o prompt original nunca mencionou.

A orientação de aplicação LLM da OWASP destaca riscos em torno de agência excessiva e exposição da cadeia de suprimentos. Em sandboxes de agentes, esses riscos se encontram na instalação de pacotes. Um modelo pode ter permissão para escolher comandos. Um comando pode invocar um gerenciador de pacotes. O gerenciador de pacotes pode buscar código de um registro. O pacote buscado pode executar hooks de instalação. Cada etapa pode criar consultas DNS e conexões de saída.

A avaliação defensiva deve focar na governança, não na mecânica de exploração:

• Prefira arquivos de dependência fixados para tarefas de agente repetíveis.
• Use registros aprovados ou caches de pull-through para ecossistemas comuns.
• Registre nome do pacote, versão, URL do registro, domínios resolvidos e hashes de artefatos quando prático.
• Separe a permissão de instalação de pacotes do acesso geral à internet em tempo de execução.
• Exija aprovação antes de instalar pacotes fora de uma lista de permissão para espaços de trabalho sensíveis.
• Considere modelos de sandbox pré-construídos para stacks comuns, para que os agentes não precisem de acesso amplo à rede durante cada execução.

A distinção importante é que “busca de pacote” não é um controle único. Inclui resolução DNS, autenticação de registro, download de artefatos, execução de código em tempo de instalação e comportamento de cache. Uma boa revisão de sandbox pergunta sobre todo o caminho.

Suposições sobre segredos e exposição de dados

A exfiltração de DNS só importa se houver algo significativo para vazar. Isso torna o posicionamento de segredos e o escopo de dados parte da revisão de DNS.

As sandboxes de agentes de IA devem ser tratadas como workers de construção não confiáveis, a menos que provado o contrário. Não coloque credenciais de produção de longa duração, tokens de nuvem amplos, dados de clientes ou código-fonte interno em uma sandbox apenas porque a sandbox está isolada do host. O isolamento reduz o raio de explosão, mas não torna todos os comandos seguros.

Use estas suposições ao projetar fluxos de trabalho de maior risco:

• Qualquer arquivo legível pelo código executado pelo agente pode ser incluído em logs, saídas, solicitações de rede ou mensagens de erro.
• Qualquer variável de ambiente visível para um processo pode ser copiada por esse processo.
• Qualquer canal de saída permitido para a sandbox merece a mesma revisão de perda de dados, incluindo DNS.
• Qualquer instrução injetada por prompt em um fluxo de trabalho de navegador ou documento pode tentar influenciar o uso de ferramentas.
• Qualquer sessão de longa duração aumenta o valor dos logs de ciclo de vida e da expiração de tokens.

Os controles práticos incluem credenciais de curta duração, chaves de API com privilégios mínimos, contas de serviço com escopo, segredos por tarefa, logs com dados redigidos e separação explícita entre tarefas de pesquisa de dados públicos e tarefas de execução de código sensível.

Logs, trilhas de auditoria e evidências de incidentes

Os controles de DNS só são úteis se as equipes puderem verificá-los. Quando uma tarefa de sandbox é suspeita, as equipes de segurança precisam de evidências rapidamente: o que foi executado, o que foi resolvido, o que se conectou, quais arquivos mudaram e quais saídas foram retornadas.

No mínimo, pergunte se a plataforma pode reconstruir esses eventos para uma sessão específica de sandbox:

• Hora de criação da sandbox, modelo, configuração de recursos e proprietário.
• Comandos executados pelo agente ou usuário.
• Arquivos lidos, escritos, enviados ou baixados quando o produto expõe operações de arquivo.
• Instalações de pacotes e buscas de registro.
• Consultas DNS, incluindo timestamp, nome consultado, resultado e identificador de sandbox/sessão.
• Tentativas de conexão de saída, incluindo host de destino, IP, porta, protocolo, resultado de permitir/negar e volume quando disponível.
• Chamadas de ferramenta, eventos de navegação do navegador e processos em segundo plano.
• Eventos de injeção de segredos sem expor valores de segredo nos logs.
• Eventos de término, pausa, retomada, snapshot e limpeza da sessão.

Não peça apenas logs de tráfego bem-sucedido. Eventos negados são frequentemente mais úteis para avaliar se a política funcionou. Se uma sandbox tenta resolver um domínio não aprovado e a política o bloqueia, essa consulta negada é a evidência que separa um controle funcional de uma falha silenciosa.

A retenção também importa. Uma janela de log de sete dias pode ser suficiente para depuração, mas fraca para resposta a incidentes. Equipes com cargas de trabalho regulamentadas ou sensíveis a clientes devem alinhar a retenção de telemetria da sandbox com sua política de registro de segurança mais ampla.

Notas de avaliação da Novita Agent Sandbox

A Novita Agent Sandbox é projetada para fluxos de trabalho de agentes de IA que precisam de execução de código isolada, automação de navegador, tarefas no estilo computer-use, sessões de longa duração e cargas de trabalho de avaliação ou aprendizado por reforço. A visão geral da Novita Agent Sandbox é o ponto de partida certo para o comportamento atual do produto, e a página do produto Agent Sandbox descreve o encaixe mais amplo da plataforma.

Ao avaliar a Novita ou qualquer outro provedor de sandbox para cargas de trabalho sensíveis a DNS, separe dois tipos de declarações:

• Adequação do produto: se a sandbox suporta o fluxo de trabalho do agente que você precisa, como execução de código, automação de navegador ou tarefas de longa duração.
• Evidência de controle de segurança: se os controles exatos de DNS, saída, busca de pacotes, segredos e logs atendem à sua política interna.

Essa separação evita alegações excessivas. Uma sandbox pode ser uma forte adequação para execução de agente e ainda exigir uma revisão específica do cliente para política de DNS, caminho do resolvedor, listas de permissão, retenção de auditoria e fluxos de trabalho de incidentes. As equipes de segurança devem solicitar documentação atual ou confirmação do produto para esses detalhes de controle antes de aprovar cargas de trabalho sensíveis.

Para equipes que já usam modelos Novita AI, a adequação da plataforma é que as APIs de modelo e a infraestrutura de execução de agente podem ser avaliadas juntas. Isso pode reduzir a dispersão operacional, mas não elimina a necessidade de um modelo de ameaça. Trate a sandbox como um ambiente de execução controlado, defina qual acesso de rede cada classe de agente precisa e valide que as evidências de controle correspondem ao risco dos dados colocados dentro.

Lista de verificação de revisão de segurança

Use esta lista de verificação antes de aprovar cargas de trabalho de sandbox de agente de IA que possam tocar em código sensível, credenciais, dados de clientes ou sistemas internos.

Pergunta de revisão	Por que é importante
O que a sandbox pode resolver por padrão?	O DNS pode ser um sinal de saída mesmo quando o HTTP está bloqueado.
O DNS pode ser restrito por domínio, modelo, espaço de trabalho ou política de VPC?	Fluxos de trabalho sensíveis precisam de padrões mais restritos do que tarefas de pesquisa pública.
As consultas DNS são registradas por sessão de sandbox?	A resposta a incidentes precisa de atribuição, não apenas métricas agregadas do resolvedor.
As tentativas de DNS e conexão negadas são registradas?	Eventos negados provam que a política bloqueou comportamento inesperado.
Os registros de pacotes são permitidos ou proxyzados?	Gerenciadores de pacotes podem acionar DNS e downloads orientados por dependências.
As instalações de pacotes podem ser separadas do acesso de rede em tempo de execução?	O risco em tempo de construção e em tempo de execução são diferentes.
As faixas de IP internas e endpoints de metadados estão bloqueados?	Os agentes não devem descobrir ou contatar planos de controle de infraestrutura por acidente.
Como os segredos são injetados, escopados, rotacionados e redigidos?	A revisão de DNS está incompleta se segredos de longa duração estiverem disponíveis para o código em sandbox.
Os subrecursos do navegador são visíveis nos logs?	Agentes de navegador podem resolver mais domínios do que a URL de nível superior.
Que evidência está disponível após pausa, retomada, snapshot ou limpeza?	Sessões de longa duração precisam de telemetria com consciência de ciclo de vida.
Quem pode relaxar a política de saída?	Mudanças de exceção devem ser auditáveis.
Como as sessões suspeitas são preservadas?	A limpeza não deve apagar a única evidência útil de incidente.

Se várias respostas forem desconhecidas, mantenha a carga de trabalho fora da sandbox até que o provedor ou a equipe interna da plataforma possa documentar o caminho de controle. Se a carga de trabalho lida apenas com dados públicos e não usa segredos, as mesmas lacunas podem ser aceitáveis durante a prototipagem inicial, mas ainda devem ser rastreadas antes do uso em produção.

Conclusão

Para sandboxes de agentes em produção, revise o DNS como parte da saída, não como uma nota de rodapé. A configuração defensável mínima é uma política de saída com escopo, governança explícita de busca de pacotes, segredos de curta duração, logs de DNS e conexão por sessão e um fluxo de trabalho de incidente testado para preservar evidências.

Use acesso de rede mais amplo apenas para protótipos de baixo risco quando os dados não forem sensíveis e o agente não tiver segredos significativos. Para bases de código sensíveis, dados de clientes, APIs internas ou fluxos de trabalho regulamentados, exija um perfil de saída mínima e evidências atuais do provedor antes de conceder aos agentes execução autônoma.

FAQ

A exfiltração de DNS é relevante se a sandbox bloquear HTTP?

Sim. Os controles de HTTP e DNS são camadas diferentes. Uma sandbox pode bloquear solicitações web de saída enquanto ainda permite consultas DNS. As equipes de segurança devem verificar tanto a política de resolução quanto a política de conexão.

As sandboxes de agentes de IA devem ficar sem acesso à internet?

Nem sempre. Muitas tarefas úteis de agente precisam de registros de pacotes, documentação pública, APIs ou acesso ao navegador. O objetivo mais seguro é uma saída mínima e explicável: permita o que a tarefa precisa, negue o que não precisa e registre a atividade permitida e negada.

Instalações de pacotes são o mesmo que acesso geral à rede?

Não. As instalações de pacotes merecem uma política separada porque envolvem registros, resolução de dependências, downloads de artefatos e, às vezes, scripts em tempo de instalação. Uma equipe pode permitir buscas de pacotes através de um cache aprovado enquanto nega saída arbitrária em tempo de execução.

Quais logs são mais importantes para o risco de DNS?

Os logs mais úteis conectam uma consulta DNS a uma sandbox, comando, tempo, usuário ou fluxo de trabalho do agente e decisão de política específicos. Logs de consultas negadas são especialmente importantes porque mostram se o controle realmente funcionou.

Um provedor de sandbox pode garantir que não haverá exfiltração de dados?

Tenha cuidado com garantias absolutas. Um provedor pode oferecer isolamento, controles de rede, registro em log e opções de configuração, mas o risco final depende do design da carga de trabalho, segredos, posicionamento de dados, política de saída e monitoramento operacional.

Artigos recomendados

• Como as Sandboxes de Agentes Impulsionam a Inovação Segura e Escalável em IA
• Construindo um Agente de Codificação com a Agent Sandbox da Novita
• Construa um Servidor MCP de Execução Remota de Código com a Novita Sandbox e a Biblioteca mcp-use