Перейти к основному содержанию
У вас есть политика, которую вы хотите поставить перед production. Страх не в политике — а в том, чтобы включить её и обнаружить, что она блокирует инструмент, который вашему агенту реально нужен, или маскирует поле, от которого зависит ваше приложение. Исправление не в большем тестировании в песочнице; оно в выкатке против реального трафика в позиции, которая ничего не может сломать, а затем ужесточении только после того, как вы увидели, что срабатывает. Этот рецепт — та выкатка: observe → shadow → enforce, с автономией balanced перед tight. Вы остаётесь в консоли (или REST API) всю дорогу; агент продолжает вызывать https://api.orcarouter.ai/v1/... ровно как раньше.
Новичок в модели? Прочитайте Режимы применения о том, что каждая позиция делает механически, и базис Secure Agents о том, что задаёт каждый уровень автономии. Эта страница — последовательность — порядок, в котором вы щёлкаете переключатели.

​
1. ИИ-выкатка безопасности в три приёма

Вся выкатка обменивает автономию на безопасность в три шага, каждый проверенный против живого трафика перед следующим:

Observe

Разрешать всё, логировать всё. Непокрытые вызовы инструментов приземляются в Discovered Tools; правила guardrail flag записывают совпадения, не меняя трафик. Вы узнаёте реальную форму вашего агента.

Shadow

Реальная политика вычисляет каждый вызов, но каждый применяющий вердикт понижается до audit и логируется [shadow] would …. Вы видите в точности, что заблокировалось бы — при том что ничего фактически не заблокировано.

Enforce

Shadow выключен. deny блокирует, mask редактирует, pending_approval удерживает. Автономия идёт от широкой (balanced) к плотной (tight), и ваш агент управляется.
Дисциплина — это суть: вы никогда не применяете правило, которое сначала не понаблюдали срабатывающим в shadow против вашего собственного трафика.

​
2. Ход первый — observe (автономия = permissive)

Начните настолько широко, насколько возможно. Примените уровень автономии permissive из Firewall → Posture (Developer+) — или POST /api/workspace/firewall/autonomy. Он включает observe-режим рабочего пространства и не оставляет применяющей политики, так что каждый вызов разрешается, а каждый непокрытый вызов логируется как пробел покрытия. 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
Маршруты /api/workspace/firewall/* работают на вашей консольной сессии / access-токене, а не на ключе ретрансляции sk-orca-.... Применение уровня автономии — это запись рабочего пространства — Developer+. Только вызовы модели /v1/* используют ключ ретрансляции.
Теперь направьте на него реальный трафик и дайте поработать. Наблюдайте за двумя лентами:
  • Firewall → Discovered Tools (Member) — каждый инструмент, который вызывает ваш агент, помеченный covered или gap. Это вход для ваших правил: вы вот-вот напишете политику для трафика, который реально происходит, а не для гипотетического.
  • Guardrails → Matches (Member) — если вы добавили какие-либо правила с действием flag, каждое записанное ими совпадение, не касаясь запроса.
Дайте поработать, пока Discovered Tools не перестанет выводить новые инструменты. Этот стабильный список — ваша спецификация для написания правил.

​
3. Ход второй — shadow (реальная политика, ноль блокировки)

Теперь создайте политику, которую вы реально хотите — глобы инструментов, клаузы аргументов, egress-списки, потолок cap_cost — и включите shadow_mode перед её привязкой. (Стройте правила из правил firewall; полная модель политики в справочнике Firewall.) 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
С shadow_mode: true этот deny и этот cap_cost оба понижаются до audit во время вычисления — движок вычисляет реальный вердикт, логирует его с префиксом [shadow] would … и пропускает вызов. Привяжите политику к ключам, которые вы выкатываете (установите firewall_policy_id на ключе), или сделайте её default рабочего пространства. Затем прочитайте Firewall → Events / Runs (Developer+), отфильтрованные на префикс [shadow], и подтвердите обе стороны:
Каждый вызов shell.exec показывает [shadow] would deny. Каждый прогон, пересекающий ваш кап, показывает [shadow] would cap_cost. Политика видит трафик, для которого вы её построили.
Ни один легитимный инструмент не появляется с потенциальным блокирующим вердиктом. Это проверка ложных срабатываний — причина, по которой существует shadow. Если нужный вам инструмент флагирован, исправьте правило и перепроверьте, прежде чем вообще применять.
У guardrails нет shadow на уровне политики. Эквивалент — пер-правило действие flag: оно записывает совпадение в ленту Matches и ничего не меняет, так что вы можете измерить правило контента, прежде чем переключить его на block или mask. Прогоняйте правила guardrail как flag через этот же ход.

​
4. Ход третий — enforce (автономия balanced, затем tight)

Когда shadow-лог выглядит правильно, применяйте в две стадии, не в одну. Не прыгайте прямо к default-deny. Сначала balanced. Это рекомендуемая первая применяющая позиция: default-вердикт firewall — audit, но самые деструктивные действия (вроде деструктивного shell) запрещены, а guardrail PII Shield работает audit-only — он флагирует PII, пока не маскируя его. Вы теперь блокируете худшее, продолжая наблюдать остальное. Выключите shadow_mode на вашей собственной политике в том же ходе, чтобы её вердикты deny / cap_cost запустились в production наряду с базисом. 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Понаблюдайте за Events час. Реальные блоки теперь появляются без префикса [shadow]. Запрещённый вызов инструмента возвращает HTTP 400 firewall_blocked; он skip-retry и не стоит токенов модели. Затем tight. Как только balanced тих, переходите к default-deny. Уровень tight запрещает по умолчанию, запрещает деструктивный shell и SSRF-egress и применяет PII Shield + Secrets Blocker — PII маскируется на запросе до того, как его увидит модель, а секреты в ваших запросах блокируются. Заблокированный промпт возвращает HTTP 400 guardrail_blocked, не стоит никакой квоты и skip-retry.
СтадияFirewall (действия)Guardrails (текст)Что вы доказываете
permissiveObserve; ничего не заблокированоТолько flagРеальную форму трафика
balancedDefault audit; деструктивный shell запрещёнPII флагированХудший случай остановлен
tightDefault-deny; shell + fetch-образные инструменты (SSRF) запрещеныPII замаскирован, секреты заблокированыПолное нулевое доверие
Оговорка про поток для PII. Под tight PII Shield маскирует PII на запросе до того, как его увидит модель, — это работает. Маскирование потокового ответа на стороне вывода пока не работает; block на выводе применяется на потоке (сканер обрезает поток). Если вы зависите от редактирования вывода модели, проверьте вашу комбинацию стадии/потока во вкладке guardrail Test сначала. См. Guardrails.

​
5. Аварийный выход — отмена в один клик

Каждое изменение автономии — это одна транзакция, которая снимает снимок вашей предыдущей позиции, так что вы можете откатиться прямо из Firewall → Posture (или POST /api/workspace/firewall/autonomy/undo/:audit_id). Вы также можете просто заново применить более мягкий уровень — сбросить tight обратно до balanced или balanced обратно до permissive — в любое время.
Отмена восстанавливает из снимка аудита самого недавнего применения. Если вы делали ручные правки политики с момента применения, которое отменяете, тот снимок больше не последний неиспользованный, и отмена отклоняется, а не молча откатывает эти правки. Когда это происходит, заново примените более мягкий уровень вместо этого — он всегда доступен.

​
6. Откуда берутся вердикты каждого хода

Выкатка никогда не блокирует то, о чём вы не просили, потому что каждая позиция отображается на явный, наблюдаемый механизм:
ПозицияМеханизмИсход
ObserveРабочее пространство firewall_observe_mode включён + guardrail flagAllow + лог пробелов / совпадений
ShadowПер-политика shadow_modeРеальный вердикт вычислен, понижен до audit, залогирован [shadow] would …
Enforceshadow_mode выключен + автономия tight/balanceddeny / mask / cap_cost запускаются в production
Четыре термина — observe-режим, вердикт audit, действие flag и shadow_mode — это различные переключатели, задокументированные бок о бок в Режимах применения.

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

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

Карта механизмов за observe, shadow и enforce.

Базис Secure Agents

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

Укротите автономного агента

Следующий шаг после применения: кост-капы, детектирование аномалий и подтверждения.

Agent Firewall

Политики, правила, вердикты, shadow-режим и MCP-шлюз полностью.
Go-live, которому можно доверять, — это выкатка, а не переключатель. Наблюдайте, что делает ваш агент, запустите политику в shadow против его реального трафика, затем применяйте — balanced перед tight — и каждое правило проверено на production, прежде чем когда-либо его заблокирует.