Агенты удаляют файлы, сливают данные и сами себя взламывают: как устроена безопасность ИИ‑систем в 2026 году

Вступление

Тема искусственного интеллекта ^[1] за последние несколько лет набили, честно говоря, оскомину. Есть как защитники, так и противники технологий, которых принято называть ИИ. Везде начали приделывать ИИ‑помощников. Встраивать нейросети в разные приложения. И раз уж не избежать искусственного интеллекта в повседневной жизни. Я решил поговорить про атаки на языковые модели. Потому что такие кибератаки перестали быть экзотикой, а защита ИИ стала отдельная дисциплина с собственной таксономией, инструментарием и, к сожалению, реальными инцидентами.

Я решил поговорил с автором Telegram‑канала ^[2] PWN AI, посвящённого небезопасному применению ИИ, Артёмом Семёновым. С Артёмом уже был разговор ^[3] тут на Хабре об ИБ и ИИ. Но я решил обновить данные. Артём рассказал, как расширилась поверхность атаки с появлением агентов и MCP‑протоколов, почему системный промпт — не граница безопасности, какие атаки модели до сих пор не умеют отбивать и чем принципиально отличается прямой prompt injection от косвенного. Приятного чтения!

Интервью

Как вы определяете поверхность атаки для LLM‑системы?

В 2025–2026 годах атаки на LLM вышли за пределы самой модели. С появлением агентных систем — таких как Hermes или OpenClaw — и протоколов вроде MCP картина угроз существенно усложнилась. Раньше, говоря об угрозах LLM, мы имели в виду промпт‑атаки, отравление обучающих данных, отравление пайплайна и отказы в обслуживании. Сегодня к этому добавились угрозы, характерные именно для агентных систем.

Агенты принимают автономные решения, а именно это порождает новый класс угроз. Поведение ^[4] таких агентов недетерминировано, например, агент может начать рассуждать о себе таким образом, что это приведёт к нарушению не только норм безопасности, но и вполне конкретных операционных границ. В инцидентах, которые уже зафиксированы, агенты самостоятельно удаляли файлы и кодовые базы с машин пользователей. Бывали случаи, когда агент выкладывал конфиденциальные корпоративные данные в открытый доступ — например, сотрудник отдела AI Superintelligence одной крупной ^[5] технологической компании столкнулся с тем, что его агент самостоятельно слил внутренние данные в интернет.

Важно понимать: классическое моделирование угроз в этом контексте работает лишь частично. Мы не можем перечислить все возможные угрозы, часть из них принципиально не поддаётся контролю — мы попросту не знаем, что происходит «под капотом» модели. Я думаю, что стоит расширять перечень угроз моделью доверия. Организации нужно определить, каким компонентам ИИ‑стека она доверяет, а какие исключаются из доверенной зоны. Это даёт более практичную и управляемую рамку для работы с рисками, чем попытки охватить необъятную таксономию угроз.

Какие основные уязвимости вы видите в современных LLM‑приложениях?

Если говорить тезисно, то их несколько. Первые представляют собой утечки данных: либо утечка обучающих данных, либо утечка сведений из корпоративного контекста, имплементированного в модель через RAG или fine‑tuning. Второе — компрометация поведения ^[6] агента: когда агент используется как инструмент для реализации сложных кибератак, а не как помощник пользователя. Более того — пентест‑агенты также уязвимы ^[7]. Третье — промпт‑атаки во всём их многообразии: с использованием кодировок, обфускации, многошаговых сценариев.

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

Чем прямой Prompt Injection отличается от косвенного на уровне реализации?

Прямая промпт‑атака (классический Prompt Injection) — это когда злоумышленник напрямую взаимодействует с моделью через пользовательский интерфейс, вводя инструкции, призванные обойти alignment и заставить модель выполнить нечто нежелательное. Технически это проще: не нужно готовить внешние ресурсы, покупать домены, встраивать вредоносный контент куда‑то ещё. Однако именно от прямых атак фронтирные модели сейчас защищены лучше всего. Например, Anthropic использует constitutional classifiers, которые в реальном времени понимают «природу небезопасного» и способны дообучать модель при обнаружении аномалий.

Косвенная, или непрямая, промпт-атака устроена иначе. Злоумышленнику не нужно обращаться к модели напрямую — достаточно разместить вредоносную инструкцию в стороннем источнике, к которому агент обратится в ходе своей работы: на веб-странице, в базе данных, в документе, который агент проиндексирует. Классический пример — атака EchoLeak ^[8] на Microsoft Copilot: злоумышленник отправил письмо с промпт-атакой, Copilot прочитал его по запросу пользователя, выполнил инструкции — извлёк все письма из почтового ящика и отправил их на внешний сервер, обойдя встроенные средства защиты Outlook. Косвенную промпт-атаку сложнее детектировать именно потому, что вредоносный контент иногда поступает из, казалось бы, легитимного источника.

_{*Alignment (англ. «выравнивание») — когда модель обучают таким образом, чтобы она соответствовала каким‑либо ценностям.}

Какие каналы ввода чаще всего используют для внедрения вредоносных инструкций?

Выделю три канала:

• Первый — внешние веб-ресурсы. Наиболее подвержены браузерные агенты, индексирующие страницы и извлекающие из них информацию.

• Второй — кодовые базы и конфигурационные файлы: сгенерированный или подменённый код с промпт-атакой может нарушить поведение кодового агента, работающего с репозиторием.

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

Отдельно стоит упомянуть No-prompless-атаки — класс угроз, при которых LLM начинает «осознавать» нечто небезопасное в ходе интерпретации файлов без каких-либо явных вредоносных инструкций от пользователя. Модель сама, без атакующего ввода, через цепочку рассуждений приходит к небезопасному действию. Это сложнее всего предсказать и обнаружить. Инцидент Echoleak, где нулевое взаимодействие пользователя с атакующим контентом оказалось достаточным для полной компрометации почтового ящика, — один из самых наглядных примеров этого класса.

Почему системный промпт не может быть надёжной границей безопасности?

Принципиальная проблема в том, что модель не разграничивает системный промпт и пользовательский ввод на уровне, который обеспечивал бы реальную защиту. Для неё это просто текст — и относиться к нему «строже» она изначально не умеет. Плюс системные промпты регулярно утекают: исследователи вроде Elder Plinius ^[9] публикуют их спустя часы после релиза, после чего создаётся набор атакующих запросов, специально заточенных под конкретные ограничения.

Дополнительная проблема — явление «lost in the middle»: модели плохо запоминают инструкции, расположенные в середине длинного системного промпта. Показательный случай: системный промпт одной из версий моделей Claude утёк ^[10] в виде многостраничного документа, а важные ограничения, прописанные в его середине, модель попросту не c полной точностью воспроизводила последовательно. Существуют попытки усилить защиту промпта — например, использование XML-тегов для разделения контекста (когда системные инструкции и пользовательский ввод явно разделяются тегами <system> и <user>), или техника sandwiching (помещение пользовательского ввода между двумя копиями системных инструкций). Также развивается концепция Instruction Hierarchy — иерархии инструкций, когда модель на уровне архитектуры учится приоритизировать системные сообщения над пользовательскими. Но даже это не решает проблему полностью: злоумышленник, знающий структуру промпта, может сформировать запрос нетипичного формата — например, JSON вместо естественного языка — и модель начинает интерпретировать его иначе, игнорируя часть ограничений.

Как проводится тестирование безопасности LLM и агентских систем?

Есть несколько подходов. Первый — автоматизированные инструменты, генерирующие состязательные примеры запросов и «натравливающие» их на модель или агента. У этого подхода есть очевидные ограничения: инструмент может не знать новых векторов атак, его запросы «стареют» по мере обучения ^[11] моделей, и он не всегда умеет адаптироваться к ответам модели в реальном времени.

Второй подход — формирование промпт-атак с учётом бизнес-контекста тестируемой системы. Если понимать, как работает агент и каков его контекст, можно с помощью мощной генеративной модели создавать запросы, которые с высокой вероятностью пробьют защиту. Третий — бенчмарки: Inspect Eval ^[12] позволяет проверять поведение агентов в искусственных средах («Удастся ли через промпт-атаку вынудить агента совершить покупку?»), а Agent Dojo ^[13] позволяет интегрировать защитные решения в среду тестирования и получать на выходе датасет для дообучения guardrails. Из open-source инструментов для Red Teaming LLM сейчас активно используются Garak (от NVIDIA), PyRIT (от Microsoft), Promptfoo — они позволяют автоматизировать генерацию состязательных запросов и проверку моделей на устойчивость к различным векторам атак. Также стоит следить за OWASP LLM Top 10 — это де-факто стандарт таксономии угроз для LLM-приложений, который регулярно обновляется сообществом.

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

Каковы слабые места guardrails* и фильтров контента?

У guardrails есть фундаментальная уязвимость: они сами могут стать целью атаки. На соревнованиях типа CTF фиксировались кейсы, когда промпт-атака проходила именно через guardrail: злоумышленник добивался того, чтобы через «защитник» в агент вернулась скомпрометированная инструкция. Guardrail становился не барьером, а каналом доставки атаки. Ещё одна системная проблема guardrails, особенно у open-source решения, — это часто они не учитывают бизнес-контекст организации, например, определённый запрос, который в контексте грузоперевозочной компании может быть нормальным,   будет пропущен именно потому, что guardrail не понимает специфики отрасли. Наконец, контент-фильтры нередко дают ложные срабатывания: безопасный ответ блокируется из-за слова или темы, которые фильтр счёл подозрительными. Это ухудшает пользовательский опыт ^[14] и снижает довериев целом к ИИ-системе.

_{*Guardrails — один из распространённых подходов к защите моделей. Классическая схема: дополнительная модель-классификатор ставится на вход и выход основной модели, оценивая запросы и ответы на предмет опасного контента. Это позволяет снизить риск утечки конфиденциальной информации и минимизировать репутационные риски.}

Какие риски несёт использование внешних инструментов, функций и API?

Здесь применим классический вектор supply chain. Скиллы и инструменты для агентов активно появляются в специализированных скилл-хабах — и, как и в случае с пакетными менеджерами, ничто не гарантирует их безопасность. В описании скилла может лежать вредоносная инструкция, которую агент затем проинтерпретирует как команду. При использовании MCP-серверов пользователи нередко скачивают их без должной проверки, а сам сервер может содержать скомпрометированный контент. Аналогичные риски присутствуют в протоколах агентских платежей, например, через скомпрометированный протокол агент может получить команду на несанкционированный денежный перевод или передачу данных.

Отдельно стоит упомянуть галлюцинации при работе с инструментами: агент может «придумать» название тула, которого не существует, и вызвать не тот инструмент. А сами последствия работы агента зависят от уровня доступа этого инструмента.

Как вы оцениваете безопасность мультиагентных систем и длительных рабочих сессий?

Мультиагентные системы уязвимы к каскадным атакам. С появлением фреймворков типа OpenClaw и Hermes возник класс угроз, получивший название AI Worm.

AI Worm — вирус, распространяющийся от одного агента ко всем остальным в сети. Например, инцидент с ClawWorm ^[15] был одиним из первых задокументированных случаев применения этого класса угроз. Для митигации предлагается аутентификация между агентами и использование доверенных протоколов взаимодействия. Эта область активно развивается, и часть каскадных рисков, вероятно, будет закрыта в обозримом будущем.

Другая проблема — длительные агентные сессии. Чем дольше агент работает без сброса контекста, тем выше вероятность галлюцинаций, ошибок в управлении памятью ^[16] и нарушения инструкций. Это не решается стандартным guardrail. Можно ограничить количество вызовов, добавить правила на отключение инструментов. Однако фундаментальная проблема потери когерентности в длинном контексте пока не решена. И, кстати, ни одна из компаний, занимающихся разработкой моделей, убедительного решения этой проблемы не дала.

Какие атаки текущие механизмы защиты отбивают хуже всего?

Выделю три типа атак:

• Первый — многошаговые атаки, которые представляют собой серию запросов, каждый из которых выглядит безобидно, в совокупности приводит модель к состоянию, из которого она выполняет jailbreak. Эти атаки эксплуатирует слабость контекстного окна и накопление семантического «давления».

• Второй — атаки на модели с рассуждениями. Атакующий заставляет модель рассуждать о себе достаточно долго и в нужном направлении, она может сама прийти к небезопасному выводу и без какого-либо явного вредоносного ввода. Эти атаки задокументированы в нескольких исследованиях, в том числе в контексте self-jailbreak ^[17]*: модель, не получавшая атакующих инструкций, в ходе цепочки рассуждений сама себя «уговорила» нарушить ограничения.

• Третий — это атаки с использованием низкоресурсных языков. В рамках такой атаки, Alignment, обученный преимущественно на английском и популярных языках, значительно слабее держится при вводе на малоизученных языках или нестандартных кодировках. Большинство моделей пока не умеет обнаруживать этот тип атак.

_{*Self‑jailbreak  — это методы, с помощью которых большая языковая модель (LLM) сама обходит собственные защитные механизмы и ограничения, не требуя внешнего вмешательства в веса модели.}

Что сейчас уязвимее всего: сама модель, слой оркестрации или интеграции вокруг неё?

Здесь важно понимать, что «уязвимее» не означает «опаснее атаковать». Атака напрямую на модель даёт небезопасные генерации, но их влияние ограничено. Однако атака на слой оркестрации потенциально позволяет отравить сразу множество моделей в кластере. Такой инцидент уже был: в платформе Ray нашли уязвимость, открывавшую доступ к кластерам, где хранились ML-модели.

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

Заключение

Как становится понятно из разговора, угрозы для LLM-систем к 2026 году вышли далеко за пределы «плохих промптов». Всё большая интеграция ИИ-агентов в IT-жизнь компаний и пользователей создаёт принципиально новые векторы атак. И далеко не все из этих проблем имеют готовые защитные решения. Часть рисков носит имманентный характер: недетерминированность языковых моделей выступает не обычным багом, который можно запатчить.

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