Журналы аудита для ИИ-агентов, защищённые от незаметных изменений

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

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

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

Здесь побеждает скучный ответ.

Шлюз действий должен создавать запись во время выполнения HTTP-вызова или SSH-команды, помещать её в упорядоченный журнал и делать последующие изменения заметными. Тогда у расследующего есть артефакт, который не зависит от памяти агента, его промпта или готовности признаться.

Расшифровка разговора и журнал аудита отвечают на разные вопросы

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

Представим, что агент сообщает о запуске terraform apply после открытия SSH-сессии. Этот текст не доказывает, что SSH-соединение установилось, команда достигла нужного хоста или хост её принял. Это могла быть запланированная команда, выведенная до запуска. Она могла завершиться ошибкой на первой строке. Обёртка могла изменить её уже после выполнения.

Полезная запись действия связывает факты из разных уровней:

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

Запись не должна превращаться в слепок всей активности. Более того, постоянно сохранять каждый текст запроса и полный текст ответа часто безрассудно. Deployment API может вернуть токен доступа. SSH-команда может содержать временный секрет в присваивании переменной окружения. Фиксируйте сведения, необходимые для восстановления решения по безопасности, а срок хранения конфиденциальных данных строго ограничивайте.

NIST SP 800-92 рассматривает управление журналами как процесс, включающий создание, хранение, анализ и удаление данных, а не как папку, куда приложения складывают текст. Это старое руководство удивительно хорошо подходит агентам: запись должна происходить у исполнителя, хранилище должно пережить инцидент, а анализ не должен требовать доверия к участнику расследования.

Граница действий сужает область, где можно установить факты. И это хорошо.

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

Защита от незаметных изменений не означает неизменяемость

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

Цепочка хешей создаёт для каждой записи зависимость от предыдущей. Упрощённая запись может выглядеть так:

record_1042 = {
  sequence: 1042,
  run_id: "run_7f3c",
  time: "2026-03-18T14:22:09Z",
  action: "ssh.exec",
  destination: "deploy@release-host",
  result: "exit 0",
  previous_hash: "a4c1...",
  hash: "8d72..."
}

Реализация детерминированно сериализует поля, вычисляет хеш этой сериализации и помещает хеш предыдущей записи в следующую. Измените exit 0 на exit 1, подмените хост или поменяйте местами две записи, и проверка завершится ошибкой с этого места.

Secure Hash Standard от NIST определяет одобренные алгоритмы хеширования, которые создают дайджесты сообщений фиксированной длины. Дайджест не является шифрованием и не является подписью. Это компактная связка, благодаря которой последующая запись зависит от точных предыдущих байтов.

Изменения это обнаруживает. Но не всякий обман.

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

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

Цепочке нужна контрольная точка вне досягаемости автора

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

Есть несколько способов закрепить журнал. Они различаются стоимостью и удобством эксплуатации.

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

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

Certificate Transparency даёт полезную модель мышления. RFC 9162 использует деревья Меркла для журналов только с добавлением, доказательств включения и доказательств согласованности между опубликованными корнями деревьев. В RFC прямо сказано и о сложной части: нечестный журнал может попытаться показывать разным клиентам несовместимые представления.

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

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

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

Шифрование скрывает запись, но не историю

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

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

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

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

Шифрование также заставляет решить, сколько хранить данные. Если после переноса устройства никто не может расшифровать старые записи, доказательство целостности может сохраниться, но журнал потеряет практический смысл. Храните процедуры восстановления и хранения отдельно от формата аудита. Не складывайте секрет расшифровки рядом с зашифрованным архивом, считая задачу решённой.

В macOS аппаратная защита может уменьшить риск раскрытия локальных секретов. Документация Apple по безопасности описывает Secure Enclave как изолированный аппаратный процессор безопасности, а документация Apple для разработчиков отмечает, что описанный в ней механизм Secure Enclave не позволяет переносить материал секретов в открытом виде внутрь или наружу. Это помогает построить локальное хранилище, но не превращает каждый процесс на Mac в доверенный.

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

Сбой обычно начинается до опасной команды

Правдоподобный инцидент с агентом редко начинается с команды, которая выглядит злонамеренной. Обычно всё начинается с обычного запроса, получившего слишком широкие полномочия.

Представим, что агент для программирования получает задачу разобраться со сбоем выкладки. Он читает репозиторий, находит скрипт развёртывания и открывает SSH-канал к хосту релиза. Первая команда безобидна:

systemctl status web.service

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

Где средства контроля могли остановить это или сделать событие заметным?

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

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

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

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

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

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

Идентификатор процесса должен быть частью записи

Записи «Claude Code использовал SSH» недостаточно, чтобы разрешить спор. Нужно знать, какой локальный процесс начал запуск, какие полномочия подписи сообщила операционная система и распространялось ли разрешение на конкретный экземпляр процесса.

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

Журнал должен сохранять стабильный идентификатор запуска и достаточно сведений о происхождении процесса, чтобы позже ответить на такие вопросы:

• Один и тот же процесс сделал первый и последний запрос?
• Пользователь одобрил этот запуск до выполнения вызова?
• Запуск был отозван до прихода следующего запроса?
• Пытался ли другой локальный процесс повторно использовать канал?

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

Цена этого подхода есть. Легитимные сборки для разработки, локальные форки и неподписанные инструменты создадут больше работы для проверяющих. Это не недостаток модели аудита. Это видимая цена доступа экспериментального ПО к реальным учётным данным. Решите, не стоит ли дать таким инструментам отдельные учётные данные с минимальными правами, вместо того чтобы приучать проверяющих игнорировать незнакомые сведения об идентичности.

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

Один журнал для запусков и вызовов создаёт более точную временную шкалу

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

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

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

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

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

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

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

Проверка должна быть регулярной, а не церемониальной

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

Для установки Sallyport первая конкретная проверка выглядит так:

sp audit verify

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

Одной команды недостаточно. Дополните её простой процедурой:

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

Третий пункт важен, потому что локальная целостность и внешняя истина дополняют друг друга. Корректный журнал может показать, что шлюз отправил POST /deployments, а провайдер выкладки покажет, принял ли он операцию, поставил ли её в очередь или отклонил. Код выхода SSH может сообщать о завершении команды оболочки, а журналы служб на хосте покажут, какой процесс действовал после этого.

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

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

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

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

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

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

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

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

Сначала решите, что нужно доказать, а потом выдавайте доступ

Полезный вопрос звучит не так: «Есть ли у нас логи?» Лучше спросить: «Какое утверждение нам понадобится подтвердить, если этот запуск завершится проблемой?»

Для каждого типа учётных данных, которым может воспользоваться агент, сформулируйте утверждение простыми словами. Например: этот подписанный процесс получил разрешение на этот запуск; этот запуск обратился к этому endpoint API; эта SSH-команда прошла через локальный шлюз; эти учётные данные были заблокированы во время отклонённого запроса; эти записи не менялись после сохранённой контрольной точки.

Затем проверьте журнал в неудобном сценарии. Удалите последние 50 строк. Измените поле назначения. Скопируйте журнал на другой Mac. Заблокируйте хранилище и запустите проверку. Отзовите запуск между двумя вызовами. Если вы не можете сказать, какое средство контроля должно остановить событие и какая запись должна его показать, у вас есть наблюдаемость, но нет доказательств.

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

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