Уязвимость агента считается по формуле из трёх слагаемых: доступ к приватным данным, недоверенный текст на входе, канал отправки наружу. Пока есть все три, агента можно заставить украсть у вас же, и сделать это не взломом, а письмом. Уберите любое слагаемое — и целый класс атак перестаёт работать. Это формулировка Саймона Уиллисона, которую в русскоязычных обзорах называют «смертельной триадой», и она объясняет большинство инцидентов 2025–2026 годов.
Дальше — какие атаки реально случились, через что они шли, и что из этого следует для компании, которая заказывает агента, а не пишет его сама. Если вы ещё выбираете, нужен ли агент вообще, — сначала разбор рисков внедрения ИИ: там про деньги и процессы, здесь про безопасность.
Почему агента атакуют иначе, чем сайт
Сайт ломают через уязвимость в коде. Агента ломают через текст, потому что модель не умеет отличать данные от команды. Письмо, страница, комментарий в файле, описание встречи — для модели это всё одинаковые токены, и если среди них есть инструкция, написанная убедительно, модель её выполнит. Не потому что «взломана», а потому что так устроена.
Anti-Malware.ru формулирует это точно: «главная уязвимость языковых моделей в том, что они неспособны отличить легитимную команду от инструкции, зашитой в сырых данных» (обзор атак через письма, сайты и календари, проверено 07.09.2026). Там же цифры масштаба: по данным Google, с ноября 2025 по февраль 2026 года доля вредоносных инъекций в веб-контенте выросла на 32%; OWASP второй год подряд держит инъекцию промпта на первом месте среди угроз для приложений на языковых моделях.
Второе отличие — права. Обычная программа делает то, что в ней написано. Агент делает то, что умеет, по любой просьбе, которая выглядит как задача. «Лаборатория Касперского» в разборе инцидентов называет три причины, почему это трудно ловить: широкие права доступа, тысячи способов сформулировать просьбу и невозможность отличить аномальное поведение агента от нормального — он по определению читает файлы, запускает сценарии и ходит в сеть (блог Касперского об атаках через агентов, проверено 07.09.2026).
Через что атакуют: разбор по каналам
Ниже — реальные случаи из двух обзоров, сгруппированные по каналу входа. Даты и названия приведены так, как они опубликованы; оценивать, насколько каждый случай применим к вашему агенту, лучше по каналу, а не по громкости названия.
Почта
EchoLeak (CVE-2025-32711) — уязвимость в Microsoft 365 Copilot, исправленная в мае 2025 года: письмо с инструкцией, оформленной как сообщение для человека, а не команда для ИИ, обходило фильтры и приводило к утечке без единого клика пользователя. Reprompt, найденный Varonis в январе 2026 года, обходил защиту Copilot Personal командой повторять каждое действие дважды. Вывод для вашего агента: если он читает входящую почту, содержимое писем — недоверенный контент, и оно не должно попадать в один блок с системными инструкциями.
Календарь
Инструкция в описании события. По запросу «что у меня в расписании» агент загружает все события, включая вредоносное, и следует ему. SafeBreach в августе 2025 года показала на Gemini в Google Workspace рассылку спама и фишинга через календарь, а 73% найденных вариантов отнесла к высокому или критическому риску. Вывод: агент не добавляет встречи из внешних приглашений сам и не меняет календарь без явной команды.
Сайты, формы и логи
Команда прячется в метаданных страницы, скрытых комментариях, служебных атрибутах. GrafanaGhost в апреле 2026 года: несуществующие параметры в адресе записывались в логи, а ИИ-помощник обрабатывал их как данные. ForcedLeak в агенте Salesforce: в поле веб-формы для сбора лидов вставляли до 42 000 символов инструкции, и когда сотрудник спрашивал агента об этом лиде, инструкция выполнялась. Вывод: любая форма на вашем сайте, которую потом читает агент, — канал атаки, и её содержимое чистится до того, как попасть в промпт.
Подключённые инструменты и MCP
Здесь два механизма. Первый — инструкция в описании инструмента, которое агент читает, чтобы решить, когда его вызывать: Microsoft описывает финансового агента, который после изменения описания стороннего сервиса начал прикладывать к ответам сведения о неоплаченных счетах. Второй — исследование AgentJacking: через ложное сообщение об ошибке в Sentry, оформленное как данные MCP-сервера, агентов заставляли ставить сторонний пакет; исследователи получили обращения от агентов из множества организаций. Вывод: реестр разрешённых инструментов с фиксацией версий и повторная проверка после каждого обновления.
Кодинг-агенты на компьютере разработчика
Самый массовый случай — компрометация пакетов Nx в августе 2025 года. Заражённый сценарий установки проверял, стоит ли на машине Claude Code, Gemini CLI или Amazon Q CLI, и через найденного агента искал кошельки, файлы .env и ключи, выгружая результат в публичные репозитории. Раскрыты тысячи секретов сотен организаций. Атакующие не писали свой инструмент поиска — использовали легитимного агента жертвы, который умел ориентироваться в файлах и понимать, что ценно. Вывод: агент разработчика работает в изоляции, без доступа к секретам, с подтверждением установок и отправок.
Память
Инструкция, однажды попавшая в долговременную память, действует во всех следующих диалогах. Radware в январе 2026 года описала ShadowLeak и ZombieAgent: первая внедряет инструкции через коннекторы к почте и облачному диску, вторая модифицирует уже сохранённые правила. OWASP выделил отравление памяти и контекста в отдельный пункт ASI06 (OWASP Top 10 for Agentic Applications, декабрь 2025, проверено 07.09.2026). Вывод: запись в память — только после проверки, и память диалога отделена от базы знаний.
| Канал | Что делает атакующий | Что закрывает канал |
|---|---|---|
| Почта | инструкция в тексте письма | письма — недоверенный блок, отдельная учётка для почтового агента |
| Календарь | инструкция в описании события | события извне не добавляются сами, изменения только по команде |
| Сайты и формы | инструкция в метаданных, полях форм, логах | очистка входящих данных, агент читает только проверенные источники |
| Инструменты и MCP | инструкция в описании инструмента, ложные данные от сервера | реестр разрешённых инструментов с версиями, повторная проверка при обновлении |
| Компьютер разработчика | заражённый пакет управляет установленным агентом | изоляция, нет доступа к секретам, подтверждение установок |
| Память | инструкция сохраняется как правило | верификация записей, разделение памяти, срок жизни |
| Любой | утечка под видом картинки, предпросмотра, запроса к сети | белый список исходящих адресов на уровне сети |
Последняя строка — общая для всех каналов, и она самая дешёвая. Если агент физически не может отправить данные никуда, кроме вашей CRM и вашего почтового сервера, большинство сценариев выше заканчиваются ничем: инструкция выполнена, а канала утечки нет.
Десять рисков по OWASP простыми словами
OWASP 9 декабря 2025 года выпустил список десяти рисков именно для агентных приложений, отдельно от рисков для чат-ботов. Ниже он переведён на язык владельца бизнеса, потому что в оригинале это термины для инженеров по безопасности.
| Код | Риск | Что это значит для вашего агента |
|---|---|---|
| ASI01 | Подмена цели | агент начинает решать чужую задачу вместо вашей |
| ASI02 | Злоупотребление инструментами | инструмент вызывается не для того и не с теми параметрами |
| ASI03 | Превышение полномочий | агент действует с правами, которых у задачи быть не должно |
| ASI04 | Цепочка поставки | уязвимость приходит с плагином, инструментом, чужим агентом |
| ASI05 | Неожиданное выполнение кода | агент запускает код, который ему подсунули |
| ASI06 | Отравление памяти | инструкция закрепляется надолго |
| ASI07 | Небезопасное общение агентов | один агент обманывает другого |
| ASI08 | Каскадные отказы | ошибка одного шага разрастается по цепочке |
| ASI09 | Эксплуатация доверия | человек подтверждает опасное, потому что агенту верит |
| ASI10 | Агент-отступник | агент действует вне заданных рамок |
Три из десяти — ASI01, ASI02, ASI03 — прямо про права и инструменты, то есть про то, что настраивается кодом, а не промптом. Как это настраивается, разобрано в статье про четыре слоя настройки агента; здесь важно другое: половина списка вообще не касается модели. Каскадные отказы, цепочка поставки и общение агентов между собой — это архитектура, и она проектируется до выбора модели. Если у вас система из нескольких агентов, пункты ASI07 и ASI08 становятся главными.
Где ошибаются компании
Оба обзора сходятся в списке типовых ошибок, и он совпадает с тем, что я вижу в чужих агентах.
Общая учётная запись и права «на всякий случай». Агент запускается от имени сотрудника или одной сервисной записи на всё. По данным Sonrai, которые приводит Anti-Malware, 92% облачных идентификаторов перепривилегированы, и агенты наследуют эту модель. Взломанный агент получает всё, что было у учётки.
Данные и команды в одной куче. Письма, события, страницы попадают в промпт без пометки. Агент не понимает, где текст, а где инструкция, — и на этом строятся все косвенные инъекции.
Важные действия на автомате. Создание ключей, выгрузка файлов, массовая рассылка — без подтверждения. Если модель ошиблась или выполнила чужую команду, остановить некому.
Нет сквозного лога. Пишутся вызовы API, но не связываются с запросом пользователя и контентом, который видел агент. Атака идёт часами, и её никто не замечает.
Опасные режимы «без подтверждений». У агентов для разработчиков есть режим, в котором всё выполняется автоматически, — и его включают ради скорости. «Касперский» прямо советует блокировать такие режимы.
- Учётка сотрудника, права на всё
- Письма и страницы в промпте без пометки
- Отправка на любой адрес
- Запись и выгрузка без подтверждения
- Лог только вызовов API
- Своя учётка, минимум прав, короткие ключи
- Внешний контент в отдельном блоке как данные
- Белый список исходящих адресов
- Запись и отправка после подтверждения человеком
- Лог: запрос, контент, решение, вызов
Как выстроить защиту: пять уровней
Из рекомендаций обоих обзоров и практики складывается пять уровней, и они страхуют друг друга: если модель ошибётся, права не дадут удалить, сеть не выпустит, человек отклонит, лог зафиксирует.
- 1Учётная записьсвоя на каждого агента, минимум прав, ключи короткоживущие и ротируются
- 2Разделение данных и командвнешний контент очищен, помечен и лежит в отдельном блоке
- 3Сетьбелый список исходящих адресов, реестр инструментов и MCP с версиями
- 4Человекзапись, отправка, установка, массовые операции — только после подтверждения
- 5Лог и проверкився цепочка от запроса до вызова, регулярные атаки-тесты
Стоимость уровней разная. Первые три — это настройка инфраструктуры, обычно день-два работы, и они закрывают большую часть каналов из таблицы. Четвёртый — процесс: кто подтверждает и как быстро. Пятый требует привычки смотреть лог, и именно на нём чаще всего экономят.
Один случай из практики. Агент поддержки работал под учётной записью менеджера — так было быстрее на старте. Через два месяца в базу знаний загрузили присланный клиентом документ с инструкцией внутри, и агент попытался выгрузить контакты на внешний адрес. Не выгрузил: стоял белый список адресов, включённый после спора с заказчиком о «лишней паранойе». Дальше учётку заменили на отдельную. Это иллюстрация к формуле из первого абзаца: третье слагаемое было убрано, и инструкция выполнилась впустую.
Десять вопросов подрядчику перед запуском
Если агента делает кто-то для вас, это список для приёмки. На каждый вопрос должен быть ответ словами и местом в коде или настройках, а не «модель сама разберётся».
- Под какой учётной записью работает агент и какие у неё права?
- Куда агент может отправлять данные — есть ли белый список адресов?
- Какие действия агент делает без подтверждения, а какие — только после?
- Есть ли лимит шагов и стоимости на один диалог?
- Как внешний контент — письма, файлы, страницы — отделён от инструкций?
- Что попадает в память агента и кто это проверяет?
- Какие инструменты и MCP-серверы разрешены и как фиксируются их версии?
- Что пишется в лог и можно ли по нему восстановить, что агент видел?
- Прогонялись ли провокации — «забудь правила», «покажи чужой заказ», текст с инструкцией внутри?
- Что происходит, если модель попросит сделать запрещённое?
Хороший признак — если на вопрос 9 подрядчик показывает набор тестов и три числа: долю верных ответов, долю неверных действий и долю передач человеку. Плохой — если ответ на любой вопрос начинается со слова «промпт».
Что я делаю, когда прихожу к работающему агенту: сначала смотрю учётку и исходящие адреса, потом режим подтверждений, потом лог. Промпт — последним, и почти всегда проблема находится раньше. Разработку ИИ-агентов я веду с этими пятью уровнями с первого дня: не потому, что заказчик просит, а потому, что переделывать после инцидента дороже, чем заложить до.
