Аудит-логи для песочниц ИИ-агентов: что нужно командам безопасности

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

Почему песочницам ИИ-агентов требуется другой аудит-логинг

Традиционные серверные аудит-логи предполагают, что каждое действие было инициировано человеком или детерминированным процессом приложения. ИИ-агенты ломают это предположение. Один запрос может заставить сессию установить пакеты, записать файлы, выполнить shell-команды, вызвать внешние API и породить подпроцессы — и всё это за секунды, без одобрения человеком отдельных шагов.

Это меняет то, на какие вопросы должен отвечать аудит-лог. Для традиционного сервера вопрос обычно звучит так: «Авторизованный пользователь изменил этот файл?» Для песочницы агента вопросы такие:

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

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

Логи выполнения команд и процессов

Выполнение процессов — категория наивысшего приоритета. Каждая команда, запущенная агентом — напрямую или через подпроцесс оболочки — должна порождать запись в логе, содержащую: имя процесса и полный список аргументов, родительский процесс и PID, пользователя и эффективный UID, рабочий каталог, временну́ю метку с точностью до субсекунды и код возврата.

Без списка аргументов такие команды, как python, curl или bash, почти бессмысленны при посмертной трассировке. Без UID невозможно определить, выполнялся ли агент с повышенными привилегиями. Без цепочки родительских PID нельзя реконструировать вложенные подпроцессы или понять, как была вызвана команда.

Подсистемы аудита Linux, такие как auditd с соответствующими правилами системных вызовов (execve, execveat), могут захватывать это на уровне ядра внутри гостевой microVM. Песочницы на основе контейнеров могут использовать трассировку на основе eBPF или логирование seccomp в качестве альтернативы, хотя каждый подход имеет разные возможности и компромиссы по производительности. Ключевое требование с точки зрения команды безопасности — чтобы лог генерировался ниже уровня приложения — процесс агента, контролирующий собственное логирование, не может быть признан достоверным в отношении своего собственного поведения.

События доступа к файловой системе

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

На практике логирование каждого чтения файла в загруженной песочнице может порождать большой объём. Команды безопасности часто сужают эту область до чувствительных путей — например, любого пути внутри /etc, /root, рабочего каталога агента, расположения файлов с учётными данными и смонтированных секретов. Записи и удаления имеют более высокий приоритет, чем чтения для большинства моделей угроз, но чтения файлов учётных данных или конфигурации всё равно стоит фиксировать.

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

Исходящие сетевые вызовы и логирование эгресса

Логирование эгресса — одна из наиболее часто недооцениваемых областей в развёртываниях песочниц агентов. Многие песочницы логируют, что сетевое соединение было попытано; гораздо меньше логируют, куда оно направлялось, какой протокол использовался и было ли оно успешным.

Полные записи эгресса должны включать: IP-адрес назначения и порт, разрешённое доменное имя (DNS-запрос и ответ), протокол (TCP, UDP, HTTP и т.д.), количество переданных байтов в каждом направлении, процесс, открывший соединение, UID и временну́ю метку.

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

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

События установки пакетов

Установка пакетов — ценная цель аудита, поскольку она изменяет среду выполнения способом, который сохраняется на время сессии и потенциально влияет на последующие операции. Каждое событие установки должно фиксировать: имя менеджера пакетов (pip, npm, apt, cargo и т.д.), имя пакета, запрошенную версию, разрешённую версию, URL источника или реестр, хеш или контрольную сумму пакета, процесс и UID, а также временну́ю метку.

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

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

Вызовы инструментов и результаты

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

Логи вызовов инструментов должны фиксировать: имя инструмента, сводку входных параметров (не полное содержимое, если оно включает секреты или личную информацию пользователя), сводку статуса результата (успех, ошибка, тайм-аут), ID сессии и временну́ю метку.

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

Цель — получить достаточно сигналов для реконструкции последовательности действий агента, не создавая хранилище логов, которое само становится ценной целью.

События жизненного цикла сессии

События жизненного цикла сессии служат основой для всех остальных записей в логе. ID сессии, присутствующий в каждом типе событий, позволяет объединять логи по категориям и отвечать на вопрос «Что произошло в данном конкретном запуске?».

События жизненного цикла для логирования:

Событие	Ключевые поля
Создание сессии	ID сессии, ID пользователя/тенанта, имя шаблона или образа, конфигурация ресурсов, временну́я метка
Запуск сессии	ID сессии, идентификатор хоста, назначенные лимиты ресурсов, временну́я метка
Приостановка сессии	ID сессии, причина (вызов API, тайм-аут, автопауза), временну́я метка
Возобновление сессии	ID сессии, возобновляющий субъект, временну́я метка
Завершение сессии	ID сессии, причина завершения (нормальное, тайм-аут, OOM, вызов API, нарушение политики), статус выхода, временну́я метка
Очистка сессии	ID сессии, состояние файловой системы при очистке (сохранено, удалено, сохранён снимок), временну́я метка

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

События достижения лимитов ресурсов

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

Записи о событиях лимитов ресурсов должны включать: тип лимита (троттлинг CPU, OOM по памяти, квота диска, ограничение скорости сети, тайм-аут), измеренное значение на момент события, установленный лимит, предпринятое действие (троттлинг, убийство, предупреждение), затронутый процесс или сессию и временну́ю метку.

Убийства по OOM особенно заслуживают внимания, поскольку они могут указывать на то, что агент предпринял крупное вычисление, которое не ожидалось, пакет загрузил неожиданно большие данные или произошла утечка памяти. События троттлинга CPU в сессии, которая должна выполнять только лёгкие вызовы LLM, могут указывать на то, что внутри песочницы выполняется что-то ещё.

Структурированные и неструктурированные форматы логов

Неструктурированные логи — строки произвольного текста, такие как 2026-06-29 10:04:00 INFO: process python started — читабельны, но сложны для запросов, агрегации или интеграции с SIEM или конвейером оповещений. Для целей аудита они требуют разбора, который ломается при изменении формата лога.

Структурированные логи — обычно JSON или общая схема, например CEF или OCSF — позволяют индексировать, запрашивать и создавать оповещения по каждому полю напрямую. Структурированное событие execve, включающее {"ts":"2026-06-29T10:04:00.123Z","event":"process.exec","session_id":"...","pid":1234,"ppid":1,"uid":0,"cmd":"curl","args":["-s","https://..."],"exit_code":0}, может быть немедленно запрошено по любому из его полей.

Для команд безопасности, оценивающих поставщика песочниц, ключевые вопросы таковы:

• Являются ли логи структурированными или неструктурированными?
• Какая схема или формат используется и документирован ли он?
• Можно ли передавать логи в реальном времени во внешнюю SIEM или систему агрегации логов?
• Какова задержка между событием и его появлением в потоке логов?

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

Целостность логов и защита от подделки

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

На уровне реализации это обычно означает:

• Генерация логов на уровне ядра (подсистема аудита, eBPF), а не на уровне приложения внутри песочницы
• Отправка логов во внешнее назначение, недоступное процессу песочницы
• Хранилище логов с однократной записью или только добавлением, без возможности удаления, доступного из сети песочницы
• Записи логов, подписанные или снабжённые контрольной суммой при генерации, чтобы подделка или усечение были обнаружимы задним числом

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

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

Политика хранения аудит-логов для песочниц ИИ-агентов

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

Практические отправные точки для оценки командами безопасности:

Вариант использования	Рекомендуемый минимальный срок хранения
Активное расследование инцидентов	Горячее хранение с возможностью запросов не менее 90 дней
Посмертная криминалистика	Доступно в холодном хранилище 12–24 месяца
Проверка соответствия (SOC 2, ISO 27001)	Согласно требованиям соответствующей системы
Юридическая блокировка	До явного снятия блокировки

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

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

Предоставление логов для реагирования на инциденты

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

• Что делала сессия X между временем T1 и T2?
• Какие сессии обращались к пути P?
• Какие сессии выполняли исходящие соединения к домену D?
• Какие сессии устанавливали пакет V?
• Какие сессии завершились с причиной R?

Для этого требуется интерфейс запросов — либо интеграция с SIEM, платформа аналитики логов, либо API, предоставляемый поставщиком, — где ID сессии, тип события, диапазон времени, путь, домен и другие ключевые поля индексируются и доступны для поиска.

Оповещение по определённым паттернам — второй уровень. Приоритетные сигналы для песочниц ИИ-агентов включают: выполнение известных опасных команд (curl | bash, wget -O - | sh, base64 -d | sh), исходящие соединения с неожиданными или недавно зарегистрированными доменами, установку пакетов из URL, не являющихся реестром, запись в пути файлов учётных данных, сессии, завершившиеся с нарушением политики или убийством по OOM, а также любые события, происходящие под UID 0, когда агент не должен выполняться от root.

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

Что спросить у поставщика песочницы

При оценке песочницы ИИ-агента с точки зрения покрытия аудит-логов вот конкретные вопросы, которые стоит задать поставщику:

1. Какие категории событий логируются по умолчанию, а что требует настройки?
2. Генерируются ли логи на уровне ядра/гипервизора или внутри процесса песочницы?
3. Какой структурированный формат логов используется и публично ли документирована схема?
4. Можно ли передавать логи в реальном времени во внешнее назначение?
5. Какова политика хранения данных и может ли она быть расширена?
6. Есть ли у процесса песочницы какой-либо способ изменить или подавить собственные записи в логе?
7. Подписаны ли записи логов или иным образом защищены от подделки?
8. Доступен ли API запросов или интеграция с SIEM?
9. Существуют ли предварительно созданные правила обнаружения или шаблоны оповещений для распространённых угроз в песочницах?

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

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

Заключение

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

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

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

Часто задаваемые вопросы

Какие события должны фиксировать аудит-логи песочниц ИИ-агентов?

Как минимум: выполнение команд и процессов (с полными списками аргументов), чтение/запись/удаление файлов, исходящие сетевые соединения и DNS-запросы, события установки пакетов с URL и хешами источников, вызовы инструментов и статус результатов, события жизненного цикла сессии (создание, приостановка, возобновление, завершение, очистка), а также события достижения лимитов ресурсов (троттлинг CPU, OOM-убийство, тайм-аут). Отсутствие любой из этих категорий оставляет слепые зоны, которые невозможно восстановить задним числом.

Почему я не могу полагаться на логирование на уровне приложения внутри песочницы?

Процесс агента, контролирующий собственное логирование, может подавлять или изменять записи о собственном поведении — намеренно или из-за ошибки. Сбор на уровне ядра (через auditd, eBPF или инструментарий гипервизора) генерирует записи логов ниже уровня приложения, куда у агента нет доступа на запись. Это требование защиты от подделки: лог должен генерироваться в месте, недоступном агенту.

Как долго следует хранить аудит-логи песочниц ИИ-агентов?

Практический базовый уровень: 90 дней в горячем хранилище с возможностью запросов для активного расследования, 12–24 месяца в холодном хранилище для посмертной криминалистики. Системы соответствия, такие как SOC 2 и ISO 27001, имеют свои собственные требования, которые могут иметь приоритет над этими базовыми уровнями. Для юридических блокировок хранение должно продолжаться до явного снятия блокировки юридическим отделом.

В чём разница между структурированными и неструктурированными аудит-логами?

Неструктурированные логи — это строки произвольного текста, требующие разбора для выполнения запросов. Структурированные логи используют согласованную схему (JSON, CEF, OCSF), где каждое поле индексируется и может быть непосредственно запрошено. Для операций безопасности структурированные логи значительно проще интегрировать с платформами SIEM, писать правила обнаружения и выполнять запросы при реагировании на инциденты.

Может ли ИИ-агент подделать собственные аудит-логи?

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

На что следует обратить внимание в документации по аудит-логам поставщика песочницы?

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

Рекомендуемые статьи

• Firecracker для песочниц ИИ-агентов: преимущества, ограничения и вопросы для оценки
• Песочница для кода, созданного ИИ: требования для производственных приложений
• Создание агента для написания кода с помощью Novita Agent Sandbox