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

Бета-версия 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 инструменту 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 размещает запись 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 и контроль времени выполнения NVIDIA OpenShell и Sentry, которые устанавливают ограничения вокруг рабочей нагрузки или ее доступа. Для Armor непосредственное решение при внедрении — удерживает ли выбранный формат ответа помеченный вызов или клиент должен остановить его сам.

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

• Документация OpenRouter Armor, просмотрена 17 октября 2026 года. Первичный источник о статусе бета-версии, последовательности классификации, приоритете правил, контрактах ответов API, обработке ошибок, исключенных контекстах конфиденциальности, заявленной задержке и оплате бета-версии. Это документированные утверждения OpenRouter; BIG CHANGE не запускал плагин.
• BIG CHANGE о Microsoft MXC объясняет ограничение команд, созданных агентом, на основе политик. Материал описывает отдельный уровень применения ограничений, а не раннюю стадию Armor.
• BIG CHANGE о NVIDIA OpenShell и Sentry описывает программный контроль доступа и необязательный проект аппаратного мониторинга. Это связанный контекст, а не прямое продолжение этой функции OpenRouter.