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