Отсутствие атрибуции и форензики

Когда что-то идёт не так с агентом, первый вопрос всегда один и тот же: что он на самом деле сделал, и кто изменил политику, которая это позволила? Без журнала вы не можете ответить ни на один. Вы не можете показать аудитору, что контроль был в силе в нужный день, вы не можете отличить реальную атаку от шумного ложного срабатывания, и вы не можете реконструировать прогон, который слил строку. OrcaRouter записывает ответ по ходу. Каждый проверенный промпт, каждый вызов инструмента, каждое подтверждение и каждое редактирование политики попадают в запрашиваемую запись в рамках рабочего пространства — коррелированную обратно с прогоном и сессией агента, которые её произвели. Эта страница показывает, как использовать эту запись как журнал аудита ИИ-агента: от единственного подозрительного прогона до подписанного отчёта, который вы вручаете аудитору.

​

1. Четыре записи за журналом аудита ИИ-агента

Атрибуция приходит из четырёх независимых потоков, каждый коррелированный с одним и тем же прогоном и сессией, так что вы можете переключаться между ними: Соединительная ткань — это id прогона агента и сессии. Совпадение guardrail и событие firewall из одного разговора несут одну и ту же родословную прогона, так что «этот прогон замаскировал email, затем попробовал выборку, которую мы запретили, затем был одобрен на запись» читается как одна история вместо трёх несвязанных логов.

​

2. Guardrail Matches — что было проверено (Member)

Каждый раз, когда срабатывает правило guardrail, шлюз пишет совпадение. Лента живёт на странице Guardrails (вкладка Matches) и читаема любым участником рабочего пространства. Каждое совпадение записывает тип правила, предпринятое действие (block / mask / flag / annotate / spotlight), этап (input / output), строку детализации и родословную прогона запроса, который его вызвал. Перечисляйте, группируйте по guardrail или типу правила, фильтруйте по действию, углубляйтесь в одно совпадение или экспортируйте ленту в CSV. Шумное правило тоже часть журнала. Пометьте совпадение как ложное срабатывание через POST /api/guardrail/match/:id/mark-fp (Admin), чтобы ваш сигнал оставался чистым, а отчёты не переучитывали.

​

3. Firewall Events & Runs — что агент сделал (Developer+)

Где Matches покрывают текст, firewall Events покрывают действия. Каждая оценка вызова инструмента логируется со своим вердиктом, поверхностью, именем инструмента и — что критично — прогоном и сессией агента, которым она принадлежит. Чтение Events, сводки Runs/sessions и трейса для каждого прогона требует Developer+; более лёгкие ленты Discovered-tools и аномалий открыты каждому участнику. Представление Runs & sessions — это форензическая рабочая лошадка: оно сворачивает события по прогону агента в разбивку вердиктов, отдельные инструменты и модели, которых коснулся прогон, и метки времени первого/последнего появления — ответ «что этот агент на самом деле делал» на одном экране. Помимо статических вердиктов, лента аномалий отмечает отклонения от выученного базового уровня по часу недели каждого рабочего пространства (скользящее 14-дневное среднее) — всплески частоты и стоимости, retry_loop и переходы novel_path — так что разрешённый-но-аномальный паттерн всё равно всплывает в записи.

​

4. Решения о подтверждении — кто сказал «да» (действие аудита)

Когда правило разрешается в pending_approval, удержанный вызов становится внеполосной проверкой (см. HITL-поток Firewall). Решение — часть журнала: одобрение или отклонение пишет строку аудита рабочего пространства — firewall_approval_approve или firewall_approval_reject — называя актора. Решения по принципу first-writer-wins и идемпотентны, и если лежащее в основе правило изменилось после удержания, обогащение отмечает, что контекст сместился. Так что удержанный-затем-одобренный вызов инструмента полностью атрибутируем от начала до конца: событие firewall показывает удержание, строка аудита показывает, кто его освободил, и оба коррелируют с одним и тем же прогоном.

​

5. Аудит изменений политик — кто изменил правила

Журнал поведения агента надёжен, только если вы можете также доказать, какой была политика в тот момент — и кто её изменил. Guardrails ведут полную историю версий. Каждое создание, обновление и удаление пишет версионированную строку истории в той же транзакции, что и изменение. Откройте History у guardrail, чтобы увидеть каждую версию с автором и меткой времени, сравнить любые две и откатиться к более старой (откат записывается как новая версия — история никогда не мутируется). Изменения политики, правила и настроек Firewall каждое пишут строку аудита рабочего пространства после коммита изменения — firewall_policy_update, firewall_rule_create, firewall_settings_update и так далее — а изменения уровня автономии (firewall_autonomy_applied / firewall_autonomy_undone) захватывают снимок состояния-до, который питает отмену в один клик. Секреты и блобы правил никогда не логируются.

​

6. Разобранный пример: проследите один подозрительный прогон

Предположим, прогон отмечен за неожиданный исходящий вызов. Из консоли, с сессией Developer+: Один прогон, четыре коррелированные записи, без археологии log-grep. Для самих защит от эксфильтрации см. Эксфильтрация данных и Опасные вызовы инструментов.

​

7. Подписанные отчёты комплаенса — журнал, который аудитор может проверить

Для внешнего доказательства поверхность Compliance превращает этот журнал в один артефакт. Просмотр каталога фреймворков, пакетов и готовности открыт каждому участнику и бесплатен; установка пакета, генерация отчёта, выход в эфир и установка резидентности данных — это действия Admin рабочего пространства на платном плане (server-gated). Отчёт комплаенса подписан Ed25519 с хешем содержимого SHA256 и публично проверяем — получатель проверяет его без аккаунта OrcaRouter: Отчёты экспортируются как CSV / JSON / PDF. Фреймворки включают soc2, hipaa, gdpr, iso_27001, iso_42001, nist_ai_rmf, pci_dss, EU AI Act (eu_ai_act) и OWASP Top 10 for LLM Applications (owasp_llm), среди прочих — установка пакета материализует соответствующие guardrails и политики firewall, так что контроли, о которых вы отчитываетесь, — это контроли, фактически применяемые.

​

8. Удержание и право на удаление

Форензическая запись ограничена, а не вечна. Логи запросов по умолчанию хранятся 30 дней и server-clamped до жёсткого максимума 180 дней. Когда пользователь самоудаляется, применяется окно 30-дневной отсрочки, после которого его PII вычищается, а каскад удаляет его совпадения guardrail, логи запросов и события firewall — удовлетворяя обязательства права-на-удаление / DSAR, сохраняя при этом агрегатную историю аудита нетронутой.

​

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