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

# Comment OpenRouter Armor examine les appels d'outils, et quand le client doit les arrêter

> OpenRouter Armor classe les appels d'outils proposés selon les règles du développeur. Responses et Chat Completions peuvent retenir les appels signalés ; la compatibilité Messages en laisse la responsabilité au client.

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.

La [bêta d'Armor](https://openrouter.ai/docs/guides/features/plugins/armor) d'OpenRouter place un classificateur de règles entre l'appel d'outil proposé par un modèle et l'application susceptible de l'exécuter. Pour un développeur d'agents, le point essentiel est l'endroit où un verdict arrête réellement l'exécution. Dans Chat Completions et Responses, Armor peut retenir un appel signalé. Dans le mode de compatibilité Claude Code de l'API Messages, le `tool_use` signalé reste dans la réponse, et le client doit refuser de l'exécuter.

La documentation actuelle décrit une bêta disponible depuis octobre 2026. BIG CHANGE a examiné les contrats documentés de requête et de réponse le 17 octobre. Nous n'avons envoyé aucune requête à l'API, exécuté aucun agent ni mesuré ses performances de sécurité.

## Le grand changement

- **Ce qui a changé :** Un agent OpenRouter peut transmettre ses appels d'outils proposés à un classificateur qui applique les règles écrites par le développeur avant que les appels n'atteignent l'application. Dans le circuit d'application des règles par défaut, l'exécution d'un appel signalé est ignorée et un motif est renvoyé pour permettre au modèle de continuer.
- **Pourquoi c'est important :** Les développeurs peuvent définir en langage courant des limites au niveau des actions, avec des exceptions pour des tâches strictement autorisées. Le contrat de compatibilité Messages confie toujours au client l'étape décisive de l'exécution : un client qui ignore un verdict de signalement peut tout de même exécuter l'appel.
- **À surveiller :** Les équipes doivent adapter leur client au mode de sortie de l'API choisi, tester les règles sur leur propre trafic et décider du comportement en cas d'erreur du classificateur. Les formats de la bêta peuvent changer. OpenRouter indique que le classificateur peut aussi bien bloquer des appels acceptables que laisser passer des appels inacceptables.

## Suivre un appel de sa proposition au verdict

OpenRouter dit retenir chaque appel d'outil proposé avant de le transmettre à l'application. Son modèle de décision reçoit l'appel, les règles et la conversation jusqu'alors, estime si chaque règle correspond et combine les résultats en `flagged` ou `not_flagged`. Un appel non signalé est libéré sans modification. En mode d'application des règles, un appel signalé est marqué pour ne pas être exécuté ; le modèle reçoit le motif et peut essayer un appel plus restreint ou expliquer le refus. Il s'agit du jugement d'un classificateur sur l'action proposée, pas d'une preuve que l'outil suivant ou l'agent entier est sûr.

Les niveaux de règles répondent à des questions différentes. Une correspondance avec `hard_deny` bloque l'appel indépendamment d'une règle d'autorisation ou de la demande de l'utilisateur. Une correspondance avec `soft_deny` peut être annulée par une correspondance avec `allow` ou par une demande de l'utilisateur, dans la conversation, portant sur cette opération exacte et cette cible exacte. Une règle `allow` ne bloque jamais à elle seule un appel. OpenRouter documente aussi un refus souple intégré pour une limite que l'utilisateur a fixée et n'a pas levée. Les développeurs fournissent des faits, tels qu'un dépôt de confiance ou une cible de déploiement, dans `environment` ; des faits obsolètes peuvent rendre une règle moins précise. Les objets de règles nommés affichent un identifiant et un nom dans les verdicts. Les seuils facultatifs sont par défaut de 0.6 pour les règles de refus et de 0.7 pour les règles d'autorisation.

L'[exemple Responses documenté](https://openrouter.ai/docs/guides/features/plugins/armor#example) attribue à un outil `bash` une règle de refus strict pour `git push`. Avec `output_mode: "custom_item"`, un push signalé est remplacé par un élément `openrouter:armor_blocked` contenant l'appel et le motif, suivi de la réponse du modèle. L'exemple montre ce que la documentation dit que le service renvoie ; ce n'est pas un test réalisé par BIG CHANGE.

## Choisir le contrat de sortie avant d'exécuter des outils

Pour Chat Completions et Responses, le mode par défaut `text` retire l'appel bloqué et place un marqueur `<openrouter_armor_blocked>` dans le texte de l'assistant. L'API Responses prend aussi en charge `custom_item`, qui renvoie l'élément bloqué typé à l'endroit où un `function_call` serait apparu. La documentation demande de renvoyer cet élément sans modification dans l'entrée Responses suivante, sans créer de `function_call_output` distinct pour lui. `safeguard_results` enregistre les verdicts par identifiant d'appel.

L'API Messages a un comportement par défaut sensiblement différent lorsque la requête contient `safeguards` : `claude_code_compatibility` conserve le `tool_use` signalé dans `content[]` et ajoute son résultat `flagged` à `safeguard_results`. **L'application doit lire ce résultat et refuser d'exécuter l'appel.** OpenRouter avertit explicitement qu'un client Messages ignorant le verdict exécutera une utilisation d'outil signalée. Un développeur qui ne contrôle pas le client peut demander `output_mode: "text"` dans Messages pour qu'OpenRouter retienne l'appel. Demander à une API un mode de sortie qu'elle ne peut pas représenter renvoie un 400.

Le mode automatique de Claude Code via le métaharnais Ori d'OpenRouter utilise le contrat Messages sans entrée supplémentaire du plugin Armor. La documentation indique que Claude Code refuse les appels signalés, écrit un résultat d'erreur dans la transcription et laisse le modèle continuer. Elle précise aussi qu'un endpoint Anthropic compatible avec son classificateur peut fournir un verdict transmis directement ; Armor évalue sur les autres endpoints. C'est le comportement d'intégration documenté, pas l'affirmation que chaque client tiers l'implémente correctement.

## Configurer et vérifier un ensemble restreint de règles

Pour un agent personnalisé, le [guide Armor](https://openrouter.ai/docs/guides/features/plugins/armor#example) place une entrée `armor` dans `plugins`, avec `classifier_context` versionné (`v: 1`), des règles `auto_mode` et des faits facultatifs sur l'environnement. Commencez par l'action et la ressource protégée que la règle doit reconnaître, puis choisissez un refus strict pour une interdiction devant subsister malgré le consentement de l'utilisateur, ou un refus souple lorsqu'un consentement exact ou une autorisation nommée peut légitimement la lever. La documentation conseille de décrire l'action plutôt qu'une seule façon d'écrire une commande et de maintenir les faits sur l'environnement à jour.

Le mode par défaut `enforce` agit selon les verdicts. `audit` rapporte les mêmes verdicts tout en libérant chaque appel, y compris ceux signalés. Il sert à examiner le trafic réel et à ajuster les règles avant leur application, pas à protéger. Le mode d'audit ne peut pas être combiné avec `claude_code_compatibility`. Dans les deux modes, lisez `safeguard_results` : `not_flagged` signifie autorisé, `flagged` identifie une règle correspondante, `unavailable` signifie que l'évaluation a échoué, et `skipped` identifie un outil natif du fournisseur non évalué. En streaming, l'objet de verdict arrive à la fin de la réponse ; un client utilisant Messages doit donc l'attendre avant d'agir sur une utilisation d'outil.

OpenRouter indique `on_error: "block"` comme valeur par défaut lorsque le classificateur dépasse le délai, rencontre une erreur ou ne peut traiter une requête trop volumineuse ; `on_error: "log"` libère l'appel. En mode de compatibilité Claude Code, un appel `unavailable` est libéré avec le verdict visible. Les outils serveur natifs du fournisseur sont ignorés par défaut, sauf si `evaluate_native_tools` les fait sortir du circuit natif pour évaluation. Ces paramètres et le chemin réel de l'outil doivent faire partie des vérifications d'intégration de l'équipe ; une entrée Armor ne prouve pas à elle seule que tous les outils ont été évalués.

## Coût, vitesse et limites de couverture de la bêta

OpenRouter rapporte que l'évaluation a ajouté **279 millisecondes à la médiane et 334 millisecondes au 90e percentile** avec son ensemble de règles compatible Claude Code chargé. Ce sont des mesures rapportées par le fournisseur dans cette condition, pas un benchmark d'un agent particulier ni de tous les ensembles de règles. Chaque appel est évalué une fois avant d'être libéré ou bloqué. L'évaluation n'est pas facturée pendant la bêta ; OpenRouter dit qu'il annoncera les prix avant la disponibilité générale. La documentation ne fixe pas de tarif futur.

Le modèle de décision peut produire des faux positifs et des omissions, car il confronte des règles en prose à des arguments en prose. La documentation recommande les verdicts d'audit sur du trafic réel et l'ajustement des seuils de chaque règle. L'évaluation Armor ne prend pas encore en charge les requêtes HIPAA, Zero Data Retention ou soumises à des restrictions de région des données. Une requête avec plugin activé dans l'un de ces contextes reçoit un 403 ; une requête Claude Code libère au contraire l'appel comme `unavailable`, et Claude Code revient à l'évaluation locale de son mode automatique. L'avertissement sur la bêta couvre aussi les changements des champs de configuration, de `safeguard_results` et du type d'élément `openrouter:armor_blocked`.

Armor examine les appels proposés lors du passage du modèle à l'application. Son mécanisme diffère donc du [confinement des commandes MXC de Microsoft](https://bigchange.ai/blog/mxc-agent-command-containment-guide) et des [contrôles d'exécution OpenShell et Sentry de NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), qui appliquent des restrictions autour d'une charge de travail ou de son accès. Pour Armor, la décision immédiate d'implémentation est de savoir si le format de réponse choisi retient un appel signalé ou demande au client de l'arrêter.

## Sources et lectures complémentaires

- [Documentation OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor), consultée le 17 octobre 2026. Source primaire pour le statut bêta, la séquence du classificateur, la priorité des règles, les contrats de réponse des API, le comportement en cas d'erreur, les exclusions de contextes de confidentialité, la latence rapportée et la facturation de la bêta. Ce sont des affirmations documentées d'OpenRouter ; BIG CHANGE n'a pas exécuté le plugin.
- [BIG CHANGE sur Microsoft MXC](https://bigchange.ai/blog/mxc-agent-command-containment-guide) explique le confinement des commandes générées par les agents selon des politiques. Il décrit une couche d'application des restrictions distincte, pas une phase antérieure d'Armor.
- [BIG CHANGE sur NVIDIA OpenShell et Sentry](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) décrit des contrôles d'accès logiciels et une conception facultative de surveillance matérielle. C'est un contexte connexe, pas une suite directe de cette fonctionnalité OpenRouter.

## Sources

- [Documentation OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor) — Documentation primaire du produit vérifiée le 17 octobre 2026. Établit le statut bêta, le comportement du classificateur et des règles, les formes de réponse des API, les erreurs, les contextes restreints, la latence rapportée et la facturation de la bêta. Affirmations du fournisseur, pas un test indépendant.
- [BIG CHANGE : Comment définir une politique MXC pour les commandes générées par les agents](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — Couverture antérieure d'un mécanisme distinct de confinement des commandes ; utilisée uniquement pour contextualiser la relation entre articles.
- [BIG CHANGE : La plateforme de sécurité des agents de NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — Couverture antérieure de contrôles d'accès à l'exécution distincts et d'une conception facultative de surveillance ; utilisée uniquement pour contextualiser la relation entre articles.