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

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

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

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

🔍 Что именно делает песочница для агента

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

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

В публичном разборе защиты Codex выделяются три слоя. Первый слой изолирует среду на уровне операционной системы. Второй проверяет спорные действия. Третий задаёт сетевые правила со списком разрешённых доменов.

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

Что сделать сейчас: составьте перечень файлов, команд, сетевых направлений и API, которые реально нужны агенту. Всё остальное временно запретите.

🧱 Где проходят границы изоляции

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

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

Для более жёсткой границы применяют среды с отдельным уровнем ядра. В материалах о защите агентных систем упоминаются gVisor, Kata и Firecracker. У gVisor ядро работает в пространстве пользователя. Kata и Firecracker используют виртуальную машину.

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

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

🛠️ Какие действия нужно разделить по риску

Одна кнопка «разрешить агенту всё» разрушает смысл песочницы. Политика должна делить действия на три группы. Первая группа разрешена сразу. Вторая требует подтверждения. Третья запрещена всегда.

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

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

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

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

Что сделать сейчас: оформите матрицу «действие — ресурс — решение». Для каждой строки укажите автоматический допуск, подтверждение или запрет.

🔐 Как ограничить файлы, сеть и секреты

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

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

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

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

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

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

📡 Почему лога модели недостаточно

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

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

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

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

Оба слоя нужны вместе. Событие «файл открыт» не объясняет цель операции. Событие «план обновлён» не доказывает, что файл действительно не изменился.

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

📊 Какие события передавать в SOC

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

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

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

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

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

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

⚠️ Как распознать опасное поведение вовремя

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

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

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

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

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

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

🚨 Что делать при срабатывании защиты

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

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

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

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

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

Что сделать сейчас: проведите тест аварийной кнопки в изолированной среде. Убедитесь, что она останавливает процесс, отзывает токены и сохраняет доказательства.

✅ Чек-лист перед запуском агента

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

Затем проверьте сетевые правила. Список направлений должен быть явным. Для каждого домена или API нужна причина доступа. Общий выход в сеть не должен оставаться настройкой по умолчанию.

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

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

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

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

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

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

Что сделать сейчас: пройдите чек-лист на одном тестовом агенте и сохраните результаты. Запуск в рабочей среде начинайте только после проверки каждого пункта.

📚 Читайте также

• Локальный файрвол для кодинг-агентов: защита действий в CI/CD
• ИИ-агент в продакшене: как удержать автоматизацию под контролем
• Как защитить облачные контейнеры от вредных образов и атак на цепочку поставки
• Лицензии на ПО под контролем: как вузам и подрядчикам не потерять права
• Отпечаток не спас: расследование защиты биометрических замков

📖 Термины

AppArmor · Container Security · IAM (Identity and Access Management) · Kubernetes · Безопасность ИИ

🔗 Источники

• SOC для мониторинга ИИ-агентов(2026-09-09 ✓)
• А точно ли вы знаете, чем занят ваш агент в песочнице?(2026-09-16 ✓)
• Как OpenAI ограничивает своего ИИ-агента Codex от опасных действий(2026-09-16 ✓)