Версия Markdown

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

# Как OpenRouter Armor проверяет вызовы инструментов и когда их должен останавливать клиент

> OpenRouter Armor классифицирует предложенные вызовы инструментов по правилам разработчика. Responses и Chat Completions могут не передавать помеченные вызовы; режим совместимости Messages оставляет ответственность клиенту.

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.

Бета-версия [Armor](https://openrouter.ai/docs/guides/features/plugins/armor) от OpenRouter помещает классификатор правил между предложенным моделью вызовом инструмента и приложением, которое может его выполнить. Для разработчика агентов принципиально, на каком этапе вердикт действительно останавливает выполнение. В Chat Completions и Responses Armor может не передавать помеченный вызов. В режиме совместимости с Claude Code API Messages помеченный `tool_use` остается в ответе, и клиент должен отказаться от его выполнения.

Текущая документация описывает бета-версию, доступную с октября 2026 года. BIG CHANGE изучил документированные контракты запросов и ответов 17 октября. Мы не отправляли запрос API, не запускали агента и не измеряли его показатели безопасности.

## Главная перемена

- **Что изменилось:** Агент OpenRouter может направлять предложенные вызовы инструментов через классификатор, применяющий написанные разработчиком правила до передачи вызовов приложению. В стандартном режиме применения правил выполнение помеченного вызова пропускается, а модель получает причину и может продолжить работу.
- **Почему это важно:** Разработчики могут описывать ограничения отдельных действий обычным текстом, включая исключения для узко разрешенных задач. Однако контракт совместимости Messages оставляет решающий шаг выполнения клиенту: проигнорировав пометку, клиент все равно может выполнить вызов.
- **За чем следить:** Командам нужно согласовать клиент с выбранным режимом вывода API, проверить правила на собственном трафике и определить поведение при ошибках классификатора. Форматы бета-версии могут меняться. OpenRouter предупреждает, что классификатор способен как блокировать допустимые вызовы, так и пропускать недопустимые.

## Проследите путь вызова от предложения до вердикта

По словам OpenRouter, каждый предложенный вызов инструмента удерживается перед отправкой приложению. Модель принятия решений получает вызов, правила и предшествующую беседу, оценивает соответствие каждому правилу и объединяет результаты в `flagged` или `not_flagged`. Непомеченный вызов передается без изменений. В режиме применения правил помеченному вызову предписывается пропуск выполнения; модель получает причину и может попробовать вызов с более узким охватом либо объяснить отказ. Это суждение классификатора о предложенном действии, а не доказательство безопасности следующего инструмента или всего агента.

Уровни правил отвечают на разные вопросы. Совпадение с `hard_deny` блокирует вызов независимо от разрешающего правила или запроса пользователя. Совпадение с `soft_deny` можно отменить совпадением с `allow` либо прямой просьбой пользователя в беседе выполнить именно эту операцию именно над этим объектом. Правило `allow` само по себе никогда не блокирует вызов. OpenRouter также документирует встроенный мягкий запрет для границы, которую пользователь установил и не отменил. Разработчики указывают факты, например доверенный репозиторий или цель развертывания, в `environment`; устаревшие факты могут снизить точность правила. Именованные объекты правил показывают ID и название в вердиктах. Необязательные пороги по умолчанию равны 0.6 для запрещающих правил и 0.7 для разрешающих.

В [документированном примере Responses](https://openrouter.ai/docs/guides/features/plugins/armor#example) инструменту `bash` назначено правило жесткого запрета для `git push`. При `output_mode: "custom_item"` помеченная отправка заменяется элементом `openrouter:armor_blocked` с вызовом и причиной, после которого идет ответ модели. Пример показывает ответ сервиса, описанный в документации; это не испытание, проведенное BIG CHANGE.

## Выберите контракт вывода до запуска инструментов

В Chat Completions и Responses стандартный режим `text` удаляет заблокированный вызов и помещает маркер `<openrouter_armor_blocked>` в текст ассистента. API Responses также поддерживает `custom_item`, который возвращает типизированный элемент блокировки вместо ожидаемого `function_call`. Согласно документации, этот элемент нужно без изменений повторить в следующем входе Responses, не создавая для него отдельный `function_call_output`. Поле `safeguard_results` записывает вердикты по ID вызова.

API Messages имеет существенно иное поведение по умолчанию, когда запрос содержит `safeguards`: `claude_code_compatibility` оставляет помеченный `tool_use` в `content[]` и добавляет его результат `flagged` в `safeguard_results`. **Приложение должно прочитать этот результат и отказаться выполнять вызов.** OpenRouter прямо предупреждает, что клиент Messages, игнорирующий вердикт, выполнит помеченное обращение к инструменту. Разработчик, который не контролирует клиент, может запросить в Messages `output_mode: "text"`, чтобы OpenRouter удержал вызов. Запрос режима вывода, который API не может представить, возвращает 400.

Автоматический режим Claude Code через метахарнесс Ori от OpenRouter использует контракт Messages без дополнительной записи плагина Armor. В документации сказано, что Claude Code отклоняет помеченные вызовы, записывает результат ошибки в протокол диалога и дает модели продолжить. Также указано, что эндпоинт Anthropic с поддержкой собственного классификатора может выдавать вердикт, который просто передается дальше; на других эндпоинтах оценку выполняет Armor. Это документированное поведение интеграции, а не утверждение, что каждый сторонний клиент реализует его правильно.

## Настройте и проверьте узкий набор правил

Для собственного агента [руководство Armor](https://openrouter.ai/docs/guides/features/plugins/armor#example) размещает запись `armor` в `plugins`, с версионированным `classifier_context` (`v: 1`), правилами `auto_mode` и необязательными фактами об окружении. Начните с действия и защищаемого ресурса, которые должно распознавать правило. Затем выберите жесткий запрет для ограничения, действующего даже при согласии пользователя, или мягкий запрет, если точное согласие либо именованное разрешение могут обоснованно его снять. Документация советует описывать действие, а не один способ написания команды, и поддерживать сведения об окружении актуальными.

Стандартный режим `enforce` действует на основании вердиктов. `audit` сообщает те же вердикты, но пропускает все вызовы, включая помеченные. Так можно исследовать реальный трафик и настроить правила до их применения; это не защитный режим. Аудит нельзя сочетать с `claude_code_compatibility`. В обоих режимах читайте `safeguard_results`: `not_flagged` означает разрешение, `flagged` указывает совпавшее правило, `unavailable` означает сбой оценки, а `skipped` указывает неоцененный нативный инструмент провайдера. При потоковой передаче объект вердикта приходит в конце ответа, поэтому клиент Messages должен дождаться его, прежде чем выполнять обращение к инструменту.

OpenRouter указывает `on_error: "block"` как значение по умолчанию при тайм-ауте классификатора, ошибке или слишком большом запросе, который он не может обработать; `on_error: "log"` пропускает вызов. В режиме совместимости с Claude Code вызов со статусом `unavailable` пропускается с видимым вердиктом. Нативные серверные инструменты провайдера по умолчанию пропускаются без оценки, если `evaluate_native_tools` не выводит их из нативного пути для проверки. Эти настройки и фактический путь инструмента должны входить в проверку интеграции команды; одна запись Armor не доказывает, что оценен каждый инструмент.

## Стоимость, скорость и ограничения охвата бета-версии

OpenRouter сообщает, что оценка добавила **279 миллисекунд по медиане и 334 миллисекунды на 90-м перцентиле** при загруженном наборе правил, совместимом с Claude Code. Это измерения поставщика при указанном условии, а не бенчмарк конкретного агента или всех наборов правил. Каждый вызов оценивается один раз перед передачей или блокировкой. В бета-версии оценка не оплачивается; OpenRouter обещает объявить цены до общей доступности. Документация не устанавливает будущий тариф.

Модель принятия решений может давать ложные срабатывания и пропускать нарушения, поскольку сопоставляет правила в обычном тексте с аргументами в обычном тексте. Документация рекомендует использовать аудиторские вердикты на реальном трафике и настраивать пороги отдельных правил. Оценка Armor пока не поддерживается для запросов HIPAA, Zero Data Retention или с ограничениями по региону данных. Запрос с включенным плагином в одном из этих контекстов получает 403; запрос Claude Code вместо этого пропускает вызов как `unavailable`, а Claude Code переходит к локальной оценке автоматического режима. Предупреждение о бета-версии также касается изменений полей конфигурации, `safeguard_results` и типа элемента `openrouter:armor_blocked`.

Armor проверяет предложенные вызовы при передаче от модели к приложению. Этим он отличается от таких механизмов, как [ограничение команд Microsoft MXC](https://bigchange.ai/blog/mxc-agent-command-containment-guide) и [контроль времени выполнения NVIDIA OpenShell и Sentry](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), которые устанавливают ограничения вокруг рабочей нагрузки или ее доступа. Для Armor непосредственное решение при внедрении — удерживает ли выбранный формат ответа помеченный вызов или клиент должен остановить его сам.

## Источники и дополнительное чтение

- [Документация OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor), просмотрена 17 октября 2026 года. Первичный источник о статусе бета-версии, последовательности классификации, приоритете правил, контрактах ответов API, обработке ошибок, исключенных контекстах конфиденциальности, заявленной задержке и оплате бета-версии. Это документированные утверждения OpenRouter; BIG CHANGE не запускал плагин.
- [BIG CHANGE о Microsoft MXC](https://bigchange.ai/blog/mxc-agent-command-containment-guide) объясняет ограничение команд, созданных агентом, на основе политик. Материал описывает отдельный уровень применения ограничений, а не раннюю стадию Armor.
- [BIG CHANGE о NVIDIA OpenShell и Sentry](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) описывает программный контроль доступа и необязательный проект аппаратного мониторинга. Это связанный контекст, а не прямое продолжение этой функции OpenRouter.

## Sources

- [Документация OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor) — Первичная документация продукта, проверенная 17 октября 2026 года. Описывает статус бета-версии, поведение классификатора и правил, формы ответов API, ошибки, ограниченные контексты, заявленную задержку и оплату бета-версии. Утверждения поставщика, а не независимое испытание.
- [BIG CHANGE: Как задать политику MXC для команд, созданных агентом](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — Предыдущий материал об отдельном механизме ограничения команд; используется только как контекст связи между статьями.
- [BIG CHANGE: Платформа NVIDIA для безопасности агентов](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — Предыдущий материал об отдельных средствах контроля доступа во время выполнения и необязательном проекте мониторинга; используется только как контекст связи между статьями.