Como o OpenRouter Armor verifica chamadas de ferramentas e quando o cliente precisa impedi-las

A versão beta do Armor da OpenRouter coloca um classificador de regras entre a chamada de ferramenta proposta por um modelo e o aplicativo que poderia executá-la. Para quem desenvolve agentes, o detalhe decisivo é onde o veredito realmente interrompe a execução. Em Chat Completions e Responses, o Armor pode reter uma chamada sinalizada. No modo de compatibilidade com Claude Code da API Messages, o tool_use sinalizado permanece na resposta, e o cliente precisa se recusar a executá-lo.

A documentação atual descreve uma versão beta disponível desde outubro de 2026. O BIG CHANGE analisou os contratos documentados de solicitações e respostas em 17 de outubro. Não enviamos uma solicitação à API, não executamos um agente nem medimos seu desempenho de segurança.

A grande mudança

• O que mudou: Um agente OpenRouter pode enviar suas chamadas propostas de ferramentas por um classificador que aplica regras escritas pelo desenvolvedor antes de chegarem ao aplicativo. No caminho padrão de aplicação das regras, a execução de uma chamada sinalizada é ignorada, e um motivo é devolvido para que o modelo possa continuar.
• Por que importa: Desenvolvedores podem expressar em prosa limites no nível das ações, incluindo exceções para trabalhos autorizados de escopo restrito. O contrato de compatibilidade com Messages ainda deixa o passo decisivo da execução com o cliente: um cliente que ignore o veredito de sinalização pode executar a chamada mesmo assim.
• O que acompanhar: As equipes precisam adequar o cliente ao modo de saída escolhido para a API, testar regras com seu próprio tráfego e decidir como tratar erros do classificador. Os formatos da beta podem mudar. A OpenRouter diz que o classificador pode tanto bloquear chamadas aceitáveis quanto deixar passar chamadas inaceitáveis.

Acompanhe uma chamada da proposta ao veredito

A OpenRouter diz que retém cada chamada proposta de ferramenta antes de encaminhá-la ao aplicativo. Seu modelo de decisão recebe a chamada, as regras e a conversa até aquele momento, estima se cada regra corresponde e combina os resultados em flagged ou not_flagged. Uma chamada não sinalizada é liberada sem alterações. No modo de aplicação das regras, uma chamada sinalizada recebe uma indicação para não ser executada; o modelo recebe o motivo e pode tentar uma chamada de escopo mais restrito ou explicar a recusa. É um julgamento do classificador sobre a ação proposta, não uma prova de que a ferramenta seguinte ou todo o agente sejam seguros.

Os níveis de regras respondem a perguntas diferentes. Uma correspondência com hard_deny bloqueia independentemente de uma regra de permissão ou do pedido do usuário. Uma correspondência com soft_deny pode ser anulada por uma correspondência com allow ou se o usuário pedir, na conversa, aquela operação exata sobre aquele alvo exato. Uma regra allow nunca bloqueia uma chamada sozinha. A OpenRouter também documenta uma recusa flexível integrada para um limite que o usuário definiu e não retirou. Desenvolvedores fornecem fatos, como um repositório confiável ou um destino de implantação, em environment; fatos desatualizados podem reduzir a precisão da regra. Objetos de regras com nome mostram um ID e um nome nos vereditos. Os limiares opcionais são, por padrão, 0.6 para regras de recusa e 0.7 para regras de permissão.

O exemplo documentado de Responses atribui a uma ferramenta bash uma regra de recusa rígida para git push. Com output_mode: "custom_item", um push sinalizado é substituído por um item openrouter:armor_blocked contendo a chamada e o motivo, seguido pela resposta do modelo. O exemplo mostra o que a documentação diz que o serviço devolve; não é um teste realizado pelo BIG CHANGE.

Escolha o contrato de saída antes de executar ferramentas

Para Chat Completions e Responses, o modo padrão text remove uma chamada bloqueada e coloca um marcador <openrouter_armor_blocked> no texto do assistente. A API Responses também oferece custom_item, que devolve o item bloqueado com tipo explícito onde teria aparecido uma function_call. A documentação diz para reenviar esse item sem alterações na próxima entrada de Responses, sem criar um function_call_output separado para ele. safeguard_results registra os vereditos por ID da chamada.

A API Messages tem um comportamento padrão substancialmente diferente quando a solicitação contém safeguards: claude_code_compatibility mantém o tool_use sinalizado em content[] e acrescenta seu resultado flagged a safeguard_results. O aplicativo deve ler esse resultado e se recusar a executar a chamada. A OpenRouter alerta expressamente que um cliente Messages que ignore o veredito executará um uso de ferramenta sinalizado. Um desenvolvedor sem controle do cliente pode pedir output_mode: "text" em Messages para que a OpenRouter retenha a chamada. Pedir a uma API um modo de saída que ela não consiga representar devolve um 400.

O modo automático do Claude Code pelo metaharness Ori da OpenRouter usa o contrato Messages sem uma entrada adicional do plugin Armor. A documentação diz que o Claude Code recusa chamadas sinalizadas, escreve um resultado de erro na transcrição e deixa o modelo continuar. Também diz que um endpoint Anthropic compatível com seu classificador pode fornecer um veredito transmitido diretamente; em outros endpoints, o Armor avalia. Esse é o comportamento de integração documentado, não uma afirmação de que todo cliente de terceiros o implementa corretamente.

Configure e confira um conjunto restrito de regras

Para um agente personalizado, o guia do Armor coloca uma entrada armor em plugins, com classifier_context versionado (v: 1), regras auto_mode e fatos opcionais sobre o ambiente. Comece pela ação e pelo recurso protegido que a regra deve reconhecer. Depois escolha uma recusa rígida para uma proibição que deve continuar valendo mesmo com consentimento do usuário, ou flexível quando o consentimento exato ou uma permissão com nome puderem legitimamente anulá-la. A documentação recomenda descrever a ação, em vez de uma única maneira de escrever um comando, e manter os fatos do ambiente atualizados.

O modo padrão enforce age conforme os vereditos. audit relata os mesmos vereditos, mas libera todas as chamadas, inclusive as sinalizadas. Serve para examinar tráfego real e ajustar regras antes de aplicá-las, não como modo de proteção. A auditoria não pode ser combinada com claude_code_compatibility. Em qualquer modo, leia safeguard_results: not_flagged significa permitido, flagged identifica uma regra correspondente, unavailable significa que a avaliação falhou, e skipped identifica uma ferramenta nativa do provedor que não foi avaliada. No streaming, o objeto do veredito chega ao fim da resposta; por isso, um cliente que usa Messages precisa esperá-lo antes de agir sobre um uso de ferramenta.

A OpenRouter lista on_error: "block" como padrão quando o classificador excede o tempo, apresenta erro ou não consegue tratar uma solicitação grande demais; on_error: "log" libera a chamada. No modo de compatibilidade com Claude Code, uma chamada unavailable é liberada com o veredito visível. Ferramentas nativas de servidor do provedor são ignoradas por padrão, a menos que evaluate_native_tools as force a sair do caminho nativo para avaliação. Essas configurações e o caminho real da ferramenta devem entrar na verificação de integração da equipe; uma entrada do Armor, sozinha, não mostra que todas as ferramentas foram avaliadas.

Custos, velocidade e limites de cobertura da beta

A OpenRouter informa que a avaliação acrescentou 279 milissegundos na mediana e 334 milissegundos no percentil 90 com seu conjunto de regras compatível com Claude Code carregado. São medições relatadas pelo fornecedor nessa condição, não um benchmark de um agente específico ou de todos os conjuntos de regras. Cada chamada é avaliada uma vez antes de ser liberada ou bloqueada. A avaliação não é cobrada durante a beta; a OpenRouter diz que anunciará preços antes da disponibilidade geral. A documentação não estabelece uma tarifa futura.

O modelo de decisão pode produzir falsos positivos e falhas de detecção porque julga regras em prosa contra argumentos em prosa. A documentação recomenda vereditos de auditoria sobre tráfego real e o ajuste dos limiares de cada regra. A avaliação do Armor ainda não é compatível com solicitações HIPAA, Zero Data Retention ou com restrições de região de dados. Uma solicitação com o plugin ativado em um desses contextos recebe um 403; uma solicitação Claude Code, por outro lado, libera a chamada como unavailable, e o Claude Code recorre à avaliação local do modo automático. O aviso da beta também abrange mudanças nos campos de configuração, em safeguard_results e no tipo de item openrouter:armor_blocked.

O Armor verifica chamadas propostas na passagem do modelo para o aplicativo. Isso o torna um mecanismo diferente da contenção de comandos MXC da Microsoft e dos controles de execução OpenShell e Sentry da NVIDIA, que aplicam restrições ao redor de uma carga de trabalho ou de seu acesso. Para o Armor, a decisão imediata de implementação é se o formato de resposta escolhido retém uma chamada sinalizada ou exige que o cliente a impeça.

Fontes e leituras adicionais

• Documentação do OpenRouter Armor, consultada em 17 de outubro de 2026. Fonte primária para estado beta, sequência do classificador, precedência das regras, contratos de resposta das APIs, comportamento diante de erros, exclusões por contexto de privacidade, latência relatada e cobrança da beta. São afirmações documentadas da OpenRouter; o BIG CHANGE não executou o plugin.
• BIG CHANGE sobre Microsoft MXC explica a contenção baseada em políticas para comandos gerados por agentes. Descreve uma camada separada de aplicação de restrições, não uma fase anterior do Armor.
• BIG CHANGE sobre NVIDIA OpenShell e Sentry descreve controles de acesso por software e um projeto opcional de monitoramento por hardware. É contexto relacionado, não uma continuação direta dessa função da OpenRouter.