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

La bêta d'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é 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 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 et des contrôles d'exécution OpenShell et Sentry de NVIDIA, 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, 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 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 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.