Перейти к основному содержанию
Когда ваша политика firewall судит вызов инструмента, она пишет строку. Лента событий — это тот самый текущий журнал: одна запись на каждое вычисление, несущая вердикт, поверхность, на которой оно сработало, инструмент, причину и прогон/сессию, к которым оно принадлежало. Именно так вы отвечаете на единственный вопрос, который важен после развёртывания политики, — действительно ли firewall сделал то, что я думаю, на тех вызовах, на которых я думаю, что он это сделал? Это ваша поверхность логов ai firewall. Каждый allow, каждый deny, каждое удержанное подтверждение, каждое «would-have» из shadow-режима приземляется здесь, фильтруемое и коррелированное обратно с прогоном агента, который его породил.
Лента событий читается на уровне Developer+. Каждая строка резервирует ограниченное поле args_summary для снимка аргументов вызова инструмента, так что эта поверхность стоит выше тех, что читаются на уровне Member (настройки, политики, обнаруженные инструменты, лента аномалий). Всё это настраивается из консоли — это маршруты с аутентификацией сессии, а не ретрансляционные вызовы.

​
1. Что приземляется в ленте событий

Записывается каждое вычисление, которое выполняет движок, — не только блокировки. allow и audit оставляют строку ровно так же, как deny, так что лента — это полный след, а не журнал исключений. Вердикт в строке — тот, который агент на самом деле увидел:
ВердиктОзначает
allow / auditПропущено; audit помечает это как то, за чем вы хотели наблюдать.
denyЗаблокировано — firewall_blocked (HTTP 400) на inbound, ошибка инструмента на mcp.
sanitizeПереслано с отредактированными совпавшими подстроками из аргументов вызова.
pending_approvalУдержано для человека; строка фиксирует, что вызов был поставлен на проверку.
observeНи одна политика не совпала — пробел в покрытии observe-режима.
Вы никогда не увидите буквальный cap_cost в ленте. Правило cap-cost разрешается в конкретный allow или deny во время вычисления, и именно это логируется — вердикт, который прогон реально испытал.
В shadow-режиме применяющие вердикты понижаются до audit, а причина получает префикс [shadow] would …, так что лента показывает вам ровно то, что политика заблокировала бы, прежде чем вы переключите её в боевой режим.

​
2. Что записывает каждое событие

Отдельное событие — это денормализованный снимок, достаточный, чтобы реконструировать решение, не присоединяясь обратно ни к чему:
verdict, surface (inbound / response / mcp / egress), tool_name и человекочитаемая reason («destructive shell command», «egress to 169.254.169.254 denied»). Когда у совпавшего правила была метка, policy_name и rule_label называют точное правило, которое сработало, — так что строка указывает прямо на написанную вами строку.
request_id присоединяет событие к логу запроса; conversation_id группирует многоходовую сессию; agent_run_id (с step_id / parent_step_id) привязывает его к одному полному прогону агента и LLM-вызову, который запросил инструмент. Именно это делает ленту трассировкой, а не плоским списком — см. §4.
token_name, model_name и IP вызывающего ip — ключ, модель и источник за вызовом. skill_name называет владеющий навык, когда вызов можно было ему приписать, а quarantine флагирует удержание по карантину навыка.
args_summary — это поле ограниченного снимка аргументов вызова инструмента (причина, по которой эта поверхность требует Developer+). В событии egress поле egress_host записывает исходящее назначение, которое было оценено.
args_summary ограничено — сырые байты аргументов никогда не пишутся в ленту дословно, а хеш группировки retry-цикла, на котором держится детектирование аномалий, существует только на сервере: он никогда не уходит в API.

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

Ваш агент выдал вызов shell.exec с rm -rf /data, правило deny его поймало, и вы хотите увидеть именно это решение. Отфильтруйте ленту по вердикту и инструменту: 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
Консоль рендерит те же строки как фильтруемую таблицу — вы редко обращаетесь к маршруту вручную. Настраивайте фильтры, проваливайтесь в прогон и экспортируйте из представления событий; приведённый выше curl нужен лишь чтобы показать форму.
$ORCA_CONSOLE_TOKEN — это ваш сессионный / access-токен, а не ретрансляционный ключ sk-orca-…. Маршруты /api/workspace/firewall/* аутентифицируются консолью и ограничены ролью; только трафик /v1/* использует ретрансляционный ключ.

​
4. Коррелируйте по прогону и сессии

Причина, по которой каждое событие несёт agent_run_id и conversation_id, — чтобы вы перестали смотреть на вызовы изолированно и начали спрашивать что этот агент сделал за весь свой прогон:
ФильтрНа какой вопрос отвечает
run_id=<run>Каждый вердикт в одном прогоне агента — полный след действий.
session_id=<conv>Каждый вердикт по всему многоходовому диалогу.
verdict=deny,pending_approvalПредставление «что было остановлено или удержано» в одном запросе.
surface=egressТолько решения по исходящим назначениям — линза эксфильтрации.
Список событий также принимает since / until (unix-секунды) и limit / skip для пагинации. Для свёрнутого представления — одна строка на прогон или сессию с разбивкой по вердиктам, различимыми инструментами и моделями и первым/последним появлением — консоль читает GET /api/workspace/firewall/events/aggregate?group_by=run (или group_by=session), а дерево трассировки агента читает /trace/by-run. Оба требуют Developer+, как и сырая лента.
Из выдвижной панели лога запроса вы можете развернуться в другую сторону: GET /api/workspace/firewall/events/by-request/:request_id возвращает каждое событие firewall, захваченное под одним запросом, — удобно, когда один запрос задел несколько правил на разных поверхностях.

​
5. Хранение и стирание

События firewall несут собственный горизонт хранения — по умолчанию 30 дней, ограниченный сервером жёстким максимумом в 365 дней. Каждое событие пишется со сроком истечения и автоматически устаревает по TTL-индексу; ничто в ленте не живёт дольше вашей настройки хранения. Запрос на право быть забытым каскадируется сюда тоже: удаление пользователя запускает 30-дневный льготный период, после которого его PII вычищается, а его события firewall удаляются вместе с логами запросов и совпадениями guardrails той же области.

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

Вердикты

Что каждый вердикт в ленте на самом деле сделал с вызовом.

Shadow-режим

Читайте ленту в режиме «would-have» до того, как начнёте применять.

Стадии и поверхности

Четыре поверхности, которые называет поле surface.

Справочник Firewall

Полный справочник по политикам, правилам и API.
Об угрозах, которые эти логи помогают ловить с поличным, см. эксфильтрацию данных и опасные вызовы инструментов. О том, как firewall сочетается с проверкой текста промпта/ответа, см. firewall + guardrails.