Edición en Markdown

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

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

> OpenRouter Armor clasifica las llamadas a herramientas propuestas según reglas del desarrollador. Responses y Chat Completions pueden retener las llamadas marcadas; la compatibilidad con Messages deja esa responsabilidad al 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.

La [beta de Armor](https://openrouter.ai/docs/guides/features/plugins/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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://openrouter.ai/docs/guides/features/plugins/armor#example) 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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) y [los controles de ejecución OpenShell y Sentry de NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), 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](https://openrouter.ai/docs/guides/features/plugins/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](https://bigchange.ai/blog/mxc-agent-command-containment-guide) 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](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) 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.

## Sources

- [Documentación de OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor) — Documentación primaria del producto revisada el 17 de octubre de 2026. Establece el estado beta, el comportamiento del clasificador y las reglas, las formas de respuesta de las API, los errores, los contextos restringidos, la latencia comunicada y la facturación de la beta. Afirmaciones del proveedor, no una prueba independiente.
- [BIG CHANGE: Cómo establecer una política MXC para comandos generados por agentes](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — Cobertura anterior de un mecanismo distinto de contención de comandos; se usa solo como contexto de la relación entre artículos.
- [BIG CHANGE: La plataforma de seguridad para agentes de NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — Cobertura anterior de controles de acceso en ejecución distintos y de un diseño opcional de supervisión; se usa solo como contexto de la relación entre artículos.