Аудит-логи для агентов — это задача журнала упреждающей записи, а не дашборда

Пробел в подотчётности при наблюдаемости агентов

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

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

Более глубокая проблема структурна. Запись аудита, которую может редактировать тот же процесс, который она описывает, не является доказательством. Если runtime агента держит дескриптор записи для собственного журнала, то любая компрометация этого runtime — инъекция промпта, путаница зависимостей, вредоносный инструмент — может подавить, переупорядочить или переписать записи, которые его изобличают. Конвейеры наблюдаемости, построенные таким образом, с точки зрения подотчётности являются самоотчётами. Они полезны для отладки и бесполезны в споре.

Семантика упреждающей записи для запусков агентов

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

Соответствующий требованиям запуск агента добавляет по порядку, до срабатывания любого побочного эффекта:

1. Предполагаемое действие — имя инструмента, канонизированные аргументы, целевой ресурс.
2. Санкционирующее решение политики — какое правило совпало, какой субъект инициировал запуск, какие ограничения применялись.
3. Разрешённые учётные данные — под какой идентичностью будет действовать инструмент и каков объём этой идентичности.

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

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

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

Что должна содержать запись

Минимальная схема для одной записи добавления:

{
  "seq": 41822,
  "run_id": "run_7f3a...",
  "parent_step": 41819,
  "ts_monotonic": 918273645,
  "kind": "tool.intent",
  "tool": "http.fetch",
  "args_hash": "sha256:9c1f...",
  "policy_rule": "net.egress.allowlist.v4",
  "credential": "svc-fetch-readonly@proj-9",
  "context_refs": ["doc_31a", "doc_88b"]
}

Несколько полей несут непропорционально большой вес.

Хеш аргументов, а не аргументы. Хеширование держит секреты вне журнала, но при этом привязывает запись к точному входу. Там, где аргументы должны быть восстановимы для воспроизведения, храните их в отдельном заши доступа.

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

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

Детерминированное тактирование и монотонные порядковые номера. Настенные временные метки отдельных воркеров не упорядочиваемы в распределённом оркестраторе; рассинхронизация часов и параллельные воркеры переупорядочат события, которые были причинно последовательными. Единый монотонный порядковый номер, назначаемый оркестратором, с настенным временем как вторичным полем для человеческого чтения, даёт полный порядок, который выдерживает воспроизведение.

Операционные последствия

Усиление записи и хранение становятся статьями бюджета. Каждый вызов инструмента теперь стоит как минимум одного надёжного добавления, часто нескольких (намерение, решение политики, разрешение учётных данных, результат). На высокочастотных агентах это значимая доля бюджета хранения и ввода-вывода, и она соседствует со стоимостью инференса, а не находится внутри статьи на наблюдаемость. Политика хранения становится проектным решением: как долго хранится полная траектория, что сводится к хешам, что экспортируется в холодное хранилище. Сведение никогда не должно разрывать цепочку — хеш полезен только тогда, когда прообраз извлекаем по политике, сохраняющей его достоверность.

Версионирование схемы с первого дня. Разбор инцидента происходит через месяцы после изменения кода. Если схема журнала не версионирована, записи за рассматриваемый период могут быть нечитаемы текущим инструментарием, и расследование застопорится на миграции формата. Явно версионируйте схему записей, сохраняйте читатели для каждой когда-либо испущенной версии и относитесь к изменениям схемы как к ломающим изменениям с той же строгостью, что и к API.

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

Позиция

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