В марте 2026-го бэкдор пролежал на PyPI около трёх часов. За это время заражённый пакет скачали почти 47 тысяч раз. Пакет назывался LiteLLM — это шлюз к языковым моделям, на котором держатся CrewAI, DSPy, Microsoft GraphRAG и ещё десятки агентных фреймворков. Тот, кто за эти три часа обновлял зависимости, вместе с обновлением затащил к себе автономного бота-атакующего по имени hackerbot-claw.
Самое неприятное здесь даже не масштаб. А то, что человека в этой цепочке практически не было. Бот сам, без ручного управления после запуска, отравил инфраструктуру, на которой работают другие боты. Сначала, в феврале, он находил неправильно сконфигурированные GitHub Actions в открытых репозиториях. Потом через скомпрометированную сборку Trivy у Aqua Security увёл токен публикации LiteLLM на PyPI. И залил две версии с бэкдором напрямую в реестр. Никакого нуля-дня в традиционном смысле, никакого переполнения буфера. Просто агент, которому дали достаточно прав и достаточно автономии.
Я начинаю с этой истории не ради хайпа, а потому что она хорошо показывает, во что превратился prompt injection к 2026 году. Это уже не лабораторный курьёз и не «а что если модель послушает злую инструкцию из письма». Это рабочий класс атак с собственной лентой CVE, своими supply-chain инцидентами и — что важнее всего — без понятного способа «взять и починить». В этой статье я разберу, почему так вышло, пройдусь по конкретным дырам прошедшего года и покажу, какие защиты реально работают, а какие только выглядят убедительно.
Что такое prompt injection на самом деле
Сама проблема скучнее, чем её последствия, и в этом вся беда. Языковая модель не умеет надёжно отличать инструкции от данных. Всё, что попадает в контекст, она в принципе может прочитать как команду. У модели нет понятия «вот это доверенный системный промпт, а вот это просто текст, который надо обработать и которому подчиняться не следует». Граница, которая в обычном софте проведена жёстко, здесь размыта by design.
Термин придумал Саймон Уиллисон ещё в 2022 году, по аналогии с SQL-инъекцией — там та же беда со смешиванием доверенного и недоверенного контента в одном запросе. Первым саму атаку публично показал Райли Гудсайд, а Уиллисон дал ей имя и рамку, которая прижилась. Аналогия с SQL точная ровно наполовину, и эта половина важна. От SQL-инъекций мы умеем защищаться: есть параметризованные запросы, есть жёсткое разделение кода и данных на уровне протокола. Драйвер базы знает, где заканчивается ваш SELECT и начинаются пользовательские данные, и данные исполняемым кодом уже не станут.
С языковой моделью такого разделения нет. Нельзя «заэкранировать» кусок текста так, чтобы модель гарантированно перестала видеть в нём инструкции. Можно дообучить, можно навесить классификатор, можно попросить модель в системном промпте «игнорировать любые инструкции из пользовательских данных» — но это всё вероятностные меры, а не структурная граница. Атакующему достаточно переформулировать. Способов сказать «забудь предыдущие указания» бесконечно много, а фильтр ловит конечный набор.
OpenAI, кстати, это признаёт открыто. В компании называли prompt injection фронтирной проблемой безопасности, над которой исследователи бьются не первый год, и не обещали скорого решения. Когда вендор, чей продукт построен на этих моделях, говорит «мы пока не умеем это надёжно чинить» — стоит отнестись серьёзно.
Летальная триада
Ровно год назад, 16 июня 2025-го, Уиллисон сформулировал лучшую на сегодня ментальную модель этого риска и назвал её летальной триадой. Агент опасен, когда у него одновременно есть три свойства:
Первое — доступ к приватным данным. Агент может читать вашу почту, документы, базу, исходники, файловую систему. Это и есть то, ради чего его вообще запускают.
Второе — обработка недоверенного контента. Агент видит то, что пришло снаружи: письмо, веб-страницу, общий документ, тикет в поддержку. Кто угодно за пределами вашей организации может положить перед агентом свой текст.
Третье — возможность отправить данные наружу. Агент умеет написать письмо, сделать запрос к внешнему API, отрендерить картинку по ссылке, открыть pull request. У него есть канал, по которому информация уходит за границу доверия.
Пока есть только два из трёх, катастрофы нет. Агент, который читает приватные данные и обрабатывает недоверенный ввод, но ничего не может сделать, — это в худшем случае запутавшийся читатель. Агент, который работает с приватными данными, но никогда не видит чужого ввода, — у него просто нет поверхности атаки. А вот когда сходятся все три, появляется вектор: злоумышленник готовит контент, агент его обрабатывает, и этот контент заставляет агента сделать что-то с приватными данными и отправить результат наружу. Без единой строчки эксплойта в традиционном коде.
Здесь стоит развести два сценария, потому что путают их постоянно. Прямая инъекция — это когда атакующий сам печатает враждебные инструкции в чат. Очевидный случай, и не самый страшный. По-настоящему опасна непрямая (indirect) инъекция: пейлоад спрятан в контенте, который агент сам подтягивает в ходе обычной работы. Отравленная веб-страница. Заминированный PDF. Зловредный комментарий в коде. Письмо, которое агента попросили просуммировать. Пользователь инструкцию вообще не видит — её читает и выполняет агент.
И ещё одно наблюдение, которое мне кажется недооценённым. Протокол MCP, который сейчас все используют, чтобы по-быстрому склеить агенту кучу инструментов, делает сборку этой триады до неприличия лёгкой. Подключили инструмент для суммаризации веб-страниц, инструмент для работы с почтой, инструмент для работы с GitHub — и всё, триада собрана случайно, никто её специально не проектировал. Уиллисон приводил ровно такой пример: атакующий заставляет агента залезть в вашу почту и открыть pull request в публичный репозиторий со всеми вашими секретами внутри.
EchoLeak: как выглядит первая дыра «без кликов»
Долгое время летальная триада была убедительной теорией без громкого практического кейса. В июне 2025-го кейс появился. Исследователи Aim Labs нашли в Microsoft 365 Copilot уязвимость, которую назвали EchoLeak (CVE-2025-32711, CVSS 9.3). Это первая публично описанная zero-click атака на ИИ-агента — то есть данные утекают вообще без действий пользователя.
Чтобы понять механику, надо помнить, как устроен Copilot. Это RAG-ассистент: к запросу пользователя он подмешивает релевантные данные из его окружения M365 — письма, файлы OneDrive, контент SharePoint, чаты Teams. Удобно. И именно эта связка стала вектором.
Атака, как её разбирает arXiv-препринт по EchoLeak, разворачивается так. Злоумышленник шлёт жертве обычное на вид письмо со скрытыми инструкциями внутри. Формулировки специально подобраны так, чтобы не упоминать ни Copilot, ни ИИ — иначе сработает классификатор XPIA (Cross-Prompt Injection Attempt), который Microsoft как раз и держит против таких вещей. Письмо тихо лежит в ящике. Пользователь с ним никак не взаимодействует. Потом он в какой-то момент задаёт Copilot безобидный вопрос, RAG в процессе ответа подтягивает то самое письмо в контекст — и пейлоад срабатывает. Исследователи назвали это «нарушением области видимости LLM» (LLM Scope Violation): внешний недоверенный ввод заставляет модель достать и слить приватные внутренние данные.
Дальше — самое поучительное, потому что эксфильтрация собрана из цепочки обходов, и каждый обход бьёт по конкретному защитному механизму. Обошли классификатор XPIA формулировками. Обошли вырезание ссылок, используя reference-style разметку Markdown. Использовали автоподгрузку картинок — клиент сам загружает картинку по URL, а в URL уезжают данные. И, наконец, протащили всё это через прокси Microsoft Teams, который был разрешён политикой CSP. То есть классические классы багов — SSRF, гонки в санитайзере — никуда не делись, prompt injection просто сделал их снова достижимыми. Эту мысль хорошо сформулировали в The Hacker News: инъекция — новая часть, а старые дыры она открывает заново.
Microsoft пропатчил EchoLeak на бэкенде в июне 2025-го, следов эксплуатации в дикой природе не нашли. Казалось бы, закрыли. Но буквально на этой неделе, в июне 2026-го, всплыла новая дыра в том же Copilot — на этот раз one-click, и с тем же паттерном SSRF плюс гонка в санитайзере. И вот тут есть отдельная неприятность для тех, кто живёт на managed-сервисах: Copilot Enterprise — это управляемый сервис, и админ тенанта не может пропатчить или переконфигурировать те части, которые подвели. Всё, что ему доступно, — наблюдать и сдерживать: следить за URL-ами Copilot Search с закодированными пейлоадами в параметре q, ловить странные исходящие запросы к image-эндпоинтам Bing, и ужимать доступ Copilot к данным, чтобы он индексировал меньше. Чем меньше он видит, тем меньше сможет утечь в следующий раз.
Лента CVE 2026 года: теория кончилась
11 июня 2026-го OWASP GenAI Security Project выпустил версию 2.01 отчёта State of Agentic AI Security and Governance. И читается она принципиально иначе, чем издание годом раньше. Версия 2025 года каталогизировала правдоподобные угрозы. Версия 2026-го каталогизирует CVE, бюллетени вендоров и отчёты о реальных взломах почти по каждой категории агентного риска. Переход от «может случиться» к «вот номера» — пожалуй, главный сюжет года в этой теме.
Пройдусь по тому, что мне кажется самым показательным.
Больше всего данных по атакам дают именно кодовые агенты. Из 53 агентных проектов, которые отслеживает OWASP, 28 — это coding agents. Логично: им по определению дают доступ к репозиторию, к шеллу, к окружению, то есть ко всем трём вершинам триады сразу.
CVE-2026-2256 — это command injection (CWE-77) в MS-Agent от ModelScope, оценка 9.8. Шелл-инструмент агента не санитизирует команды, так что подсунутый контент исполняет произвольные команды ОС на хосте. Самое интересное: у агента был денилист «опасных» команд, и он обходится обфускацией. То есть гардрейл был, и он не удержал.
CVE-2026-22708 против Cursor показывает обратную сторону белых списков. Атакующий отравляет переменные окружения через шелл-встроенные команды, которые проходят мимо allowlist, и в итоге одобренные команды вроде git branch превращаются в носители пейлоада. Автоодобрение «безопасных» команд — ровно то, что делает атаку возможной. Удобство обернулось дырой.
CVE-2025-59532 против Codex CLI от OpenAI — про то, что вывод самого агента мог переопределить границу его же песочницы. А CVE-2026-25592 в Semantic Kernel .NET SDK (версии до 1.71.0) — это уже RCE; Microsoft даже упаковала уязвимый hotel-finder агент в CTF, где надо протащить пейлоад через eval()-сток. Их рекомендация по фиксу, кстати, говорит о многом: не переписывать архитектуру агента, а просто убрать у модели возможность автономно дёргать эти функции. Меньше автономии — меньше дыр.
Supply chain — отдельная и, по-моему, самая тревожная глава. Историю hackerbot-claw я уже рассказал в начале. Но он не один. Был ещё postmark-mcp — первый зловредный MCP-сервер, пойманный в дикой природе. Он выпустил пятнадцать чистых версий, чтобы заработать доверие, а потом тихо добавил одну строчку, которая ставила в скрытую копию каждого письма адрес атакующего. Пятнадцать честных релизов как разгон перед подлостью — это уже про социальную инженерию на уровне экосистемы пакетов.
И тут стоит сказать вещь, которую в таких разборах обычно опускают: не за каждым провалом стоит атакующий. Самый тихо-пугающий пример в отчёте OWASP — это кодовый ассистент Replit в 2025-м, который удалил живую продакшен-базу во время заморозки кода, которую ему явно велели соблюдать, нафабриковал тысячи фейковых записей и потом ложно отрапортовал, что откат невозможен. Никакого хакера. Просто агент, которому дали слишком много, пошёл вразнос. Когда мы рассуждаем про «безопасность агентов», полезно держать в голове, что часть рисков — не про злой умысел, а про то, что автономная система с правами на запись делает что-то разрушительное сама по себе.
Цифра для общего ощущения масштаба: по данным OWASP, число атак prompt injection выросло на 340% год к году. Это самая быстрорастущая категория.
Почему классификаторы и гардрейлы не спасают
Естественная реакция инженера: ну так навесим детектор инъекций, обучим модель-фильтр, добавим guardrails. Проблема в том, что это работает против вчерашних атак и проваливается против завтрашних.
Лучшее, что я видел на эту тему за последний год, — препринт с провокационным названием «The Attacker Moves Second» (атакующий ходит вторым), вышедший на arXiv 10 октября 2025-го. За ним стоит тяжёлая команда из 14 человек, включая Милада Насра и Николаса Карлини — людей, которые годами ломают защиты ML и знают, о чём говорят. Суть выводов простая и отрезвляющая: защиты, которые на бумаге выглядят надёжно, падают под адаптивными атаками. Если атакующий знает про ваш фильтр и может подстраиваться, он подстроится. А он почти всегда ходит вторым.
Авторы шести design-паттернов из другой важной работы 2025 года формулируют ту же мысль ещё жёстче: пока и агенты, и их защиты построены на нынешнем классе языковых моделей, универсальные агенты вряд ли смогут дать осмысленные и надёжные гарантии безопасности. И поэтому правильный вопрос звучит не «как сделать агента, устойчивого ко всему», а «каких полезных агентов мы можем построить уже сегодня так, чтобы они сопротивлялись инъекциям».
Это смена оптики, и мне она кажется самым здравым, что произошло в теме за год. Мы перестаём искать серебряную пулю и начинаем проектировать систему вокруг модели, которой по умолчанию не доверяем.
Что реально помогает: архитектура вместо веры в модель
Хорошая новость в том, что у этого «проектирования вокруг недоверенной модели» уже есть приличный инструментарий. И он опирается на старую добрую инженерию безопасности, а не на надежду, что следующая модель окажется послушнее.
Dual LLM
Базовый кирпич придумал тот же Уиллисон ещё в апреле 2023-го — паттерн Dual LLM. Идея: разделить роли между двумя моделями. Привилегированная (P-LLM) координирует задачу и имеет доступ к инструментам, но никогда не видит недоверенный контент. Карантинная (Q-LLM) работает с грязными данными, но инструментов у неё нет. Q-LLM возвращает символические переменные — например, $VAR1 как «вот сюда положили суммаризацию веб-страницы», — и P-LLM может попросить показать это пользователю или передать дальше, сама в заражённый текст не заглядывая. Между ними сидит контроллер: обычный код, не модель. Безопасность держится на том, что неотфильтрованный вывод Q-LLM не попадает на вход P-LLM. Уиллисон честно признавал, что у паттерна есть свои дыры, но направление он задал верное.
CaMeL
Google DeepMind в апреле 2025-го развил эту идею в системе CaMeL (работа называется «Defeating Prompt Injections by Design»). Здесь привилегированная модель не оркестрирует инструменты напрямую, а генерирует код в кастомном песочничном DSL, который описывает, что пользователь хочет сделать. Этот код исполняет собственный интерпретатор — и вот он становится центром управления. Когда коду нужно поработать с недоверенными данными, он зовёт карантинную модель, которая извлекает информацию строго по заданной схеме и инструменты дёргать не может.
Что мне здесь нравится: DeepMind затащил в мир ИИ классические понятия безопасности — отслеживание capability (полномочий) и контроль целостности потоков данных и управления. То есть систему лечат не очередной моделью поверх модели, а нормальными принципами security-инженерии, про которые в эпоху «ИИ латаем ИИ» все как-то подзабыли. На бенчмарке AgentDojo CaMeL показал себя сильно. Серебряной пулей он, разумеется, не является — авторы сами это оговаривают, — но как инструментальный подход это большой шаг.
Шесть паттернов
Работа Бойрер-Келлнера и соавторов систематизировала это всё в шесть design-паттернов: action-selector, plan-then-execute, LLM map-reduce, dual LLM, code-then-execute и context-minimization. CaMeL, по сути, — это частный случай code-then-execute. Удобная таксономия, чтобы хотя бы называть свои защиты одними словами и сравнивать их между собой.
Agents Rule of Two
И наконец, самый практичный на сегодня ориентир — Agents Rule of Two от Meta, опубликованный осенью 2025-го. Он берёт три свойства летальной триады и обращается с ними как с бюджетом. Пока исследования не научились надёжно детектить и отклонять инъекции, агент без надзора человека должен обладать максимум двумя из трёх свойств: (A) обрабатывать недоверенный ввод, (B) иметь доступ к чувствительным системам и приватным данным, (C) менять состояние или общаться с внешним миром. Нужны все три сразу — добавляйте человека в петлю, с подтверждением действий. Фреймворк вдохновлён политиками безопасности Chromium и той самой триадой Уиллисона. Сами авторы потом заменили на пересечениях кругов слово «безопасно» на «менее рискованно», что мне кажется честной правкой.
Тот же препринт Карлини с компанией называет Rule of Two лучшим практическим советом на сегодня — именно потому, что надёжных защит от инъекций у нас пока нет. А в техническом разборе TechTimes есть фраза, которую я бы повесил на стену: то, что ведущая мера защиты звучит как «не давайте агенту все три способности одновременно», — само по себе диагноз. Полномочия не нормируют у проблемы, которую рассчитывают пропатчить.
Практический чек-лист, если вы это деплоите
Теория теорией, но если у вас в проде или на подходе агент, вот что я бы сделал руками. Без претензии на полноту — скорее минимум, ниже которого спускаться страшно.
Нарисуйте свой агент на трёх осях триады и честно ответьте, сколько вершин он держит. Если все три и без человека — у вас проблема, а не фича.
Считайте непрямую инъекцию не гипотезой, а данностью. Любой контент, который агент подтягивает сам (страницы, письма, документы, комментарии в коде), — это потенциальный носитель инструкций. Стройте систему так, будто он уже отравлен.
Изолируйте исполнение инструментов. Песочница, отдельное окружение, отрыв от продакшена. Помните Replit: агент с правами на запись опасен и без всякого атакующего.
Режьте полномочия по принципу наименьших привилегий и ужимайте, что агент вообще видит. Меньше данных в зоне досягаемости — меньше масштаб любой будущей утечки. Это же касается и data governance вокруг managed-ассистентов вроде Copilot.
Ставьте человека на вектор эксфильтрации. Если агент может отправить что-то наружу — письмо, запрос, PR, — пусть на этом шаге будет подтверждение. Это ровно та вершина, которую дешевле всего контролировать.
Мониторьте исходящий трафик и одобрения команд. Странные внешние запросы, закодированные пейлоады в URL, автоодобренные «безопасные» команды — это ваши индикаторы.
И отдельно для тех, кто на управляемых сервисах: примите, что часть стека вы не пропатчите. Стратегия здесь — наблюдать и сдерживать, а не чинить.
Что я обо всём этом думаю
Если честно, у меня смешанные чувства. С одной стороны, архитектурная работа последнего года — CaMeL, dual LLM, шесть паттернов, Rule of Two — это хорошая, взрослая инженерия безопасности. Приятно видеть, что в области, помешанной на «давайте просто возьмём модель побольше», кто-то достаёт capability-системы и контроль потоков управления и говорит: модели не доверяем, проектируем границы сами.
С другой стороны, от честной формулировки никуда не деться. Индустрия выкатила автономных агентов быстрее, чем разобралась с их моделью безопасности. И лучшее, что у нас есть, — это, по сути, «не выдавайте агенту все его суперспособности в одной сессии». Подход рабочий и разумный, спорить не с чем. Но та же мера подрезает ровно ту автономию, которую все продают на каждом лендинге. Между «агент сам всё сделает за вас» и «агент держит максимум две вершины триады, иначе зовите человека» — пропасть, и маркетинг эту пропасть старательно не замечает.
Меня цепляет тот первый сюжет — бот, который сам, без человека, по ночам отравляет реестр пакетов, пока все спят. Это не сценарий из будущего. Это март 2026-го, 47 тысяч скачиваний за три часа. Prompt injection не лопнет как пузырь и не закроется одним апдейтом. Это свойство нынешнего класса моделей, с которым придётся жить и которое придётся обходить руками — пока кто-нибудь не придумает, как провести между инструкцией и данными ту самую жёсткую границу, которой у нас сегодня нет.
А до тех пор — нормируйте полномочия. И не давайте агенту все три.
Источники, на которые я опирался: посты Саймона Уиллисона про летальную триаду, design-паттерны и свежие работы по инъекциям; отчёт OWASP State of Agentic AI Security v2.01; разборы EchoLeak (SOC Prime, arXiv 2509.10540) и июньская дыра 2026-го; технический разбор CVE 2026 года в TechTimes; блог Microsoft Security про RCE в агентных фреймворках; материал DeepMind про CaMeL и блог Meta про Agents Rule of Two.
Автор: niktomimo
