Cómo OpenRouter Armor examina las llamadas a herramientas y cuándo debe detenerlas el cliente

La beta de Armor de OpenRouter sitúa un clasificador de reglas entre la llamada a una herramienta propuesta por un modelo y la aplicación que podría ejecutarla. Para quien desarrolla agentes, lo decisivo es dónde un veredicto detiene realmente la ejecución. En Chat Completions y Responses, Armor puede retener una llamada marcada. En el modo de compatibilidad con Claude Code de la API Messages, el tool_use marcado permanece en la respuesta y el cliente debe negarse a ejecutarlo.

La documentación actual describe una beta disponible desde octubre de 2026. BIG CHANGE revisó los contratos documentados de solicitud y respuesta el 17 de octubre. No enviamos una solicitud a la API, ejecutamos un agente ni medimos su rendimiento en seguridad.

El gran cambio

• Qué cambió: Un agente de OpenRouter puede enviar sus llamadas propuestas a un clasificador que aplica reglas escritas por el desarrollador antes de que lleguen a la aplicación. En la vía predeterminada de aplicación de reglas, se omite la ejecución de una llamada marcada y se devuelve un motivo para que el modelo pueda continuar.
• Por qué importa: Los desarrolladores pueden expresar en prosa límites sobre acciones, con excepciones para trabajos autorizados de alcance reducido. El contrato de compatibilidad con Messages sigue dejando al cliente el paso decisivo de la ejecución: un cliente que ignore un veredicto de marcado puede ejecutar la llamada de todos modos.
• Qué observar: Los equipos deben adaptar su cliente al modo de salida elegido para la API, probar las reglas con su propio tráfico y decidir cómo responder a errores del clasificador. Los formatos de la beta pueden cambiar, y OpenRouter afirma que el clasificador puede tanto bloquear llamadas aceptables como dejar pasar otras inaceptables.

Seguir una llamada desde la propuesta hasta el veredicto

OpenRouter dice que retiene cada llamada propuesta antes de enviarla a la aplicación. Su modelo de decisión recibe la llamada, las reglas y la conversación hasta ese momento, estima si coincide cada regla y combina los resultados en flagged o not_flagged. Una llamada sin marcar se libera sin cambios. En el modo de aplicación de reglas, una llamada marcada se señala para omitir su ejecución; el modelo recibe el motivo y puede intentar una llamada de menor alcance o explicar la denegación. Es un juicio del clasificador sobre la acción propuesta, no una prueba de que una herramienta posterior o el agente completo sean seguros.

Los niveles de reglas responden a preguntas distintas. Una coincidencia con hard_deny bloquea la llamada independientemente de una regla de permiso o de la petición del usuario. Una coincidencia con soft_deny puede anularse mediante una coincidencia con allow o si el usuario pide en la conversación esa operación exacta sobre ese objetivo exacto. Una regla allow nunca bloquea una llamada por sí sola. OpenRouter también documenta una denegación flexible incorporada para un límite fijado por el usuario que no se haya retirado. Los desarrolladores aportan datos, como un repositorio de confianza o un destino de despliegue, en environment; los datos obsoletos pueden restar precisión a una regla. Los objetos de reglas con nombre muestran un ID y un nombre en los veredictos. Los umbrales opcionales son, de forma predeterminada, 0.6 para las reglas de denegación y 0.7 para las de permiso.

El ejemplo documentado de Responses asigna a una herramienta bash una regla de denegación estricta para git push. Con output_mode: "custom_item", un envío marcado se sustituye por un elemento openrouter:armor_blocked que contiene la llamada y el motivo, seguido de la respuesta del modelo. El ejemplo muestra lo que la documentación dice que devuelve el servicio; no es una prueba realizada por BIG CHANGE.

Elegir el contrato de salida antes de ejecutar herramientas

Para Chat Completions y Responses, el modo predeterminado text elimina la llamada bloqueada e inserta un marcador <openrouter_armor_blocked> en el texto del asistente. La API Responses también admite custom_item, que devuelve el elemento bloqueado con tipo explícito donde habría aparecido una function_call. La documentación indica que ese elemento debe reenviarse sin cambios en la siguiente entrada de Responses, sin crear un function_call_output separado para él. safeguard_results registra los veredictos por ID de llamada.

La API Messages tiene un comportamiento predeterminado sustancialmente distinto cuando la solicitud incluye safeguards: claude_code_compatibility deja el tool_use marcado en content[] y añade su resultado flagged a safeguard_results. La aplicación debe leer ese resultado y negarse a ejecutar la llamada. OpenRouter advierte expresamente que un cliente de Messages que ignore el veredicto ejecutará un uso de herramienta marcado. Un desarrollador que no pueda controlar el cliente puede solicitar output_mode: "text" en Messages para que OpenRouter retenga la llamada. Solicitar a una API un modo de salida que no pueda representar devuelve un 400.

El modo automático de Claude Code a través de Ori, el metaharness de OpenRouter, usa el contrato de Messages sin una entrada adicional del complemento Armor. La documentación dice que Claude Code rechaza las llamadas marcadas, escribe un resultado de error en la transcripción y permite que el modelo continúe. También indica que un endpoint de Anthropic compatible con su clasificador puede proporcionar un veredicto que se transmite directamente; Armor evalúa en los demás endpoints. Es el comportamiento de integración documentado, no una afirmación de que todos los clientes de terceros lo implementen correctamente.

Configurar y comprobar un conjunto acotado de reglas

Para un agente personalizado, la guía de Armor sitúa una entrada armor en plugins, con classifier_context versionado (v: 1), reglas auto_mode y datos opcionales del entorno. Empiece por la acción y el recurso protegido que debe reconocer la regla; después elija una denegación estricta para una prohibición que deba mantenerse incluso con el consentimiento del usuario, o flexible si el consentimiento exacto o un permiso con nombre pueden anularla legítimamente. La documentación aconseja describir la acción en lugar de una única forma de escribir un comando y mantener actualizados los datos del entorno.

El modo predeterminado enforce actúa según los veredictos. audit informa de los mismos veredictos, pero libera todas las llamadas, incluidas las marcadas. Sirve para examinar tráfico real y ajustar reglas antes de aplicarlas, no como modo de protección. El modo de auditoría no puede combinarse con claude_code_compatibility. En cualquiera de los modos, lea safeguard_results: not_flagged significa permitido, flagged identifica una regla coincidente, unavailable significa que la evaluación falló y skipped identifica una herramienta nativa del proveedor no evaluada. En streaming, el objeto de veredicto llega al final de la respuesta, por lo que un cliente que use Messages debe esperarlo antes de actuar sobre un uso de herramienta.

OpenRouter establece on_error: "block" como valor predeterminado si el clasificador agota el tiempo, da error o no puede procesar una solicitud demasiado grande; on_error: "log" libera la llamada. En el modo de compatibilidad con Claude Code, una llamada unavailable se libera con el veredicto visible. Las herramientas de servidor nativas del proveedor se omiten de forma predeterminada, salvo que evaluate_native_tools las fuerce a salir de la vía nativa para evaluarlas. Estos ajustes y la ruta real de las herramientas deben incluirse en la comprobación de integración del equipo; una entrada de Armor por sí sola no demuestra que se hayan evaluado todas las herramientas.

Los límites de coste, velocidad y cobertura de la beta

OpenRouter informa de que la evaluación añadió 279 milisegundos en la mediana y 334 milisegundos en el percentil 90 con su conjunto de reglas compatible con Claude Code cargado. Son mediciones comunicadas por el proveedor bajo esa condición concreta, no una prueba comparativa de un agente determinado ni de todos los conjuntos de reglas. Cada llamada se evalúa una vez antes de liberarse o bloquearse. La evaluación no se cobra durante la beta; OpenRouter dice que anunciará los precios antes de la disponibilidad general. La documentación no establece una tarifa futura.

El modelo de decisión puede generar falsos positivos y omisiones porque compara reglas en prosa con argumentos en prosa. La documentación recomienda usar veredictos de auditoría sobre tráfico real y ajustar los umbrales de cada regla. La evaluación de Armor aún no admite solicitudes HIPAA, Zero Data Retention o con restricciones de región de datos. Una solicitud con el complemento activado en uno de esos contextos recibe un 403; una solicitud de Claude Code, en cambio, libera la llamada como unavailable, y Claude Code recurre a la evaluación local de su modo automático. La advertencia sobre la beta también abarca cambios en campos de configuración, safeguard_results y el tipo de elemento openrouter:armor_blocked.

Armor examina las llamadas propuestas al pasar del modelo a la aplicación. Por eso es un mecanismo distinto de la contención de comandos MXC de Microsoft y los controles de ejecución OpenShell y Sentry de NVIDIA, que aplican restricciones alrededor de una carga de trabajo o de su acceso. En Armor, la decisión inmediata de implementación es si el formato de respuesta elegido retiene una llamada marcada o exige que el cliente la detenga.

Fuentes y lecturas adicionales

• Documentación de OpenRouter Armor, consultada el 17 de octubre de 2026. Fuente primaria sobre el estado beta, la secuencia del clasificador, la prioridad de las reglas, los contratos de respuesta de las API, el comportamiento ante errores, las exclusiones por contexto de privacidad, la latencia comunicada y la facturación de la beta. Son afirmaciones documentadas de OpenRouter; BIG CHANGE no ejecutó el complemento.
• BIG CHANGE sobre Microsoft MXC explica la contención mediante políticas de comandos generados por agentes. Describe una capa de aplicación de restricciones distinta, no una fase anterior de Armor.
• BIG CHANGE sobre NVIDIA OpenShell y Sentry describe controles de acceso de software y un diseño opcional de supervisión por hardware. Es contexto relacionado, no una continuación directa de esta función de OpenRouter.