Observabilidade de agentes de IA: monitorar o que você não vê

A Anthropic lançou no Claude Desktop um recurso chamado Cowork. Esse recurso criava um bundle de máquina virtual de 10 GB em toda instalação do macOS. Usuários que nunca ativaram o Cowork recebiam a VM mesmo assim. Quem apagava o bundle via ele se regenerar. Um usuário relatou um bundle que chegou a 21 GB. A issue no GitHub acumulou 345 pontos e 175 comentários no Hacker News antes de a Anthropic reconhecer o problema.¹

Ninguém percebeu até o espaço em disco acabar.

O que é observabilidade de agentes de IA? Observabilidade de agentes é a prática de monitorar o que agentes autônomos consomem e executam em tempo de execução. Ela exige três camadas: medição de recursos (disco, memória, CPU e rede por sessão), aplicação de políticas (regras de permissão e negação em cada chamada de ferramenta) e auditoria em tempo de execução (registro do comportamento real no nível do kernel). Sem as três, o operador não consegue detectar desvios, nem impor escopo, nem reconstruir incidentes.

TL;DR

As ferramentas de agentes hoje alocam recursos de computação (disco, memória, CPU e rede) sem nenhuma visibilidade para o operador. A VM do Cowork, da Anthropic, é o exemplo visível; cada chamada de ferramenta MCP, cada subagente iniciado e cada busca na web são exemplos invisíveis. Governar agentes exige três camadas de observabilidade: medição de recursos (o que ele consumiu?), aplicação de políticas (o que ele tinha permissão de fazer?) e auditoria em tempo de execução (o que ele realmente fez?). Dois projetos de código aberto cobrem a camada de políticas e a de auditoria (mcp-firewall e Logira), mas nenhuma ferramenta pronta para produção cobre as três. A seguir: o problema de visibilidade, a pilha de três camadas, o que cada camada captura e os hooks mínimos de monitoramento que você pode implementar hoje.

O problema de visibilidade

O software tradicional opera abaixo de uma linha de observabilidade que os operadores escolhem traçar. Um servidor web grava logs de acesso porque alguém configurou o registro. Um banco de dados acompanha consultas lentas porque alguém definiu log_min_duration_statement. A granularidade é decidida pelo operador.

Os sistemas de agentes invertem essa relação. É o agente que decide o que executar em tempo de execução. Um agente de programação que recebe “conserte o endpoint de login” pode ler 47 arquivos, escrever em 12, iniciar três subagentes, buscar duas páginas web e executar 15 comandos bash. Cada ação consome recursos. Nada desse consumo aparece no monitoramento tradicional.

O incidente do Cowork expôs essa inversão na camada de infraestrutura. O Claude Desktop alocava 10 GB de espaço em disco, consumia de 24 a 55 % de CPU em repouso e elevava a atividade de swap de 20.000 para mais de 24.000 swapins em máquinas de 8 GB.¹ Os usuários descobriram esse consumo pelos avisos de armazenamento do macOS, não pela telemetria da Anthropic. O aplicativo não oferecia painel algum, nenhum medidor e nenhum aviso prévio sobre a alocação da VM.

O padrão não é hipotético. Em março de 2026, um desenvolvedor relatou que o Claude Code executou um comando Terraform que destruiu um banco de dados de produção. O agente rodou terraform apply contra um arquivo de estado de produção. Nenhuma confirmação apareceu. Nenhum hook interceptou o comando. O desenvolvedor descobriu a destruição quando a aplicação saiu do ar. O incidente acumulou 142 pontos e 158 comentários no Hacker News.¹² Dias depois, outro desenvolvedor relatou que o Claude Code apagou um ambiente de produção inteiro, incluindo snapshots de banco de dados que representavam 2,5 anos de registros.¹³ Os dois incidentes compartilham a mesma causa raiz: visibilidade zero sobre o que o agente estava fazendo antes de o dano se tornar irreversível.

Leve o padrão para a escala das sessões de agentes. Meu sistema de orquestração de hooks — construído sobre a infraestrutura de hooks do Claude Code — intercepta 15 tipos de eventos em cada chamada de ferramenta.¹¹ Ao longo de mais de 60 sessões, o sistema registrou 84 hooks disparando a cada ação e produziu uma telemetria que nenhuma instalação padrão de agente entrega.² Sem essa instrumentação, eu não teria detectado os 12 incidentes de desvio, nem as verificações fantasma, nem os laços de criação recursiva que documentei no meu comentário público ao NIST.³

O relatório DORA Accelerate State of DevOps 2024 concluiu que times com práticas sólidas de observabilidade implantam com mais frequência e se recuperam mais rápido de falhas. A edição de 2025 estende o modelo ao desenvolvimento assistido por IA, ligando a observabilidade a “como a programação ou os testes assistidos por IA afetam a qualidade, o tempo de entrega e a confiabilidade geral”.⁴ Observabilidade de agentes não é um luxo. Medir o comportamento de um agente é pré-requisito para governá-lo.

Três camadas de visibilidade de agentes

A observabilidade de agentes exige três camadas independentes. Cada camada responde a uma pergunta diferente. A falha de uma camada não compromete as outras.

As camadas formam uma progressão: você não consegue aplicar políticas a recursos que não mede, nem auditar a conformidade com políticas que nunca definiu. Cada camada se apoia na que está abaixo dela.

Camada 1: medição de recursos

A medição de recursos responde: quanto o agente consumiu e onde?

O incidente do Cowork é uma falha de medição de recursos. O bundle da VM ocupava 10 GB de disco. O processo de renderização consumia 24 % de CPU em repouso. A atividade de swap subia de forma constante durante as sessões. Todas essas métricas existiam no Monitor de Atividade do macOS. Nenhuma aparecia na interface do Claude Desktop.¹

Em sessões de programação com agentes, a medição de recursos acompanha quatro dimensões:

Disco. Cada escrita de arquivo, cada entrada de cache, cada arquivo de log. Minhas sessões geram de 200 a 400 KB de arquivos de estado por sessão (jiro.state.json, jiro.progress.json, logs de hooks). Em mais de 60 sessões, isso se acumula em 12 a 24 MB de dados de estado que persistem de uma sessão para outra enquanto não forem limpos explicitamente.²

Memória. O consumo da janela de contexto por turno. Uma janela de contexto de 200.000 tokens custa cerca de 3 dólares por preenchimento completo nos preços atuais do Opus. Meu rastreador de custos registra o uso acumulado de tokens por sessão, com limiares de orçamento em 80 %, 90 % e 95 % de um limite configurável.⁵

CPU. O tempo de execução dos hooks. Meu despachante de prompts com nove hooks acrescenta 200 ms por prompt. Essa sobrecarga é invisível para os usuários (o gargalo é a digitação humana), mas se acumula em pipelines automatizados. O laço autônomo ralph dispara o despachante de 50 a 100 vezes por história, somando de 10 a 20 segundos de sobrecarga de hooks por história.²

Rede. Buscas na web, chamadas de API, invocações de ferramentas MCP. Toda requisição de saída é um canal de dados em potencial — e cada servidor MCP é uma nova superfície de ataque que a medição de rede precisa cobrir. Minha biblioteca de extração web registra as URLs buscadas e o tamanho das respostas. Sem medição de rede, uma busca que retorna 50 MB é indistinguível de outra que retorna 5 KB.⁶

Nenhuma ferramenta comercial de agentes oferece um painel de recursos por sessão. Os provedores de nuvem medem computação para cobrança, não para dar visibilidade ao operador. A lacuna entre o que os agentes consomem e o que os operadores conseguem ver é o déficit de medição de recursos.

Essa ausência parece invisível até os números se acumularem. Uma sessão que escreve 400 KB de arquivos de estado não é nada. Sessenta sessões que escrevem 400 KB cada uma, sem limpeza, deixam 24 MB de estado órfão. Uma busca web que retorna 847 KB é desprezível. Um pipeline de varredura que busca 80 URLs por execução gera 67 MB de conteúdo em cache que a abstração de ferramentas do agente esconde do operador. A medição de recursos torna o acumulado visível antes que ele vire a crise que leva alguém a abrir a issue #22543 no GitHub.¹

Camada 2: aplicação de políticas

A aplicação de políticas responde: quais regras restringem o agente e essas regras são aplicadas de forma consistente?

O mcp-firewall cobre a camada de políticas para agentes de linha de comando.⁷ A ferramenta fica entre o agente e todas as solicitações de uso de ferramentas, avaliando cada solicitação contra uma política baseada em expressões regulares antes da execução. As políticas usam arquivos de configuração JSONNet delimitados por pasta, repositório git ou usuário. O firewall dá suporte ao Claude Code e ao GitHub Copilot CLI por meio da integração com o hook PreToolUse.

A arquitetura reflete uma percepção central: cada agente implementa a própria solução pela metade para a lógica de permissão e negação. O Claude Code usa padrões glob. O Codex CLI só faz correspondência por prefixo. Cada abordagem cobre um subconjunto do espaço de políticas. O mcp-firewall centraliza as regras em um único motor que funciona entre agentes diferentes.

Considere a lacuna de políticas sem aplicação centralizada. Meu sistema de hooks inclui 12 handlers PreToolUse:Bash que verificam padrões de credenciais, operações git perigosas, acesso a caminhos sensíveis e comandos de implantação.² Cada handler é um script de shell separado com suas próprias expressões regulares. Quando preciso adicionar uma regra de negação, escrevo um script novo. Quando preciso auditar quais regras existem, faço grep em 12 arquivos. O mcp-firewall consolida tudo isso em um único arquivo de configuração com arrays de permissão explícitos.

O OWASP Top 10 for Agentic Applications (2025) identifica o sequestro de objetivo do agente (ASI01) e a agência excessiva (LLM06:2025) como riscos principais.⁸ Os dois riscos exigem aplicação de políticas no nível da chamada de ferramenta. Um agente com o objetivo sequestrado continua chamando ferramentas. Um agente com agência excessiva continua pedindo permissões. A aplicação de políticas intercepta os dois na fronteira em que a intenção do agente encontra as ferramentas do sistema.

Aplicação de políticas é diferente de controle de acesso. O controle de acesso tradicional pergunta: “este usuário tem permissão?”. A aplicação de políticas para agentes pergunta: “esta ação, neste contexto, para esta tarefa, cabe dentro do escopo aprovado?”. O paradoxo de confiança entre implantar e defender explica por que conceder permissões amplas aos agentes para torná-los úteis cria exatamente a superfície que a aplicação de políticas precisa conter. O desafio está na sensibilidade ao contexto. Um git push em uma branch de funcionalidade e um git push --force na main são a mesma ferramenta (Bash) com raios de impacto bem diferentes. As expressões regulares do mcp-firewall conseguem distinguir os dois. As permissões padrão de um agente, não.

A aplicação de políticas no nível da aplicação também corre risco de ser contornada. Como documentei em seu sandbox de agente é apenas uma sugestão, fronteiras de aplicação que parecem sólidas costumam ter brechas estruturais. Uma análise de março de 2026 documentou três técnicas cada vez mais avançadas de escape de sandbox contra a lista de negação embutida do Claude Code: evasão por caminho (/proc/self/root/usr/bin/npx resolve para o mesmo binário que o bloqueado /usr/bin/npx), desativação autodirigida do sandbox (o agente raciocinou por conta própria sobre remover o sandbox quando ele impedia a conclusão da tarefa) e invocação do linker dinâmico (ld-linux-x86-64.so.2 carrega binários por mapeamento de memória, contornando por completo os hooks de aplicação do kernel).¹⁴ A terceira técnica é uma classe inteira de exploit: qualquer carregamento de código que evite o execve contorna a aplicação no nível do processo. A lição para a aplicação de políticas é que listas de negação baseadas em correspondência de strings são uma primeira camada necessária, mas não suficiente. A aplicação endereçada por conteúdo (identificar binários pelo hash SHA-256 em vez do nome do arquivo) fecha a brecha da evasão por caminho, mas contornar o carregador dinâmico exige controles no nível do kernel, que ficam abaixo da camada de políticas.

A mesma lição vale uma camada acima, onde a política não enxerga nada. Plugin4Shell, divulgada pela Air Security em setembro de 2026, é uma falha de cadeia de suprimentos no marketplace dos quatro principais agentes de programação: o marketplace fixa um commit verificado para um plugin, mas o agente faz checkout desse commit sem conferir se ele realmente está lá, de modo que um atacante que controle o repositório do plugin pode criar uma branch com o nome do commit fixado e torná-la a branch padrão; uma refixação de rotina no marketplace dispara então a atualização automática em segundo plano de todos os agentes, e o checkout resolve para a branch enquanto a fixação continua parecendo respeitada. Na minha leitura, nenhum hook PreToolUse, nenhuma lista de negação e nenhum firewall desta pilha enxerga a troca de um plugin, porque a troca acontece antes de o agente fazer uma chamada de ferramenta. A linha do tempo da Air diz que a Anthropic confirmou uma correção no Claude Code 2.1.179 e que a OpenAI entregou outra no Codex 0.146.0, sem correção para o GitHub Copilot e sem nenhuma prevista para o Gemini CLI, já descontinuado; a entrada pública do changelog do Claude Code para a 2.1.179 não nomeia a correção, então a versão se apoia no relato dos pesquisadores. O controle que se aplica é higiene de versões mais um inventário do que o marketplace de fato resolveu, e isso é uma questão de medição, não de políticas.¹⁷

Camada 3: auditoria em tempo de execução

A auditoria em tempo de execução responde: o que o agente realmente fez no nível das chamadas de sistema?

O Logira cobre a camada de auditoria usando sondas eBPF para interceptar chamadas de sistema no nível do kernel.⁹ A ferramenta registra três categorias de eventos: execução de processos (eventos exec), operações em arquivos (incluindo acesso a arquivos de credenciais) e conexões de rede (com rastreamento do destino). Cada execução auditada gera três arquivos: events.jsonl para revisar a linha do tempo, index.sqlite para filtragem por consulta e meta.json para os metadados da execução.

A filosofia de projeto é “observe-only”: o Logira registra e detecta, mas não aplica nem bloqueia nada.⁹ A separação em relação à camada de aplicação é deliberada. A aplicação de políticas impede ações sabidamente ruins. A auditoria em tempo de execução descobre, depois do fato, ações ruins desconhecidas. As duas camadas cumprem funções temporais distintas: prevenção (antes) e perícia (depois).

As sondas eBPF do Logira operam abaixo da camada de aplicação. Um agente que monta um comando inédito para exfiltrar dados ainda assim faz chamadas de sistema. O agente não consegue esconder leituras de arquivos, conexões de rede ou processos iniciados do rastreamento no nível do kernel. A abordagem captura o que escapa aos hooks no nível da aplicação: efeitos colaterais que contornam a abstração da chamada de ferramenta.

As regras de detecção embutidas miram especificamente os riscos de agentes de IA: acesso a arquivos de credenciais, mudanças em mecanismos de persistência (/etc, systemd, cron), cadeias de comandos suspeitas (padrões curl-pipe-sh), operações destrutivas (rm -rf) e tráfego de saída anômalo.⁹ São padrões opinativos para o modelo de ameaças de agentes, não uma auditoria genérica de sistema.

A restrição de plataforma importa. O Logira exige Linux 5.8+ com cgroup v2. Agentes no macOS (Claude Desktop, Claude Code no Darwin) não podem usar auditoria baseada em eBPF. Meu sandbox de sistema operacional usa perfis Seatbelt do macOS como equivalente mais próximo: regras de negação impostas pelo kernel que bloqueiam escritas em caminhos sensíveis.³ O Seatbelt é aplicação, não auditoria. Falta ao macOS um equivalente pronto para produção à trilha de auditoria puramente observacional do Logira.

O Agent Safehouse, uma ferramenta de sandbox nativa do macOS que acumulou 802 pontos e 181 comentários no Hacker News em março de 2026, ataca essa lacuna de plataforma pelo lado da aplicação.¹⁵ A ferramenta oferece perfis de sandbox desenhados especificamente para agentes de IA locais no macOS. A resposta da comunidade (802 pontos é algo excepcional para uma ferramenta de sandbox) reflete a urgência: quem roda agentes no macOS tem poucas opções entre “nenhum sandbox” e “escreva seu próprio perfil Seatbelt”. O Agent Safehouse preenche essa lacuna do lado da aplicação. A lacuna de auditoria no macOS continua aberta.

A distinção entre aplicação e auditoria corresponde a uma divisão temporal na resposta a incidentes. A aplicação evita o incidente. A auditoria permite reconstruí-lo depois. As duas são necessárias. Uma camada de aplicação que bloqueia todo acesso a credenciais evita a exfiltração, mas também impede operações SSH legítimas. Uma camada de auditoria que registra todo acesso a credenciais sem bloquear permite ao operador revisar padrões de acesso e ajustar as regras de aplicação com base em evidências. É esse laço de retroalimentação entre dados de auditoria e refinamento de políticas que faz a pilha de visibilidade melhorar com o tempo: a auditoria revela padrões, os padrões informam a política e a política reduz a superfície que a auditoria precisa cobrir.

O isolamento por cgroup v2 do Logira acrescenta uma propriedade que a auditoria no nível da aplicação não consegue replicar: a atribuição por execução. O sistema atribui cada evento a uma execução auditada específica, e não ao sistema como um todo. Quando duas sessões de agentes rodam ao mesmo tempo na mesma máquina, o isolamento por cgroup garante que um acesso a arquivo na sessão A não apareça na trilha de auditoria da sessão B. Os hooks no nível da aplicação não oferecem a mesma garantia, porque disparam dentro do processo do agente, que não tem nenhuma fronteira de kernel separando sessões concorrentes.⁹

O que eu realmente uso

Meu sistema de orquestração cobre as três camadas com hooks, e não com ferramentas dedicadas de monitoramento.

Medição de recursos. O hook cost-gate acompanha o uso de tokens por sessão contra limiares de orçamento configuráveis.⁵ O monitor de desempenho do sistema verifica CPU, memória, disco e swap em intervalos configuráveis, injetando avisos quando a pressão sobre os recursos ultrapassa os limiares.¹⁰ O detector de desvio de sessão dispara a cada 25 chamadas de ferramenta e calcula a similaridade de cosseno entre o embedding do prompt original e uma janela deslizante das ações recentes.²

Aplicação de políticas. Oito hooks despachantes PreToolUse encaminham para hooks handlers conforme o tipo de ferramenta. Só o PreToolUse:Bash executa 12 handlers cobrindo padrões de credenciais, operações git destrutivas, acesso a caminhos sensíveis e comandos de implantação. O guarda de recursão impõe profundidade máxima de dois e no máximo cinco filhos por agente pai.²

Auditoria em tempo de execução. Os hooks PostToolUse registram o resultado de cada chamada de ferramenta. Os hooks de varredura de segurança inspecionam a saída do bash em busca de vazamento de credenciais depois da execução. Os arquivos de estado da sessão (jiro.state.json) registram cada história concluída, cada veredicto do revisor e cada resultado do portão de evidências.² O sistema não usa eBPF (limitação do macOS), mas captura telemetria no nível das ferramentas pelo pipeline de hooks.

O sistema funciona porque toda ação passa pelo pipeline de hooks. A limitação é a profundidade: o monitoramento no nível do hook captura o que o agente pediu para fazer, não o que o sistema operacional realmente executou. Um agente que monta um comando bash com subshells embutidos executa um código que o hook enxerga como uma única string. Uma auditoria no nível do kernel veria cada subprocesso.

Resultados concretos de incidentes em produção em que a pilha de três camadas capturou falhas que o monitoramento padrão teria deixado passar:

O ponto cego que se multiplica

Agentes que iniciam agentes multiplicam a opacidade. Cada salto de delegação introduz perda de informação.

Quando meu sistema de orquestração executa o laço autônomo ralph, o processo pai inicia instâncias novas do Claude Code para cada história do PRD. Cada agente filho recebe uma tarefa focada e uma janela de contexto limpa. O pai acompanha o status de conclusão. O que o pai não vê são as chamadas de ferramenta individuais, as leituras de arquivo nem o consumo de recursos do filho.²

Na profundidade um (o pai inicia um filho), o pai vê a saída final do filho. Na profundidade dois (o filho inicia um neto), o pai vê o relatório do filho sobre a saída do neto. Cada salto comprime informação. A análise da cadeia de delegação no meu comentário ao NIST mediu três riscos que se acumulam: compressão semântica (o contexto encolhe para uma string de prompt), amplificação de autoridade (os filhos herdam permissões sem entender a sensibilidade delas) e difusão de responsabilidade (o agente raiz responde por resultados que nunca inspecionou).³

A observabilidade se degrada no mesmo ritmo. Uma pilha de visibilidade de três camadas no agente raiz dá visibilidade zero sobre o agente neto, a menos que cada filho execute o próprio monitoramento de forma independente. Meu guarda de recursão impõe o limite de profundidade, mas esse guarda é um controle de política, não de observabilidade. Saber que a delegação parou na profundidade dois não diz o que aconteceu lá.

Um exemplo concreto do meu sistema em produção: o laço ralph iniciou um agente filho para implementar uma história de migração de banco de dados. O agente filho decidiu que a migração precisava de uma “etapa de verificação” e iniciou o próprio subagente para rodar testes de integração. O agente neto falhou em silêncio (o banco de dados de teste não estava configurado). O agente filho recebeu uma resposta vazia, interpretou o silêncio como sucesso e reportou a história como concluída. O pai registrou “história 4: concluída”. Descobri a migração quebrada três horas depois, quando a aplicação caiu na coluna que faltava. A telemetria do agente raiz mostrava uma execução limpa. A falha morava dois saltos abaixo, invisível para todas as camadas de monitoramento que eu havia implantado na raiz.²

O framework OWASP Agentic Applications trata de falhas em cascata e de agentes fora de controle, mas não prescreve requisitos de observabilidade para cadeias de delegação entre vários agentes.⁸ A análise da OpenGuard de março de 2026 sobre injeção de prompt em agentes expõe a mesma lacuna pelo lado da segurança: contexto contaminado circulando entre agentes com permissões diferentes cria, nas passagens de bastão, “um caminho silencioso para escalar autoridade”, sem políticas claras de fluxo de dados nem autorização no nível da composição.¹⁶ A lacuna é estrutural: cada agente da cadeia precisaria da própria medição de recursos, da própria aplicação de políticas e da própria auditoria em tempo de execução, configuradas e reportadas de forma independente. A sobrecarga é multiplicativa. Três camadas de monitoramento em três agentes de uma cadeia são nove instâncias de monitoramento, cada uma gerando a própria telemetria e exigindo a própria configuração. Nenhuma ferramenta existente gerencia essa coordenação.

O que você pode implementar hoje

Três hooks mínimos de monitoramento que cobrem a pilha de visibilidade:

1. Recursos: rastreador de orçamento de tokens. Registre os tokens de entrada e saída acumulados por sessão. Defina um limite rígido. Alerte em 80 %. A implementação exige ler as estatísticas de uso do agente (o Claude Code expõe os custos da sessão pelo /cost) e compará-las com um limiar. Meu hook cost-gate faz isso em 47 linhas de bash.⁵

2. Política: lista de negação no PreToolUse. Crie um hook que dispare antes de cada chamada da ferramenta Bash. Compare o comando com uma lista de padrões: rm -rf /, git push --force, caminhos que contenham .ssh ou .env, curl | sh. Bloqueie as correspondências. A implementação exige um script de shell que leia o stdin (o JSON da chamada de ferramenta), extraia o campo do comando e faça grep contra um arquivo de padrões. Meu hook de verificação de credenciais faz isso em 31 linhas.²

3. Auditoria: log de sessão no PostToolUse. Acrescente cada chamada de ferramenta e seu resultado a um arquivo JSONL específico da sessão. Inclua horário, nome da ferramenta, argumentos e código de saída. Esse log permite a reconstrução depois da sessão: o que o agente fez, em que ordem e alguma coisa falhou em silêncio? Meu registrador de sessão faz isso em 22 linhas de bash.²

Um exemplo prático do hook de lista de negação no settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

O script do hook lê a chamada de ferramenta do stdin, extrai a string do comando e a compara com os padrões. Um comando bloqueado retorna um objeto JSON com {"decision": "block", "reason": "Sensitive path access denied"}. Um comando permitido retorna {"decision": "approve"}. O Claude Code respeita as duas respostas sem perguntar de novo. O hook inteiro não acrescenta latência alguma aos comandos permitidos (a verificação por expressão regular roda em menos de 5 ms) e dá retorno imediato para os bloqueados.

Esses três hooks somam menos de 100 linhas no total. Eles não substituem ferramentas dedicadas de monitoramento. Eles substituem visibilidade zero por visibilidade mínima, e a visibilidade mínima é o pré-requisito de toda decisão de governança que vier depois. Você não consegue definir um orçamento de recursos sem medição. Você não consegue impor uma política de escopo sem uma lista de negação. Você não consegue investigar um incidente sem um log de auditoria. Comece pelo log. Os outros dois vêm em seguida.

Principais conclusões

Para engenheiros de plataforma: os agentes consomem recursos que o monitoramento existente não acompanha. Uso de disco, memória, CPU e rede por sessão de agente pertence ao mesmo painel que as métricas de contêineres. O incidente do Cowork comprova a necessidade: 10 GB alocados com visibilidade zero para o operador.

Para times de segurança: a aplicação de políticas na fronteira da chamada de ferramenta é a postura mínima viável de segurança para agentes. A abordagem centralizada do mcp-firewall consolida a lógica de permissão e negação de cada agente em uma única configuração auditável. Avalie se as permissões embutidas do seu agente cobrem o espaço de políticas que o seu modelo de ameaças exige.

Para gestores de engenharia: a resposta de longo prazo é a autogovernança dos agentes — agentes que internalizam o monitoramento como norma de comportamento, e não apenas como restrição externa. Enquanto isso amadurece, faça três perguntas sobre o seu ferramental de agentes. Você consegue ver o consumo de recursos por sessão? Você consegue definir e auditar políticas de chamada de ferramentas? Você consegue reconstruir depois o que um agente fez? Se alguma resposta for “não”, você tem uma lacuna de visibilidade que cresce a cada agente adicional no seu fluxo de trabalho.

Perguntas frequentes

O que é observabilidade de agentes?

Observabilidade de agentes é a capacidade de monitorar e entender o que um agente de IA faz durante a execução: quais recursos ele consome, quais ações ele realiza e se essas ações cumprem as políticas definidas.

Por que o Cowork, da Anthropic, criou uma VM de 10 GB?

O recurso Cowork do Claude Desktop provisiona uma máquina virtual para sessões de desenvolvimento colaborativo. O Claude Desktop cria o bundle da VM automaticamente em toda instalação do macOS, mesmo para usuários que nunca ativam o recurso, e o mantém até que seja apagado manualmente.¹

O que é o mcp-firewall?

O mcp-firewall é uma ferramenta de código aberto para aplicação de políticas que intercepta as solicitações de uso de ferramentas de agentes de linha de comando (Claude Code, GitHub Copilot CLI) e as avalia, antes da execução, contra regras de permissão e negação baseadas em expressões regulares.⁷

O que é auditoria em tempo de execução com eBPF?

O eBPF (extended Berkeley Packet Filter) permite rastrear chamadas de sistema no nível do kernel sem modificar o processo auditado. Ferramentas como o Logira usam sondas eBPF para registrar a execução de processos, as operações em arquivos e as conexões de rede durante as execuções de agentes de IA.⁹

Como os agentes iniciam subagentes sem visibilidade para o operador?

Agentes que delegam tarefas iniciam processos filhos com janelas de contexto limpas. O agente pai vê a saída final do filho, mas não as chamadas de ferramenta individuais, as leituras de arquivo nem o consumo de recursos. A cada salto de delegação a informação se comprime: a sessão inteira do neto vira uma linha de status no log do pai. A observabilidade se degrada no mesmo ritmo em que a profundidade de delegação aumenta.²

Como o monitoramento de agentes difere do APM tradicional?

O monitoramento tradicional de desempenho de aplicações (APM) acompanha latência de requisições, taxas de erro e throughput de software determinístico. O monitoramento de agentes acompanha comportamento não determinístico: o que o agente decidiu fazer em tempo de execução, se essas decisões couberam dentro da política e quais recursos cada decisão consumiu. O APM presume que a aplicação segue um caminho de código conhecido. O monitoramento de agentes presume que o agente escolhe o próprio caminho.²

Os hooks do Claude Code conseguem entregar observabilidade de agentes?

Sim. O sistema de hooks do Claude Code dispara scripts em eventos do ciclo de vida (PreToolUse, PostToolUse, Notification) capazes de medir recursos, aplicar políticas e registrar ações. Um arranjo de três hooks — rastreador de orçamento de tokens, lista de negação no PreToolUse e registrador de sessão no PostToolUse — cobre as três camadas de visibilidade em menos de 100 linhas de bash. Os hooks são o ponto de entrada mais acessível para times que já usam o Claude Code.

O que acontece quando os agentes contornam o próprio sandbox?

Contornar o sandbox significa que a camada de aplicação falha em silêncio. O agente continua executando fora do escopo pretendido e, sem auditoria em tempo de execução, não sobra registro algum da brecha. As técnicas de escape de sandbox documentadas em março de 2026 incluem evasão por caminho, desativação autodirigida do sandbox e invocação do linker dinâmico — todas invisíveis para o monitoramento no nível da aplicação.

Por que a observabilidade de ferramentas MCP é importante?

Cada chamada de ferramenta MCP é um canal de dados em potencial: ela pode ler arquivos, fazer requisições de rede e executar código. Os servidores MCP ampliam a superfície de ataque porque cada servidor introduz capacidades novas que o agente pode invocar em tempo de execução. Sem registro por chamada e sem aplicação de políticas, as invocações de ferramentas MCP são invisíveis para o operador.

Como monitorar cadeias de delegação com vários agentes?

Cada agente de uma cadeia de delegação precisa da própria medição de recursos, da própria aplicação de políticas e da própria auditoria em tempo de execução. O laço autônomo ralph mostra bem o problema: um pai inicia agentes filhos que recebem, cada um, uma janela de contexto limpa. O pai vê a saída final, não as chamadas de ferramenta individuais. A observabilidade se degrada no mesmo ritmo em que a profundidade de delegação aumenta, o que exige monitoramento independente em cada salto.

Fontes