Перейти к основному содержанию
День, когда вы ставите агента перед пользователями, — худший день, чтобы узнать, что джейлбрейк проходит прямо через вашу политику контента или что инструмент, который вы забыли управлять, срабатывает на первом же прогоне. Предзапусковый ред-тиминг превращает эти сюрпризы в число, которое вы можете прочитать до выкатки, — и OrcaRouter даёт вам три способа его произвести, все без касания кода вашего агента или отправки единственного живого запроса, который вы не имели в виду. Этот рецепт — проход вхолостую: измерьте политику против известных атак, запустите в shadow её против вашего собственного трафика и симулируйте более плотную позицию, прежде чем на неё решиться.
Всё здесь read-only или в песочнице — никакого видимого пользователю блока, никакого затронутого production-трафика. (Правила по ключевым словам, regex и PII работают целиком локально; правило llm_judge всё равно вызывает свою настроенную модель, так что eval над политикой-судьёй делает этот вызов.) Суть в том, чтобы ломать вещи до запуска, на ваших условиях.

​
1. Как провести ред-тиминг ИИ-агента перед запуском

Предзапусковый ред-тиминг отвечает на три вопроса, и у OrcaRouter есть один инструмент для каждого:

Ловит ли мой guardrail атаки?

Запустите eval-харнесс guardrail против встроенных адверсариальных корпусов и прочитайте precision / recall / F1.

Что бы сломал мой firewall?

Включите shadow-режим и понаблюдайте, какие реальные вызовы инструментов были бы запрещены — пока не запрещая ни один из них.

Безопасна ли более плотная позиция?

Симулируйте уровень автономии, чтобы предпросмотреть в точности, что он изменил бы против вашего трафика, прежде чем применять его.
Первый тестирует ваши Guardrails (текстовую плоскость); второй и третий тестируют ваш Firewall (плоскость действий). Настоящий чек-лист запуска прогоняет все три.

​
2. Оцените ваш guardrail против адверсариальных корпусов

Самый быстрый способ узнать, переживёт ли политика контента контакт с атакующим, — швырнуть в неё корпус известных атак и прочитать счёт. Вкладка Eval редактора guardrail делает именно это: она проигрывает каждый образец в корпусе через вашу текущую политику и сравнивает вердикт с ожидаемым исходом каждого образца — проигрывая корпус локально против ваших правил, никогда против живого трафика. OrcaRouter поставляет встроенные red-team-корпуса, так что вам не надо искать свои. Среди них:
КорпусЧто это
advbench_harmful_behaviorsКанонический целевой набор адверсариальных суффиксов — каждая строка это небезопасный запрос, который guardrail должен заблокировать.
anthropic_hh_redteamРеальные многоходовые человеческие red-team-транскрипты против ассистента.
deepset_prompt_injectionsРазмеченные prompt-injection против безобидных запросов — базис precision/recall для блока на стадии input.
databricks_dolly_benignЧисто безобидный базис: чересчур строгая политика не должна блокировать ни один из них.
Всегда сочетайте корпус атак с безобидным. Политика, которая блокирует 100% атак, но также блокирует databricks_dolly_benign, небезопасна — она непригодна. Безобидный прогон — это ваш бюджет ложных срабатываний.
Запустите eval против встроенного корпуса deepset_prompt_injections: 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
Маршруты /api/guardrail/* используют вашу консольную сессию / access-токен, а не ключ ретрансляции sk-orca-... — и они ограничены рабочим пространством через X-Workspace-Id. На практике вы будете запускать это из вкладки Eval в консоли; curl здесь, чтобы показать форму. Запуск eval открыт любому Member.
Прогон сообщает метрики детектирования, вычисленные против ожидаемых действий:
  • TP / FP / FN / TN — истинные/ложные срабатывания и пропуски, где «ложное срабатывание» включает поимку атаки неправильным классом действия (например, маскирование, когда вы ожидали блок).
  • Precision / Recall / F1 — заголовочные числа. Низкий recall означает, что атаки проскальзывают; низкая precision означает, что вы блокируете безобидный трафик.
Откройте прогон, чтобы изучить отказы образец за образцом, настройте правило или рубрику судьи и перезапустите, пока счёт не удержится. Кастомные корпуса работают так же — загрузите собственный JSONL (Developer+), чтобы тестировать против точных форм атак, с которыми сталкивается ваш продукт.
Где живёт защита от prompt-injection. Встроенный пресет Prompt-Injection Basics — это правило по ключевым словам на действии flag — оно выводит распространённые джейлбрейк-фразы на проверку, не блокируя пользователя. Для семантического намерения инъекции, которое не захватывает ни один список ключевых слов, добавьте правило llm_judge и проведите его ред-тиминг так же: запустите eval против deepset_prompt_injections и anthropic_hh_redteam и прочитайте F1. См. справочник guardrail.

​
3. Запустите firewall в shadow-режиме против реального трафика

Eval guardrail тестирует текст против фиксированного корпуса. Ваш firewall, в противоположность, нужно тестировать против беспорядочной реальности того, что ваш агент реально делает, — и самый безопасный способ сделать это до запуска — shadow-режим. Shadow-режим — это пер-политический флаг, который заставляет firewall вычислять и логировать каждый вызов инструмента ровно так, как он делал бы в production, но понижать каждый применяющий вердикт до audit. deny становится строкой audit, чья причина имеет префикс [shadow] would …. Ничего не блокируется. Ничего не ломается. Но лента Events теперь показывает вам точный список вызовов, которые ваша политика отклонила бы. Это ред-тиминг firewall: создайте вашу самую строгую планируемую политику, включите shadow-режим, прогоните вашего агента через реалистичную репетицию запуска, затем прочитайте события [shadow] would ….
Постройте вашу применяющую политику в консоли (Developer+) — для прогона запуска вхолостую установите default_verdict в audit и добавьте deny-правила, которые собираетесь выкатить. Переключите shadow-режим на. Вся политика теперь логирует, не применяя.
Прогоните ваши реальные потоки агента против шлюза с ключом, привязанным к shadow-политике. Каждый вызов инструмента — inbound, response, MCP-диспетч, egress — вычисляется и логируется.
Откройте Firewall → Events (Developer+) и отфильтруйте по причинам [shadow] would …. Каждая — это вызов, который ваша политика запретила бы в production. Убедитесь, что каждая запись — это вызов, который вы хотите запретить, — и что ничего легитимного нет в списке.
Как только список would-block чист, выключите shadow-режим. Самый следующий совпадающий вызов применяется реально — никаких других изменений.
Сочетайте shadow-режим с observe-режимом (настройка рабочего пространства) для покрытия, а не только корректности. Observe-режим логирует каждый вызов инструмента, который разрешается в никакую политику, как пробел, наполняя представление Discovered tools — так что вы ловите инструмент, для которого забыли написать правило, а не только правила, которые написали неправильно. См. режимы применения.

​
4. Симулируйте более плотную позицию, прежде чем решиться

Третий ред-тиминг-ход самый дешёвый: прежде чем применить более строгий уровень автономии, симулируйте его. Симулятор предпросматривает, что применение tight (или любого уровня) изменило бы против недавнего трафика вашего рабочего пространства — сколько вызовов переключилось бы на deny — не записывая ни одной строки политики. 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
Чтение симулятора открыто любому Member. Используйте его, чтобы ответить «готов ли мой агент к tight?» перед запуском: если предпросмотр показывает стену потенциальных запретов на вызовах, от которых зависит ваш агент, у вас есть правила, которые надо смягчить до go-live, а не инцидент после него.
Simulate — только предпросмотр — он никогда не мутирует ваши политики. Применение уровня автономии — отдельное действие Developer+, и это одна транзакция с отменой в один клик, если живой результат всё равно вас удивит.

​
5. Предзапусковый чек-лист ред-тиминга

Сложите три прохода вместе, и у вас есть ворота запуска:
ПроходИнструментЗелёный, когда
Политика контентаGuardrail Eval против корпусов атак + безобидныхВысокий recall на атаках, нет блоков на безобидных
Политика действийFirewall shadow-режим против репетиционного трафикаКаждый [shadow] would … намеренный
ПокрытиеObserve-режим + Discovered toolsНи один сюрпризный инструмент не сидит в пробеле покрытия
ПозицияSimulate целевого уровня автономииПредпросмотр соответствует ожиданиям
Прогоните все четыре зелёными, затем применяйте: выключите shadow-режим и примените ваш уровень автономии. Поскольку каждая привязка живёт на ключе в шлюзе, переход от вхолостую к live — это изменение конфигурации, а не деплой — ваш агент продолжает вызывать https://api.orcarouter.ai/v1/... ровно как раньше.
Маскирование на стадии output и live-сканирование ответа всё ещё созревают — прогон eval доказывает логику правила в песочнице, но подтвердите вашу конкретную комбинацию стадии и потока против заметок guardrail, прежде чем полагаться на неё в production.

​
6. Дальнейшие шаги

Режимы применения

Observe → shadow → enforce, безопасная выкатка, которую репетирует этот рецепт.

Базис Secure Agents

Что задаёт каждый уровень автономии — и как simulate его предпросматривает.

Prompt injection

Угроза, против которой набирает очки ваш eval guardrail.

Go live

Переход в production после прохождения ред-тиминга.
Для полных движков за каждым проходом см. справочники Guardrails и Firewall, а также связанные угрозы: джейлбрейки и опасные вызовы инструментов.