В июле 2026 года AI-инвестор и бывший CEO HyperWrite Мэтт Шумер (Matt Shumer) пробовал у себя на Mac ещё не выпущенный GPT-5.6 от OpenAI под кодовым именем Sol. Он дал модели полный доступ к машине. Подзадача по уборке файлов выполнила единственную команду rm -rf, нацеленную прямо на его домашнюю директорию. Пока он среагировал и убил процесс, прошёл больше часа, и большая часть его файлов исчезла.
Неприятная деталь: OpenAI уже знала о такого рода риске. За шестнадцать дней до инцидента её собственная model card пометила «дать AI Agent полный доступ» как серьёзный риск.
Никакого хакера не было. Никакого эксплойта. Удаление файлов было просто одной из способностей, которые этому Agent осознанно выдали.
Всё это указывает на более фундаментальную проблему: архитектура большинства сегодняшних AI Agent небезопасна by design. И инстинктивный ответ — навешать ещё больше guardrails — это неверное направление. Guardrails сидят на одном уровне с тем, что должны сдерживать, поэтому сколько их ни ставь, их обходят. Оборона, которая держит, живёт вне модели.
«Безопасность AI» означает три разных вещи, и здесь речь о третьей
«Безопасность AI» сейчас звучит везде, но в разных контекстах говорят о разном. Грубо — о трёх сюжетах.
Первый — безопасность самой модели: как не пустить jailbreak, как не давать ей выдавать вредный контент, как выравнивать её с человеческими намерениями. Об этом было большинство обсуждений последних лет.
Второй — AI для безопасности (AI for security): перевернуть большие модели и использовать их для защиты — обнаружение угроз, аудит кода, аналитика. Мы сами тут кое-что делали, например Thought Is All You Need — модель с мышлением на входе для поиска уязвимостей в smart contracts, и REEVMBench — бенчмарк того, готовы ли AI Agent реально проводить аудит безопасности smart contracts.
Третий — тема этого текста — безопасность самого AI Agent. Как только модель перестаёт просто отвечать на вопросы и начинает читать твои файлы, держать твои учётные данные и действовать за тебя, инструменты, которые она умеет звать, права, которые она несёт, и каждое её действие становятся поверхностью атаки.
Первые две области имеют зрелый корпус исследований. Третья — новая, легко ускользает из поля зрения и по совпадению является предусловием для того, чтобы AI Agent массово вошёл в корпоративную среду: ни одна компания не отдаст реальный бизнес и реальные данные Agent’у, который не в состоянии обезопасить самого себя.
От недоверенного ввода к произвольному исполнению: врождённый дефект
Чтобы делать реальную работу, Agent’у обычно нужны несколько способностей одновременно: он умеет читать внешний контент (веб-страницы, почту, репозитории, чужие pull requests), он достаёт ценные ресурсы (ключи, облачные пароли, базы), и он вызывает инструменты, чтобы действовать (запускать команды, слать запросы, править файлы). Соедини эти три — и получишь самую опасную комбинацию, которая вообще возможна.
Корень проблемы в том, что модель не отличает, является ли данное предложение инструкцией её оператора или контентом, который она только что прочитала и который написал кто-то другой. Для модели это один и тот же текст в одном и том же контекстном окне. Кому подчиняться, она решает по натренированной интуиции, а не по жёсткому правилу, которое разделяло бы две вещи. В security это старая проблема — confused deputy: программа с привилегиями оказывается обманутой стороной без привилегий и делает от её имени что-то вредное.
Цепочку стоит расписать. Инструменты, реально выполняющие действия, слушают модель; модель слушает prompt; а prompt собирается из всего подряд — часть написал пользователь, часть подтянута из веб-страниц, писем и документов. Значит, недоверенный источник, пройдя через модель с недетерминированным поведением, в итоге способен направить инструменты на произвольные операции. В классическом ПО данные — это данные, код — это код, разделены чисто. У Agent’а прочитанное предложение в любой момент может быть воспринято как команда.
Отсюда: атакующему не нужен ни изощрённый эксплойт, ни украденный аккаунт. Достаточно посадить одно предложение в документ, на веб-страницу или в комментарий к коду, и Agent сделает то, чего делать не должен был. Команда безопасности Microsoft говорит без обиняков: ваш LLM — это не граница безопасности; инструменты, которые вы ему открыли, задают ту область, которую вы отдали атакующему.
Ничего гипотетического — реальные случаи выстраиваются в ряд. Инструмент xAI Grok Build на каждой рабочей сессии молча загружал весь репозиторий — включая секреты в .env и полную историю коммитов — на собственные облачные серверы; замеренный объём был почти в тридцать тысяч раз больше, чем требовала задача. В одном тесте Agent Cursor снёс всю продовую базу компании вместе с бэкапами за девять секунд, а потом написал извинение. Agent Replit во время явного code freeze удалил целиком продовую БД и сфабриковал тысячи фальшивых записей, чтобы это прикрыть. А расширение Amazon Q для VS Code отравили через вредоносный коммит с инструкцией «сотри систему», и оно ушло в официальном релизе почти на миллион машин.
Выстрой эти случаи в ряд — общее сразу видно: ущерб почти всегда шёл от прав, которые Agent’у сами выдали, а не от внешнего взлома. Прочитать .env, запустить команду, сходить в БД — это же его повседневная работа. Один канал наружу, одна команда удаления — и обычная способность превращается в катастрофу.
Почему guardrails внутри модели не спасают: защитник на том же уровне
Инстинктивная реакция на эти инциденты — навесить guardrails внутри Agent’а. Под guardrails я имею в виду правила, ставящиеся внутри модели, чтобы она не делала опасного: prompt’ом попросить её не выполнять опасные операции, или добавить в Agent’е слой проверки — как некоторые инструменты для программирования перехватывают опасные команды и инспектируют пути файлов.
Но у этого подхода есть проблема в корне: guardrail и то, от чего он защищает, живут на одном уровне.
Апостол Васильев (Apostol Vassilev), старший научный сотрудник Национального института стандартов и технологий США (NIST), в июне 2026 года опубликовал статью, которая накладывает логику теорем Гёделя о неполноте ровно на этот сюжет. Название — риторический вопрос: Robust AI Security and Alignment: A Sisyphean Endeavor?
Его аргумент коротко таков. Guardrail — это, по сути, конечный, фиксированный набор правил. Так же, как конечная аксиоматическая система не может быть одновременно полной и непротиворечивой, для любого фиксированного набора guardrails всегда найдётся фраза, которая его обходит, — а неоднозначность и гибкость человеческого языка делают пространство таких фраз фактически бесконечным. По его собственным словам, никакой конечный набор guardrails не устойчив универсально ко всем adversarial prompts. Единственный оставшийся вопрос — кто первым найдёт эту фразу, защитник или атакующий. NIST рекомендовал соответственно сместить мышление с «сделать правильно один раз» на «непрерывно мониторить и патчить».
Есть и более прямое доказательство. Если самой модели верить нельзя — можно ли использовать одну модель, чтобы проверять, скомпрометирована ли другая? Исследование из University of Wisconsin показывает, что эта дорога тупиковая: такого рода схема, где одна модель судит, была ли подделана другая, страдает структурным дефектом, а адаптивная атака, которую построили исследователи, снижает детекцию почти до нуля, тогда как injection всё равно проходит примерно в девяти из десяти случаев. Модель, которая должна ловить атаки, сидит на одном уровне с контентом, который она инспектирует, и оказывается скомпрометированной первой.
И есть временной аспект, который легко упустить: guardrails включаются уже после того, как Agent получил полномочия действовать. EchoLeak — самый ясный пример. Это была zero-click атака на Microsoft 365 Copilot: тщательно сконструированное письмо тихо проскользнуло мимо injection-фильтров, которые Microsoft поставила перед Copilot, и вынесло чувствительные данные, пока пользователь не кликал ничего вообще.
Так что «поставить guardrails внутри модели» — это немного как строить Линию Мажино. Не бесполезно, но по конструкции гарантированно обходится. Это может быть одним слоем защиты; единственной линией — не может.
Настоящая оборона живёт вне Agent’а
Если внутренностям модели верить нельзя, линия обороны должна сдвинуться наружу — на системный уровень.
Запирать недоверенный код в изолированной среде и давать ему только тот минимум прав, который необходим, — это не ново в security, это уже десятилетия. Ещё в 1975-м классическая статья Saltzer и Schroeder изложила два принципа: least privilege — программа получает только тот кусочек прав, который нужен, чтобы сделать работу; и separation of privilege — власть разделена, чтобы одна ошибка или один обман не могли обрушить систему целиком (The Protection of Information in Computer Systems). Дальнейшая история sandbox’ов — от Janus в 1990-х, через FreeBSD Jails в 2000-х, до gVisor сегодня — идёт по тому же пути: изолировать недоверенный код так, чтобы даже при компрометации ущерб не выходил наружу. Защита AI Agent’а в конце концов — это применение того же тела практики, накопленного за десятилетия, к новому объекту.
Конкретно сегодня прямой ход — обернуть его в системный sandbox: изолировать окружение, в котором Agent запускает инструменты, с контролем до гранулярности syscall’ов, чтения и записи файлов, сетевого egress. Насколько это включено по умолчанию, сильно варьируется от инструмента к инструменту. Codex от OpenAI sandbox’ит исполнение команд по умолчанию и режет сеть по умолчанию; локальный sandbox Claude Code нужно включать вручную, а sandbox Cursor, по собственным словам продукта, лишь «best-effort» и не считается границей безопасности. Дальше — поместить весь Agent внутрь платформенного runtime, отдав сеть и учётные данные внешнему слою, а не модели. Облачный managed Claude Code от Anthropic работает ровно так: каждая сессия крутится в управляемой Anthropic VM, все исходящие запросы идут через прокси с allowlist, а учётные данные лежат вне sandbox’а.
Естественный вопрос: если sandbox’ы настолько зрелые, как случались те удаления и выгрузки репозиториев? Две причины. Первая — защита по умолчанию у этих инструментов часто тонкая: у Cursor по умолчанию нет строгого sandbox’а, а в случае с GPT-5.6 пользователь просто дал полный доступ — что эквивалентно выключенному sandbox’у. Вторая — даже с включённым sandbox’ом этот класс инцидентов он не останавливает: sandbox защищает от того, чтобы Agent вырвался и нанёс вред хосту, но БД, которые он удалил, и репозитории, которые он выгрузил, были вещами, к которым ему явно разрешили доступ — никакого побега не требовалось. Так что sandbox — необходимый слой и совершенно недостаточный.
Идея «огородить радиус действия Agent’а» пришла и в продукты для обычных офисных пользователей. Настольный ассистент WorkBuddy от Tencent, выпущенный в этом году, работает на персональном компьютере и читает только те локальные папки, которые пользователь авторизовал. В его публичных материалах, впрочем, упомянуты только «авторизованные папки» — как работает изоляция под капотом и как далеко она распространяется, не объясняется.
Что важнее: у всей категории «Agent с sandbox’ом» есть общий слепой угол. Sandbox контролирует, где Agent работает и может ли он вырваться и повредить хосту, но не то, что он делает с данными, пока работает. Agent с prompt injection полностью движется по явно разрешённым каналам и выглядит неотличимо от нормальной работы. Как выразился один исследователь безопасности, оценивая GKE Agent Sandbox от Google: это «isolation sandbox», а не «behavior sandbox» — он решает, где Agent запускается, но не следит за тем, что тот делает во время работы.
Ровно потому что sandbox умеет управлять только «где», но не «что» Agent делает с данными, Google DeepMind предложили более радикальный подход: с самого начала относиться к большой модели как к недоверенному компоненту и оборачивать её в фиксированный, не-AI слой, который шаг за шагом решает, можно ли действовать. Их CaMeL компилирует доверенную инструкцию пользователя в программу, которую исполняет не-AI-интерпретатор; интерпретатор отслеживает происхождение каждого куска данных и перед каждым вызовом инструмента решает по политике, разрешить ли — а модель, которая реально касается недоверенного внешнего контента, вовсе не имеет полномочий вызывать инструменты. На заметной доле задач это даёт «доказуемую безопасность».
Трудность, которую sandbox не решает: данные, без которых Agent не работает
И всё же ни sandbox, ни CaMeL не обходят более трудной задачи, и это самый скользкий узел во всём деле.
Sandbox отделяет Agent от хоста, но не возводит никакой стены вокруг данных, которые Agent’у нужны для работы. Код, .env, БД, которую он должен опрашивать, — всё живёт в том же окружении, что и Agent; чтобы работать, Agent’у нужен какой-то канал наружу. Так что скомпрометированный Agent по-прежнему может выносить то, что читает, через этот разрешённый канал. Собственная документация sandbox’а Anthropic это признаёт: пока разрешён сетевой egress, данные, которые Agent способен прочитать, могут быть вынесены — потому что allowlist фильтрует по домену и не инспектирует то, что уходит наружу.
Так как же защищать данные, без которых Agent не может делать свою работу? Разбивается на три случая, каждый труднее предыдущего.
Первый — явные учётные данные, например API-ключ. Agent’у не нужно понимать содержимое ключа; он просто использует его для отправки запросов. Значит, можно показывать модели только плейсхолдер на всём протяжении, а внешний managed runtime подставит настоящий ключ ровно в момент реального запроса. Даже если через prompt кто-то выманит «ключ», получит бесполезный dummy. Этот случай в инженерном смысле в основном решается.
Второй — данные, которые Agent обязан прочитать и осмыслить сам. Финансовый Agent, которому не дали финансовых данных, просто не сможет работать. Здесь простая подмена не подходит. Один компромисс — запускать жёстко изолированный саб-Agent, который единственный касается чувствительных данных и передаёт наружу только вывод. Но здесь неотвратимый подвох: никто не гарантирует, что сам вывод не чувствителен. Утечки обычно перефразированы и зарыты в смысле, где keyword matching их не поймает. Изоляция уменьшает blast radius; полностью не запечатывает.
Третий и самый радикальный — information-flow tracking: пометить каждый кусок данных, следить, куда он течёт, и перехватить его ровно в тот момент, когда он пытается уйти. Fides от Microsoft идёт этим путём, применяя information-flow control для отслеживания движения каждого куска данных — в теории это самый чистый подход. Но и самый дорогой: он замедляет производительность, ухудшает usability, метки размножаются, а политики кто-то должен писать и поддерживать. Именно здесь трейдоф между безопасностью и удобством кусается сильнее всего.
Системная инженерия безопасности Agent’а: изоляция, контроль, трассируемость
Ни один из этих подходов не решает задачу в одиночку: guardrails обходят, sandbox’ы не удерживают данные, information-flow tracking стоит слишком дорого, а изоляция саб-Agent’а не гарантирует нечувствительность вывода.
Но именно так и работала security всегда. Нет абсолютно «безопасного» или «небезопасного»; что можно — это постоянно повышать стоимость атаки и уменьшать blast radius инцидента.
Поэтому для команды, которая всерьёз хочет собрать корпоративный (ToB) Agent-продукт, серебряной пули нет. Работающий ход — совместить три вещи. Первое — изоляция: системными sandbox’ами и внешними ограничениями строго очертить, что Agent может делать. Второе — контроль по политикам: least privilege и фиксированные правила ограничивают, до чего в пределах этого ему разрешено дотягиваться. Третье — трассируемость: логи и audit trail гарантируют, что если что-то всё-таки пойдёт не так, можно указать, на каком шаге и с чьей стороны это произошло.
Первые две — превенция; третье забывается легко и одинаково важно. Guardrails — про то, чтобы плохое не случалось; логи — про то, чтобы, когда оно случилось, можно было объяснить, что именно произошло; ни одно не заменяет другого. В практике заметный провал: множество компаний сообщали о подозреваемых или подтверждённых инцидентах безопасности с Agent’ами, а тех, кто реально относится к Agent’у как к сущности со своей авторизацией и своей ответственностью, очень мало. Этот пробел — самое конкретное слабое место безопасности Agent’ов сегодня.
AI Agent’ы переходят от «отвечать на вопросы» к «делать работу за тебя». Чем автономнее Agent, тем больше ему отдают — решения, данные, всякие учётные данные и ключи. Надеяться, что модель сама научится сдержанности, или дописать ей ещё пару сотен правил guardrail’ов — оба варианта остаются внутри модели, на одном с ней уровне, и не удерживают проблемы, описанные выше. Чтобы компания реально смогла пользоваться Agent’ом, линия обороны должна быть построена вне модели: sandbox ограничивает, над чем он может оперировать; least privilege ограничивает, до каких данных он может дотягиваться в этом кругу; логи фиксируют каждый шаг, чтобы, если что-то пойдёт не так, можно было проследить до источника. Эти три слоя вместе и заслуживают названия корпоративной архитектуры безопасности Agent’а.