Агент не должен быть единственным свидетелем собственных действий

Агент отправляет платёжное поручение, меняет карточку клиента, принимает условие поставщика или запускает производственный процесс. Позже возникает простой вопрос: что произошло? Трасса агента сообщает, что он действовал по политике, получил успешный ответ инструмента и завершил задачу. Для эксплуатации это полезная телеметрия. Но сама по себе она не является авторитетным свидетельством.

Структурная проблема проста: компонент, совершивший действие, нередко сам же о нём рассказывает. Агент способен сформировать подробный журнал, не будучи независимым свидетелем. Его среда выполнения может отказать, быть неверно настроена, скомпрометирована или просто описать событие иначе, чем его зафиксировала вызванная бизнес-система. Когда агенты получают доступ к корпоративным системам, это различие становится критичным. Подотчётность нельзя строить на самоотчёте.

Архитектурный ответ — независимый контур свидетельств: защищённая запись решений и эффектов, которую создают контрольные границы вне действующего агента. Это не ещё одна панель наблюдаемости. Это отдельно администрируемая система подотчётности, связывающая авторизацию, попытку и подтверждение внешнего эффекта, а также итоговое авторитетное состояние.

Телеметрия объясняет эксплуатацию; свидетельства обеспечивают подотчётность

Телеметрия приложений нужна операторам для понимания работающей системы. Журналы, трассировки и метрики показывают задержки, сбои, повторы и зависимости. OpenTelemetry даёт для этого сильное общее представление. Его спецификация журналов поддерживает корреляцию через идентификаторы трассы и спана, временные метки и контекст ресурса. Это упрощает восстановление распределённого действия по компонентам.

Корреляция ценна, однако она не делает запись защищённым от подмены доказательством и не подтверждает истинность заявленного события. Идентификатор трассы может связать запрос агента с решением политики и записью в базе данных. Но он не устанавливает, что агент был авторизован, что запись достигла авторитетной системы или что она сохранена вне контроля проверяемого участника.

NIST SP 800-53 рассматривает аудит не как наличие логов, а как систему мер контроля. В нём отдельно определены содержание записей, временные метки, защита, неотказуемость, хранение и генерация. Контроль AU-9 посвящён защите аудиторской информации; его расширения включают хранение на отдельных системах или компонентах, ограничение административного доступа, криптографическую защиту, двойную авторизацию и доступ только на чтение. Направление ясно: система не должна без ограничений управлять свидетельствами, по которым оценивают саму эту систему.

“Агент может описать действие. Но организации нужны другие системы, которые засвидетельствуют авторизацию, эффект и переход состояния.

Размещайте свидетелей на значимых границах

Управляемая среда не должна спрашивать агента, какие действия следует фиксировать. Требование создавать свидетельства обязано обеспечиваться границами, которые агент не может обойти на предоставленном ему пути. На практике полезный минимум образуют квитанции трёх границ.

1. Шлюз политик фиксирует решение об авторизации: кто запросил действие, какая делегирующая идентичность и цель применялись, какая политика проверялась, какая её версия использовалась и был ли запрос разрешён, отклонён или направлен на эскалацию.
2. Шлюз инструмента или эффекта фиксирует попытку внешнего эффекта и, где это возможно, его подтверждение. Именно эта граница видит, как API-вызов, платёжное поручение, исходящее сообщение, передача файла или иная значимая операция покидает управляемую среду.
3. Авторитетное хранилище состояния фиксирует итоговую версию состояния. Успешный ответ инструмента не всегда означает, что состояние организации изменилось ожидаемым образом. Система учёта должна засвидетельствовать зафиксированную версию, отказ или конфликт.

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

Проектируйте квитанцию, а не только поток событий

Квитанция свидетельства должна быть достаточно структурированной, чтобы позднее ответить на вопрос, не сохраняя каждый чувствительный фрагмент данных. Практическая схема — архитектурная рекомендация, а не набор полей, предписанный одним стандартом. В неё стоит включить идентификатор операции или эффекта; идентичность действующего и делегирующего субъекта; решение политики и её версию; возможность инструмента и его версию; дайджесты входов и выходов; версии авторитетного состояния; временные метки; статус результата; ссылки на предшествующие квитанции.

Важны дайджесты и контролируемые ссылки. Полные промпты, ответы модели и бизнес-полезная нагрузка могут быть чувствительными, коммерчески ограниченными или подпадать под сроки хранения. Контур свидетельств должен поддерживать минимизацию, контроль доступа и политику хранения, а не предполагать, что всё содержимое следует навсегда поместить в журнал. Запись должна устанавливать, какой материал использовался или был создан на определённой границе, а не требовать безразборного сбора.

W3C PROV даёт полезную семантическую модель для такой структуры. Его сущности, активности и агенты, а также отношения использования, генерации, происхождения, атрибуции, ассоциации и делегирования позволяют представить граф происхождения, охватывающий людей, агентов, планы и артефакты. Квитанция авторизации может связать активность с агентом и делегированным полномочием. Квитанция состояния может показать, что сущность создана предшествующей активностью. PROV сам по себе не даёт защищённого хранения или независимого свидетельствования, но обеспечивает графу единый словарь.

Делайте изменения обнаружимыми — и контролируйте контролёров

Отдельно администрируемое хранилище свидетельств должно быть дописываемым и защищённым от обычного контроля среды исполнения. Техники журналов прозрачности добавляют полезное свойство: представленные записи можно организовать в дерево Меркла, получая доказательства включения и согласованности. RFC 9162 определяет такие доказательства для Certificate Transparency. Rekor от Sigstore — развёрнутый пример хранения подписанных метаданных в дописываемой криптографически проверяемой структуре.

Это не означает, что дописываемый журнал подтверждает истинность самого события. Он может свидетельствовать, что представленная запись включена и что представления журнала остаются согласованными. Но он не превращает ложное утверждение скомпрометированного источника в истинное. Также одного центрального журнала не всегда достаточно. RFC 9162 отмечает, что недобросовестный журнал может показывать разным клиентам несогласованные представления. Поэтому независимый мониторинг и сравнение представлений — часть проекта; Sigstore также указывает мониторинг как необходимый элемент долгосрочного доверия.

Практическое следствие — архитектурная дисциплина. Защищайте хранилище свидетельств административно; собирайте квитанции на независимых границах принуждения и эффекта; криптографически связывайте и дописывайте их; поручайте отдельным наблюдателям проверять видимость и согласованность журнала. Разделение уменьшает масштаб последствий одной компрометации. Мониторинг уменьшает масштаб доверия к заявлениям одного оператора.

Что это меняет для автономных организаций

Организация с такой архитектурой может расследовать действие как цепочку независимо созданных утверждений. Было ли у агента делегированное полномочие? На это отвечает квитанция политики. Был ли значимый запрос направлен за пределы организации? Отвечает шлюз эффекта. Зафиксировала ли система учёта ожидаемое изменение? Отвечает квитанция авторитетного состояния. Сохранились ли эти записи без незамеченного переписывания? На этот вопрос — в пределах своих свойств — отвечают защищённое хранение, криптографические доказательства и независимый мониторинг.

Меняются и приоритеты внедрения. Не начинайте с вопроса, как сохранить цепочку рассуждений агента. Сначала определите существенные контрольные границы: где проверяется полномочие, где предпринимается внешний эффект и где состояние организации становится авторитетным. Требуйте от каждой границы выпускать квитанцию, прежде чем считать путь управляемым. Используйте совместимый с OpenTelemetry контекст для корреляции записей. Используйте отношения, совместимые с PROV, когда нужен долговечный граф происхождения. Сохраняйте эксплуатационное и административное разделение контура свидетельств и контура исполнения.

Цель — не совершенное знание и не ритуальный реестр. Нужна запись, которая останется полезной, когда агент, его сессия и его собственное описание уже не заслуживают доверия. Автономные организации будут ошибаться, сталкиваться со спорами и отменять решения. Им нужно знать не только то, что агент говорит о своих действиях, но и какие независимые границы засвидетельствовали, как организация авторизовала, попыталась совершить, подтвердила и зафиксировала действие.

Источники

• NIST SP 800-53 Rev. 5, включая AU-9 о защите аудиторской информации.
• Спецификация журналов OpenTelemetry — о представлении и корреляции распределённой телеметрии.
• W3C PROV-DM — о сущностях, активностях, агентах и связях происхождения.
• RFC 9162, Certificate Transparency Version 2.0 — о доказательствах включения и согласованности на деревьях Меркла и рисках разных представлений журнала.
• Документация Sigstore — о журналах прозрачности Rekor и сохраняющейся необходимости мониторинга.