Кратко

  • 31 августа IETF открыла список AUDIT вне рабочей группы по теме Agent Use of Delegation and Interaction Traceability. Объявление формулирует проблему совместимости, но не создаёт рабочую группу, не принимает архитектуру и не стандартизирует формат записей.
  • Идентификатор трассы способен соединить утверждения пользователя, агента и сервиса, но не сделать их истинными. Аудиторское доказательство должно сохранять производителя записи, предел её смысла, поколение действовавшего разрешения, релевантные часы и независимое наблюдение эффекта со стороны сервиса, а пропуски и конфликты показывать явно.

Допустим, агент должен остановить одну партию на складе. Пользователь называет номер отправления, планировщик делегирует задачу, а исполнитель получает разрешение на изменение статуса. Агент пишет «остановлено», шлюз фиксирует принятый запрос, но складская система уже передала партию перевозчику. В соседнем журнале тот же идентификатор относится к отмене другой накладной после автоматического объединения заказов.

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

Именно этой проблеме объявление секретариата IETF дало имя и площадку 31 августа 2026 года. Новый список, не относящийся к рабочей группе, называется Agent Use of Delegation and Interaction Traceability, или AUDIT. В объявлении сказано: существующие журналы, системы трассировки и механизмы авторизации фиксируют отдельные части поведения агентов, однако им недостаёт совместимого способа соотнести намерение пользователя, делегирование, изменение состояния разрешений и последующие действия за пределами одной административной области.

Статус площадки нельзя опускать. Список рассылки — место для работы, а не принятое решение. IETF не объявляла рабочую группу AUDIT, не утверждала её устав, архитектуру, заголовок или модель данных. Индивидуальные черновики по теме также не стали консенсусом IETF. Новость в другом: разрывы между доказательствами получили именованное техническое пространство.

Корреляция соединяет записи, но не выносит приговор

Распределённая трассировка хорошо показывает и пользу, и предел общего контекста. Рекомендация W3C Trace Context определяет traceparent, чтобы разные системы могли собрать запросы в один граф, и tracestate для дополнительного состояния участников. Узел может изменить родительский идентификатор, политику выборки, собственное состояние или начать новую трассу на границе доверия. Даже флаг выборки прямо не гарантирует, что данные трассы действительно записаны.

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

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

Поэтому вопрос «существует ли трасса?» слишком слаб. Для каждого ребра нужно установить, кто сделал утверждение, каким ключом и по какой политике, из какой области доверия, какие поля покрыты, на какой стадии оно возникло и видел ли тот же переход независимый участник. Граф становится доказательством только через атрибуцию его рёбер.

Четыре класса записей и пять часов

Архитектурный черновик разделяет записи взаимодействия, действия, делегирования и перехода разрешений. Это не просто аккуратная схема.

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

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

Черновик Verifiable Agent Conversation Records отличает время создания записи от времени сеанса и отдельных элементов. Он также признаёт, что показанное рассуждение может отличаться от процесса, породившего действие. Воспроизведение разговора остаётся представлением, заявленным его производителем, а не прямым доступом к причинной истине.

Редакция 01 Agent Audit Trail делает временную проблему конкретной через record_phase. Отказ или эскалация, записанные только после исполнения, не доказывают, что контроль предшествовал действию. Предлагаются связанные записи до и после исполнения. Это полезное направление проектирования, но пока индивидуальное предложение, а не правило IETF.

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

Что доказывают существующие механизмы

Объявление AUDIT указывает на уже имеющиеся средства авторизации, HTTP, аттестации и прозрачности. Каждое отвечает на более узкий вопрос.

Обмен токенов OAuth способен представить контекст субъекта и действующего лица при замене одного токена другим. Корректный обмен служит свидетельством решения сервера авторизации по его политике. Он не раскрывает все инструкции модели, не доказывает незаписанное субделегирование и не устанавливает результат в целевом сервисе.

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

Архитектура SCITT и квитанции COSE дают прозрачную регистрацию и проверяемые доказательства включения. Квитанция показывает, что заявление зарегистрировано по политике сервиса и включено в определённое состояние. Она не делает заявление истинным и не наделяет издателя властью над его предметом. Прозрачно зафиксированная ложь остаётся ложью — лишь удалить её незаметно становится труднее.

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

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

Эти механизмы хорошо сочетаются именно потому, что полномочие каждого узко. Система аудита ломается, когда одному доказательству предлагают унаследовать работу следующего.

Отсутствующая запись — тоже вывод о системе

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

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

Хеш-цепочки не устраняют эту обязанность. Они могут обнаружить удаление или перестановку внутри захваченной последовательности, но не событие, которое никогда не внесли, не скрытую альтернативную цепь и не поле, которого схема не потребовала. Регистратор рядом с агентом может безупречно подписать избирательный рассказ. Прозрачность сделает его долговечным, но не полным.

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

Аудируемость может превратиться в наблюдение

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

Здесь полезно различие Lu Heng между формальным и практическим суверенитетом над данными. Организация может формально владеть политикой аудита, тогда как другой поставщик держит запросы, результаты инструментов, графы трасс, ключи подписи или квитанции включения. Практический контроль принадлежит тому, кто способен читать, сопоставлять, удерживать, менять и сохранять эти материалы.

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

Это прямое применение дисциплины слоёв реальности Lu Heng. Ссылка трассы, подпись, результат аттестации, квитанция включения, решение авторизации, ответ сервиса и пользовательский исход — разные факты. Соседство на одном экране не сливает их значения.

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

Новая площадка IETF важна потому, что эти соединения проходят через протоколы и административные области. Её успех не следует измерять созданием одного универсального рассказа. Он будет в том, чтобы несовместимые утверждения, пропавшие свидетели и ограниченные доказательства стали достаточно различимы для обоснованного вывода аудитора.

Источники