Подключение почты к ИИ безопаснее строить как цепочку отдельных компонентов: получение выбранных сообщений, нормализация, проверка содержимого, работа модели, согласование и отправка. Модель не должна получать универсальный пароль от ящика или считать текст письма доверенной командой. По умолчанию она готовит проверяемый черновик, а внешнее действие выполняет отдельный сервис после разрешения.
Ограничьте ящик, папку и полномочия
Сначала формулируется деловая цель. Укажите адрес, папку или метку, допустимых отправителей, состояния сообщений и поля, которые нужны процессу. Выделенный ящик для обращений проще контролировать, чем личную почту руководителя. Классификатор новых заявок не нуждается в удалении писем, изменении правил, чтении посторонних папок или самостоятельной отправке.
Чтение и отправку следует разделить. Провайдеры предлагают пользовательские и прикладные разрешения разной ширины, причём прикладное право без дополнительного ограничения может затрагивать множество ящиков. Используйте отдельную техническую личность, минимальные полномочия, защищённое хранение секрета, замену ключей и владельца, способного быстро отозвать доступ.
Если подходящего API нет, IMAP даёт доступ к сообщениям и папкам, но не решает задачу согласования исходящей почты. Нужны защищённое соединение, устойчивые идентификаторы и состояние синхронизации для восстановления пропущенных изменений. До интеграции полезно ответить на вопросы о задаче, проверке и безопасной среде.
Считайте письмо недоверенной записью
Сервис приёма сохраняет неизменяемую ссылку на оригинал и создаёт нормализованную запись. В неё входят ящик, идентификатор провайдера, цепочка переписки, отправитель, получатели, тема, время, выбранные заголовки, текстовые части, сведения о вложениях и состояние обработки. Остальные компоненты работают с этой схемой, а не разбирают исходный формат заново.
Содержимое письма недоверенно даже при знакомом отправителе. В тексте или вложении может находиться инструкция игнорировать правила, раскрыть данные, заменить адресата или вызвать инструмент. Для модели это материал, который надо классифицировать, но не источник полномочий. Системные правила, список инструментов и проверки доступа остаются вне сообщения.
Вложения проходят политику типа, размера, проверки на вредоносное содержимое и извлечения текста. Если сканер недоступен или формат неизвестен, письмо переходит в карантин. Процесс не отправляет сырое вложение модели и не продолжает работу только потому, что тема выглядит знакомой.
Дополнительный контекст извлекается только из разрешённых записей. Похожий фрагмент не подтверждает клиента, договор или прошлое решение. Правила проверки фактов ИИ-агента требуют связывать утверждение с источником и не заполнять пробелы правдоподобным текстом.
Ограничьте результат модели и добавьте согласование
Модель получает узкую задачу и возвращает структурированный результат. Она может предложить категорию, извлечь разрешённые поля, составить краткое содержание, перечислить недостающие сведения или подготовить ответ. Схема разделяет цитаты из письма, факты из авторитетных систем и сформулированный текст. Неподтверждённое поле остаётся пустым или вызывает исключение.
После модели выполняются детерминированные проверки. Они подтверждают правила отправителя, обязательные доказательства, допустимую категорию, адресатов, чувствительные данные и необходимость ручного решения. Стоимость, договорные условия, изменение учётной записи, платёжные инструкции, сомнение в личности и внешнее обещание всегда попадают в очередь назначенного проверяющего.
Проверяющий видит исходное сообщение, использованные записи, предложенных адресатов, вложения и точный черновик. После согласования модель не может незаметно изменить получателя или добавить файл. Перед рабочим запуском проверяются ценность, поведение и безопасность на обычных, спорных и вредоносных письмах.
Отправляйте отдельно и наблюдайте без копии ящика
Исходящее письмо отправляет отдельный компонент с отдельным разрешением. У согласованного черновика есть ключ намерения, связанный со случаем и действием. При неопределённом ответе провайдера сервис сначала проверяет отправленное состояние, а не повторяет вызов. Идентификатор доставленного письма связывается с входной записью и квитанцией согласования.
Журнал хранит ссылки на сообщения, состояния, решения политики, версии модели и инструкции, результаты инструментов, проверяющего, итог доставки и класс ошибки. Токены доступа, полные тела писем, лишние персональные сведения и найденные секреты в общий журнал не попадают. Доступ к подробному содержанию выдаётся отдельно по рабочей необходимости.
Отдельные очереди обрабатывают пропущенное событие, дубль, перемещённое письмо, отказ сканера, удержание по политике, спорного адресата и неопределённую отправку. После восстановления синхронизация сверяет состояние с провайдером, чтобы ни одно письмо не потерялось и не получило повторный ответ.
Частые вопросы
Обычно нет. Доступ ограничивают нужным ящиком, папкой, меткой, отправителями, полями и действиями утверждённого процесса.
Разделение уменьшает последствия ошибки и не позволяет компоненту, который читает недоверенный текст, автоматически отправлять внешние сообщения.
Как недоверенное содержание для анализа. Правила процесса, инструменты, права и порядок согласования должны находиться вне письма.
Используйте устойчивый ключ действия, сохраняйте идентификаторы провайдера и проверяйте отправленное состояние перед повтором после неопределённого ответа.
Если нужно определить границы почтового доступа, согласование и обработку отказов, обсудите автоматизацию с MYOD.
