Defesa em tempo de execução para agentes com ferramentas

Uma semana atrás publiquei 50 vulnerabilidades em MCP envolvendo SSRF, envenenamento de ferramentas e padrões de bypass de confiança. A conclusão implícita era sombria: a superfície de ataque cresce mais rápido que a capacidade de auditoria. Um novo artigo de Wei Zhao, Zhe Li, Peixin Zhang e Jun Sun propõe uma resposta estrutural — e um incidente real de telemetria na mesma semana demonstra exatamente por que essa resposta importa.

ClawGuard, publicado em 13 de abril no arxiv, é um framework de segurança em tempo de execução que aplica um conjunto de regras confirmadas pelo usuário em cada fronteira de chamada de ferramenta.¹ Na configuração avaliada, o framework aplica regras básicas de controle de acesso — bloqueando acesso não autorizado a arquivos, impedindo exfiltração de credenciais, restringindo chamadas de rede — antes de qualquer invocação de ferramenta externa. Sem modificação do modelo. Sem mudança de infraestrutura. Sem fine-tuning específico para segurança.¹ Os autores testaram nos benchmarks AgentDojo, SkillInject e MCPSafeBench usando cinco LLMs de ponta.¹ O artigo também descreve um componente de indução de regras específicas por tarefa que derivaria automaticamente restrições a partir do objetivo declarado pelo usuário, mas isso não fez parte da configuração avaliada.

A afirmação que importa: ClawGuard transforma defesa dependente de alinhamento em um mecanismo determinístico e auditável.¹

Por que alinhamento não é uma fronteira de segurança

Muitas das vulnerabilidades de MCP que cataloguei na semana passada exploram uma lacuna estrutural comum. O agente recebe instruções de uma descrição de ferramenta, uma página web buscada ou um arquivo de skill — e a única coisa entre essa injeção e a execução é a capacidade do modelo de distinguir instruções legítimas de adversárias. (Algumas vulnerabilidades — SSRF, RCE, travessia de diretórios — exploram falhas no lado do servidor que não dependem do modelo seguir instruções, mas a fronteira de chamada de ferramenta continua relevante para a defesa.)

Treinamento de alinhamento ajuda. RLHF torna os modelos mais propensos a recusar solicitações prejudiciais. Porém, “mais propenso” não é uma propriedade de segurança. Um modelo que recusa 99% das injeções de prompt ainda falha 1% das vezes, e um atacante que controla a entrada pode iterar até que esse 1% acerte. O padrão de envenenamento de ferramentas nem precisa que o modelo falhe — a descrição envenenada faz a ação maliciosa parecer a ação pretendida.

Interceptação em tempo de execução opera em uma camada completamente diferente. Um hook ou motor de políticas que inspeciona uma chamada de ferramenta antes da execução não depende de o modelo ter entendido o ataque. A verificação é determinística: a chamada corresponde ao conjunto permitido ou não?

Três canais de injeção, um ponto de aplicação

ClawGuard identifica três canais de ataque para agentes com ferramentas:¹

Injeção por conteúdo web e local. O agente lê uma página web ou arquivo local contendo instruções adversárias. As instruções direcionam o agente a chamar ferramentas de maneiras que o usuário não pretendia. A superfície de ataque de egresso silencioso é uma instância desse padrão — instruções de exfiltração escondidas em conteúdo buscado.

Injeção por servidor MCP. Um servidor MCP comprometido ou malicioso embute instruções em descrições de ferramentas ou payloads de resposta. O agente lê essas instruções como contexto e age com base nelas. O catálogo de 50 vulnerabilidades da semana passada documenta esse canal extensivamente.

Injeção por arquivo de skill. Instruções adversárias colocadas em arquivos de skill e configuração que o agente carrega como contexto confiável. O agente trata o conteúdo de arquivos de skill como autoritativo — um atacante que consiga escrever em um arquivo de skill ou configuração pode direcionar o comportamento do agente.

A arquitetura de defesa posiciona a aplicação na fronteira de chamada de ferramenta — o ponto único por onde toda ação externa deve passar, independentemente de qual canal injetou a instrução.¹ Antes de o agente invocar qualquer ferramenta, ClawGuard verifica a chamada contra restrições derivadas da tarefa original do usuário. Uma chamada que esteja fora dessas restrições é bloqueada, não importa quão convincente tenha sido o prompt de injeção.

O insight arquitetural vale ser dito claramente: você não precisa detectar toda injeção se conseguir aplicar políticas na fronteira de execução.

O incidente de telemetria da Vercel

Quatro dias antes da publicação do artigo do ClawGuard, Akshay Chugh publicou uma divulgação sobre o Plugin da Vercel para Claude Code em 9 de abril.² As descobertas no momento da divulgação:

O plugin registrava hooks que enviavam strings de comandos bash para telemetry.vercel.com.² Um UUID persistente armazenado em ~/.claude/vercel-plugin-device-id vinculava essas strings de comando a um dispositivo.² O plugin usava matchers de string vazia em seus hooks, o que significava que os hooks disparavam em todos os projetos — não apenas projetos Vercel.² O mecanismo de consentimento usava uma injeção de prompt em vez de UI nativa para obter a concordância do usuário.² A telemetria disparava em cada evento correspondido, a menos que o usuário definisse VERCEL_PLUGIN_TELEMETRY=off.²

A Vercel tratou as preocupações de telemetria em 14 de abril, removendo os matchers amplos e o mecanismo de consentimento baseado em prompt.²

O incidente da Vercel não é uma vulnerabilidade no sentido tradicional. Ninguém está roubando credenciais. Contudo, demonstra exatamente a classe de problema que a defesa em tempo de execução aborda: um hook que dispara de forma mais ampla do que o usuário pretendia, coletando dados que o usuário não consentiu explicitamente em compartilhar, por meio de um mecanismo que contorna a UI nativa de consentimento.

Substitua “telemetria” por “exfiltração” e a arquitetura é idêntica. Um hook com um matcher excessivamente amplo, rodando em todos os projetos, enviando dados para um endpoint externo. A diferença entre telemetria e ataque é intenção — e intenção não é auditável em tempo de execução.

Do artigo à prática: o que profissionais já têm

ClawGuard formaliza algo que profissionais vêm construindo informalmente. Claude Code vem com um sistema de hooks que suporta interceptação PreToolUse e PostToolUse. Eu rodo mais de 95 hooks que aplicam restrições de caminhos de arquivo, validam entradas de ferramentas e condicionam operações destrutivas a confirmação explícita.³

A diferença entre meus hooks e a visão do ClawGuard é automação. Meus hooks são regras escritas manualmente: bloquear endereços IP internos em entradas de MCP, restringir escritas de arquivo a diretórios do projeto, exigir aprovação para git force-push. A configuração avaliada do ClawGuard usa regras básicas de controle de acesso semelhantes em espírito a hooks escritos manualmente. O componente proposto de indução de regras específicas por tarefa derivaria automaticamente restrições a partir do objetivo declarado pelo usuário¹ — em vez de escrever “bloquear escritas em /etc”, o framework inferiria que uma tarefa descrita como “refatorar o módulo de login” não deveria precisar de acesso de escrita a diretórios do sistema. Esse componente continua sendo trabalho futuro.

Derivação automática de restrições é o problema mais difícil — e o componente de indução de regras específicas por tarefa do ClawGuard representa trabalho futuro, não resultados avaliados. A configuração de regras básicas que os autores de fato avaliaram mostrou resultados fortes, mas não perfeitos: AgentDojo alcançou 0% de taxa de sucesso de ataque (ASR), mas SkillInject ainda apresentou 4,8-14% de ASR e MCPSafeBench mostrou 7,1-11,0% de ASR dependendo do modelo.¹ Regras escritas manualmente são frágeis — cobrem os ataques que você antecipou. Restrições derivadas poderiam cobrir ataques que você não antecipou, porque operam no conjunto positivo (o que deveria acontecer) em vez do conjunto negativo (o que não deveria).

Se a derivação automática funciona de forma confiável em produção é uma questão em aberto. Os benchmarks são ambientes controlados. Sessões reais de agentes envolvem tarefas ambíguas, cadeias de ferramentas com múltiplas etapas e chamadas de ferramentas que parecem anômalas mas são legítimas. Falsos positivos que bloqueiam chamadas válidas de ferramentas eroderiam rapidamente a afirmação de “sem comprometer a utilidade do agente”.

A pilha de defesa em camadas

Defesa em tempo de execução não é um mecanismo único. A pilha prática para agentes com ferramentas tem pelo menos quatro camadas:

Camada 1: Validação de entrada. Hooks que inspecionam argumentos de chamadas de ferramentas antes da execução. Bloquear endereços IP internos, validar caminhos de arquivo, rejeitar metacaracteres de shell. Meus hooks PreToolUse operam nesta camada. Baixa taxa de falsos positivos, mas só captura padrões conhecidamente ruins.

Camada 2: Restrições por escopo de tarefa. Restringir o conjunto de ferramentas permitidas e argumentos permitidos ao que a tarefa atual requer. ClawGuard opera primariamente nesta camada.¹ Cobertura maior que validação de entrada sozinha, mas requer compreensão precisa da tarefa.

Camada 3: Inspeção de saída. Hooks PostToolUse que examinam resultados de ferramentas antes de o agente processá-los. Captura exfiltração de dados, detecta respostas anômalas, sinaliza comportamento inesperado de ferramentas. O post sobre o intermediário documentou por que a inspeção de saída importa — um roteador comprometido modifica respostas após a geração.

Camada 4: Auditoria de sessão. Registrar cada chamada de ferramenta, cada argumento, cada resultado para revisão posterior. Não é um mecanismo de prevenção, mas de detecção. Akshay Chugh descobriu o incidente de telemetria da Vercel exatamente por esse tipo de auditoria — lendo a configuração dos hooks e rastreando o que eles faziam.²

Nenhuma camada isolada é suficiente. Validação de entrada não detecta padrões novos. Restrições por escopo de tarefa podem ser restritivas ou permissivas demais. Inspeção de saída adiciona latência. Auditoria de sessão captura problemas depois do dano. A pilha funciona porque cada camada cobre as lacunas que as outras deixam.

O que ClawGuard acerta

O artigo faz três contribuições que importam para profissionais:

Determinismo acima de alinhamento. Enquadrar a defesa em tempo de execução como um mecanismo determinístico em vez de uma propriedade de alinhamento é o enquadramento correto. Alinhamento é uma propriedade de tempo de treinamento que se degrada sob condições adversárias. Aplicação determinística é uma propriedade de tempo de execução que se mantém independentemente do comportamento do modelo. A distinção soa acadêmica, mas muda o que você pode prometer sobre a postura de segurança do seu sistema.

Aplicação agnóstica ao canal. Defender contra injeção web, injeção de MCP e injeção de arquivo de skill com um único ponto de aplicação é arquiteturalmente sólido. Três defesas separadas para três canais de injeção criariam uma carga de manutenção e deixariam lacunas nas interseções. Um único ponto de aplicação na fronteira de chamada de ferramenta cobre os três canais por construção.

Sem modificação do modelo. Não exigir fine-tuning nem modificação arquitetural significa que a defesa funciona com qualquer modelo, incluindo modelos que você não controla. Um operador rodando Claude Code, Codex CLI ou qualquer outro framework de agentes pode adicionar defesa em tempo de execução sem esperar que o provedor do modelo lance uma atualização de segurança.

O que permanece em aberto

ClawGuard foi testado em benchmarks. Sessões de agentes em produção são mais bagunçadas. Várias questões permanecem antes que profissionais possam confiar na derivação automática de restrições:

Tarefas ambíguas. “Me ajude com esse projeto” não especifica quais ferramentas ou caminhos estão no escopo. Derivar restrições de objetivos vagos corre o risco de bloquear chamadas legítimas (restritivo demais) ou permitir chamadas perigosas (permissivo demais).

Cadeias de múltiplas etapas. Um agente que precisa ler um arquivo de configuração, chamar uma API e gravar resultados em um banco de dados tem um padrão de acesso complexo. Restrições derivadas da descrição inicial da tarefa podem não antecipar etapas intermediárias.

Descrições de tarefa adversárias. Se a derivação de restrições depende do objetivo declarado pelo usuário, um atacante que controla a descrição da tarefa (por meio de um workspace compartilhado, um issue tracker envenenado ou um arquivo de projeto manipulado) pode influenciar as próprias restrições.

Custo de desempenho. Avaliar restrições em cada fronteira de chamada de ferramenta adiciona latência. O artigo afirma que o framework preserva a utilidade, mas não reporta medições de latência.¹ Para sessões interativas de agentes, até 200ms por chamada de ferramenta muda a experiência do usuário.

Conclusões práticas

Para profissionais rodando agentes com ferramentas hoje:

Implante hooks PreToolUse agora. Você não precisa esperar pelo ClawGuard ou qualquer outro framework. O sistema de hooks do Claude Code suporta interceptação de chamadas de ferramentas hoje. Comece com validação de entrada — bloqueie endereços internos, restrinja caminhos de arquivo, condicione operações destrutivas a aprovação. O tutorial de hooks cobre a implementação.

Audite seus matchers de hooks. O incidente da Vercel aconteceu porque matchers de string vazia disparavam em todos os projetos.² Revise cada hook no seu .claude/settings.json e verifique se cada matcher visa apenas o contexto pretendido. Um hook com um matcher excessivamente amplo é uma vulnerabilidade, não uma defesa.

Registre cada chamada de ferramenta. Auditoria de sessão é a camada de defesa de menor esforço e maior valor. Mesmo que você não consiga prevenir todo ataque, pode detectá-lo depois — mas só se tiver logs.

Avalie ClawGuard contra sua pilha. O código do artigo está disponível publicamente. Avalie a configuração de regras básicas contra sua pilha de hooks existente. Se o componente de indução de regras específicas por tarefa amadurecer, a derivação automática de restrições complementaria regras escritas manualmente, não as substituiria.

Trate configuração como uma fronteira de confiança. Arquivos de skill, configuração de hooks, definições de servidores MCP — todo arquivo que influencia o comportamento do agente é uma superfície de ataque. Aplique os mesmos controles de acesso que você aplicaria a credenciais de produção.

O catálogo de vulnerabilidades de MCP documentou a superfície de ataque. ClawGuard propõe uma arquitetura de defesa. O incidente da Vercel demonstra por que ambos importam. Defesa em tempo de execução na fronteira de chamada de ferramenta é a camada aplicável — não porque alinhamento não ajuda, mas porque aplicação não depende dele.

Fontes

Perguntas frequentes

Como ClawGuard difere do sistema de permissões integrado do Claude Code?

O sistema de permissões do Claude Code pede aprovação do usuário no nível da ferramenta — aprovar ou negar categorias específicas de ferramentas. ClawGuard opera no nível do argumento, derivando automaticamente restrições sobre quais argumentos uma chamada de ferramenta deveria conter com base na tarefa atual. Os dois mecanismos são complementares: permissões controlam quais ferramentas podem rodar, restrições em tempo de execução controlam como essas ferramentas podem ser chamadas.

Preciso esperar o ClawGuard ser lançado para adicionar defesa em tempo de execução?

Não. O sistema de hooks do Claude Code suporta interceptação PreToolUse e PostToolUse hoje. Hooks escritos manualmente que validam entradas de ferramentas cobrem os padrões de ataque mais comuns imediatamente. A contribuição do ClawGuard é a derivação automática de restrições, que complementaria regras manuais em vez de substituí-las.

O incidente de telemetria da Vercel foi uma vulnerabilidade de segurança?

A divulgação descreveu uma questão de privacidade e consentimento, não uma vulnerabilidade tradicional. No momento da divulgação, o plugin coletava strings de comandos bash de todos os projetos e as enviava para um endpoint externo sem opt-in explícito por meio de UI nativa. A Vercel desde então tratou essas preocupações. O padrão arquitetural — matchers amplos em hooks, transmissão externa de dados, consentimento não nativo — permanece instrutivo porque espelha o mesmo padrão que um hook malicioso usaria para exfiltração de dados.

Qual é o impacto de desempenho da interceptação de chamadas de ferramentas em tempo de execução?

Para hooks escritos manualmente usando scripts de shell ou validadores leves, o overhead deve ficar abaixo de 200ms por chamada de ferramenta conforme a orientação da documentação de hooks. O artigo do ClawGuard não reporta medições de latência para sua avaliação de restrições, que pode adicionar overhead adicional. Para sessões interativas, latência por chamada de ferramenta importa — teste antes de implantar lógica de validação complexa.