- Por que Sandboxes de Agentes de IA Precisam de Logs de Auditoria Diferentes
- Logs de Execução de Comandos e Processos
- Eventos de Acesso ao Sistema de Arquivos
- Chamadas de Rede de Saída e Logs de Egress
- Eventos de Instalação de Pacotes
- Invocações de Ferramentas e Resultados
- Eventos do Ciclo de Vida da Sessão
- Eventos de Limite de Recursos
- Formatos de Log Estruturados vs Não Estruturados
- Integridade do Log e Evidência de Violação
- Políticas de Retenção de Logs de Auditoria para Sandboxes de Agentes de IA
- Disponibilizando Logs para Resposta a Incidentes
- O que Perguntar ao seu Provedor de Sandbox
- Conclusão
- FAQ
- Artigos recomendados
Os logs de auditoria para sandboxes de agentes de IA devem capturar a execução de comandos e processos, leituras e gravações de arquivos, chamadas de rede de saída e destinos de egress, eventos de instalação de pacotes, invocações de ferramentas, resumos de entrada e saída de modelos no nível da sessão, limites de recursos atingidos e eventos do ciclo de vida da sessão. Sem essa cobertura, uma equipe de segurança não consegue reconstruir o que um agente fez, rastrear uma invasão ou satisfazer uma revisão pós-incidente. Lacunas em qualquer uma dessas categorias deixam pontos cegos que são difíceis ou impossíveis de fechar retroativamente.
Por que Sandboxes de Agentes de IA Precisam de Logs de Auditoria Diferentes
Os logs de auditoria tradicionais de servidores assumem que uma ação foi desencadeada por um humano ou por um processo de aplicação determinístico. Agentes de IA quebram essa suposição. Um único prompt pode fazer com que uma sessão instale pacotes, escreva arquivos, execute comandos de shell, chame APIs externas e gere subprocessos — tudo em segundos, sem aprovação humana para etapas individuais.
Isso muda o que um log de auditoria precisa responder. Para um servidor tradicional, a pergunta geralmente é “um usuário autorizado alterou este arquivo?”. Para um sandbox de agente, as perguntas são:
- O que o modelo decidiu executar, e em qual ordem?
- Quais comandos de shell foram executados e como quais processos?
- O agente acessou arquivos que não deveria tocar?
- O que saiu do sandbox pela rede, e para onde foi?
- Uma instalação de pacote introduziu código inesperado?
- O que o agente estava fazendo quando atingiu um limite de recursos ou foi encerrado?
Um sistema de logs que possa responder a essas perguntas dá às equipes de segurança a capacidade de reconstrução de que precisam. Um sistema que não consiga deixa a resposta a incidentes no palpite.
Logs de Execução de Comandos e Processos
A execução de processos é a categoria de maior prioridade. Cada comando que o agente executa — diretamente ou por meio de um subprocesso de shell — deve produzir uma entrada de log que inclua: o nome do processo e a lista completa de argumentos, o processo pai e PID, o usuário e UID efetivo, o diretório de trabalho, o timestamp com precisão de submilissegundos e o código de saída.
Sem a lista de argumentos, comandos como python, curl, ou bash são quase sem sentido em uma rastreabilidade pós-incidente. Sem o UID, você não pode dizer se o agente foi executado com privilégios elevados. Sem a cadeia de PID pai, você não pode reconstruir subprocessos aninhados ou entender como um comando foi invocado.
Subsistemas de auditoria Linux como auditd com regras de chamada de sistema apropriadas (execve, execveat) podem capturar isso no nível do kernel dentro de uma guest de microVM. Sandboxes baseados em container podem usar rastreamento baseado em eBPF ou logging de seccomp como alternativa, embora cada abordagem tenha diferentes coberturas e trade-offs de desempenho. O requisito chave da perspectiva da equipe de segurança é que o log seja gerado abaixo da camada de aplicação — um processo agente que controla seu próprio log não pode ser confiável para relatar seu próprio comportamento com precisão.
Eventos de Acesso ao Sistema de Arquivos
A cobertura de auditoria do sistema de arquivos deve registrar leituras, gravações, exclusões, renomeações e operações de montagem. Para cada evento, o log deve incluir: o tipo de operação, o caminho completo, o processo e PID responsável, o UID e o timestamp.
Na prática, registrar cada leitura de arquivo em um sandbox ocupado pode gerar alto volume. As equipes de segurança geralmente restringem isso a caminhos sensíveis — por exemplo, qualquer caminho sob /etc, /root, o diretório de trabalho do agente, locais de arquivos de credenciais e segredos montados. Gravações e exclusões têm prioridade mais alta que leituras para a maioria dos modelos de ameaça, mas leituras de arquivos de credenciais ou configuração valem a pena serem capturadas independentemente.
Os eventos do sistema de arquivos são particularmente úteis para identificar tentativas de exfiltração de dados (grandes leituras seguidas de chamadas de rede de saída), alterações inesperadas de configuração (gravações em arquivos que o agente não deveria tocar) e comportamento de limpeza (exclusões executadas no final de uma sessão, que podem indicar uma tentativa de ocultar atividade).
Chamadas de Rede de Saída e Logs de Egress
O logging de egress é uma das áreas mais comumente subespecificadas em implantações de sandbox de agente. Muitos sandboxes registram que uma conexão de rede foi tentada; poucos registram para onde foi, qual protocolo foi usado e se teve sucesso.
Entradas completas de log de egress devem incluir: o endereço IP e porta de destino, o nome de domínio resolvido (consulta e resposta DNS), o protocolo (TCP, UDP, HTTP, etc.), os bytes transferidos em cada direção, o processo que abriu a conexão, o UID e o timestamp.
O logging de consultas DNS é separadamente importante. Um agente que consulta um domínio inesperado — mesmo que a conexão seja posteriormente bloqueada — é um sinal que vale a pena capturar. DNS sobre HTTPS pode contornar o logging de consultas a menos que o sandbox aplique política de rede em um nível que o intercepte.
Sandboxes que fornecem controles de egress baseados em lista de permissões devem registrar tentativas de conexão permitidas e bloqueadas. Um alto volume de tentativas bloqueadas para destinos inesperados é, por si só, um sinal de segurança significativo.
Eventos de Instalação de Pacotes
Instalações de pacotes são um alvo de auditoria de alto valor porque alteram o ambiente de runtime de maneiras que persistem pela duração da sessão e potencialmente afetam operações posteriores. Cada evento de instalação deve capturar: o gerenciador de pacotes invocado (pip, npm, apt, cargo, etc.), o nome do pacote, a versão solicitada, a versão resolvida, a URL de origem ou registro, o hash ou checksum do pacote, o processo e UID, e o timestamp.
A URL de origem é importante. Um pacote instalado de um registro privado, uma URL direta ou um mirror incomum tem um perfil de risco diferente de um instalado do registro público padrão. O hash é importante para verificação pós-incidente — se um pacote for posteriormente considerado malicioso, você quer saber se essa versão exata foi instalada em uma determinada sessão.
Sandboxes que bloqueiam completamente instalações de pacotes eliminam esta categoria de risco, mas também restringem significativamente o que os agentes podem fazer. A maioria das implantações de produção precisa de um caminho intermediário: registrar tudo, permitir instalações de uma lista de fontes aprovadas e sinalizar ou bloquear instalações de fontes desconhecidas.
Invocações de Ferramentas e Resultados
Agentes de IA normalmente operam através de um mecanismo de chamada de ferramenta onde o modelo solicita uma ação nomeada — executar código, ler arquivo, chamar API, pesquisar na web — e a camada de orquestração a executa. Essas invocações de ferramenta estão acima do nível do SO e são eventos de camada de aplicação, mas são importantes de registrar porque representam a intenção do modelo, não apenas a consequência no nível do sistema.
Os logs de invocação de ferramenta devem capturar: o nome da ferramenta, um resumo dos parâmetros de entrada (não o conteúdo completo se isso incluir segredos ou PII do usuário), um resumo do status do resultado (sucesso, erro, timeout), o ID da sessão e o timestamp.
Registrar a entrada e saída completa de cada chamada de ferramenta é útil para depuração, mas cria riscos de privacidade e vazamento de segredos. Uma abordagem prática é registrar nomes de ferramentas e status incondicionalmente, registrar resumos de entrada/saída em um nível de verbosidade configurável e fornecer uma maneira de recuperar detalhes completos para sessões específicas durante uma investigação com controles de acesso apropriados.
O objetivo é sinal suficiente para reconstruir a sequência de ações do agente sem criar um repositório de logs que se torne ele próprio um alvo de alto valor.
Eventos do Ciclo de Vida da Sessão
Eventos do ciclo de vida da sessão ancoram todas as outras entradas de log. Um ID de sessão que aparece em todo tipo de evento torna possível juntar logs entre categorias e responder “o que aconteceu nesta execução específica?”
Eventos do ciclo de vida a registrar:
| Evento | Campos chave |
|---|---|
| Criar sessão | ID da sessão, ID do usuário/tenant, nome do template ou imagem, configuração de recursos, timestamp |
| Iniciar sessão | ID da sessão, identificador do host, limites de recursos atribuídos, timestamp |
| Pausar sessão | ID da sessão, motivo (chamada de API, timeout, pausa automática), timestamp |
| Retomar sessão | ID da sessão, ator que retomou, timestamp |
| Encerrar sessão | ID da sessão, motivo do encerramento (normal, timeout, OOM, chamada de API, violação de política), status de saída, timestamp |
| Limpar sessão | ID da sessão, estado do sistema de arquivos na limpeza (preservado, deletado, snapshot salvo), timestamp |
O motivo do encerramento é especialmente útil pós-incidente. Uma sessão que terminou devido a uma violação de política, um kill OOM ou um sinal inesperado em vez de uma saída limpa merece ser examinada mais de perto. Sessões que foram pausadas e retomadas merecem ser examinadas quanto à continuidade de estado — algo mudou no ambiente entre a pausa e a retomada?
Eventos de Limite de Recursos
Eventos de limite de recursos capturam momentos em que uma sessão atingiu um teto configurado e o sistema tomou uma ação. Esses eventos sinalizam ou comportamento normal de alta carga ou algo mais preocupante — um processo descontrolado, um burst de computação inesperado ou uma tentativa deliberada de exaurir recursos.
Entradas de log para eventos de limite de recursos devem incluir: o tipo de limite (throttle de CPU, OOM de memória, cota de disco, limite de taxa de rede, timeout), o valor medido no momento do evento, o limite configurado, a ação tomada (throttle, kill, aviso), o processo ou sessão afetado e o timestamp.
Kills OOM merecem particular atenção porque podem indicar um agente tentando uma computação grande que não era esperada, um pacote que carregou dados inesperadamente grandes ou um vazamento de memória. Eventos de throttle de CPU em uma sessão que deveria estar apenas fazendo chamadas leves de LLM podem indicar que algo mais está sendo executado dentro do sandbox.
Formatos de Log Estruturados vs Não Estruturados
Logs não estruturados — linhas de texto livre como 2026-06-29 10:04:00 INFO: process python started — são legíveis, mas difíceis de consultar, agregar ou integrar com um SIEM ou pipeline de alerta. Para fins de auditoria, eles exigem parsing que quebra quando o formato do log muda.
Logs estruturados — tipicamente JSON ou um formato de esquema comum como CEF ou OCSF — permitem que cada campo seja indexado, consultado e alertado diretamente. Um evento execve estruturado que inclui {"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0} é imediatamente consultável por qualquer um de seus campos.
Para equipes de segurança avaliando um provedor de sandbox, as perguntas chave são:
- Os logs são estruturados ou não estruturados?
- Qual esquema ou formato é usado, e está documentado?
- Os logs podem ser transmitidos em tempo real para um SIEM externo ou sistema de agregação de logs?
- Qual é a latência entre um evento e sua disponibilidade no fluxo de logs?
A transmissão em tempo real ou quase real é importante para casos de uso de detecção. Um log que só está disponível horas após o término de uma sessão é útil para reconstrução de incidentes, mas não para alertas ao vivo.
Integridade do Log e Evidência de Violação
Um log de auditoria que o agente pode modificar não é um log de auditoria. Este é o requisito de evidência de violação: o log deve ser gerado e armazenado de forma que o processo agente não possa alterar, excluir ou suprimir suas próprias entradas.
No nível de implementação, isso normalmente significa:
- Geração de log no nível do kernel (subsistema de auditoria, eBPF) em vez de logging no nível da aplicação dentro do sandbox
- Envio de log para um destino externo que o processo sandbox não pode alcançar
- Armazenamento de log write-once ou append-only sem API de exclusão acessível a partir da rede do sandbox
- Entradas de log assinadas ou com checksum na geração para que violação ou truncamento seja detectável posteriormente
Para provedores de sandbox gerenciados, a pergunta relevante é se o processo do agente tem algum caminho para modificar a entrega do log. Se os logs são escritos em um arquivo dentro do sandbox e depois enviados, um processo agente suficientemente privilegiado pode interferir no envio. Se os logs são gerados no nível do hypervisor ou host e enviados fora da banda, o agente não tem acesso.
A cadeia de custódia para dados de log — particularmente importante para conformidade ou revisão legal — exige que o caminho de coleta do log, os controles de acesso ao armazenamento e quaisquer transformações aplicadas a eventos brutos sejam documentados e auditáveis por si só.
Políticas de Retenção de Logs de Auditoria para Sandboxes de Agentes de IA
Os requisitos de retenção para logs de auditoria de sandboxes de agentes de IA dependem do ambiente regulatório, do perfil de risco das cargas de trabalho e do cronograma de resposta a incidentes que a equipe de segurança precisa apoiar.
Pontos de partida práticos para equipes de segurança avaliarem:
| Caso de uso | Retenção mínima sugerida |
|---|---|
| Investigação ativa de incidentes | Armazenamento quente/consultável por pelo menos 90 dias |
| Perícia pós-incidente | Disponível em armazenamento frio por 12–24 meses |
| Revisão de conformidade (SOC 2, ISO 27001) | De acordo com os requisitos do framework aplicável |
| Preservação legal | Até ser explicitamente liberada |
Para cargas de trabalho de agentes de IA, 90 dias de armazenamento quente é uma linha de base significativa porque padrões de comprometimento em agentes autônomos podem não ser descobertos imediatamente — um agente que exfiltrou dados durante uma sessão há três semanas pode não ser identificado até que uma anomalia downstream seja notada.
O volume é um fator de custo real. Um sandbox executando milhares de sessões por dia com logging completo de execve e rede pode gerar dados significativos. Armazenamento em camadas — quente para dados recentes, morno para médio prazo, frio para arquivamento — é uma abordagem comum. Compressão e filtragem em nível de campo (logging apenas de tipos de evento de alta prioridade com fidelidade total) também valem a pena considerar, com o trade-off de que logs filtrados podem perder tipos de evento inesperados.
Disponibilizando Logs para Resposta a Incidentes
Coletar logs é necessário, mas não suficiente. Logs que ficam em um bucket que ninguém consulta não oferecem proteção. Para equipes de segurança, o requisito operacional é ser capaz de responder a perguntas específicas rapidamente:
- O que a sessão X fez entre o tempo T1 e T2?
- Quais sessões acessaram o caminho P?
- Quais sessões fizeram conexões de saída para o domínio D?
- Quais sessões instalaram o pacote V?
- Quais sessões terminaram com o motivo R?
Isso requer uma interface de consulta — seja uma integração SIEM, uma plataforma de análise de logs ou uma API fornecida pelo provedor — onde ID da sessão, tipo de evento, intervalo de timestamp, caminho, domínio e outros campos chave sejam indexados e pesquisáveis.
Alertas sobre padrões específicos são a segunda camada. Sinais de alta prioridade para sandboxes de agentes de IA incluem: execução de comandos conhecidos como perigosos (curl | bash, wget -O - | sh, base64 -d | sh), conexões de saída para domínios inesperados ou recém-registrados, instalações de pacotes de URLs não-registro, eventos de gravação para caminhos de arquivos de credenciais, sessões que terminam com violação de política ou kill OOM, e qualquer evento ocorrendo sob UID 0 quando o agente não deveria estar sendo executado como root.
Regras de detecção pré-construídas calibradas para padrões de comportamento de agentes reduzem o tempo para o primeiro alerta de atividade nova. Equipes de segurança avaliando provedores de sandbox devem perguntar se o provedor fornece regras de detecção, documentação de esquema de log e integrações SIEM de exemplo, ou se construir essa camada é deixado inteiramente para o cliente.
O que Perguntar ao seu Provedor de Sandbox
Ao avaliar um sandbox de agente de IA quanto à cobertura de logs de auditoria, estas são as perguntas concretas que valem a pena fazer a um provedor:
- Quais categorias de evento são registradas por padrão, e quais requerem configuração?
- Os logs são gerados no nível do kernel/hypervisor ou dentro do processo sandbox?
- Qual formato de log estruturado é usado, e o esquema é documentado publicamente?
- Os logs podem ser transmitidos em tempo real para um destino externo?
- Qual é a política de retenção de dados, e pode ser estendida?
- O processo sandbox tem algum caminho para modificar ou suprimir suas próprias entradas de log?
- As entradas de log são assinadas ou de outra forma à prova de violação?
- Existe uma API de consulta ou integração SIEM disponível?
- Existem regras de detecção pré-construídas ou modelos de alerta para padrões comuns de ameaças em sandbox?
Nenhuma implantação de sandbox é completa em logging por padrão. Lacunas entre o que um provedor coleta e o que uma equipe de segurança precisa para reconstruir um incidente são comuns. Identificar essas lacunas antes da implantação, e não após um incidente, é o retorno prático deste tipo de avaliação.
O Novita Agent Sandbox fornece eventos de ciclo de vida da sessão, logs de execução e métricas de recursos acessíveis através de sua API. Equipes de segurança avaliando o Novita Agent Sandbox devem verificar a cobertura atual de logs, opções de exportação e configuração de retenção na documentação do produto antes de tomar decisões de arquitetura.
Conclusão
O logging de auditoria para sandboxes de agentes de IA não é um recurso que você pode adaptar após um incidente. As categorias de evento que importam — execução de processos, acesso ao sistema de arquivos, tráfego de saída, instalações de pacotes, invocações de ferramentas, ciclo de vida da sessão e limites de recursos — precisam estar em escopo antes que uma carga de trabalho entre em produção, e o caminho de coleta do log precisa estar fora do alcance do agente.
O checklist prático para equipes de segurança é direto: identifique quais categorias de evento seu provedor de sandbox captura por padrão, confirme que os logs são gerados no nível do kernel ou hypervisor em vez de dentro do processo agente, verifique se a saída estruturada está disponível para integração SIEM e estabeleça políticas de retenção antes de precisar delas para uma investigação.
Lacunas em qualquer uma dessas áreas são lacunas em sua capacidade de responder “o que este agente fez?” — e para agentes autônomos operando em escala, essa pergunta eventualmente precisará de uma resposta.
FAQ
Quais eventos os logs de auditoria de sandbox de agente de IA devem capturar?
No mínimo: execução de comandos e processos (com listas completas de argumentos), leituras/gravações/exclusões do sistema de arquivos, conexões de rede de saída e consultas DNS, eventos de instalação de pacotes com URLs de origem e hashes, invocações de ferramentas e status de resultado, eventos de ciclo de vida da sessão (criar, pausar, retomar, encerrar, limpar) e eventos de limite de recursos (throttle de CPU, kill OOM, timeout). A falta de qualquer uma dessas categorias deixa pontos cegos que não podem ser reconstruídos posteriormente.
Por que não posso confiar no logging no nível da aplicação dentro do sandbox?
Um processo agente que controla seu próprio logging pode suprimir ou modificar entradas sobre seu próprio comportamento — intencionalmente ou através de um bug. A coleta no nível do kernel (via auditd, eBPF ou instrumentação do hypervisor) gera entradas de log abaixo da camada de aplicação, onde o agente não tem acesso de gravação. Este é o requisito de evidência de violação: o log deve ser gerado em um local que o agente não possa alcançar.
Por quanto tempo os logs de auditoria de sandbox de agente de IA devem ser retidos?
Uma linha de base prática: 90 dias em armazenamento quente consultável para investigação ativa, 12–24 meses em armazenamento frio para perícia pós-incidente. Frameworks de conformidade como SOC 2 e ISO 27001 têm seus próprios requisitos que podem substituir essas linhas de base. Para preservação legal, a retenção deve continuar até ser explicitamente liberada pelo conselho jurídico.
Qual é a diferença entre logs de auditoria estruturados e não estruturados?
Logs não estruturados são linhas de texto livre que requerem parsing para consultar. Logs estruturados usam um esquema consistente (JSON, CEF, OCSF) onde cada campo é indexado e consultável diretamente. Para operações de segurança, logs estruturados são significativamente mais fáceis de integrar com plataformas SIEM, escrever regras de detecção e consultar durante a resposta a incidentes.
Um agente de IA pode violar seus próprios logs de auditoria?
Depende de onde os logs são gerados e armazenados. Se os logs são escritos em um arquivo dentro do sandbox e enviados externamente, um processo agente privilegiado pode interferir no pipeline de envio. Se os logs são gerados no nível do hypervisor ou host e escritos diretamente em um destino externo que a rede do sandbox não pode alcançar, o agente não tem caminho para modificá-los. Sempre verifique a arquitetura de coleta de logs, não apenas o formato do log.
O que devo procurar na documentação de log de auditoria de um provedor de sandbox?
Confirme: quais categorias de evento são registradas por padrão versus requerem configuração; se os logs são gerados no nível do kernel/hypervisor ou dentro do processo sandbox; qual formato estruturado e esquema é usado; se a transmissão em tempo real para sistemas externos é suportada; qual é a política de retenção padrão e se pode ser estendida; e se regras de detecção pré-construídas ou integrações SIEM estão disponíveis.
