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

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

> O OpenRouter Armor classifica chamadas propostas de ferramentas pelas regras do desenvolvedor. Responses e Chat Completions podem reter chamadas sinalizadas; a compatibilidade com Messages deixa a responsabilidade com o 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 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](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` 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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) e dos [controles de execução OpenShell e Sentry da NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), 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](https://openrouter.ai/docs/guides/features/plugins/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](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 separada de aplicação de restrições, 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 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.

## Sources

- [Documentação do OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor) — Documentação primária do produto verificada em 17 de outubro de 2026. Estabelece estado beta, comportamento do classificador e das regras, formatos de resposta das APIs, erros, contextos restritos, latência relatada e cobrança 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 controles de acesso em execução separados e de um projeto opcional de monitoramento; usada apenas como contexto da relação entre artigos.