Хранение активности AI-агентов: записи, которым доверяют расследователи

AI-агенты превращают знакомую проблему журналирования в проблему доказательств. Человек может потратить весь день, переходя по экрану приложения, а агент за это время способен выполнить множество внешних вызовов, пока разработчик читает его сводку. Если в записи сказано только «агент выполнил задачу», она не ответит на вопросы, которые возникнут после ошибочного удаления, неожиданного изменения в рабочей среде или оспариваемой передачи данных.

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

Хранение начинается с вопроса, на который должен ответить расследователь

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

Для агента, который может вызывать HTTP API или открывать SSH-сессию, расследователю обычно нужно установить пять обстоятельств:

• Какой идентификатор выполнения сделал запрос и какой человек или сервис разрешил этот запуск?
• Какую возможность агент пытался использовать и к какому назначению обращался?
• Какую операцию он попросил выполнить на стороне назначения?
• Каков был результат, включая отклонение, тайм-аут, частичный успех или ошибку удаленного сервиса?
• Может ли команда показать, что после события запись не редактировали незаметно?

Эти вопросы отделяют доказательства действия от операционного шума. График загрузки процессора может помочь объяснить тайм-аут, но не подтверждает, отправил ли агент запрос DELETE /customers/42. Стенограмма промптов может объяснить, почему агент считал удаление правильным, но не доказывает, что запрос дошел до удаленного сервиса.

NIST Special Publication 800-92, Guide to Computer Security Log Management, рассматривает управление журналами как жизненный цикл: создание, передача, хранение, анализ и удаление. Ценность этой рекомендации не в магическом сроке хранения. Она настаивает на том, что организация должна определить назначение журналов и учесть хранение, доступ и удаление. Команды, работающие с агентами, часто сразу переходят к сбору, потому что собирать легко. Но именно дисциплина доступа и удаления определяет, помогут записи в дальнейшем или навредят.

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

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

Записи действий нужен контекст, а не стенограмма

Хранение активности AI-агента начинается со схемы события. Собирайте минимальный набор фактов, который позволяет компетентному расследователю восстановить действие и связать его с сессией, не сохраняя учетные данные и не относящийся к делу контент.

Я использую четыре слоя информации.

1. Контекст идентификации и авторизации. Записывайте неизменяемый идентификатор события, отметку времени с часовым поясом, идентификатор процесса агента, путь к исполняемому файлу или идентификатор пакета, центр сертификации кода, если операционная система его предоставляет, идентификатор сессии и идентификатор человека или сервиса, связанный с сессией. Фиксируйте решение об авторизации и использованный режим согласования.
2. Запрошенное действие. Записывайте канал, хост назначения, порт, если он важен, HTTP-метод и нормализованный маршрут либо класс SSH-команды, псевдоним учетных данных или внутреннюю ссылку и безопасное описание операции.
3. Наблюдаемый результат. Записывайте успех, отказ, отмену, тайм-аут, ошибку транспорта, код состояния удаленного сервиса, если применимо, классификацию ответа, объем отправленных и полученных данных, если это важно, и отредактированное резюме ошибки.
4. Связи доказательств. Записывайте хеш предыдущей записи, хеш текущей записи, версию схемы и идентификаторы, связывающие попытки, повторы и последующие действия.

Различие между назначением и запросом имеет значение. api.example.internal это назначение. PATCH /v1/users/42 это действие. Журнал, в котором есть только хост, не отличит запрос списка учетных данных от блокировки аккаунта. Журнал, где хранится только путь, может не указать целевую среду, а именно она часто отличает безопасный тест от инцидента.

Нормализуйте данные до сохранения. Помещайте переменные идентификаторы в структурированное поле, чтобы расследователям не приходилось разбирать свободный текст. Записывайте route_template: "/v1/users/{user_id}" рядом с защищенным полем target_identifier, если идентификатор важен. Для SSH различайте команду, отправленную агентом, и удаленную команду после раскрытия оболочкой, если ваш путь выполнения позволяет наблюдать обе. Не заявляйте о том, чего вы не знаете наверняка.

Практическая JSON-запись может выглядеть так:

{
  "event_id": "01J8...",
  "occurred_at": "2025-03-08T14:22:31.482Z",
  "session_id": "ses_7f...",
  "actor": {
    "process_id": 18422,
    "signing_authority": "Developer ID Application: Example Developer"
  },
  "authorization": {
    "decision": "approved",
    "mode": "session"
  },
  "action": {
    "channel": "http",
    "destination": "billing.internal:443",
    "operation": "POST /v2/invoices/{invoice_id}/void",
    "credential_ref": "billing-production"
  },
  "outcome": {
    "status": "remote_rejected",
    "http_status": 403,
    "error_class": "authorization"
  },
  "previous_hash": "...",
  "record_hash": "..."
}

В этой записи нет bearer-токена, заголовка авторизации или тела счета. Но она сообщает расследователю, что конкретный подписанный процесс в рамках определенной одобренной сессии попытался аннулировать счет в рабочей среде через указанную ссылку на учетные данные и получил ответ 403.

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

Храните классы доказательств разные сроки

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

Используйте классы, соответствующие реальной работе расследования. Практичным начальным набором могут быть:

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

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

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

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

Определяйте срок по обнаружению и реагированию, а не по цене хранения

Выбирайте срок, двигаясь назад от последнего момента, когда вы еще рассчитываете расследовать событие. Расчет не выглядит изящно, зато делает предположения видимыми.

Для каждого класса записей сложите:

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

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

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

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

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

Доказательство неизменности требует отдельной границы доверия

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

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

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

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

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

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

$ audit verify activity.log
records_checked: 18427
chain_status: valid
first_error: none
checkpoint_status: matched

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

Правдоподобный сбой показывает, что скрывают скудные журналы

Представим агента для программирования, которому разрешили задачу в среде разработки, а позже он пытается выполнить HTTP-вызов к платежному сервису в рабочей среде. Шлюз действий отклоняет вызов, потому что авторизация сессии относится к другому процессу, чем тот, который отправляет запрос. Через несколько минут разработчик повторяет попытку из другого запуска агента и одобряет ее, не заметив рабочее назначение.

Удаленный сервис возвращает ответ 200. В стенограмме чата агента сказано только, что он «решил проблему со счетом». Команда узнает о жалобе клиента через три недели.

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

С полезной записью расследователь может восстановить последовательность:

1. Подписанный процесс запустил сессию и получил согласование, связанное с этим запуском.
2. Процесс с другим идентификатором попытался выполнить операцию в рабочей среде и получил отказ.
3. В более поздней сессии использовалась конкретная ссылка на учетные данные, был выбран рабочий хост, запрошено аннулирование счета по защищенному идентификатору и получен результат 200.
4. Целостность цепочки подтверждается контрольной точкой, созданной до жалобы.

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

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

Редактирование должно происходить до попадания записи в журнал

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

Создайте список разрешенных полей для каждого канала. Для HTTP разрешите метод, назначение, шаблон маршрута, отдельные безопасные имена параметров запроса, длину содержимого, статус и класс ошибки. Явно удаляйте Authorization, Cookie, Set-Cookie, API-токены, секреты клиентов и известные чувствительные заголовки. Тела запросов и ответов по умолчанию должны быть запрещены.

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

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

Когда для дела действительно требуется содержимое, создайте узкую копию доказательств с идентификатором дела, именованной группой доступа, сроком окончания и датой проверки. Зафиксируйте наличие копии в журнале действий, но не копируйте ее содержимое во все последующие отчеты. Так обычные расследования останутся полезными, а доступ к наиболее чувствительным материалам получат не все читатели.

Удаление, запреты и исправления должны оставлять собственные доказательства

Хранение это операционный процесс, а не абзац в политике безопасности. График, который никто не проверяет, со временем превращается в случайное вечное хранение или автоматическую очистку во время инцидента.

Выполняйте удаление через записываемую задачу. Для каждого запуска сохраняйте версию политики, класс записей, выбранный диапазон времени, число удаленных записей, число пропущенных из-за запретов, идентификатор исполнителя и результат. Задача удаления должна подчиняться той же дисциплине добавления записей, что и журнал действий. Оператору не должен требоваться прямой доступ к базе данных для «очистки» записей.

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

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

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

Компактную политику проще выполнять, чем идеальный документ

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

Purpose: reconstruct externally executed agent actions and investigate misuse.

Action ledger: retain for [period].
Fields: actor identity, session, authorization decision, destination,
operation, credential reference, protected target identifier, outcome,
integrity fields. Exclude secrets and raw bodies.

Diagnostic detail: retain for [shorter period].
Fields: bounded error text and timing. Apply allowlist and redaction rules.

Protected evidence capture: case-only. Require case identifier, expiry,
access group, and documented approval.

Integrity: append records; verify chain [cadence]; export or compare
checkpoints [cadence]. Record verification failures.

Deletion: execute [cadence]. Record policy version, range, result, and holds.
Holds: suspend deletion for defined selectors. Review [cadence].
Corrections: append a correction record; never overwrite an action record.

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

Sallyport хранит журналы Sessions и Activity, сформированные из одного зашифрованного журнала аудита с хеш-сцеплением, а sp audit verify может проверять эту цепочку офлайн поверх шифротекста. Такая архитектура полезна только в том случае, если команда заранее решит, какие поля должны входить в записи и как с ними работают задачи хранения, запреты и экспорты.

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