Перейти к основному содержанию
Когда модель отвечает, она не просто возвращает текст — она выдаёт tool_calls: конкретные вызовы с реальными, выбранными моделью аргументами. Поверхность response agent firewall инспектирует именно их, в момент, когда они покидают модель, и до того как они достигнут цикла вашего агента. Это поверхность, где вы фильтруете то, что модель реально решила сделать, с аргументами, которые она реально выбрала. Эта страница покрывает use-case фильтрации на поверхности response — когда тянуться за ней вместо inbound, один твист вердикта, который она добавляет, и как она ведёт себя на стриме. О полном словаре правил и семантике вердиктов см. Схему правил и Вердикты.

​
1. Фильтруйте вызовы инструментов в ответе llm, с аргументами в области

Стадия inbound видит инструменты, которые вы рекламируете — только имена, пока никаких аргументов времени вызова. Стадия response видит tool_calls, которые модель выдаёт, которые несут аргументы, выбранные моделью. Это вся причина фильтровать здесь: это единственная поверхность, которая видит фактический вызов + аргументы для выполняемого клиентом (не-MCP) инструмента, так что клаузы аргументов, последовательности и правила состояния прогона все приземляются на response. Различие в одну строку:
СтадияВидитИспользуйте, чтобы
inboundРекламируемые определения инструментовСделать инструмент невидимым для модели
responseВыданные tool_calls + аргументыОтфильтровать вызов, который модель реально сделала
Так inbound отвечает, какие инструменты существуют; response отвечает, что модель сделала с одним из них. Тянитесь за response (или оставьте stage пустым, чтобы покрыть оба), когда инструмент законно появляется в некоторых запросах, но конкретный его вызов опасен — или когда вы контролируете только цикл агента, а не набор рекламируемых инструментов.
Правило без stage выполняется на каждой поверхности, включая response. Привязывайте к response только когда правило должно только инспектировать выданные вызовы — например, клауза аргумента, которой всё равно нечего сопоставлять на поверхности inbound. См. Стадии.

​
2. Один конкретный пример

Разрешите shell.exec в целом, но уберите его из ответа модели в тот момент, когда его аргумент command выглядит деструктивным. В консоли рабочего пространства откройте политику (или создайте её) и добавьте правило, привязанное к поверхности response: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Сопоставитель аргументов живёт в args_match_json — JSON-строке, содержащей {"clauses":[…]}, где каждая клауза — тройка path / op / value (op — один из eq, contains, regex, gt, lt). Форма консоли строит её за вас; сырая форма показана здесь, чтобы имя поля было однозначным. Инструмент остаётся рекламируемым — модель всё ещё может предложить shell.exec — но когда выданный вызов несёт деструктивный command, firewall убирает этот tool_call из ответа до того, как ваш агент его увидит. Безобидный shell.exec (скажем, ls -la) проходит нетронутым. Это паттерн «разреши инструмент, ограничь вызов», ради которого существует поверхность response; клауза аргумента — то, что делает это возможным.
Правила вычисляются в порядке приоритета, побеждает первое совпадение. Ставьте узкое allow-исключение с меньшим числом priority, чем широкий deny, так чтобы исключение выполнялось первым. См. Приоритет правил.

​
3. Что делает вердикт на поверхности response

Поверхность response инспектирует каждый выданный tool_call и переписывает ответ на месте. Сохранённые вызовы пересылаются побайтно; меняется только совпавший вызов:
Совпавший tool_call убирается из ответа модели до того, как он достигнет вашего агента. В отличие от inbound deny — который возвращает HTTP 400 с кодом firewall_blocked — deny поверхности response не проваливает запрос; остальная часть ответа (другие вызовы инструментов, любой текст) проходит, а нарушающий вызов просто отсутствует.
Совпавшие подстроки в аргументах вызова заменяются отредактированными движком аргументами, и очищенный вызов пересылается — полезно, когда инструмент в порядке, но модель поместила секрет или значение PII в аргумент. Sanitize редактирует только аргументы вызова инструмента; он никогда не трогает содержимое, которое инструмент возвращает. Если движку нечего подставить, вызов убирается (fail-closed). См. Очистку ответов.
Удержания human-in-the-loop открываются на поверхности inbound, не response. Правило pending_approval, которое впервые совпадает на выданном вызове, поэтому убирается (fail-closed) — сохранение его переслало бы непроверенный вызов без человеческого решения. Создавайте HITL-удержания, чтобы они срабатывали на inbound; см. Подтверждения.
allow и audit оба пересылают вызов; audit — обычный default_verdict — записать всё, не блокировать ничего, пока вы не готовы применять.
cap_cost и pending_approval — inbound-концепции на этой поверхности. cap_cost инертен на response (модель уже отработала), а pending_approval разрешается в убирание, а не удержание. Ставьте потолки стоимости и HITL-удержания на поверхность inbound — см. Cap cost и Подтверждения.

​
4. Стриминг: удержан, затем отфильтрован

В не-стрим ответе весь ответ парсится и фильтруется сразу. На стриме tool_calls модели приходят как дельты на каждый индекс через множество SSE-фреймов — и как только дельта переслана, ваш агент её уже имеет, и её нельзя отозвать. Так что шлюз удерживает фреймы вызовов инструментов: они никогда не пересылаются посреди стрима. В конце стрима firewall собирает каждый вызов (имя + полные аргументы), вычисляет его и выдаёт только выжившие вызовы.
Контентные фреймы всё равно стримятся нормально — текстовые токены достигают вашего клиента по мере прибытия. Только фреймы tool_call удерживаются для вычисления, так что отклонённый или очищенный вызов отфильтровывается до того, как собранный вызов инструмента доставлен. Семантика вердикта и правила идентична не-стрим поверхности. О деталях на уровне фреймов см. Внутренности стриминга и Стриминг провайдеров.

​
5. Разверните его безопасно

Вкладка Test в консоли прогоняет политику против образца вызова инструмента и возвращает вердикт, совпавшее правило и причину — ничего не диспетчеризуется, ничего не сохраняется. Подтвердите, что ваш глоб и клауза аргумента совпадают с вызовом, который вы имели в виду, до привязки ключа. См. Тестирование правил.
Включите shadow-режим, и каждый применяющий вердикт — включая deny поверхности response — понижается до audit, причина с префиксом [shadow] would …. Вы измеряете ровно то, что правило убрало бы против реального трафика, до того как оно изменит хоть один ответ.
Каждое вычисление пишет событие firewall с вердиктом, поверхностью, инструментом и совпавшим правилом. Отфильтруйте журнал событий по поверхности response, чтобы увидеть, как ваше правило срабатывает на выданных вызовах, которые вы ожидали. См. Аналитику.

​
6. Привяжите политику и кто может её настраивать

Политика ничего не делает, пока к ней не разрешится ключ. Привяжите в консоли, установив firewall_policy_id на ключе, или сделайте политику default рабочего пространства. Разрешение: привязанная политика ключа (когда она существует и включена), иначе default рабочего пространства — и отключённая привязанная политика откатывается к default рабочего пространства. См. Управление политиками. Вся конфигурация выполняется в консоли под вашей сессией (/api/workspace/firewall/*):
ДействиеРоль
Чтение политик, пресетов, обнаруженных инструментов, SimulateMember
Прогон вхолостую (Test), чтение журнала событий и свёрток прогоновDeveloper+
Создание / редактирование / удаление правил и политикDeveloper+

​
Связанное

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

Клаузы аргументов, которые делают фильтрацию поверхности response точной.

Очистка ответов

Отредактировать секреты из аргументов вызова вместо его убирания.

Стадии Firewall

Как response сравнивается с inbound, mcp и egress.

Блокировать инструменты

Inbound-аналог: отклонить инструмент до того, как он предложен модели.

Опасные вызовы инструментов

Угроза, которую решает фильтрация ответа.

Справочник Firewall

Полный справочник правил + сопоставления.