Традиционная модель автоматизации почты строится вокруг регулярного опроса ящика по расписанию (polling). Сервер каждые 15–30 минут проверяет почтовую службу и при обнаружении сообщений вызывает языковую модель. На практике эта схема неэффективна: один ящик совершает до 96 пустых сетевых обращений в сутки, расходуя вычислительные ресурсы и упираясь в лимиты API провайдеров. Срочное обращение клиента или сервисный инцидент при этом может ожидать реакции до получаса.
Событийно-ориентированная архитектура (Event-Driven Architecture) исключает фоновый опрос. Программный агент больше не опрашивает сервер в цикле: почтовый шлюз сам отправляет входящий вебхук при доставке письма, инициируя обработку за секунды. Вызовы модели происходят только тогда, когда событие действительно зафиксировано.
Четыре уровня контура: от шлюза до изоляции очередей
Корпоративная почтовая система не должна передавать входящий HTTP-запрос напрямую в языковую модель. Почта остается асинхронным и недоверенным каналом: письма могут задерживаться, приходить повторно или содержать поддельные заголовки. Чтобы обеспечить надежность, обработка делится на четыре уровня: прием события, криптографическая проверка, нормализация и постановка в очередь.
Специализированный шлюз (сервис AgentMail) принимает сообщение на своих серверах и отправляет HTTP POST-запрос на публичный эндпоинт компании. Веб-обработчик проверяет подлинность до разбора текста: сверяется заголовок Authorization с секретным токеном или проверяется HMAC-подпись тела запроса. Невалидные запросы отклоняются сразу без раскрытия внутренней структуры сервиса.
После успешной валидации формируется детерминированный ключ идемпотентности на базе идентификатора письма или комбинации адреса ящика, заголовка Message-ID и версии события. Повторный запрос с тем же ключом распознается как дубликат и не запускает вторичную обработку. Зафиксированное событие отправляется в брокер сообщений, а шлюз получает ответ 200 OK. Это гарантирует, что задержка ответа нейросети не вызовет тайм-аут соединения.
Для сбойных сообщений создается очередь недоставленных сообщений (Dead Letter Queue, DLQ). Если письмо повреждено или модель возвращает ошибку, событие изолируется в DLQ с сохранением причины отказа для аудита инженером.
Диспетчеризация входящих: фильтрация перед вызовом модели
Центральную роль в системе играет диспетчер входящих сообщений (Inbox Manager). Передавать весь массив сырых писем напрямую в языковую модель нерационально: это увеличивает затраты на токены и открывает систему для спама. Надежный контур сочетает детерминированные правила на первом шаге и семантическую классификацию на втором.
Первичный фильтр анализирует служебные заголовки без вызова нейросети. Сообщения с заголовками Auto-Submitted, уведомления о недоставке (NDR), рассылки с заголовками List-Unsubscribe и письма от доменов без SPF и DKIM отсекаются или архивируются.
Очищенные сообщения передаются классификатору для определения категории и приоритета:
urgent: сбои инфраструктуры, обращения ключевых клиентов, блокировки доступов;primary: стандартные рабочие задачи, вопросы по проектам, контрактные согласования;outreach: предложения о сотрудничестве, входящие коммерческие запросы, лиды;newsletters: информационные дайджесты и отраслевые статьи, не требующие ответа.
Классификатор возвращает целевой маршрут и оценку уверенности. Если уверенность ниже порога, письмо направляется на ручную сортировку оператором. Финансовые и юридические документы требуют обязательного подтверждения человеком.
Изоляция субагентов и нейтрализация промпт-инъекций
Безопасность — ключевой фактор при работе агентов с открытой почтой. Тело входящего письма представляет собой недоверенный ввод, где злоумышленник может спрятать инструкцию (непрямая промпт-инъекция) для раскрытия системного промпта или несанкционированных действий.
Защита выстраивается по принципу минимальных привилегий:
- Стерилизация контента: HTML-разметка очищается от скриптов, скрытых стилей, невидимого текста и пикселей слежения с преобразованием в безопасный плоский текст.
- Карантин вложений: файлы не подгружаются в контекст модели автоматически. Они сохраняются в изолированном хранилище, а исполнитель получает метаданные: тип файла, имя и ссылку. Данные OCR помечаются как недоверенные.
- Разметка границ в промпте: в системной инструкции фиксируется, что блок сообщения является внешними данными для анализа, а не командным интерфейсом. Директивы проигнорировать правила внутри письма расцениваются как атака.
- Изоляция доступов: специализированный субагент не имеет доступа к главному почтовому аккаунту и чужим ящикам. Он генерирует только черновик ответа, а отправку выполняет отдельный сервис после проверки политикой безопасности.
Защита от бесконечных циклов автоответов
Опасный сценарий в агентной инфраструктуре — рекурсивная петля (Recursive Autoresponder Loop). Если агент отвечает на письмо другого автоматического бота или автоответчика, системы могут бесконечно пересылать сообщения, сжигая баланс токенов.
Для предотвращения подобных петель внедряются защитные барьеры:
- проверка адреса получателя с блокировкой отправки, если он совпадает с агентским контуром;
- ограничение глубины цепочки переписки с остановкой автоответов при превышении порога без участия человека;
- интервал охлаждения (cooldown) на отправку сообщений одному контакту;
- отсечение сообщений с признаками автоматической генерации по служебным заголовкам.
Пошаговый план внедрения и верификации
Развертывание событийно-ориентированного почтового контура включает шесть этапов:
- Подготовка инфраструктуры: создание выделенного ящика в специализированном сервисе (например, AgentMail по адресу https://docs.agentmail.to/) и настройка тестового сервера приема вебхуков.
- Настройка безопасности: генерация секрета вебхука, сохранение в переменных окружения и реализация валидации подписи входящих POST-запросов.
- Проверка идемпотентности: отправка контрольного сообщения и его дубликата с проверкой, что в очереди появляется одна запись, а повторный запрос возвращает статус 200 OK.
- Тестирование отказов: имитация сетевого сбоя для проверки экспоненциальной паузы повторов и перемещения проблемных событий в Dead Letter Queue.
- Запуск в режиме черновиков: перевод субагентов в режим формирования черновиков без права прямой отправки с ручной проверкой первых сформированных писем.
- Постепенное включение отправки: открытие отправки для доверенного белого списка адресов с мониторингом времени доставки (p95), доли ручной эскалации и расхода токенов.
Регламент действий при инцидентах
При обнаружении некорректных ответов, атаки через входящее письмо или невалидных запросов к вебхуку дежурный инженер блокирует сервис исходящей отправки. Брокер сообщений переводится в режим накопления, что останавливает ущерб, сохраняя данные для расследования.
Затем отзываются скомпрометированные секреты вебхуков и ключи, после чего логи анализируются по trace-id. После устранения уязвимости накопившиеся сообщения обрабатываются контролируемыми порциями с дедупликацией. Событийная архитектура с изолированными субагентами превращает почтовую автоматизацию в управляемый процесс с полным аудитом и контролем со стороны человека.