O Agente Invisível: Por Que Você Não Pode Governar o Que Não Consegue Ver

Anthropic lançou um recurso chamado Cowork no Claude Desktop. O recurso criava um pacote de máquina virtual de 10GB em toda instalação macOS. Usuários que nunca habilitaram o Cowork ainda assim recebiam a VM. Usuários que a deletavam assistiam ela se regenerar. Um usuário relatou que o pacote cresceu para 21GB. A issue no GitHub acumulou 345 pontos e 175 comentários no Hacker News antes de Anthropic reconhecer o problema.¹

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

Resumo

Ferramentas de agentes agora alocam recursos computacionais (disco, memória, CPU, rede) sem visibilidade do operador. A VM do Cowork da Anthropic é o exemplo visível; cada chamada de ferramenta MCP, cada sub-agente gerado e cada busca na web é um exemplo invisível. Governar agentes requer três camadas de observabilidade: medição de recursos (o que ele consumiu?), aplicação de políticas (o que ele tinha permissão para fazer?) e auditoria em tempo de execução (o que ele realmente fez?). Dois projetos open-source abordam as camadas de política e auditoria (mcp-firewall e Logira), mas nenhuma ferramenta em produção cobre as três. Abaixo: o problema de visibilidade, a stack de três camadas, o que cada camada detecta e hooks mínimos de monitoramento que você pode implementar hoje.

O Problema de Visibilidade

Software tradicional opera abaixo de uma linha de observabilidade que os operadores escolhem traçar. Um servidor web registra logs de acesso porque engenheiros configuraram o logging. Um banco de dados rastreia queries lentas porque alguém definiu log_min_duration_statement. O operador decide a granularidade.

Sistemas de agentes invertem a relação. O agente decide o que executar em tempo de execução. Um agente de codificação que recebe “corrija o endpoint de login” pode ler 47 arquivos, escrever em 12, gerar três sub-agentes, 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 a inversão no nível de infraestrutura. O Claude Desktop alocou 10GB de espaço em disco, consumiu 24-55% de CPU em modo ocioso e elevou o uso de swap de 20K para mais de 24K swapins em máquinas com 8GB.¹ Usuários descobriram o consumo de recursos através de avisos de armazenamento do macOS, não pela telemetria do Anthropic. A aplicação não fornecia nenhum painel, nenhum medidor e nenhuma divulgação opt-in para a alocação da VM.

Escale o padrão para sessões de agentes. Meu sistema de orquestração por hooks intercepta 15 tipos de eventos em cada chamada de ferramenta.¹¹ Ao longo de 60 sessões, o sistema registrou 84 hooks disparando em cada ação, produzindo telemetria que nenhuma instalação padrão de agente fornece.² Sem essa instrumentação, eu não teria detectado os 12 incidentes de desvio, as falhas de verificação fantasma ou os loops de geração recursiva documentados no meu comentário público ao NIST.³

O Relatório DORA 2024 Accelerate State of DevOps descobriu que equipes com práticas robustas de observabilidade fazem deploys mais frequentemente e se recuperam mais rápido de falhas. A edição de 2025 estende o framework para desenvolvimento assistido por IA, conectando observabilidade a “como codificação ou testes assistidos por IA afetam qualidade, lead time e confiabilidade geral.”⁴ Observabilidade de agentes não é algo opcional. Medir o comportamento de agentes é um pré-requisito para governá-los.

Três Camadas de Visibilidade de Agentes

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

As camadas mapeiam uma progressão: você não pode aplicar políticas sobre recursos que não mede, e não pode auditar conformidade com políticas que nunca definiu. Cada camada se constrói sobre a anterior.

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 pacote da VM consumiu 10GB de espaço em disco. O processo de renderização consumiu 24% de CPU em modo ocioso. A atividade de swap cresceu constantemente durante as sessões. Todas essas métricas existiam no Monitor de Atividade do macOS. Nenhuma aparecia na interface do Claude Desktop.¹

Para sessões de agentes de codificação, a medição de recursos rastreia quatro dimensões:

Disco. Cada escrita de arquivo, cada entrada de cache, cada arquivo de log. Minhas sessões geram 200-400KB de arquivos de estado por sessão (jiro.state.json, jiro.progress.json, logs de hooks). Ao longo de 60 sessões, isso acumula 12-24MB de dados de estado que persistem entre sessões a menos que sejam explicitamente limpos.²

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

CPU. Tempo de execução de hooks. Meu dispatcher de prompts com nove hooks adiciona 200ms por prompt. Essa sobrecarga é invisível para usuários (a digitação humana é o gargalo), mas se acumula em pipelines automatizados. O loop autônomo ralph dispara o dispatcher 50-100 vezes por story, adicionando 10-20 segundos de sobrecarga de hooks por story.²

Rede. Buscas web, chamadas API, invocações de ferramentas MCP. Cada requisição de saída é um potencial canal de dados. Minha biblioteca de extração web registra URLs de busca e tamanhos de resposta. Sem medição de rede, uma busca web que retorna uma resposta de 50MB é indistinguível de uma que retorna 5KB.⁶

Nenhuma ferramenta comercial de agentes fornece um painel de recursos por sessão. Provedores de nuvem medem computação para faturamento, não para visibilidade do operador. A lacuna entre o que os agentes consomem e o que os operadores conseguem ver é o déficit de medição de recursos.

A ausência parece invisível até os números acumularem. Uma sessão que escreve 400KB de arquivos de estado não é nada. Sessenta sessões que escrevem 400KB cada, sem limpeza, deixam 24MB de estado órfão. Uma busca web que retorna 847KB é desprezível. Um pipeline de varredura que busca 80 URLs por execução gera 67MB 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 se torne a crise que leva alguém a registrar a issue GitHub #22543.¹

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 consistentemente?

O mcp-firewall aborda a camada de políticas para agentes CLI.⁷ A ferramenta fica entre o agente e todas as requisições de uso de ferramentas, avaliando cada requisição contra uma política baseada em regex antes da execução. As políticas usam arquivos de configuração JSONNet com escopo por pasta, repositório git ou usuário. O firewall suporta Claude Code e GitHub Copilot CLI através de integração com hooks PreToolUse.

A arquitetura reflete um insight fundamental: cada agente implementa sua própria solução incompleta de lógica permitir/negar. Claude Code usa padrões glob. Codex CLI usa correspondência apenas 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.

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 deploy.² Cada handler é um script shell separado com seus próprios padrões regex. Quando preciso adicionar uma nova regra de negação, escrevo um novo script. Quando preciso auditar quais regras existem, faço grep em 12 arquivos. O mcp-firewall consolida isso em um único arquivo de configuração com arrays de permissão explícitos.

O OWASP Top 10 for Agentic Applications (2025) identifica Agent Goal Hijacking (ASI01) e Excessive Agency (LLM06:2025) como riscos principais.⁸ Ambos os riscos requerem aplicação de políticas no nível da chamada de ferramenta. Um agente que sequestra um objetivo ainda faz chamadas de ferramentas. Um agente com agência excessiva ainda solicita permissões. A aplicação de políticas intercepta ambos na fronteira onde a intenção do agente encontra as ferramentas do sistema.

Aplicação de políticas difere 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, está dentro do escopo aprovado?” A sensibilidade ao contexto é o desafio. Um git push para um branch de feature e um git push --force para main são a mesma ferramenta (Bash) com raios de impacto diferentes. Os padrões regex do mcp-firewall conseguem distinguir entre eles. As permissões padrão de agentes não conseguem.

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 de syscalls?

O Logira aborda a camada de auditoria usando probes 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 de arquivo (incluindo acesso a arquivos de credenciais) e conexões de rede (com rastreamento de destino). Cada execução auditada gera três arquivos: events.jsonl para revisão de timeline, index.sqlite para filtragem consultável e meta.json para metadados da execução.

A filosofia de design é “apenas observar”: o Logira registra e detecta, mas não aplica nem bloqueia.⁹ A separação da camada de aplicação é deliberada. A aplicação de políticas previne ações conhecidamente ruins. A auditoria em tempo de execução descobre ações desconhecidamente ruins após o fato. As duas camadas servem funções temporais diferentes: prevenção (antes) e perícia (depois).

Os probes eBPF do Logira operam abaixo da camada de aplicação. Um agente que constrói um comando inédito para exfiltrar dados ainda faz syscalls. O agente não consegue esconder leituras de arquivos, conexões de rede ou geração de processos do rastreamento em nível de kernel. A abordagem captura o que hooks em nível de aplicação perdem: efeitos colaterais que contornam a abstração de chamadas de ferramentas.

As regras de detecção integradas visam riscos de agentes de IA especificamente: 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 rede de saída anômalo.⁹ As regras são padrões opinativos para o modelo de ameaças de agentes, não auditoria genérica de sistema.

A restrição de plataforma é relevante. O Logira requer Linux 5.8+ com cgroup v2. Agentes macOS (Claude Desktop, Claude Code no Darwin) não podem usar auditoria baseada em eBPF. Meu sandbox de SO usa perfis Seatbelt do macOS como o equivalente mais próximo: regras de negação aplicadas pelo kernel que bloqueiam escritas em caminhos sensíveis.³ Seatbelt é aplicação, não auditoria. O macOS carece de um equivalente pronto para produção da trilha de auditoria apenas-observação do Logira.

A distinção entre aplicação e auditoria mapeia uma divisão temporal na resposta a incidentes. A aplicação previne o incidente. A auditoria permite a reconstrução após o incidente. Ambas são necessárias. Uma camada de aplicação que bloqueia todo acesso a credenciais previne exfiltração, mas também previne operações SSH legítimas. Uma camada de auditoria que registra todo acesso a credenciais sem bloquear permite que o operador revise padrões de acesso e ajuste regras de aplicação com base em evidências. O ciclo de feedback entre dados de auditoria e refinamento de políticas é como a stack de visibilidade melhora ao longo do tempo: a auditoria revela padrões, padrões informam políticas, políticas reduzem a superfície que a auditoria precisa cobrir.

O isolamento por cgroup v2 do Logira adiciona uma funcionalidade que auditoria em nível de aplicação não consegue replicar: atribuição por escopo de execução. O sistema atribui cada evento a uma execução auditada específica, não ao sistema globalmente. Quando duas sessões de agentes rodam simultaneamente na mesma máquina, o isolamento por cgroup garante que o acesso a arquivos na sessão A não apareça na trilha de auditoria da sessão B. Hooks em nível de aplicação não conseguem fornecer a mesma garantia porque os hooks disparam dentro do processo do agente, que não tem fronteira em nível de kernel separando sessões concorrentes.⁹

O Que Eu Realmente Executo

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

Medição de recursos. O hook cost-gate rastreia o uso de tokens por sessão contra limites 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 de recursos excede os limites.¹⁰ O detector de desvio de sessão dispara a cada 25 chamadas de ferramentas, calculando similaridade cosseno entre o embedding do prompt original e uma janela deslizante de ações recentes.²

Aplicação de políticas. Oito hooks de dispatcher PreToolUse roteiam para hooks handlers por tipo de ferramenta. Apenas o PreToolUse:Bash executa 12 handlers cobrindo padrões de credenciais, operações git destrutivas, acesso a caminhos sensíveis e comandos de deploy. O guard de recursão aplica uma profundidade máxima de dois e máximo cinco filhos por agente pai.²

Auditoria em tempo de execução. Hooks PostToolUse registram cada resultado de chamada de ferramenta. Os hooks de varredura de segurança verificam a saída do bash em busca de vazamentos de credenciais após a execução. Arquivos de estado da sessão (jiro.state.json) registram cada conclusão de story, veredicto de revisão e resultado do evidence gate.² O sistema não usa eBPF (limitação do macOS), mas captura telemetria no nível de ferramentas através do pipeline de hooks.

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

O Ponto Cego que se Acumula

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

Quando meu sistema de orquestração executa o loop autônomo ralph, o processo pai gera instâncias frescas de Claude Code para cada story do PRD. Cada agente filho recebe uma tarefa focada e uma janela de contexto nova. O pai rastreia o status de conclusão. O pai não vê as chamadas de ferramentas individuais, leituras de arquivos ou consumo de recursos do filho.²

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

A observabilidade degrada na mesma taxa. Uma stack de visibilidade de três camadas no agente raiz fornece zero visibilidade sobre o agente neto, a menos que cada filho execute independentemente seu próprio monitoramento. Meu guard de recursão aplica o limite de profundidade, mas o guard é um controle de política, não um controle de observabilidade. Saber que a delegação parou na profundidade dois não diz o que aconteceu na profundidade dois.

Um exemplo concreto do meu sistema em produção: o loop ralph gerou um agente filho para implementar uma story de migração de banco de dados. O agente filho decidiu que a migração precisava de uma “etapa de verificação” e gerou seu próprio sub-agente para rodar testes de integração. O agente neto falhou silenciosamente (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 story como completa. O pai registrou “story 4: completa.” Descobri a migração quebrada três horas depois, quando a aplicação travou na coluna ausente. A telemetria do agente raiz mostrava uma execução limpa. A falha vivia dois saltos de profundidade, invisível para cada camada de monitoramento que eu tinha implantado no raiz.²

O framework do OWASP para Aplicações Agênticas aborda falhas em cascata e agentes descontrolados, mas não prescreve requisitos de observabilidade para cadeias de delegação multi-agente.⁸ A lacuna é estrutural: cada agente na cadeia precisaria de sua própria medição de recursos, aplicação de políticas e auditoria em tempo de execução, configuradas e reportadas independentemente. A sobrecarga é multiplicativa. Três camadas de monitoramento em três agentes em uma cadeia são nove instâncias de monitoramento, cada uma gerando sua própria telemetria, cada uma requerendo sua 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 stack de visibilidade:

1. Recursos: Rastreador de orçamento de tokens. Registre tokens de entrada e saída acumulados por sessão. Defina um limite rígido. Alerte em 80%. A implementação requer a leitura das estatísticas de uso do agente (Claude Code expõe custos de sessão via /cost) e comparação com um limite. Meu hook cost-gate faz isso em 47 linhas de bash.⁵

2. Política: Lista de negação PreToolUse. Crie um hook que dispare antes de cada chamada da ferramenta Bash. Verifique o comando contra uma lista de padrões: rm -rf /, git push --force, caminhos contendo .ssh ou .env, curl | sh. Bloqueie correspondências. A implementação requer um script shell que leia stdin (a chamada de ferramenta em JSON), extraia o campo de 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 PostToolUse. Adicione cada chamada de ferramenta e resultado a um arquivo JSONL específico da sessão. Inclua timestamp, nome da ferramenta, argumentos e código de saída. O log permite reconstrução pós-sessão: o que o agente fez, em que ordem, e algo falhou silenciosamente? Meu logger de sessão faz isso em 22 linhas de bash.²

Um exemplo prático do hook de lista de negação em 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 de comando e verifica contra padrões. Um comando bloqueado retorna um objeto JSON com {"decision": "block", "reason": "Sensitive path access denied"}. Um comando permitido retorna {"decision": "approve"}. Claude Code respeita ambas as respostas sem prompt adicional. O hook inteiro adiciona zero latência a comandos aprovados (a verificação regex executa em menos de 5ms) e fornece feedback imediato para comandos bloqueados.

Esses três hooks totalizam menos de 100 linhas. Eles não substituem ferramentas de monitoramento dedicadas. Eles substituem zero visibilidade por visibilidade mínima. Visibilidade mínima é o pré-requisito para toda decisão de governança que se segue. Você não pode definir um orçamento de recursos sem medição. Você não pode aplicar uma política de escopo sem uma lista de negação. Você não pode investigar um incidente sem um log de auditoria. Comece pelo log. Os outros dois seguem.

Conclusões Principais

Para engenheiros de plataforma: Agentes consomem recursos que o monitoramento existente não rastreia. Uso de disco, memória, CPU e rede por sessão de agente pertence ao mesmo painel que métricas de containers. O incidente do Cowork prova a necessidade: 10GB alocados com zero visibilidade do operador.

Para equipes de segurança: Aplicação de políticas na fronteira da chamada de ferramenta é a postura mínima viável de segurança de agentes. A abordagem centralizada do mcp-firewall consolida a lógica de permitir/negar por agente em uma única configuração auditável. Avalie se as permissões integradas do seu agente cobrem o espaço de políticas que seu modelo de ameaças requer.

Para gerentes de engenharia: Faça três perguntas sobre suas ferramentas de agentes: Você consegue ver o consumo de recursos por sessão? Você consegue definir e auditar políticas de chamadas de ferramentas? Você consegue reconstruir o que um agente fez após o fato? Se qualquer 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 toma e se essas ações estão em conformidade com as políticas definidas.

Por que o Cowork da Anthropic criou uma VM de 10GB? O recurso Cowork no Claude Desktop provisiona uma máquina virtual para sessões de desenvolvimento colaborativo. O Claude Desktop cria o pacote da VM automaticamente em toda instalação macOS, mesmo para usuários que nunca habilitam o recurso, e o mantém até ser deletado manualmente.¹

O que é mcp-firewall? O mcp-firewall é uma ferramenta open-source de aplicação de políticas que intercepta requisições de uso de ferramentas de agentes CLI (Claude Code, GitHub Copilot CLI) e as avalia contra regras regex de permitir/negar antes da execução.⁷

O que é auditoria de runtime com eBPF? eBPF (extended Berkeley Packet Filter) permite rastreamento em nível de kernel de chamadas de sistema sem modificar o processo auditado. Ferramentas como o Logira usam probes eBPF para registrar execução de processos, operações de arquivo e conexões de rede durante execuções de agentes de IA.⁹

Fontes