Перейти к основному содержанию
Запрос вернул HTTP 400, и ваш агент застопорился. Прежде чем менять какой-либо код, шлюз уже сказал вам, что произошло: код ошибки называет, какой контроль сработал, а одна из двух лент называет точное правило. Эта страница — поток поиска и трассировки: прочитайте код, откройте нужную ленту, найдите правило. Если вы запомните одну вещь: 400 от контроля безопасности — это не баг в вашем промпте. Это политика, делающая свою работу. Ваша задача — найти, какая политика, затем решить, исправить ли вызов или ослабить правило.

​
1. Почему мой LLM-запрос был заблокирован? — начните с кода ошибки

Каждая блокировка безопасности на хостируемом шлюзе возвращает HTTP 400 с машиночитаемым code в теле ошибки в форме OpenAI. Этот код — первая развилка на пути: он говорит, какую плоскость управления отлаживать и какую ленту открыть. 
{
  "error": {
    "message": "tool \"shell.exec\" blocked by firewall: destructive shell command",
    "code": "firewall_blocked",
    "type": "invalid_request_error"
  }
}

guardrail_blocked

Контентное правило Guardrail сработало на входе вашего запроса или выходе модели. Проследите его в ленте Matches. См. §2.

firewall_blocked

Правило Firewall отклонило вызов инструмента. Проследите его в ленте Events. См. §3.

firewall_approval_pending

Вызов инструмента удержан для подтверждения человеком — не отклонён. Разрешите его, а не отлаживайте. См. §4.
Все три кода — skip-retry: повторный прогон идентичного вызова маршрутизируется в ту же политику и снова блокируется. Повтор — потерянная задержка; вместо этого исправьте вход или правило. Полная таблица кодов живёт в Кодах ошибок.

​
2. guardrail_blocked — найдите правило в Matches

guardrail_blocked означает, что контентная политика, привязанная к вашему ключу (или к default’у рабочего пространства), выполнила действие block против входа запроса или выхода модели. Сообщение блокировки называет guardrail и правило, и запрос не стоит вам квоты — блокировки на входе срабатывают до учёта; блокировки на выходе возвращают предварительно списанную квоту. Проследите его:
1

Откройте ленту Matches

В консоли перейдите на вкладку Matches на странице Guardrails (GET /api/guardrail/match, Member). Каждое сработавшее правило попадает сюда — его RuleType, Action, Stage и строка Detail вроде pii: email, phone или matched 3 keyword(s).
2

Отфильтруйте до блокировки

Отфильтруйте по action = block и времени вашего запроса. Совпавшая строка говорит вам тип правила (pii, regex, keyword, max_chars, llm_judge, grounding, external) и сработало ли оно на стадии input или output.
3

Посмотрите, на что оно реально совпало

По умолчанию лента записывает что правило сработало и его мета-строку Detail — не совпавшую подстроку. Включите Log raw content на этом guardrail (по умолчанию выключено — приватность-консервативная позиция), чтобы захватить нарушающую строку для разбора. Переключатель не имеет обратной силы.
Блокировка, которую вы считаете неверной? Откройте совпадение и отметьте его как ложное срабатывание (POST /api/guardrail/match/:id/mark-fp, Admin). Чтобы доказать исправление до отгрузки, отредактируйте правило и переиграйте образец на вкладке Test редактора guardrail — без вызова вверх по потоку, без квоты.

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

Вы отправляете ответ поддержки, содержащий SSN клиента. Ваш guardrail pii-shield имеет override entity_actions, который блокирует на ssn: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "ssn"],
  "entity_actions": { "ssn": "block" }
}
Шлюз возвращает 400 guardrail_blocked. Лента Matches показывает RuleType: pii, Action: block, Stage: input, Detail: pii: ssn. Исправление — продуктовое решение, а не изменение кода: ослабьте override до mask (модель никогда не видит SSN, вызов проходит) или оставьте блокировку и вырежьте SSN выше по потоку. См. Guardrails для полного справочника по типам правил и PII-сущностям.

​
3. firewall_blocked — найдите вердикт в Events

firewall_blocked означает, что политика Firewall отклонила вызов инструмента. На поверхности inbound он проявляется как 400; через MCP-шлюз он проявляется как ошибка инструмента (firewall deny: <reason>), так что модель может среагировать вместо падения. metadata ошибки несёт код причины, факторы риска и оценку. Проследите его в ленте Events (GET /api/workspace/firewall/events, Developer+) — сырая запись за каждым вычислением. Каждое событие несёт вердикт и поверхность, на которой оно было увидено:
ВердиктЧто он значит для вашей блокировки
denyПравило (или default_verdict) заблокировало вызов. Это ваш firewall_blocked.
auditРазрешено, но залогировано — включая [shadow] «would deny», если политика в shadow-режиме.
cap_costНакопленные траты прогона пересекли пороговый лимит правила в центах; разрешается в deny.
1

Отфильтруйте Events до отказа

Отфильтруйте по verdict=deny, затем по tool, run_id или session_id, чтобы изолировать точный вызов. Событие называет совпавшее правило и поверхность — inbound, response, mcp или egress.
2

Прочитайте причину на совпавшем правиле

Строка причины (например, destructive shell command, egress host not allowed) говорит вам, совпало ли правило по имени инструмента, клаузе args_match или egress-назначению. Глоссарий вердиктов и справочник по глобам и JSONPath декодируют сопоставление.
3

Подтвердите в песочнице Test

Переиграйте тот же вызов инструмента на вкладке Firewall Test (POST /api/workspace/firewall/test, Developer+), чтобы увидеть вердикт, совпавшее правило и причину — ничего не диспетчеризуется, ничего не логируется.
Отказ cap_cost — это не осечка правила: ваш прогон агента упёрся в потолок трат, который вы задали. Либо прогон зациклился (проверьте свёртку Runs и ленту аномалий на retry_loop), либо лимит реально слишком мал для задачи. Поднимите лимит осознанно, а не просто повторяйте.

​
4. firewall_approval_pending — это удержано, а не отклонено

firewall_approval_pending — это единственный 400, который вы не должны трактовать как блокировку. Вердикт pending_approval удержал вызов инструмента для человека; тело ошибки несёт id подтверждения. Вызов не провалился — он ждёт.
  1. Ревьюер разрешает его — из консоли (Developer+) или через ваш собственный HMAC вебхук-колбэк (POST /api/v1/firewall/approvals/:id/callback).
  2. Ваш агент опрашивает GET /api/v1/firewall/approvals/:id (токен шлюза) по id из ошибки.
  3. После одобрения переотправьте исходный вызов с одноразовым заголовком X-OrcaRouter-Firewall-Approval, и шлюз пропустит его этот один раз.
См. Firewall → Подтверждение человеком для полного цикла HITL.

​
5. Не блокировка безопасности? Сначала исключите ключ

Не каждый 400 — вердикт guardrail или firewall. Прежде чем нырять в ленты, исключите ограничения ключа — они отклоняют до того, как сработает любая политика, и не несут кодов безопасности выше:
Allow-list model_limits ключа не включает запрошенную модель. Запросы на модель вне списка отклоняются заранее. Добавьте модель к ключу или вызовите ту, что разрешена.
У ключа есть allow-list allow_ips, и запрос пришёл с адреса вне него. Добавьте IP / CIDR вызывающего или вызывайте из разрешённой сети.
Потолок credit_limit_usd ключа исчерпан (0 означает безлимит). Поднимите лимит или переключитесь на ключ с запасом.
Хуки шлюза (evaluate, диспетч MCP) требуют ключ с is_firewall_gateway=true. Обычный relay-ключ получает 403. Выпустите ключ с областью firewall-gateway для этих маршрутов.

​
6. Двухминутный поток разбора

Блокировка на тексте промпта или ответа

Код — guardrail_blocked → откройте Matches, отфильтруйте action=block, прочитайте Stage + Detail. Исправьте содержимое или правило; докажите на вкладке guardrail Test.

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

Код — firewall_blocked → откройте Events, отфильтруйте verdict=deny, прочитайте поверхность + причину. Исправьте вызов или правило; докажите на вкладке firewall Test.

Вызов удержан

Код — firewall_approval_pending → опросите id подтверждения и переотправьте с заголовком подтверждения. Отлаживать нечего.

Ничего из вышеперечисленного

Нет кода безопасности → проверьте ключ: model_limits, allow_ips, credit_limit_usd или 403 за отсутствующую область шлюза.

​
7. Сопутствующие справочники

Коды ошибок

Полная таблица кодов — каждая блокировка, удержание и отказ, которые шлюз может вернуть.

Глоссарий вердиктов

Что значит каждый вердикт firewall и когда он разрешается в deny.

Глобы и JSONPath

Декодируйте tool_name_glob и args_match, совпавшие с вашим вызовом.

Guardrails против Firewall

Какая плоскость сработала — проверка текста или управление действиями.
О самих контролях см. Guardrails и Firewall; об угрозах, которые они останавливают, начните с модели угроз.