Seu Scanner de Segurança Era o Ataque: Syscalls Revelam o Runtime dos Agentes

Em 19 de março, alguém empurrou uma versão comprometida do Trivy para o Docker Hub. Trivy é o scanner de vulnerabilidades open-source da Aqua Security — a ferramenta que organizações usam para encontrar dependências comprometidas. Durante quatro dias, o scanner de segurança foi o vetor de ataque. O payload: um infostealer que colhia segredos de CI/CD, credenciais de nuvem, chaves SSH e configurações Docker.

Na mesma semana, o Threat Research Team da Sysdig publicou uma análise em nível de syscall de agentes de codificação com IA. Eles conectaram sondas eBPF ao Claude Code, Gemini CLI e Codex CLI e observaram o que acontece no nível do sistema operacional. Os números: 5 iterações do loop agêntico em 10 segundos. 64 eventos execve por sessão. Múltiplas conexões HTTPS de saída por iteração. Shells bash descartáveis nascendo e morrendo mais rápido do que qualquer humano consegue digitar.

Esses dois eventos estão conectados de uma forma que a indústria ainda não compreendeu.

A camada que ninguém está observando

Já cobrimos segurança de agentes na camada de aplicação. O incidente de SQL injection da McKinsey demonstrou que agentes executando código gerado criam superfícies de ataque que modelos de segurança tradicionais não antecipam. A pesquisa de monitoramento de sessões da OpenAI mostrou que observar comportamento de agentes no nível aplicacional revela padrões sistemáticos de desalinhamento. Clinejection mapeou como injeção de prompt se propaga pela cadeia de suprimentos.

Todas essas análises compartilham um ponto cego. Operam acima do kernel.

A contribuição da Sysdig não é mais um framework de segurança em nível de aplicação. É visibilidade sobre o que agentes realmente fazem na máquina. Cada arquivo lido. Cada processo criado. Cada conexão de rede aberta. Cada arquivo de credencial tocado. O sistema operacional enxerga tudo, independentemente do que o sandbox do agente permite ou não.

O que eles encontraram: agentes de codificação com IA se comportam como nenhum software anterior. Ferramentas tradicionais de desenvolvimento abrem um terminal, executam comandos sequencialmente, mantêm estado. Agentes de IA criam shells descartáveis em velocidade de máquina. Cada shell executa um único comando, retorna o resultado e morre. O processo pai imediatamente cria outro. Cinco loops em dez segundos, cada loop potencialmente tocando o sistema de arquivos, a rede e a tabela de processos.

Sandboxes em nível de aplicação enxergam o processo do agente. Não enxergam os 64 processos filhos que ele criou, os arquivos que esses filhos leram, ou as conexões que abriram.

Trivy prova o modelo de ataque

Considere o comprometimento do Trivy através das lentes da Sysdig.

Uma organização instala o Trivy para escanear imagens de contêiner em busca de vulnerabilidades. Trivy roda em pipelines de CI/CD — ambientes com acesso a credenciais de deploy, tokens de nuvem e chaves SSH. A versão comprometida colhia exatamente esses ativos.

Agora adicione agentes de IA ao cenário. Um agente rodando em um ambiente de desenvolvimento pode invocar o Trivy como parte de uma verificação de segurança. O agente não sabe que o Trivy está comprometido. O sandbox em nível de aplicação também não — Trivy é uma ferramenta aprovada no pipeline. O modelo de permissões do agente diz “autorizado a executar scanners de segurança”. O scanner é o malware.

Monitoramento em nível de syscall veria. O binário legítimo do Trivy lê camadas de imagens de contêiner e grava relatórios de scan. O Trivy comprometido lê camadas de imagens, grava relatórios, e também lê ~/.ssh/, ~/.docker/config.json e ~/.aws/credentials, depois abre conexões de saída para endereços IP que não têm nada a ver com bancos de dados de vulnerabilidades. Essa diferença comportamental é invisível na camada de aplicação. É óbvia na camada de syscall.

O CISO da Docker, Mark Lechner, confirmou que o comprometimento ficou ativo por quatro dias. Quatro dias durante os quais cada pipeline de CI/CD rodando a imagem comprometida estava exfiltrando credenciais. Segurança em nível de aplicação não tinha sinal nenhum. A ferramenta estava “funcionando corretamente” do ponto de vista da aplicação.

O problema das configurações de agentes

A pesquisa da Sysdig identifica uma vulnerabilidade específica que recebeu atenção insuficiente: arquivos de configuração de agentes armazenados em caminhos previsíveis.

Claude Code guarda sua configuração em ~/.claude/. Gemini CLI em ~/.gemini/. Codex CLI em ~/.codex/. Esses arquivos contêm chaves de API, preferências de modelo, permissões de ferramentas e prompts de sistema. Qualquer processo na máquina consegue lê-los.

Não é teórico. A Sysdig mapeou isso para MITRE ATT&CK T1552.001 (Credentials in Files) e ATLAS AML.T0056 (LLM Prompt Extraction). Uma dependência comprometida — como um Trivy com backdoor — rodando no mesmo contexto de usuário que um agente de IA consegue ler a configuração do agente, extrair suas chaves de API e modificar seu prompt de sistema. O agente continua operando normalmente. O sandbox em nível de aplicação não reporta anomalia.

O ataque SesameOp (documentado pelo Microsoft DART) e a exploração do Cursor IDE seguiram esse padrão. O comprometimento não aconteceu através da API do agente. Aconteceu através do sistema de arquivos, em uma camada que o próprio modelo de segurança do agente não consegue observar.

Por que sandboxes de aplicação são insuficientes

Claude Code roda com um modelo de permissões. Você aprova acesso a ferramentas. Pode restringir caminhos do sistema de arquivos. Codex CLI tem controles similares. São úteis e necessários.

Também são insuficientes.

Sandboxes em nível de aplicação impõem políticas sobre as ações do agente. O agente pede para ler um arquivo; o sandbox verifica se o arquivo está em um caminho permitido. O agente pede para executar um comando; o sandbox verifica se o comando é permitido. Funciona quando o agente é o ator.

Não funciona quando a ameaça opera dentro do processo do agente. Uma injeção de prompt que causa exfiltração de dados pelo agente usa as próprias permissões aprovadas do agente. Uma ferramenta comprometida que o agente invoca roda com as credenciais do agente. O sandbox vê um agente aprovado rodando uma ferramenta aprovada acessando um caminho aprovado. Tudo está permitido. Tudo é malicioso.

Monitoramento em nível de syscall não se importa com permissões. Se importa com comportamento. A pergunta não é “este agente tem permissão para ler ~/.ssh/?” A pergunta é “este agente já leu ~/.ssh/ antes? Esse padrão é consistente com sua operação normal? Essa conexão de saída é esperada?”

Baselines comportamentais no nível do kernel detectam o que modelos de permissão não conseguem.

A lacuna de governança

A Sysdig mapeia suas descobertas para quatro frameworks simultaneamente: MITRE ATLAS, MITRE ATT&CK, OWASP LLM Top 10 e Google SAIF. Esse mapeamento multi-framework revela algo importante: nenhum framework de segurança isolado cobre a superfície completa de ataque de agentes de codificação com IA.

ATLAS cobre ataques específicos de IA (injeção de prompt, extração de modelo) mas não comprometimento de infraestrutura. ATT&CK cobre ataques de infraestrutura mas não vetores específicos de IA. OWASP LLM Top 10 cobre vulnerabilidades em nível de aplicação mas não comportamento em nível de SO. Google SAIF fornece princípios arquiteturais mas não assinaturas de detecção.

A lacuna de governança é o espaço entre esses frameworks. Um ataque que combina injeção de prompt (ATLAS) com roubo de credenciais (ATT&CK) através de uma dependência comprometida na cadeia de suprimentos (OWASP) exige detecção em todas as camadas simultaneamente.

Monitoramento em nível de aplicação cobre as camadas ATLAS e OWASP. Monitoramento em nível de syscall cobre a camada ATT&CK. Você precisa dos dois. A maioria das organizações tem apenas o primeiro — quando tem algum.

O que governança de runtime realmente exige

A abordagem eBPF da Sysdig aponta para uma arquitetura específica de governança de runtime para agentes. Cinco componentes.

Baseline de syscalls. Perfile o comportamento normal de cada agente no nível do kernel. Quantos processos ele cria por iteração? Quais arquivos lê? Quais endpoints de rede contacta? Desvios da baseline são sinais, não ruído.

Integridade da cadeia de ferramentas. Todo binário que o agente invoca precisa de verificação. Não apenas no momento da instalação — no momento da execução. O comprometimento do Trivy estava na imagem do contêiner, não no código-fonte. Análise estática do repositório não encontraria nada. Verificação de hash em runtime do binário em execução teria capturado imediatamente.

Isolamento de credenciais. Configurações e credenciais de agentes não devem ser legíveis por processos arbitrários no mesmo contexto de usuário. Isso significa ir além de permissões de arquivo em direção a isolamento em nível de processo — namespaces, perfis seccomp ou cofres de credenciais dedicados que exigem autenticação explícita do agente.

Correlação entre camadas. Um trace em nível de aplicação mostrando “agente invocou scanner de segurança” combinado com um trace em nível de syscall mostrando “scanner de segurança leu chaves SSH e abriu conexão de saída inesperada” cria um sinal de detecção que nenhuma camada produz sozinha.

Política que atravessa frameworks. Política de segurança para agentes de IA precisa referenciar ATLAS, ATT&CK e OWASP simultaneamente. Uma política que só endereça injeção de prompt ignora roubo de credenciais. Uma política que só endereça segurança de infraestrutura ignora ataques específicos de IA. A pesquisa da Sysdig demonstra que comportamento real de agentes mapeia através de todos os frameworks concorrentemente.

O problema dos 64 execve

Sessenta e quatro execuções de processos em uma única sessão de agente. Esse número deveria reformular como organizações pensam sobre monitoramento de agentes.

Ferramentas tradicionais de EDR (Endpoint Detection and Response) são calibradas para atividade em velocidade humana. Um desenvolvedor pode executar uma dúzia de comandos numa sessão de terminal ao longo de uma hora. Um agente de IA executa 64 em segundos. A relação sinal-ruído se inverte. O que parece um pico de atividade suspeita é operação normal do agente. O que parece operação normal pode ser uma ferramenta comprometida se escondendo no ruído.

Ferramentas de EDR calibradas para comportamento humano vão gerar falsos positivos contínuos sobre atividade normal de agentes ou perder ameaças reais enterradas no volume. Nenhum resultado é aceitável.

Esse é o argumento central para monitoramento de syscalls específico para agentes. Não segurança de endpoint genérica aplicada a agentes. Análise comportamental construída sob medida que compreende o padrão de execução do agente: criação rápida de shells, execução de comando único, terminação imediata, repetição.

A convergência

Duas tendências estão se encontrando.

Ataques de cadeia de suprimentos estão subindo na pilha — de bibliotecas comprometidas para ferramentas de segurança comprometidas. O incidente do Trivy não é o primeiro e não será o último. Quando o scanner é o malware, segurança em nível de aplicação cria um ponto cego perfeito.

Agentes de IA estão descendo na pilha — de chamadas de API de alto nível para interação direta com o SO através de processos criados e operações no sistema de arquivos. Os 64 eventos execve não são um detalhe de implementação. São o modelo de execução fundamental.

A interseção dessas tendências é o desafio de governança para 2026. Seus agentes operam em velocidade de máquina abaixo das suas ferramentas de segurança. Suas ferramentas de segurança podem ser comprometidas acima dos seus agentes. A camada que consegue enxergar ambos — o kernel — é a camada que quase ninguém está monitorando.

A Sysdig demonstrou que o monitoramento é tecnicamente viável. A questão é se as organizações vão implementá-lo antes que o próximo comprometimento em escala Trivy tenha como alvo o ambiente de runtime de um agente de IA.

O scanner era o ataque. O sandbox não viu. O kernel viu.

Fontes

Sysdig Threat Research Team. “AI Coding Agents Are Running on Your Machines. Do You Know What They’re Doing?” Março 2026.
Docker Security (Mark Lechner). “Trivy Supply Chain Compromise: What Docker Hub Users Should Know” Março 2026.

Victorino Group ajuda empresas a construir governança de runtime para frotas de agentes de IA: contato@victorino.com.br | www.victorino.com.br