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

Uma semana atrás, publiquei 50 vulnerabilidades em MCP abrangendo 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 do 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 confirmado pelo usuário em cada fronteira de chamada de ferramenta.¹ Na configuração avaliada, o framework aplica regras básicas de controle de acesso (bloqueio de acesso não autorizado a arquivos, prevenção de exfiltração de credenciais, restrição de 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 fronteira.¹ 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 os autores não o incluíram na 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, de uma página web ou de 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, incluindo SSRF, RCE e path traversal, exploram falhas do lado do servidor que não dependem do modelo seguir instruções, mas a fronteira de chamada de ferramenta permanece relevante para 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é acertar esse 1%. 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 via 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 exfiltração silenciosa é uma instância desse padrão, com instruções de exfiltração escondidas em conteúdo obtido externamente.

Injeção via servidor MCP. Um servidor MCP comprometido ou malicioso incorpora 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 via arquivo de skill. Um atacante insere instruções adversárias 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, então 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 seu conjunto de regras. Na configuração avaliada, essas regras são restrições básicas de controle de acesso (restrições de caminho de arquivo, allowlists de chamadas de rede, bloqueios de acesso a credenciais). ClawGuard bloqueia qualquer chamada que esteja fora dessas restrições, não importa quão convincente seja o prompt de injeção.

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

O incidente de telemetria da Vercel

Quatro dias antes do artigo do ClawGuard ser publicado, Akshay Chugh divulgou uma análise sobre o Vercel Plugin 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 em 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 correspondente, a menos que o usuário configurasse VERCEL_PLUGIN_TELEMETRY=off.²

A Vercel abordou as questõ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 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 matcher excessivamente amplo, rodando em todo projeto, 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 já vem com um sistema de hooks que suporta interceptação PreToolUse e PostToolUse. Eu rodo mais de 95 hooks que aplicam restrições de caminho de arquivo, validam entradas de ferramentas e condicionam operações destrutivas a confirmação explícita.³

A lacuna 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 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 permanece como 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 atingiu 0% de taxa de sucesso de ataque (ASR), mas SkillInject ainda apresentou 4,8-14% ASR e MCPSafeBench mostrou 7,1-11,0% 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 sobre o 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 erodem 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 chamada de ferramenta antes da execução. Bloqueiam endereços IP internos, validam caminhos de arquivo, rejeitam metacaracteres de shell. Meus hooks PreToolUse operam nesta camada. Baixa taxa de falsos positivos, mas só captura padrões conhecidamente maliciosos.

Camada 2: Aplicação de regras básicas. Restringir o conjunto de ferramentas e argumentos permitidos com base em regras de controle de acesso (restrições de caminho, allowlists de rede, proteções de credenciais). A configuração avaliada do ClawGuard opera nesta camada.¹ O artigo também propõe derivação de restrições por escopo de tarefa, que ficaria entre esta camada e a próxima, mas esse componente permanece como trabalho futuro. Cobertura maior que validação de entrada sozinha, mas as regras precisam ser mantidas conforme o ambiente muda.

Camada 3: Inspeção de saída. Hooks PostToolUse que examinam resultados de ferramentas antes de o agente processá-los. Capturam exfiltração de dados, detectam respostas anômalas, sinalizam comportamento inesperado de ferramentas. O post sobre o middleman documentou por que 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 falha em 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 defesa em tempo de execução como mecanismo determinístico em vez de propriedade de alinhamento é o enquadramento correto. Alinhamento é uma propriedade de tempo de treinamento que 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 parece acadêmica, mas muda o que você pode prometer sobre a postura de segurança do seu sistema.

Aplicação agnóstica de canal. Defender contra injeção web, injeção MCP e injeção via 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 um fardo de manutenção e deixariam lacunas nas interseções. Um único ponto de aplicação na fronteira de chamada de ferramenta cobre todos 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 reais de agentes são mais confusas. Várias questões permanecem antes que profissionais possam confiar em derivação automática de restrições:

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

Cadeias com 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 controle 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 performance. 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, mesmo 200ms por chamada de ferramenta muda a experiência do usuário.

Conclusões operacionais

Para profissionais rodando agentes com ferramentas hoje:

Implemente 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 confirmaçã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 atinge apenas o contexto pretendido. Um hook com matcher excessivamente amplo é um risco, 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 artigo referencia um repositório, embora os autores ainda não tivessem publicado o código no momento da escrita. Quando disponível, 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, 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 servidor MCP: cada 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 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 suporta tanto aprovação em nível de ferramenta (aprovar ou negar categorias de ferramentas) quanto especificadores em nível de argumento (por exemplo, Bash(git diff *) para permitir apenas comandos correspondentes). A configuração avaliada do ClawGuard aplica regras básicas de controle de acesso em nível de argumento. Seu componente proposto de indução de regras específicas por tarefa derivaria automaticamente restrições de argumento a partir da tarefa atual, mas os autores não avaliaram esse componente. Os dois sistemas se complementam: permissões do Claude Code controlam quais ferramentas e padrões de argumento podem ser executados, enquanto restrições em tempo de execução no estilo ClawGuard adicionam uma segunda camada de aplicação.

Preciso esperar o ClawGuard ser lançado antes de 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 é 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 abordou essas questões. O padrão arquitetural (matchers amplos de hooks, transmissão de dados para serviço externo, 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 performance da interceptação de chamadas de ferramentas em tempo de execução?

Para hooks escritos manualmente usando scripts de shell ou validadores leves, a sobrecarga deve ficar abaixo de 200ms por chamada de ferramenta na minha experiência operacional. O artigo do ClawGuard não reporta medições de latência para sua avaliação de restrições, que pode adicionar sobrecarga extra. Para sessões interativas, a latência por chamada de ferramenta importa, então teste antes de implantar lógica de validação complexa.