Атаки на агентные системы и защита данных
Привет, Хабр! Меня зовут Андрей Бирюков. Я независимый эксперт в области ИТ и информационной безопасности, преподаю в учебных центрах, а также пишу статьи и книги.
ИИ-агенты постепенно превращаются из удобных собеседников в полноценные программные системы. Они получают доступ к файлам, почте, браузеру, корпоративным базам, репозиториям и внешним API. Вместе с полезными возможностями растёт и цена ошибки: неверно интерпретированная инструкция может привести не просто к неточному ответу, а к удалению данных, утечке документов или финансовой операции.
Именно поэтому безопасность агентных систем требует отдельного подхода. В отличие от обычного чат-бота, агент способен самостоятельно выбирать последовательность действий и выполнять их без постоянного подтверждения пользователя. Такая автономность создаёт три базовых класса рисков: нарушение конфиденциальности, целостности и доступности.
Какие данные и процессы находятся под угрозой
Нарушение конфиденциальности происходит, когда агент получает доступ к информации, которая не предназначена для текущей задачи, а затем передаёт её в неподходящий канал. Это может быть содержимое локального файла, переписка, токен доступа или фрагмент внутренней документации.
Опасность усугубляется тем, что данные проходят через множество компонентов: результаты вызова инструментов, рабочую директорию, долговременную память агента, журналы, вебхуки и внешние сервисы. Каждый из этих элементов способен стать каналом утечки. Поэтому защита данных от атак на ИИ-агенты должна учитывать не только саму языковую модель, но и всю цепочку обработки информации.
Нарушение целостности означает, что система совершает действие, которого от неё не ожидали. Агент может изменить или удалить файл, отправить письмо неправильному адресату, внести ошибку в код или инициировать платёж. Более сложный вариант - корректное с технической точки зрения выполнение, которое приводит к плохому бизнес-результату: например, система выбирает дорогого поставщика, хотя существовала более выгодная альтернатива.
Третий класс - нарушение доступности. Агент может зациклиться на повторных попытках, перегрузить API, занять все вычислительные ресурсы или остановиться из-за сбоя зависимого компонента. Особенно уязвимы длинные сценарии, планировщики задач и автоматизация браузера: отказ одного звена способен заблокировать весь рабочий процесс.
Промпт-инъекции и атаки через доверенный контент
Одним из главных векторов остаются промпт-инъекции. Языковая модель не всегда надёжно различает инструкцию и обычные данные, которые ей нужно проанализировать. Вредоносная команда может быть спрятана на веб-странице, в электронном письме, комментарии к исходному коду, карточке Jira или документе.
Особенно опасны атаки через доверенный контент. Если инструкция поступает из адресной строки браузера, внутренней базы знаний или файла, который агент считает безопасным, модель может придать ей больший вес и выполнить действие без дополнительных проверок.
Показательный пример связан с агентными браузерами. Исследователи NeuralTrust продемонстрировали сценарий, в котором строка, похожая на URL, содержала естественно-языковую команду. Браузер OpenAI Atlas не распознал её как некорректный адрес и интерпретировал текст как распоряжение пользователя. Доверие к источнику оказалось важнее строгой проверки формата.
Другой пример описывало подразделение Zscaler ThreatLabz. Исследователи подготовили поддельный сайт, стилизованный под документацию Python-библиотеки. Скрытые инструкции разместили в CSS за пределами видимой области и в метаданных JSON-LD. Агенту предлагалось "исправить ошибку" покупкой лицензионного ключа за три доллара, причём инструкция содержала порядок оплаты через криптокошелёк злоумышленника. Четыре из 26 протестированных моделей выполнили платёж.
Проблема носит не теоретический характер. В сентябре 2025 года Яндекс выпустил рекомендации по безопасной разработке ИИ-агентов и отдельно отметил, что входные данные могут контролироваться злоумышленником. Следовательно, защита ИИ-агентов от кибератак должна закладываться ещё на этапе проектирования архитектуры, а не добавляться после инцидента.
Отравление данных и скрытые бэкдоры
Промпт-инъекция воздействует на агента во время работы. Data Poisoning, или отравление данных, направлено на этап обучения, дообучения либо формирования базы знаний. Атакующий внедряет в обучающий набор специально подготовленные примеры, после чего модель усваивает ошибочные закономерности.
Представить механизм можно на примере студента. Если в учебнике систематически повторяются неверные сведения, он запомнит их как истину. На стандартном экзамене ошибки могут не проявиться, но специально составленный вопрос активирует неправильный шаблон. Так работает бэкдор: модель обычно отвечает нормально, однако при определённой комбинации слов или условий выдаёт заранее заданный результат.
Риск повышается при использовании внешних датасетов, автоматически собранных документов и пользовательских материалов. Недостаточно проверить только формат файлов: необходимо оценивать происхождение данных, повторяющиеся шаблоны, подозрительные инструкции и резкие изменения поведения модели после дообучения.
Инструменты как расширенная поверхность атаки
Каждый подключённый инструмент увеличивает возможности агента - и одновременно расширяет потенциальную поверхность атаки. Доступ к почте, файловой системе, платежам, командной строке или CRM превращает ошибку модели в действие с реальными последствиями.
Безопаснее разделять инструменты по уровню риска. Операции чтения можно разрешать автоматически, а удаление файлов, публикацию кода, отправку писем и финансовые действия - выполнять только после явного подтверждения. Дополнительно нужны ограничения по каталогам, доменам, адресатам, суммам и времени выполнения.
Следует применять принцип наименьших привилегий: агенту предоставляют только те права, которые необходимы для конкретной задачи. Секреты нельзя помещать в промпт или долговременную память, а токены доступа необходимо регулярно ротировать и ограничивать по области действия.
Как выстроить защиту
Надёжная кибербезопасность искусственного интеллекта строится на нескольких уровнях. Во-первых, входные данные нужно разделять по происхождению и степени доверия. Текст веб-страницы, письмо клиента и системная инструкция не должны попадать в единый неразмеченный контекст.
Во-вторых, опасные операции требуется проверять отдельным контроллером, не полагаясь только на решение LLM. Полезны песочницы, фильтрация исходящих запросов, allowlist доменов и команд, лимиты ресурсов, тайм-ауты и защита от бесконечных циклов.
В-третьих, необходимы подробные журналы: какие данные прочитал агент, какой инструмент вызвал, какие параметры передал и почему выбрал конкретное действие. Логи позволяют расследовать инциденты и находить признаки постепенной атаки.
Наконец, нужен регулярный аудит безопасности ИИ-систем. Он должен включать тестирование промпт-инъекций, проверку разграничения прав, анализ памяти агента, оценку внешних интеграций и моделирование сценариев утечки. Проверять следует не только модель, но и инструменты, оркестратор, хранилища, прокси и интерфейсы администратора.
Вместо вывода
Агентная система - это не просто языковая модель с расширенным промптом. Это автономный участник цифровой инфраструктуры, способный читать, принимать решения и действовать. Поэтому её нельзя защищать исключительно настройками модели или фильтром запрещённых слов.
Эффективная защита ИИ-агентов от кибератак предполагает сочетание архитектурных ограничений, контроля доступа, изоляции, проверки контекста, подтверждения критических операций и постоянного мониторинга. Чем больше полномочий получает агент, тем важнее заранее определить границы его автономии и предусмотреть безопасный отказ при неопределённости.
