Как дать ИИ-агенту безопасный доступ к отправке писем

Главная сложность почты в руках агентов

Чтобы дать ИИ-агенту безопасный доступ к почте, относитесь к отправке писем как к внешнему побочному эффекту с высоким риском. Никогда не давайте агенту корневой API-ключ. Вместо этого используйте учётные данные, ограниченные рабочим пространством, введите границу подтверждения человеком (human-in-the-loop) для массовых или чувствительных отправок и требуйте ключи идемпотентности, чтобы повторы LLM не приводили к дублям. Такая архитектура ограничивает радиус поражения агента и при этом сохраняет возможность проверить каждое исходящее письмо.

Как инженер, отвечающий за очередь инцидентов, я видел, что бывает, когда агент зацикливается или выдумывает список рассылки. Если у агента неограниченный доступ к вашему транзакционному провайдеру, одна логическая ошибка может за считаные минуты уничтожить репутацию домена. Нужно разделять способность агента составить письмо и разрешение системы его отправить.

Профиль рисков ИИ-агентов для почты

Встраивая LLM в процессы работы с почтой, мы получаем три основных сценария сбоя:

1. Бесконечный цикл: агент отправляет письмо, получает отказ или ответ и тут же отвечает, создавая рекурсивный цикл, который взвинчивает объём и упирается в лимиты запросов.
2. Выдуманные получатели: агент генерирует правдоподобные, но неверные адреса, из-за чего растёт доля отказов и страдает репутация отправителя.
3. Дрейф контекста: агент теряет исходный смысл разговора и начинает отправлять клиенту нерелевантный или неуместный контент.

Эти риски усугубляются тем, что большинство устаревших email API рассчитаны на детерминированную логику приложений, а не на вероятностную логику ИИ. Если вы используете обычный API-ключ, провайдер не отличит легитимное системное уведомление от вышедшего из-под контроля агента.

Учётные данные с ограниченными правами

Первая линия защиты — принцип минимальных привилегий. Не используйте глобальный ключ аккаунта. Используйте API-ключи, ограниченные рабочим пространством, которые разрешают агенту только определённые домены или шаблоны.

Например, в SendHQ можно использовать API-ключи, ограниченные рабочим пространством, чтобы агент мог отправлять письма только с конкретного подтверждённого домена. Это не даст агенту случайно подделать другие внутренние домены или получить доступ к административным настройкам.

Структура полезной нагрузки

Когда агент запрашивает отправку, полезная нагрузка должна содержать метаданные для аудита. Не позволяйте агенту динамически задавать адрес from. Зафиксируйте адрес from на бэкенде, а агенту оставьте только to, subject и body (или переменные шаблона).

{ "to": "customer@example.com", "template_id": "welcome-email-01", "variables": { "first_name": "Jane", "onboarding_step": "API Integration" }, "idempotency_key": "req_agent_88234_step_1", "metadata": { "agent_id": "support-bot-v2", "conversation_id": "conv_9912" } }

Решение проблемы повторной отправки

LLM склонны к тайм-аутам и повторам. Если агент вызывает email API, запрос зависает и агент повторяет его, вы рискуете отправить одно и то же письмо дважды. Это плохой пользовательский опыт и сигнал для спам-фильтров, что ваша отправка ведёт себя хаотично.

Здесь ключ идемпотентности обязателен. Это уникальное значение, которое генерирует клиент (оркестратор агента) и по которому API распознаёт последующие повторы того же запроса. Если API видит уже обработанный ключ, он возвращает исходный успешный ответ, не отправляя письмо повторно.

Границы подтверждения и участие человека (HITL)

Не каждое письмо требует проверки человеком, но рискованные — требуют. Я рекомендую многоуровневую систему подтверждения на основе оценки уверенности агента или важности получателя.

Уровень 1: автоматически (низкий риск)

• Транзакционные уведомления (например, сброс пароля).
• Напоминания о подтверждённых встречах.
• Такие письма идут в обход очереди подтверждения.

Уровень 2: с пометкой (средний риск)

• Ответы службы поддержки клиентам.
• Письма на основе данных о лидах.
• Они попадают в очередь на панели управления, где человек нажимает «Подтвердить» или «Изменить».

Уровень 3: заблокировано (высокий риск)

• Письма топ-менеджерам.
• Массовые объявления.
• Такие письма требуют ручного составления или строгого переопределения шаблоном.

Компромисс по стоимости инфраструктуры

Выбирая провайдера для агента, нужно соотносить стоимость с функциями, необходимыми для безопасности (например, детальными API-ключами и событиями доставки).

Согласно ценам Amazon SES, отправка a la carte стоит 0.10 USD за 1 000 писем. Однако новые тарифы, введённые 21 июля 2026 года, меняют расчёт: Essentials — 0.16 USD за 1 000, Pro — 0.22 USD за 1 000 плюс 105 USD в месяц за регион, Enterprise — 0.23 USD за 1 000 плюс 500 USD в месяц.

Сравните с другими провайдерами:

• Resend предлагает бесплатный тариф на 3 000 писем в месяц (не более 100 в день), тариф Pro за 20 USD в месяц на 50 000 писем и превышение по 0.90 USD за 1 000.
• SendGrid превратил бесплатный тариф в 60-дневный пробный период, Essentials — от 19.95 USD в месяц.
• Mailgun стоит от 15 USD в месяц за 10 000 писем, превышение — от 1.80 до 1.10 USD за 1 000.
• Postmark стоит от 15 USD в месяц за 10 000 писем, превышение — от 1.80 до 1.20 USD за 1 000.

С точки зрения чистой стоимости 50 000 писем обходятся примерно в 5 USD на SES a la carte против примерно 66 USD на тарифах Postmark. Но стоимость — не единственная метрика. ИИ-агентам нужны надёжные события доставки и удобное управление стоп-листом, чтобы агент не писал снова и снова на мёртвый адрес.

Журналы аудита и телеметрия

Если агент отправил проблемное письмо, нужно точно знать, почему это произошло. Логи должны связывать ID письма с промптом LLM и конкретной версией системных инструкций агента.

Обязательные поля журнала аудита

• message_id: уникальный ID у провайдера.
• agent_version: использованная версия промпта.
• prompt_hash: хеш входного контекста, переданного LLM.
• approval_timestamp: когда человек подтвердил отправку.
• delivery_status: принял ли письмо принимающий сервер.

Помните: приём провайдером — не то же самое, что доставка, а доставка — не то же самое, что попадание во «Входящие». Агент может получить от API 202 Accepted, но сервер получателя всё равно может отбросить письмо из-за непройденных проверок SPF или DKIM. Прежде чем позволить агенту отправить хоть одно письмо, проверьте записи с помощью инструмента вроде Email DNS Checker от SendHQ.

Чек-лист доставляемости для ИИ-агентов

Перед запуском агента в продакшен пройдите по этому чек-листу:

• Проверка DNS: настроены ли SPF, DKIM и DMARC? (Подробнее — в нашем руководстве по DKIM, SPF и DMARC.)
• Ключи с ограниченными правами: есть ли у агента ключ, ограниченный конкретным рабочим пространством или доменом?
• Идемпотентность: есть ли уникальный ключ для каждого запроса, предотвращающий дубликаты?
• Ограничение частоты запросов: есть ли жёсткий лимит количества писем, которые агент может отправить за час?
• Синхронизация стоп-листа: проверяет ли агент стоп-лист перед попыткой отправки?
• Участие человека: есть ли механизм перехвата писем с высоким риском?

Обработка ошибок

Оркестратор агента должен корректно обрабатывать ошибки API. Не позволяйте агенту «исправлять» ошибки 401 Unauthorized или 429 Too Many Requests, меняя полезную нагрузку. Это проблемы инфраструктуры, а не содержимого.

Код ошибки | Значение | Действие агента

400 Bad Request | Некорректная полезная нагрузка | Записать ошибку в лог, уведомить разработчика, остановить агента

401 Unauthorized | Недействительный API-ключ | Немедленно разомкнуть цепь (circuit breaker), оповестить администратора

429 Too Many Requests | Достигнут лимит запросов | Экспоненциальная задержка, не повторять сразу

500 Internal Error | Проблема на стороне провайдера | Поставить в очередь на потом, не давать агенту зацикливаться на повторах

Выводы

Возможность общаться с клиентами многократно усиливает ИИ-агента, но это и серьёзный риск. Относясь к письму как к побочному эффекту, строго ограничивая права учётных данных и внедряя идемпотентность, вы получаете скорость ИИ, не рискуя репутацией домена. Сосредоточьтесь на границах, а не только на промптах.

Стройте процессы с агентами уверенно вместе с SendHQ.