Кратко

  • Редакция 01 документа draft-kuehlewind-audit-architecture от 7 сентября 2026 года вводит хранение в основном канале: каждый агент может запустить собственный Audit Store и пересылать записи по тому же соединению, которое используется для взаимодействия.
  • Проект называет такую схему альтернативой, а не заменой внешнего хранилища, и допускает сочетание двух подходов. Одновременно он предупреждает: общий оператор агента и Store требует большего доверия к этой стороне.
  • Хранение — лишь одна функция. Документ отдельно описывает Recorder, Auditing Service, аттестацию, регистрацию прозрачности, аудитора и проверяющую сторону.
  • Это по-прежнему индивидуальный Internet-Draft. Datatracker прямо сообщает, что документ не одобрен IETF и не имеет формального статуса в её процессе стандартизации.
  • Daniel Kade предлагает квитанцию топологии хранения с указанием оператора каждой функции. Это авторская рекомендация, а не требование проекта.

Новый короткий путь снабжён предупреждением о доверии

Самое показательное добавление в редакции 01 занимает один абзац. Новый раздел 3.2 разрешает не экспортировать все записи в отдельный внешний Audit Store. Каждый агент может вести своё хранилище и передавать события в Store агента-контрагента по уже существующему соединению, не создавая отдельного канала вне основного обмена.

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

В майской редакции 00 раздела о таком хранении не было. Следовательно, новостной повод — проверяемое изменение текста, а не новое толкование прежней схемы.

Слово «аудит» скрывает несколько разных действий

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

Основные участники создают записи с разных позиций. Пользовательская сторона может сохранить намерение и подтверждение. Агент выпускает сигналы о действиях, делегировании и переходах состояния полномочий. Сервис или инструмент фиксирует запрос, который увидел на границе фактического исполнения. Audit Recorder захватывает либо преобразует сигналы. Audit Store хранит и предоставляет записи. Auditing Service приводит наблюдаемые данные к канонической форме, подписывает собственным идентификатором и отправляет на регистрацию в журнал прозрачности.

Затем Auditor оценивает доказательства по политике, а Verifier может проверить отдельное утверждение.

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

Разделение особенно важно, потому что проект допускает совмещение ролей. Роль — это функция, а не обязательно отдельная компания или техническая единица. Хост-процесс агента может выполнять и роль Recorder. Развёртывание упрощается, но возникает угроза сговора; среди мер проект называет независимый Recorder либо неотказуемость через регистрацию прозрачности. В другом месте редакция 01 говорит, что свойства подотчётности требуют независимого Auditing Service.

Если соблюдать терминологические границы, противоречия нет. Store того же оператора может перевозить и удерживать записи, а независимая служба — канонизировать их или создавать внешнее обязательство. Третья сторона может хостить Store, не будучи аудитором. И наоборот, внешний продукт может оставаться под контролем той же корпоративной группы, администратора или держателя ключей. «Внешний» описывает размещение, «независимый» — контроль и стимулы.

Адрес хранилища не доказывает независимость хранения

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

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

RFC 9334 проводит сходное разделение в удалённой аттестации: Attester создаёт Evidence, Verifier оценивает его, а Relying Party применяет собственную политику. RFC 9943 также различает подписанные заявления, службы прозрачности, квитанции и решения полагающихся сторон. Название компонента не создаёт уровень гарантии. Его определяют роли, политики, ключи и путь доказательства.

Нельзя преувеличивать и институциональный статус. Datatracker не показывает поток RFC, ответственного Area Director или принятие Working Group и публикует явное предупреждение об отсутствии одобрения IETF. Новый вариант хранения — развивающееся предложение, а не правило IETF для агентных систем.

Источники