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

Исполнительное резюме

В течение нескольких месяцев Pillar Research находила и воспроизводила побеги из песочниц и обходы границ в Cursor, Codex, Gemini CLI и Antigravity. Почти в каждом случае агенту не нужно было напрямую взламывать песочницу. Ему нужно было лишь написать то, что доверенный компонент за пределами песочницы впоследствии запустит, загрузит, просканирует или сочтёт безопасным. В совокупности эти уязвимости показывают, что ИИ-агенты для написания кода меняют модель угроз для конечных точек, и что большинство архитектур песочниц не успевают за этим. Мы публикуем исследование как Неделю побегов из песочниц: один глубокий разбор в день, каждый показывает новый путь пересечения границы.

Результаты группируются в четыре повторяющихся типа отказов:

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

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

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

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

---

Подход Pillar

В Pillar мы смотрим на внедрение ИИ через призму корпоративного риска. Агентные инструменты для написания кода — естественное место для начала, поскольку они концентрируют риск конечных точек в одном рабочем процессе. Они работают там, где исходный код, SSH-ключи, облачные токены, сессии браузера, права на публикацию пакетов и доступ к продакшну часто находятся рядом. Они обрабатывают недоверенные входные данные как рутину: README, issue, документацию, зависимости, комментарии к коду, diff, логи и веб-контент. Они созданы действовать, а не просто отвечать.

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

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

Как агенты убегают из своих песочниц

Общее эмпирическое правило для песочниц: внутри рабочей области разрешено, за пределами рабочей области защищено.

На практике границы песочниц имеют как минимум три уровня:

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

Третий уровень — где живут самые интересные сбои. Современные IDE и CLI полны автоматизации на стороне хоста:

• Расширения Python обнаруживают интерпретаторы
• Интеграции Git сканируют репозитории
• Диспетчеры задач VSCode загружают задачи проекта
• Движки хуков запускают команды жизненного цикла
• Docker Desktop предоставляет мощный локальный сокет

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

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

Серия

Пост	Платформа	Как отказала граница	Статус / Уведомление	Ссылка
Побег из seatbelt с разрешением по умолчанию Antigravity	Antigravity	Профиль Seatbelt в стиле денай-листа macOS оставил доступными функции ОС, которые позволяли выполнение за пределами песочницы.	Определено как Normal Google Applications. Категория уязвимости: «Другие действительные уязвимости безопасности». Мы применили понижение, определив, что проблему сложно эксплуатировать (социальная инженерия или доверие к репозиторию с косвенным внедрением промптов). Отзыв Antigravity: «Этот отчёт был исключительного качества!»	Читать пост
Один Docker-сокет, чтобы править всеми	Codex, Cursor, Gemini CLI	Привилегированный локальный демон стал средой выполнения без песочницы, доступной для иначе ограниченных агентов.	Проблема исправлена, уведомление: GHSA-v4xv-rqh3-w9mc	Читать пост
Песочница позволила мне изменить venv, и что-то другое его запустило	Cursor	Агент изменил интерпретатор virtualenv, который не изолированное в песочнице расширение Python Cursor выполнило во время обнаружения.	Проблема исправлена, уведомление: GHSA-p9g2-cr55-cw9c	Читать пост
Git-директории не обязаны называться .git	Cursor	Косвенность метаданных Git обошла правила песочницы на основе путей, и расширение Git запустило выполнение через fsmonitor.	Проблема исправлена в 3.0.0, ожидается CVE	Читать пост
GitPwned: от разрешённого списка к RCE	Codex CLI	Разрешённый список безопасных команд доверял имени команды без моделирования опасных аргументов и побочных эффектов Git.	Проблема исправлена в v0.95.0, выплачено вознаграждение за уязвимость высокой степени серьёзности, ожидается CVE	Читать пост
Хук уже был в рабочей области	Cursor	Управляемая рабочей областью конфигурация хука .claude превратилась в выполнение команд без песочницы.	Проблема исправлена в 3.0.0, CVE-2026-48124; отслеживается как GHSA-pc9j-3qc2-95wv	Читать пост
Бомба замедленного действия в .vscode: обход Secure Mode Antigravity	Antigravity	Агент записал конфигурацию задачи VSCode, которую хост впоследствии запустил самостоятельно.	Обоснование решения: Normal Google Applications. Категория уязвимости: «Другие действительные уязвимости безопасности» (обход песочницы). Мы применили понижение, определив, что проблему сложно эксплуатировать. Этот отчёт был исключительного качества!	Читать пост

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

Тип отказа 1: Денай-листы проигрывают сложности платформы

Находка Seatbelt в Antigravity — самый чистый пример отказа денай-листа. Профиль песочницы, который начинается с «разрешить по умолчанию», должен помнить каждую опасную операцию, которую предоставляет ОС: каждый локальный сервис, тип монтирования, путь запуска и странное взаимодействие между ними.

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

Тип отказа 2: Конфигурация рабочей области часто является кодом

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

Мы видели это в уязвимостях «Бомба замедленного действия в .vscode: обход Secure Mode Antigravity», «Хук уже был в рабочей области», интерпретаторах virtualenv, конфигурации Git и помощниках fsmonitor.

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

Тип отказа 3: «Безопасные» команды не безопасны по имени

Находка git show в Codex была разрешена, потому что имя выглядело как read-only. Фактический вызов таковым не был.

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

Вопрос политики не в том, «безопасен ли git show?». Он в том: какой именно вызов выполняется, с какими аргументами, в какой директории, с какой конфигурацией и с какими возможными побочными эффектами?

Тип отказа 4: Локальные демоны живут за пределами коробки

Находка с Docker-сокетом — напоминание: изоляция процесса агента не изолирует хост.

Привилегированный локальный демон — это вторая среда выполнения. Если агент может с ним общаться, демон может делать работу, которую самому агенту делать не разрешено. Конечные точки разработчика часто запускают Docker Desktop, менеджеры пакетов, облачные CLI, языковые серверы, демоны сборки, эмуляторы и локальные базы данных. Любой из них может стать мостом доверия.

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

Что команды безопасности должны спрашивать у вендоров инструментов для написания кода

Разговор о покупке не должен останавливаться на «есть ли у него песочница?». Для агентных систем обязательные вопросы включают:

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

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

Подход Pillar

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

• Какие недоверенные входные данные могут достичь модели?
• Что модель может делать напрямую?
• Что агент может записать?
• Какие компоненты читают эти записи?
• Какие из них выполняют код за пределами политики агента?
• Какие средства контроля детерминированы, а какие зависят от поведения модели?
• Где созданный агентом артефакт может стать действием на хосте?

Что касается того, как мы моделируем конечные точки, мы подходим к этому как к набору передач доверия, а не как к единому дереву процессов. Агенты передают работу системам, которые доверяют им в CI, в браузерах, в SaaS-рабочих процессах и на машинах разработчиков.

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

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

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

Как выглядит хорошая модель угроз для агентов

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

Начинайте с «запретить по умолчанию» везде, где используется песочница, а затем:

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

Важно понимать: агентная разработка — это новое поведение конечных точек, а не просто более удобное или новое IDE.

Наша Неделя побегов из песочниц — это история о новом типе программного обеспечения, разрушающем существующее предположение: изолировать вашего агента недостаточно. Нам нужно лучше понимать модели угроз недетерминированного агентного программного обеспечения и правильно его защищать.

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

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

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