Como o OpenRouter Armor verifica chamadas a ferramentas e quando o cliente tem de as impedir

A versão beta do Armor da OpenRouter coloca um classificador de regras entre a chamada a uma ferramenta proposta por um modelo e a aplicação que a poderá executar. Para quem desenvolve agentes, o ponto decisivo é onde o veredicto impede efetivamente 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 mantém-se na resposta e o cliente tem de recusar executá-lo.

A documentação atual descreve uma versão beta disponível desde outubro de 2026. A BIG CHANGE analisou os contratos documentados de pedidos e respostas a 17 de outubro. Não enviámos um pedido à API, não executámos um agente nem medimos o seu desempenho de segurança.

A grande mudança

• O que mudou: Um agente OpenRouter pode enviar as chamadas propostas a ferramentas através de um classificador que aplica regras escritas pelo programador antes de chegarem à aplicação. No percurso predefinido de aplicação das regras, a execução da chamada sinalizada é omitida e é devolvido um motivo para que o modelo possa continuar.
• Porque importa: Os programadores podem expressar em prosa limites ao nível das ações, incluindo exceções para trabalho com permissões muito restritas. O contrato de compatibilidade com Messages continua a atribuir ao cliente o passo decisivo da execução: um cliente que ignore um veredicto de sinalização pode executar a chamada na mesma.
• O que acompanhar: As equipas precisam de adequar o cliente ao modo de saída escolhido para a API, testar regras com o seu próprio tráfego e decidir como tratar erros do classificador. Os formatos da versão beta podem mudar e a OpenRouter diz que o classificador tanto pode bloquear chamadas aceitáveis como deixar passar chamadas inaceitáveis.

Acompanhar uma chamada da proposta ao veredicto

A OpenRouter diz que retém cada chamada proposta a uma ferramenta antes de a encaminhar para a aplicação. O modelo de decisão recebe a chamada, as regras e a conversa até esse momento, estima se cada regra corresponde e combina os resultados em flagged ou not_flagged. Uma chamada não sinalizada é libertada sem alterações. No modo de aplicação das regras, uma chamada sinalizada fica marcada para não ser executada; o modelo recebe o motivo e pode tentar uma chamada de âmbito mais restrito ou explicar a recusa. É um juízo do classificador sobre a ação proposta, não uma prova de que uma ferramenta posterior ou o agente completo são 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 utilizador. Uma correspondência com soft_deny pode ser anulada por uma correspondência com allow ou pelo utilizador pedir, na conversa, aquela operação exata sobre aquele alvo exato. Uma regra allow nunca bloqueia uma chamada por si só. A OpenRouter também documenta uma recusa flexível incorporada para um limite que o utilizador definiu e não retirou. Os programadores fornecem factos, como um repositório de confiança ou um destino de implementação, em environment; factos desatualizados podem tornar uma regra menos precisa. Os objetos de regras com nome mostram um ID e um nome nos veredictos. Os limiares opcionais têm valores predefinidos de 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 que contém a chamada e o motivo, seguido da resposta do modelo. O exemplo mostra o que a documentação diz que o serviço devolve; não é um teste realizado pela BIG CHANGE.

Escolher o contrato de saída antes de executar ferramentas

Em Chat Completions e Responses, o modo predefinido text remove a chamada bloqueada e coloca um marcador <openrouter_armor_blocked> no texto do assistente. A API Responses também suporta custom_item, que devolve o item bloqueado com um tipo explícito onde teria surgido uma function_call. A documentação indica que se deve devolver esse item sem alterações na próxima entrada de Responses, sem criar um function_call_output separado para o mesmo. safeguard_results regista os veredictos por ID da chamada.

A API Messages tem um comportamento predefinido substancialmente diferente quando o pedido inclui safeguards: claude_code_compatibility mantém o tool_use sinalizado em content[] e acrescenta o seu resultado flagged a safeguard_results. A aplicação tem de ler esse resultado e recusar a execução da chamada. A OpenRouter avisa expressamente que um cliente Messages que ignore o veredicto irá executar uma utilização de ferramenta sinalizada. Um programador sem controlo sobre o 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 não consegue representar devolve um 400.

O modo automático do Claude Code através do metaharness Ori da OpenRouter usa o contrato de 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. Diz ainda que um endpoint Anthropic compatível com o seu classificador pode fornecer um veredicto que é transmitido diretamente; nos outros endpoints, o Armor faz a avaliação. É o comportamento de integração documentado, não uma afirmação de que todos os clientes de terceiros o implementam corretamente.

Configurar e verificar um conjunto restrito de regras

Para um agente personalizado, o guia do Armor coloca uma entrada armor em plugins, com o campo classifier_context versionado (v: 1), regras auto_mode e factos 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 manter-se apesar do consentimento do utilizador, ou flexível quando o consentimento exato ou uma permissão com nome podem legitimamente anulá-la. A documentação aconselha a descrever a ação em vez de uma única forma de escrever um comando e a manter os factos do ambiente atualizados.

O modo predefinido enforce atua sobre os veredictos. audit comunica os mesmos veredictos enquanto liberta todas as chamadas, incluindo as sinalizadas. Serve para examinar tráfego real e ajustar regras antes da sua aplicação, não como modo de proteção. A auditoria não pode ser combinada com claude_code_compatibility. Em qualquer dos modos, 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 fornecedor que não foi avaliada. Em streaming, o objeto do veredicto chega no fim da resposta, pelo que um cliente que usa Messages tem de esperar por ele antes de agir sobre uma utilização de ferramenta.

A OpenRouter apresenta on_error: "block" como predefinição quando o classificador excede o tempo, dá erro ou não consegue tratar um pedido demasiado grande; on_error: "log" liberta a chamada. No modo de compatibilidade com Claude Code, uma chamada unavailable é libertada com o veredicto visível. As ferramentas nativas do servidor do fornecedor são omitidas por predefinição, a menos que evaluate_native_tools as force a sair do percurso nativo para serem avaliadas. Estas definições e o percurso efetivo da ferramenta devem fazer parte da verificação de integração da equipa; uma entrada do Armor, por si só, não mostra que todas as ferramentas foram avaliadas.

Custos, velocidade e limites de cobertura da versão beta

A OpenRouter refere que a avaliação acrescentou 279 milissegundos na mediana e 334 milissegundos no percentil 90 com o seu conjunto de regras compatível com Claude Code carregado. São medições comunicadas pelo fornecedor nessa condição, não um benchmark de um agente específico nem de todos os conjuntos de regras. Cada chamada é avaliada uma vez antes de ser libertada 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 fixa uma tarifa futura.

O modelo de decisão pode produzir falsos positivos e falhas de deteção porque avalia regras em prosa face a argumentos em prosa. A documentação recomenda veredictos de auditoria sobre tráfego real e o ajuste dos limiares de cada regra. A avaliação Armor ainda não é suportada em pedidos HIPAA, Zero Data Retention ou com restrições de região de dados. Um pedido com o plugin ativado num desses contextos recebe um 403; um pedido Claude Code, em contrapartida, liberta a chamada como unavailable, e o Claude Code recorre à avaliação local do modo automático. O aviso da beta também abrange alterações a campos de configuração, safeguard_results e ao tipo de item openrouter:armor_blocked.

O Armor verifica chamadas propostas na passagem do modelo para a aplicação. Isso distingue o mecanismo da contenção de comandos MXC da Microsoft e dos controlos de execução OpenShell e Sentry da NVIDIA, que aplicam restrições em torno de uma carga de trabalho ou do seu acesso. No 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 a 17 de outubro de 2026. Fonte primária sobre o estado beta, a sequência do classificador, a precedência das regras, os contratos de resposta das API, o comportamento perante erros, as exclusões por contexto de privacidade, a latência comunicada e a faturação da beta. São afirmações documentadas da OpenRouter; a 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 de aplicação de restrições separada, não uma fase anterior do Armor.
• BIG CHANGE sobre NVIDIA OpenShell e Sentry descreve controlos de acesso por software e um desenho opcional de monitorização por hardware. É contexto relacionado, não uma continuação direta desta funcionalidade da OpenRouter.