Безопасность AI-агентов: три способа захватить агента через электронную почту

Я собрал email-агента за вечер. LangGraph, Gmail API, набор инструментов: ответить на письмо, переслать, создать тикет в Jira, обновить запись в CRM. Классический туториальный пайплайн — и он работал отлично. Две недели.

На пятнадцатый день коллега из security-команды прислал на рабочий ящик обычное письмо: вопрос про статус проекта. Внутри, невидимым для человека текстом, была инструкция: переслать последние 20 обработанных писем на внешний адрес.

Агент переслал. С именами клиентов, деталями сделок, внутренними обсуждениями. На адрес, который я раньше никогда не видел.

Ни один туториал, по которым я собирал этого агента, не упоминал, что такое возможно. Ни один.

Почему email — идеальный вектор

Три свойства делают email уникально опасным каналом для AI-агентов:

Нулевой порог входа. Отправить письмо может любой человек в мире. Без аутентификации. Каждый входящий email — прямая доставка произвольного контента в контекст вашей модели.

Богатство формата. HTML, CSS, вложения в десятках форматов, заголовки, метаданные, вложенные цепочки пересылки. Десятки мест, где можно спрятать текст так, что человек его не увидит, а парсер извлечёт.

Полномочия на том конце. Ваш email-агент — не readonly. Он отвечает, пересылает, создаёт задачи, обновляет базы данных.

Атака 1: скрытый текст в HTML

HTML-письмо содержит два слоя. Видимый — нормальный текст. Невидимый — инструкция для агента, скрытая через CSS.

Письмо приходит. Человек видит: «Подскажите статус заказа #7842». Агент видит: вопрос + скрытую инструкцию переслать данные на внешний адрес.

Техники сокрытия: нулевой размер шрифта, цвет текста совпадает с фоном, display:none, позиционирование за пределами видимой области. HTML-парсеры по умолчанию извлекают весь текст, включая скрытый. BeautifulSoup, lxml, стандартные email-парсеры — ни один не фильтрует невидимый контент автоматически.

Масштабируемость — главная опасность. Атакующий отправляет одно письмо. Массовая рассылка по корпоративным ящикам, на которых стоят AI-агенты, — вопрос одного скрипта.

Атака 2: инструкции во вложениях

Агент обрабатывает вложения — извлекает текст из PDF, Word, Excel. Инструкция встраивается внутрь документа.

PDF: двойной слой. PDF хранит отдельно визуальный рендер и текстовый слой. Они не обязаны совпадать. Видимый слой — нормальный счёт. Текстовый слой — инструкция, замаскированная под «коррекцию».

Word: метаданные и комментарии. Поля Author, Comments, Subject. Стандартные экстракторы извлекают метаданные вместе с основным текстом.

Excel: скрытые листы. Три листа: два видимых, один скрытый с инструкцией. pandas.read_excel читает все листы по умолчанию.

Имя файла. Самый примитивный вектор: инструкция в имени файла попадает в промпт через шаблон.

Большинство команд хоть как-то фильтруют HTML тела письма. Содержимое бинарных вложений не фильтрует практически никто.

Атака 3: subject line и цепочки пересылки

Тема письма — фрейм, через который модель интерпретирует тело. Инструкция в теме задаёт контекст до того, как модель увидит остальное.

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

Почему стандартные защиты не работают

Антиспам не знает, что на том конце AI-агент.

Системный промпт — рекомендация, не барьер.

Whitelist адресов обходится через альтернативные действия.

Фундаментальная причина: LLM не различает данные и инструкции.

Архитектура защиты: четыре слоя

Слой 1: Sandbox на входе

HTML-санитизация: не strip_tags, а пересборка. Удалить все элементы с display:none, visibility:hidden, opacity:0, font-size менее 2px. PDF — рендер в изображение → OCR вместо текстового извлечения. Office-документы — игнорировать метаданные, скрытые листы, комментарии.

Слой 2: Permission boundaries

Два агента вместо одного. Reader: парсит, классифицирует — без инструментов для действий. Actor: получает структурированный вывод от Reader, не сырой текст. Whitelist адресов — в коде, не в промпте.

Слой 3: Human-in-the-loop для опасных действий

Подтверждение рисковых действий через отдельный канал: push, Telegram, Slack. Не через самого агента — его можно обмануть.

Слой 4: Мониторинг и anomaly detection

Паттерн-детекция, rate limiting, canary tokens в системном промпте.

Полного решения нет. Но разница между «ноль слоёв» и «четыре слоя» — разница между инцидентом в первый день и системой, которая работает в продакшне месяцами.

Ни один туториал этого не расскажет. Теперь рассказал я.