Гладиаторы - меню

Атаки на AI-агенты - как ломают ваших AI-ассистентов

AI-ассистенты стремительно перестали быть экспериментом. Сегодня они читают почту, отвечают клиентам, помогают SOC, запускают процессы, работают с данными и принимают решения. И чем полезнее становится AI-агент, тем выше цена ошибки. В 2026 году атака на ИИ — это уже не попытка «сломать чат-бота», а способ получить доступ к данным, инструментам и бизнес-процессам компании.

Главная проблема в том, что AI-агенты ломают не через уязвимость в коде, а через смысл. Текст, документ, тикет или письмо для модели — это не «данные» и не «инструкция», а единый контекст. Достаточно правильно сформулированного запроса или скрытой команды, чтобы ассистент изменил поведение, выполнил лишнее действие или начал доверять тому, кому доверять нельзя.

Когда AI-агент получает память, автономность и доступ к инструментам, он превращается в привилегированного пользователя. А значит — требует такого же уровня защиты, как администратор, инженер или финансовый директор. Без этого ассистент становится идеальной точкой входа: тихой, легальной и крайне опасной.

В этой статье мы разбираем, как ломают AI-агентов на практике, какие угрозы наиболее критичны для agentic-систем и как выстроить защиту, которая выдержит атаки не только людей, но и чужого искусственного интеллекта.

Содержание:

Что такое LLM и AI-ассистенты, и как они устроены
Как их создают, обучают и выводят на рабочие процессы
Top 10 угроз для Agentic AI
Как мы проверяем и защищаем AI-агентов в проде
Наше решение

Команда редакторов "Гладиаторы ИБ"

Дата публикации: 12.01.2026
Время прочтения 7 минут

Что такое LLM и AI-ассистенты, и как они устроены

AI-ассистент выглядит как чат. Но в реальности — это система, которая принимает текст и превращает его в решения, а иногда и в действия. Внутри обычно три слоя:

LLM (большая языковая модель) — движок, который “понимает” запрос и генерирует ответ. Важно: модель не отличает “инструкцию” от “цитаты” так, как человек. Для неё всё — контекст.
Контекст (данные) — история диалога, документы, тикеты, письма, база знаний, результаты поиска. Чем больше ассистент “читает”, тем больше он уязвим к подменам смысла.
Инструменты (tools) — API и действия: отправка писем, создание задач, запросы в БД, работа с файлами, изменения в системах, управление облаком.

Если классическое LLM-приложение живёт по схеме “вопрос → ответ”, то AI-агент живёт по циклу “увидел → спланировал → сделал”. У него появляется память, планирование и автономность. А значит — цена ошибки резко растёт.

Мы, “гладиаторы в костюмах”, смотрим на это просто: если система умеет действовать — её нужно защищать как привилегированного сотрудника.

Как их создают, обучают и выводят на рабочие процессы

В корпоративном мире ассистенты почти никогда не “обучают с нуля”. Чаще их собирают, как боевой комплект.

1) Берут базовую модель

Облачную или локальную — по требованиям к данным и регуляторике.

2) Настраивают поведение

системные инструкции (policy/system prompt),
ограничения (guardrails),
дообучение (fine-tuning) — реже, но бывает.

3) Подключают знания через RAG

Ассистент начинает отвечать на основе внутренних документов. Это удобно — и опасно: вместе со знаниями вы подключаете новый канал атаки через контент.

4) Подключают инструменты

Вот здесь ассистент перестаёт быть “болталкой” и становится агентом: может создавать заявки, отправлять письма, менять конфиги, запускать задачи.

5) Встраивают в процессы

Саппорт, SOC, ITSM, продажи, финансы, DevOps. И в этот момент “атака на ИИ” перестаёт быть теорией — потому что агент теперь влияет на деньги, доступы и непрерывность бизнеса.

Top 10 угроз для Agentic AI

Ниже — 10 угроз, которые чаще всего “стреляют”, когда ассистент получает память и инструменты.

Отравление памяти (Memory Poisoning) — подмена “знаний”, которые агент будет использовать дальше.
Злоупотребление инструментами (Tool Misuse) — агент легально делает нелегальное: отправляет файл наружу, создаёт доступ, запускает действие.
Компрометация привилегий (Privilege Compromise) — у агента слишком большие права, и его уговаривают “создать временную учетку”/“выдать доступ”.
Инъекция через контент (Indirect Prompt Injection) — команда спрятана в письме/PDF/HTML/тикете.
Манипуляция целями (Goal/Intent Manipulation) — агент “выполняет KPI”, ломая бизнес-ограничения.
Каскадные галлюцинации (Cascading Hallucinations) — одна ошибка превращается в цепочку действий и решений.
Подмена личности (Identity Spoofing) — в мультиагентных системах подделывают отправителя “CEO-agent/Finance-agent”.
Неотслеживаемость (Repudiation) — агент сделал изменение, но непонятно кто и почему, расследовать нечем.
Перегрузка ресурсов / Denial of Wallet — агент “сжигает” лимиты, бюджет, API-квоты.
Усталость от подтверждений (HITL fatigue) — атакующий заваливает оператора одобрениями и проталкивает одно опасное.

Как мы проверяем и защищаем AI-агентов в проде

Вот здесь начинается практика — то, чем отличается “мы внедрили ИИ” от “у нас ИИ под контролем”.

1) Аудит архитектуры Agentic AI

Мы разбираем систему по слоям и задаём неприятные вопросы:

Какие источники данных попадают в контекст?
Где формируется prompt и кто может на него влиять?
Какие инструменты доступны агенту и с какими правами?
Есть ли долговременная память и кто может её менять?
Есть ли границы автономности (что агент может сделать сам)?
Что логируется и можно ли восстановить цепочку действий?

Результат — карта поверхности атаки и приоритизация рисков.

2) Red Teaming AI-агента

Мы атакуем ассистента так, как это сделает злоумышленник, но в контролируемых условиях:

prompt injection (прямой и косвенный),
инъекции через документы и тикеты,
попытки вытянуть секреты/системные инструкции,
попытки заставить агента использовать инструменты во вред,
“социальная инженерия” против агента (роль, срочность, авторитет),
сценарии “agent-to-agent” (подмена личности, доверие между агентами),
тест на “denial of wallet” и рекурсивные планы.

Результат — отчёт с доказуемыми сценариями (PoC), где видно: что ломается, как, и какие последствия.

3) Политики инструментов: броня на действия

Самый частый провал — инструменты без ограничений. Мы вводим:

allowlist операций (что можно делать),
ограничения параметров (куда можно отправлять, какие таблицы читать, какие команды запрещены),
контекстную авторизацию (инструмент разрешён только при определённых условиях),
разделение ролей (агент “читает”, но не “удаляет”; или “предлагает”, но не “делает”).

И главное: критичные действия — только через подтверждение и/или отдельный контур.

4) Безопасный RAG: чтобы знания не стали оружием

RAG часто ломают через контент. Мы защищаем его так:

фильтрация и санитизация входных документов (в т.ч. скрытых инструкций),
разметка доверенности источников (trusted / untrusted),
“контекстные границы”: документы — это данные, а не инструкции,
минимизация выдачи: ассистент отвечает строго по вопросу и правам,
проверка на утечки (PII/секреты) перед выдачей наружу.

5) Память под контролем

Если у агента есть долговременная память, мы делаем:

отдельные зоны памяти (оперативная/доверенная/недоверенная),
правила записи (что можно сохранять, а что — нет),
аудит изменений и алерты на аномалии,
“срок жизни” для записей (TTL) и чистку.

6) Неизменяемые логи и расследуемость

Без этого вы не защититесь — вы просто не поймёте, что произошло.
Мы настраиваем логирование так, чтобы восстановить цепочку:

вход → системные инструкции → контекст → план → tool calls → результат → ответ

Плюс:

привязка к пользователю/сессии,
контроль целостности логов (immutability),
метрики качества: FP/FN, частота блокировок, попытки инъекций, “подозрительные” tool calls.

7) Режимы автономности: от “советника” к “автопилоту”

Мы не включаем автопилот сразу. Мы вводим уровни:

L0: агент только отвечает (без инструментов)
L1: агент предлагает действия, человек подтверждает
L2: агент выполняет только безопасные шаги (изолировать, собрать контекст)
L3: расширенная автономность в строго ограниченном периметре
L4: автопилот — только там, где бизнес согласен с риском и есть контроль

Наше решение

Если у вас уже есть AI-ассистент (или вы планируете агентную систему для поддержки, SOC, ITSM, DevOps, финансов) — не ждите “первого инцидента”. На практике его цена выше, чем цена правильной архитектуры.

Мы можем подключиться как проектная команда:

аудит Agentic AI и модель угроз,
red teaming и проверка устойчивости к prompt/tool атакам,
настройка политик инструментов и прав,
безопасный RAG и контроль памяти,
логирование, расследуемость, регламенты,
дальнейшее сервисное сопровождение.

Оставьте контакты — и мы в течение дня предложим план работ: быстро, прозрачно и по делу. Мы гладиаторы в костюмах. С ноутбуками. И мы не отступаем, мы берем угрозы под контроль!

29 декабря 2024г.

Какие проблемы бизнеса на самом деле решает информационная безопасность

21 декабря 2024г.

Безопасность как один из трех централизованных бизнес-процессов бизнеса

14 декабря 2024г.

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

07 декабря 2024г.

Почему бизнес сомневается в эффективности систем защиты информации

30 ноября 2024г.

Цена безопасности: насколько дорого обходятся услуги защиты информации

16 ноября 2024г.

Как выбрать надежные средства защиты информации - полезные советы и рекомендации