AI-translated from English; not yet reviewed by a fluent editor.

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

> O OpenRouter Armor classifica chamadas propostas a ferramentas segundo regras do programador. Responses e Chat Completions podem reter chamadas sinalizadas; a compatibilidade com Messages deixa a responsabilidade ao cliente.

By BIG CHANGE Editorial

Published: 2026-10-17T01:51:13.522Z
Updated: 2026-10-17T01:51:13.522Z
Canonical: https://bigchange.ai/blog/openrouter-armor-tool-call-screening-client-enforcement

![Conceptual charcoal illustration of a desktop monitor and idle keyboard; abstract code strokes and one orange pending-call shape appear on the unbranded screen.](https://bigchange.ai/api/media/file/openrouter-armor-call-screening-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual OpenRouter interface or tested security result is depicted.

A [versão beta do Armor](https://openrouter.ai/docs/guides/features/plugins/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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) e dos [controlos de execução OpenShell e Sentry da NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), 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](https://openrouter.ai/docs/guides/features/plugins/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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) 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](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) 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.

## Sources

- [Documentação do OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor) — Documentação primária do produto verificada a 17 de outubro de 2026. Estabelece o estado beta, o comportamento do classificador e das regras, os formatos de resposta das API, erros, contextos restritos, latência comunicada e faturação da beta. Afirmações do fornecedor, não um teste independente.
- [BIG CHANGE: Como definir uma política MXC para comandos gerados por agentes](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — Cobertura anterior de um mecanismo separado de contenção de comandos; usada apenas como contexto da relação entre artigos.
- [BIG CHANGE: A plataforma de segurança de agentes da NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — Cobertura anterior de controlos de acesso em execução separados e de um desenho opcional de monitorização; usada apenas como contexto da relação entre artigos.