Перейти к основному содержанию
Вы написали правило firewall — deny на shell.exec, egress allow-list, клаузу аргумента, которая срабатывает только на rm -rf — и теперь хотите знать, что оно делает ровно то, что вы думаете, до того как изменит хоть один production-вызов инструмента. Firewall даёт вам три неразрушающих способа протестировать правила firewall, каждый отвечает на свой вопрос:

Прогон одного вызова вхолостую

Песочница Test прогоняет один синтетический вызов инструмента через реальный движок и возвращает вердикт — ничего не диспетчеризуется, ничего не логируется. Developer+.

Воспроизвести позицию

Simulate воспроизводит уровень автономии против вашего недавнего трафика и считает, сколько вызовов он заблокировал бы. Читаемо для Member.

Запустить против живого трафика

Shadow-режим вычисляет целую политику на реальных вызовах, но понижает каждый применяющий вердикт до audit. Нулевой радиус поражения.
Все три настраиваются через консоль (или управляющие маршруты /api/workspace/firewall/*, которые аутентифицируются вашей сессией / access-токеном — не ретрансляционным ключом sk-orca-…). Ваши ретрансляционные вызовы агента /v1/* никогда не меняются, пока вы тестируете.

​
1. Тестируйте правила firewall песочницей Test вхолостую

Песочница Test — самый тесный цикл: подайте ей единственный синтетический вызов инструмента, и она запускает реальный движок вычисления — полное разрешение политики, правила пройдены в порядке приоритета, побеждает первое совпадение — затем возвращает вердикт, правило, которое его произвело, и читаемую человеком причину. Вызов — это прогон вхолостую: ничего не диспетчеризуется ни в какой инструмент, и ничего не пишется в ленту событий или инвентарь Discovered-tools. Она точно отвечает на один вопрос: при этом точном имени инструмента и этих аргументах, что решает моя политика — и какое правило это решает?
Песочница Test — Developer+. Она может предпросматривать против несохранённой черновой политики по id, а ответ выставляет имя совпавшей политики и метку правила, так что она сидит ближе к предпросмотру поверхности записи, чем к простому чтению — в отличие от Simulate и других read-view, которые открыты каждому участнику.

​
Один конкретный прогон вхолостую

Допустим, вы добавили правило, которое должно отклонять shell.exec только когда команда содержит rm -rf. Вы хотите подтвердить две вещи за один присест: опасная команда отклоняется, а невинная всё равно проходит.
1

Протестируйте опасный вызов

В Security → Firewall откройте вкладку Test, выберите поверхность response, введите имя инструмента shell.exec и аргументы {"command": "rm -rf /data"} и запустите. Ответ называет вердикт и совпавшее правило:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Протестируйте невинный вызов

Запустите снова с {"command": "ls -la"}. Клауза аргумента больше не совпадает, так что правило проваливается к default политики — вы должны увидеть allow или audit и пустой rule_label. Если rm -rf отклоняет, а ls -la нет, ваша клауза аргумента ограничена правильно.
3

Предпросмотрите черновик до его привязки

Передайте policy_id, чтобы вычислить против конкретной черновой политики вместо той, к которой сейчас разрешается ваш трафик — так вы можете доказать, что новая политика верна, до привязки к ней ключа или продвижения её в default рабочего пространства.
Читайте gap в ответе. gap: true означает, что политика разрешилась, но ни одно правило внутри неё не совпало с вызовом (и рабочее пространство в observe-режиме) — инструмент проскользнул через каждое правило и провалился к default. Это дыра покрытия, которую надо закрыть до релиза, а не вердикт, которому стоит доверять.
Песочница Test использует те же поверхности, что и живое вычисление — inbound, response, mcp, egress (по умолчанию inbound) — так что тестируйте каждое правило на поверхности, к которой оно привязано. На inbound нет аргументов времени вызова, так что правило sanitize эскалирует до блокировки там ровно так, как сделало бы в production; см. стадии о том, почему поверхность важна.

​
2. Симулируйте уровень автономии до его применения

Песочница Test проверяет один вызов. Simulate отвечает на вопрос уровня позиции: если я переключу всё это рабочее пространство на более строгий уровень автономии, сколько моего недавнего трафика он заблокировал бы? Simulate воспроизводит deny-правила кандидатного уровня против ваших последних событий firewall и возвращает потенциальное влияние — только имена инструментов и счётчики, никогда аргументы. Он read-only и читаем для Member, так что любой в команде может предпросмотреть радиус поражения tight до того, как Developer на него решится.
  • tight — default-deny, отклонить деструктивный shell, отклонить инструменты в форме извлечения (SSRF-вектор), PII Shield + Secrets Blocker применены. Simulate показывает, сколько вашего реального трафика поймал бы этот пол.
  • balanced — default audit, отклонить деструктивный shell, PII Shield в audit-only (флагирует PII). Рекомендуемая стартовая позиция.
  • permissive — только observe; ничего не применяется.
Simulate ничего не меняет — это «что если» поверх прошлых событий. Применение уровня автономии (запись Developer+) материализует реальные, редактируемые строки политики autonomy_* и guardrail, с отменой в один клик из снимка аудита. Предпросмотрите с Simulate, затем примените, когда счётчик выглядит правильно.

​
3. Shadow-режим: тест против живого трафика без радиуса поражения

Песочница Test и Simulate — офлайн-предпросмотры. Shadow-режим — живой: флаг на политику, который вычисляет политику на реальном трафике агентов, проходит каждое правило, выбирает вердикт — затем понижает каждый применяющий вердикт (deny, sanitize, pending_approval) до audit и снабжает причину префиксом [shadow] would …. Вызов всегда проходит; ничего не блокируется, не редактируется и не удерживается. Это делает ленту событий читаемой как production-прогон с выключенным применением. Отфильтруйте по [shadow], и у вас полный список каждого вызова, который политика вот-вот начнёт блокировать, — до того как заблокирует хоть один.
Метод тестаЗапускается противВопрос, на который отвечает
Песочница TestОдин синтетический вызов«Какой вердикт получает этот точный вызов, и какое правило решает?»
SimulateНедавние события«Сколько вызовов заблокировал бы более строгий уровень автономии?»
Shadow-режимЖивой трафик«Что заблокировала бы эта политика на реальном production-трафике?»
Shadow-режим — самый глубокий из трёх — полное живое покрытие с нулевым радиусом поражения. У него своя страница: Разверните политику firewall с shadow-режимом проходит переключатель, причины [shadow] would … и переход к применению.

​
4. Практический порядок тестирования

Три инструмента складываются в один путь безопасного развёртывания — самая дешёвая проверка первой, самое широкое покрытие последним:
1

Прогоните вхолостую правила, которые вы только что написали

Используйте Test, чтобы подтвердить, что каждое новое правило срабатывает на вызовах, на которых должно, и пропускает те, на которых не должно — включая негативные случаи. Быстро, Developer+, ничего не сохраняется.
2

Оцените позицию (опционально)

Если вы тянетесь за уровнем автономии, а не рукописными правилами, Simulate уровень и прочитайте счётчик потенциально-заблокированного против реального трафика до его применения.
3

Shadow против живого трафика

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

Применяйте

Когда лента срабатывает на том, что вы ожидаете, и ни на чём, чего не ожидаете, выключите shadow. Следующий вызов применяет по-настоящему.
Тестирование предпросматривает политику, не управляемые навыки. Навык в режиме block или quarantine всё равно применяется даже под shadow-политикой — решение разбора навыка побеждает. Shadow для политики никогда не был запросом снять навык с карантина.

​
5. API-справочник

Эти управляющие маршруты используют вашу сессию / access-токен и ограничены рабочим пространством:
Метод и путьРольНазначение
POST /api/workspace/firewall/testDeveloper+Прогон одного синтетического вызова инструмента вхолостую против разрешённой (или черновой policy_id) политики. Возвращает verdict, policy_name, rule_label, reason, gap, shadow_mode. Ничего не диспетчеризуется и не логируется.
GET /api/workspace/firewall/simulate?level=MemberВоспроизвести уровень автономии против недавних событий; возвращает счётчики потенциально-заблокированного.
GET /api/workspace/firewall/policies/:idMemberПрочитать текущий флаг shadow_mode политики.
PUT /api/workspace/firewall/policiesDeveloper+Переключить shadow_mode на политике.
Тело Test принимает surface (по умолчанию inbound), обязательный tool_name, опциональный args_json и опциональный policy_id для переопределения разрешения.

​
Куда двигаться дальше

Shadow-режим

Развёртывание на живом трафике: [shadow] would …, фильтр событий и переход к применению.

Проверять аргументы

Ограничьте правило тем, какие аргументы — клаузы, которые песочница Test позволяет проверить против rm -rf против ls -la.

Вердикты

Что allow / audit / deny / sanitize / pending_approval / cap_cost каждый делает, когда тест перестаёт быть тестом.

Журнал событий

Где приземляются shadowed-вердикты — фильтруйте, углубляйтесь в прогоны и совпавшие правила.
О грамматике сопоставления правил, которую отрабатывают эти тесты, см. полный справочник правил firewall; о том, где тестирование вписывается в более широкую модель, см. режимы применения.