А точно ли вы знаете, чем занят ваш агент в песочнице?
Представим типичную ситуацию: агент отработал около получаса и остановился. Команда хочет понять, какие действия он выполнял. Вы открываете журнал - и видите последовательный, убедительный рассказ: агент вызвал инструмент, получил результат, проанализировал данные и выбрал следующий шаг.
Затем вы смотрите метрики платформы. Там отображаются продолжительность работы, количество запросов, объём переданных данных и другие показатели, которые умеет собирать конкретная система.
Однако главный вопрос остаётся без ответа: откуда взялась уверенность в том, что агент действительно делал именно это? Лог отражает не доказанные действия, а описание, созданное той же моделью, чьи действия необходимо проверить. Метрики платформы показывают лишь заранее определённый набор событий. Между рассказом агента и реальностью песочницы может оставаться значительный разрыв.
Почему обычной трассировки недостаточно
Пока агент был обычным чат-ботом с подключённым поиском, проблема выглядела проще. Он формировал ответы и обращался к ограниченному числу сервисов. Но после появления доступа к оболочке, файловой системе, сети и внешним инструментам агент превратился в программу, которая сама выбирает следующий системный вызов.
По сути, в продакшене запускается программная система, способная самостоятельно решать, какое действие выполнить дальше, при этом её объяснение не обязательно совпадает с фактическим поведением.
Сейчас применяются два основных подхода к наблюдению.
Первый - анализ событий на уровне агентского фреймворка. Система фиксирует, какой инструмент был вызван, с какими аргументами и каким оказался результат. Такой метод удобен, недорог и хорошо подходит для отладки штатных сценариев.
Но он видит только те действия, которые прошли через контролируемую инфраструктуру. Если агент напрямую запустил процесс, открыл файл, установил сетевое соединение или обратился к системному интерфейсу в обход фреймворка, в его трассировке это событие может отсутствовать.
Второй подход - наблюдение за системными вызовами извне. Он считается более надёжным: действие проходит через ядро, а значит, теоретически его можно зафиксировать независимо от того, что сообщил сам агент. В современных системах защиты контейнеров для этого часто используются механизмы eBPF, подключённые к ядру хоста.
Именно здесь возникает фундаментальное противоречие.
Где ломается привычная модель
Чтобы наблюдатель на ядре хоста видел действия процесса, этот процесс должен исполняться на том же ядре.
В обычном контейнере это условие выполняется. runc не создаёт отдельную операционную систему: он настраивает пространства имён, cgroups и ограничения доступа, а системные вызовы приложения обрабатывает ядро хоста. Поэтому eBPF-наблюдатель может видеть происходящее внутри контейнера.
Для мультитенантной платформы с агентами разных клиентов такой подход небезопасен. Общее ядро становится общей поверхностью атаки. Уязвимость в ядре или связанной с ним подсистеме может открыть путь к данным соседних арендаторов.
Поэтому применяются изолированные рантаймы. В gVisor значительная часть функций ядра реализована в пользовательском пространстве. В Kata Containers и Firecracker агент запускается внутри виртуальной машины с отдельным ядром Linux. Системный вызов гостевой системы не проходит через ядро хоста в том виде, в котором его ожидают стандартные инструменты наблюдения.
В результате сталкиваются два требования:
- безопасная изоляция предполагает наличие отдельного ядра между агентом и хостом;
- традиционный контроль системных вызовов рассчитан на выполнение нагрузки непосредственно на ядре хоста.
Наблюдаемость перестаёт быть автоматическим свойством инфраструктуры. Её приходится проектировать отдельно.
Что уже удалось стандартизировать
Агентная инфраструктура развивается быстро, и за последние годы в ней сформировались несколько важных стандартов.
MCP описывает взаимодействие агента с инструментами и источниками данных. Он задаёт понятный способ подключения серверов возможностей к клиентам и уже используется в приложениях, IDE и различных агентских оболочках.
OpenTelemetry постепенно становится базой для сбора телеметрии. Для генеративного ИИ разработаны семантические соглашения, включающие спаны операций модели и агента, метрики, события входов и выходов. Их статус ещё может меняться, но экосистема уже активно поддерживает этот подход.
RuntimeClass позволяет выбирать тип исполнения на уровне описания пода. Одно изменение конфигурации может переключить нагрузку с runc на gVisor или Kata, не требуя переделки самого приложения.
Отдельно развиваются специализированные примитивы для агентов. В Kubernetes-проектах появляются ресурсы песочниц с постоянной идентичностью, хранилищем и возможностью приостанавливать работу, а затем продолжать её с того же состояния.
Но все эти технологии решают разные задачи. MCP отвечает за инструменты, OpenTelemetry - за телеметрию, RuntimeClass - за выбор рантайма, а управление песочницей - за её жизненный цикл. Ни один из механизмов сам по себе не формулирует полный контракт: какие фактические действия агент обязан сообщать наружу и как доказать, что сообщение соответствует реальности.
Почему лог агента нельзя считать доказательством
Самоописание полезно для понимания намерений. Оно помогает восстановить цепочку рассуждений, обнаружить ошибку в планировании и понять, почему агент выбрал тот или иной инструмент.
Но намерение и действие - не одно и то же.
Агент может сообщить, что прочитал один файл, хотя процесс получил доступ к нескольким. Он может заявить, что выполнил безопасную команду, хотя внутри скрипта запускались дополнительные операции. Он способен пропустить неудачный вызов, неправильно интерпретировать ответ инструмента или сформировать правдоподобное объяснение уже после выполнения действий.
Поэтому в системе контроля необходимо разделять как минимум три слоя:
1. Намерение - что агент собирался сделать.
2. Команду - какой инструмент или процесс он действительно запустил.
3. Фактический эффект - какие файлы изменились, какие соединения установлены, какие ресурсы были затронуты.
Только сопоставление этих слоёв позволяет выявлять расхождения.
Наблюдаемость должна учитывать тип изоляции
Для контейнера на общем ядре можно собирать события с помощью eBPF, отслеживать процессы, системные вызовы, сетевые подключения и обращения к файлам. В виртуализированной песочнице такой наблюдатель на хосте увидит лишь действия виртуальной машины: запуск, остановку, сетевую активность, операции с виртуальными дисками и другие события уровня гипервизора.
Чтобы получить сведения о процессах внутри гостя, нужны дополнительные механизмы:
- агент наблюдения внутри гостевой системы;
- специализированный монитор, работающий на уровне виртуальной машины;
- журналирование в самой гостевой ОС;
- контрольные снимки файловой системы;
- проксирование сетевого трафика;
- протоколирование команд через управляемый исполнитель.
У каждого варианта есть цена. Внутренний агент повышает полноту данных, но сам становится частью доверенной вычислительной базы. Снимки позволяют обнаружить изменения, однако не всегда показывают последовательность операций. Прокси хорошо контролирует сеть, но не видит локальные действия. Гостевые журналы могут быть изменены самой атакованной системой, если не обеспечить их защищённую доставку.
Что должно входить в минимальный контроль
Практичная архитектура наблюдения за агентом должна фиксировать не только текстовые логи, но и независимые признаки поведения.
К ним относятся:
- запуск и завершение процессов;
- дерево дочерних процессов;
- обращения к файлам и изменения содержимого;
- операции с секретами;
- установление сетевых соединений;
- DNS-запросы;
- изменение прав доступа;
- использование CPU, памяти и дискового пространства;
- обращения к API и внешним инструментам;
- итоговое состояние песочницы.
Особенно важно сохранять идентификаторы, позволяющие связать событие с конкретным агентом, задачей, версией образа и экземпляром песочницы. Без такой корреляции разрозненные журналы быстро превращаются в набор фрагментов, которые невозможно сопоставить.
Политики важнее одного лишь мониторинга
Наблюдение само по себе не предотвращает опасные действия. Оно лишь позволяет узнать о них после факта. Поэтому его необходимо дополнять политиками исполнения.
Для каждого типа агента можно заранее определить:
- разрешённые каталоги;
- допустимые сетевые направления;
- список доступных инструментов;
- лимиты времени и ресурсов;
- правила работы с секретами;
- необходимость подтверждения опасных операций;
- условия немедленной остановки.
В идеале политика должна проверять действие до выполнения, а журнал - подтверждать результат после него. Такая модель ближе к принципу "запретить по умолчанию", чем к пассивному сбору логов.
Как проверять достоверность телеметрии
Доверять журналу можно только в том случае, если понятен его источник и защищённость. Важны несколько свойств.
Во-первых, события должны формироваться независимо от модели. Агент не должен иметь возможности единолично решать, что именно попадёт в аудит.
Во-вторых, записи следует защищать от незаметного изменения: использовать последовательные идентификаторы, временные метки, контроль целостности и отправку в отдельное хранилище.
В-третьих, необходимо проверять полноту. Если система сообщает о вызове инструмента, но не фиксирует созданный процесс, сетевое соединение или изменённый файл, такой журнал нельзя считать достаточным.
Наконец, полезно проводить сверку разных источников: агентской трассировки, данных рантайма, сетевого наблюдения и состояния файловой системы. Несовпадения должны считаться отдельными событиями безопасности, а не просто ошибками форматирования.
Практический вывод
Вопрос "что делал агент?" нельзя решать одним красивым журналом рассуждений и набором метрик платформы. Необходимо различать рассказ агента, события фреймворка и независимые факты на уровне операционной системы или виртуальной машины.
Если агент работает на ядре хоста, наблюдение проще, но слабее изоляция. Если используется отдельное ядро, безопасность выше, однако стандартные инструменты хоста перестают видеть внутренние действия. Значит, телеметрия должна быть встроена в саму модель песочницы и учитывать границы виртуализации.
Надёжная система должна отвечать не только на вопрос "что агент сообщил", но и на вопросы:
- какой процесс реально был запущен;
- какие ресурсы он использовал;
- какие данные прочитал или изменил;
- куда устанавливал соединения;
- какие последствия оставил после завершения;
- совпадает ли это с заявленным планом.
Пока эти ответы не собираются из независимых источников, наблюдение остаётся интерпретацией. А интерпретация, даже убедительная и подробная, ещё не является доказательством.