Перейти к основному содержанию
Политика firewall решает одну вещь о каждом вызове инструмента, который делает ваш агент: вердикт. Либо совпадает правило и производит вердикт, либо ни одно правило не совпадает и берёт верх default-вердикт политики. Эта страница покрывает оба варианта — что делает каждый вердикт firewall, как разрешается cap_cost и почему audit — это дефолт, с которого вы начинаете. О том, где вердикты живут в грамматике правил, см. Правила Firewall; о выборе default-вердикта при создании политики см. Создание и привязка.

​
1. Шесть вердиктов правила

Правило производит ровно один из шести вердиктов. Создавайте их в консольном редакторе правил; движок проходит правила в порядке приоритета и побеждает первое совпадение.
Вызов проходит нетронутым. Он всё равно попадает в ленту событий как allow, так что вы сохраняете аудит-трейл, ничего не блокируя. Используйте его как явное разрешение в политике default-deny.
Идентичный allow результат для трафика, но вызов помечается как что-то, за чем вы хотели наблюдать. Это также значение, на которое приземляется default-вердикт из коробки — наблюдать всё, не блокировать ничего, пока вы не готовы применять.
Вызов никогда не достигает инструмента. На поверхности inbound ретрансляция возвращает HTTP 400 с кодом ошибки firewall_blocked, называя инструмент и причину; на поверхности mcp он возвращается как ошибка инструмента, так что модель может среагировать. См. как выглядит блокировка.
Редактирует совпавшие подстроки из аргументов вызова инструмента (секрет или PII, который агент поместил в поле command или body) и пересылает очищенный вызов. Редактирует только аргументы — никогда содержимое, которое возвращает инструмент. На поверхности inbound ещё нет аргументов времени вызова, так что sanitize эскалирует до deny. См. очистку ответов.
Превращает вызов в разбор вне основного канала. Ретрансляция возвращает HTTP 400 с кодом firewall_approval_pending и id подтверждения; вызов не достигает инструмента. Ревьюер разрешает его в консоли или через вебхук-колбэк, и агент повторно отправляет с одноразовым заголовком подтверждения. См. подтверждения.
Предохранитель по стоимости — создаётся как правило, но разрешается в allow или deny во время вычисления. См. §3 и cap cost.
Shadow-режим уплощает применение. В shadow-режиме каждый применяющий вердикт (deny, sanitize, pending_approval и cap_cost, разрешившийся в deny) понижается до audit, а причина получает префикс [shadow] would …. Разверните применяющую политику таким образом и понаблюдайте за лентой событий, прежде чем переключить её в боевой режим.

​
2. Default-вердикт

Default-вердикт (default_verdict на политике) — это то, что политика делает, когда ни одно правило не совпало с вызовом инструмента. Это пол вашей позиции, и в отличие от вердикта правила он принимает только три значения:
default_verdictКогда ни одно правило не совпало…
audit (по умолчанию)Разрешить вызов, но записать его. Безопасное место для старта.
allowРазрешить и залогировать, без записи для разбора.
denyЗаблокировать всё, что правило явно не разрешает, — позиция default-deny.
Новая политика по умолчанию имеет audit: она наблюдает каждый вызов инструмента и не блокирует ничего, пока вы не добавите применяющие правила. Три вердикта только-для-правил — sanitize, pending_approval и cap_cost — не могут быть дефолтом; default-вердикт — это сплошной откат, а эти вердикты имеют смысл только в области конкретного совпадения.
deny как default-вердикт — это default-deny: любой вызов инструмента, который ваши правила явно не allow, блокируется. Мощно для запертого агента, но это остановит вызовы, которые вы забыли внести в allow-list. Сочетайте его с явными allow-правилами (allow-листинг инструментов) и сначала разверните под shadow-режимом.

​
3. cap_cost разрешается в allow или deny

cap_cost — единственный вердикт, который не появляется в ваших событиях. Вы создаёте правило с потолком cap_cost_cents, но во время вычисления движок разрешает его в конкретный allow или deny до того, как событие записывается, — так что лента событий никогда не несёт буквальный вердикт cap_cost, только allow/deny, который агент реально увидел. Потолок — на прогон агента: движок сравнивает накопленные траты прогона с вашим лимитом.
  • Под лимитом → разрешается в allow. (Внутренне это трактуется как несовпадение, так что вычисление продолжается к следующему правилу, а не позволяет cap_cost победить первым совпадением как разрешение.)
  • Над лимитом → разрешается в deny, с причиной, называющей общую сумму прогона против лимита. Это терминальный исход-предохранитель.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost срабатывает только на pre-dispatch поверхностях (inbound, mcp) — точках, где блокировка вызова всё ещё предотвращает траты. На post-dispatch поверхностях response и egress он инертен (останавливать уже нечего), так что движок пропускает его там.

​
4. Как выбирается вердикт

Для любого вызова инструмента разрешение одинаково независимо от того, какой вердикт побеждает:
Шлюз выбирает политику, привязанную к вызывающему ключу (firewall_policy_id), или default рабочего пространства — см. разрешение.
Правила выполняются в порядке priority ASC. Первое правило, чьи поверхность, глоб инструмента, опциональные клаузы аргументов и опциональная область egress все совпадают, производит вердикт.
Если ни одно правило не совпало, применяется default_verdict политики — audit, если вы его не изменили.
Если вызов принадлежит управляемому навыку, навык в режиме block принудительно даёт deny, а навык в режиме quarantine эскалирует всё, что меньше deny, до pending_approval.

​
5. Поведение deny по стоимости и повтору

Вердикт firewall на поверхности inbound срабатывает до вызова вышестоящей модели, так что deny там не стоит токенов модели. Ошибка помечается skip-retry — повторный прогон того же заблокированного вызова просто снова заблокируется, так что шлюз говорит клиенту не повторять его. Это отличается от блокировки guardrail, которая проверяет текст промпта/ответа (PII, секреты), а не действия инструмента, и возвращает собственную ошибку guardrail_blocked. Запрос может пройти через обе плоскости.
Каждый вердикт оставляет след. Каждое вычисление — allow, audit, deny, разрешённый cap_cost, удержанное подтверждение — записывается как событие firewall, фильтруемое по вердикту, поверхности, инструменту и прогону. Лента событий — это то, чем вы подтверждаете, что политика производит вердикты, которых вы ожидаете. См. журнал событий и аналитику.

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

Создать и привязать политику

Выберите default-вердикт и привяжите политику к ключу.

Cap cost

Создайте потолок трат и узнайте, как он разрешается на прогон.

Shadow-режим

Понизьте каждый применяющий вердикт до audit, пока измеряете влияние.

Справочник правил

Полный язык сопоставления, стоящий за вердиктом.
Об угрозах, которые эти вердикты призваны остановить, см. опасные вызовы инструментов и избыточную автономию.