Почтовый агент: как подключить AI к отдельному ящику и не сломать безопасность

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

Этот материал — практический справочник по почтовым агентам. Не «как включить ИИ в Gmail», а как собрать отдельный рабочий контур: один адрес — один процесс — понятный следующий шаг. Без магии, с понятной ролью человека и понятной зоной риска.

Главный выбор, который делает платформу: webhook-native доступ (агент узнаёт о новом письме мгновенно) или polling/IMAP (агент опрашивает ящик). От этого зависит архитектура, задержки, надёжность и стоимость поддержки. Дальше разберём, как это устроено у Google Workspace, Microsoft 365, Яндекс 360 и Cloudflare, и где граница, за которой лучше взять готовую платформу вместо своей интеграции.

Цель — чтобы после прочтения вы могли за один вечер решить: «нам нужен Graph + shared mailbox», или «нам нужен Cloudflare Email Service на отдельном поддомене», или «нам нужен Nylas, потому что клиенты на трёх разных почтах». С правилами безопасности и понятной ролью человека в каждом сценарии.

Что это

Почтовый агент — это отдельный рабочий контур, а не «кнопка написать ответ» в почтовом клиенте. В полезном бизнес-сценарии он:

принимает письма на конкретный адрес (отдельный от личной и рабочей почты команды);

видит тему, тело, отправителя, цепочку и вложения;

классифицирует письмо по типу задачи;

извлекает важные поля: имя, компанию, бюджет, сроки, документы, дедлайны, риски;

готовит черновик ответа или задаёт уточняющие вопросы;

создаёт карточку в CRM, задачу, тикет или запись в базе знаний;

оставляет человека в контуре подтверждения там, где есть риск.

Самый безопасный режим для старта: агент не отправляет письма сам, а создаёт черновики и структурированные заметки. Автономную отправку включают только для узких сценариев с понятными правилами. Это и есть «агент предлагает — человек подтверждает».

Зачем нужно

Отдельный почтовый агент закрывает реальную дыру в операционных процессах: входящие письма сегодня часто превращаются либо в шум в почте руководителя, либо в ручную работу команды, которая разбирает однотипные заявки, тендеры, резюме и документы. Агент делает первый слой разбора одинаково, без выходных и без потери контекста.

Где это даёт эффект сразу:

• приём заявок и лидов — извлечение полей, квалификация, черновик ответа, уведомление ответственному;
• тендерный ящик — сводка по дедлайну, требованиям и рискам для руководителя;
• документы, счета, акты — структурированная запись в учётной системе и задача согласующему;
• HR и входящие кандидаты — short-list и пригласительный/отказной черновик;
• support без тяжёлого helpdesk — первый слой ответов по базе знаний с эскалацией сложных;
• executive intake — фильтр шума и подготовленная сводка для руководителя.

Как устроено

Рабочий контур почтового агента выглядит одинаково независимо от платформы:

flowchart LR
 A["Письмо на отдельный адрес"] --> B["Агент классифицирует тип"]
 B --> C["Извлекает поля: кто, что, бюджет, сроки"]
 C --> D["Готовит черновик ответа"]
 D --> E["Создаёт задачу или запись в рабочей системе"]
 E --> F["Человек подтверждает отправку"]

На входе — отдельный адрес под конкретный процесс. На выходе — управляемое действие: карточка в CRM, задача в таск-трекере, тикет в helpdesk, запись в базе знаний или черновик ответа, который человек подтверждает или правит.

Главное различие между платформами — есть ли у них webhook-native доступ к почте (когда о новом письме агент узнаёт мгновенно, без опроса) или агенту приходится опрашивать ящик по IMAP. Это влияет на задержку, на надёжность и на сложность поддержки.

Сводная картина по платформам:

Платформа	Способ подключения	Webhook-native	Когда выбирать
Google Workspace	Gmail API + Pub/Sub push, либо маршрутизация копии	Да	Кастомный агент на корпоративной почте
Microsoft 365	Microsoft Graph + change notifications, shared mailbox	Да	Enterprise, общие ящики команды
Яндекс 360	IMAP/SMTP + OAuth, правила обработки писем	Нет (polling / IMAP IDLE)	Российский рынок, платный тариф 360
Mail.ru / VK WorkMail	IMAP/SMTP, OAuth или пароль приложения	Нет	1–2 ящика, небольшие команды
Cloudflare Email Service	Email Routing → Worker (open-source Agentic Inbox)	Да	Быстрый пилот на отдельном поддомене
Helpdesk-платформы	Входящая почта превращается в тикеты	—	Поддержка клиентов с готовым процессом
Unified email API	Один API для Gmail, Outlook, Exchange, IMAP	Да	SaaS-продукт под разные почты клиентов

Коротко по платформам:

• Google Workspace и Microsoft 365 дают полноценный API-доступ к ящикам и событиям.
• Яндекс 360 в реальном внедрении чаще подключается через IMAP/SMTP с OAuth и админские правила маршрутизации. Бесплатный доступ по IMAP/SMTP сворачивается — нужен платный тариф.
• Cloudflare Email Service с открытым приложением Agentic Inbox удобен для быстрого запуска отдельного агентного ящика на домене или поддомене через Email Routing.
• Helpdesk-платформы (Zendesk, Front, Freshdesk, Intercom) продают похожую ценность как часть поддержки, но хуже подходят под кастомный бизнес-процесс.
• Унифицированные API (Nylas, Unipile, EmailEngine) — прослойка, когда нужно подключать клиентов с разными почтовыми системами.

Google Workspace / Gmail

Google Workspace — один из самых удобных вариантов для подключения агента к отдельному корпоративному email.

Рабочая схема:

• создать отдельный ящик или группу, например leads@company.com;
• подключить приложение через Gmail API;
• подписаться на изменения через Gmail API push notifications и Google Cloud Pub/Sub;
• при новом письме забирать сообщение и вложения через Gmail API;
• создавать черновик ответа, отправлять ответ или ставить метки;
• при необходимости создавать задачу во внешней системе.

Подписка на новые письма строится через метод users.watch, который привязывает ящик к вашему Pub/Sub-топику:

POST https://gmail.googleapis.com/gmail/v1/users/me/watch
{
  "topicName": "projects/my-project/topics/gmail-inbox",
  "labelIds": ["INBOX"]
}

Важная деталь: watch живёт не дольше 7 дней, поэтому его нужно периодически продлевать (обычно — повторным вызовом users.watch раз в сутки по расписанию). Иначе уведомления тихо прекратятся, и агент перестанет видеть новые письма.

Для корпоративного внедрения есть два уровня доступа.

Первый — пользовательская авторизация OAuth для конкретного ящика. Хорошо для пилота: владелец ящика явно даёт приложению доступ.

Второй — domain-wide delegation. Это админский механизм Google Workspace: сервисное приложение получает доступ к данным пользователей организации без отдельного согласия каждого. Режим мощный, поэтому обязательны минимальные scopes, отдельный сервисный аккаунт, список разрешённых ящиков и журналирование.

Если в организации включён multi-party approval, авторизация domain-wide delegation потребует подтверждения второго супер-админа. Google рекомендует регулярно пересматривать сервисные аккаунты и удалять неиспользуемые.

Встроенный Gemini в Gmail — это помощник для пользователя внутри интерфейса, а не кастомный агент на отдельном бизнес-ящике. Gemini помогает с summary и черновиком, но для процесса «письмо пришло → агент разобрал → создал задачу → подготовил ответ по правилам компании» нужен отдельный интеграционный слой.

Маршрутизация отдельного адреса

Если компания не хочет давать агенту прямой API-доступ к ящику, можно использовать маршрутизацию. Google Workspace поддерживает split delivery, dual delivery, forwarding / address maps и compliance routing.

Для агентного сценария это даёт несколько вариантов:

• письмо остаётся в Gmail, а копия уходит агенту;
• отдельный адрес пересылается на агентный поддомен;
• агент получает только письма с определёнными признаками (с вложениями, от конкретных доменов).

Удобно, когда надо пилотировать агента без изменения MX домена и без переноса всей почты.

Microsoft 365 / Outlook / Exchange Online

Microsoft 365 часто даже удобнее для enterprise-сценариев: Microsoft Graph хорошо покрывает почту, shared mailboxes и события.

Рабочая схема:

• создать shared mailbox, например requests@company.com;
• зарегистрировать приложение в Microsoft Entra ID;
• выдать приложению минимальные права на нужный ящик;
• подписаться на изменения через Microsoft Graph change notifications;
• при новом письме забирать сообщение через Microsoft Graph Mail API;
• создавать черновик, ответ, категорию, задачу или запись в helpdesk.

Подписка на новые письма создаётся так:

POST https://graph.microsoft.com/v1.0/subscriptions
{
  "changeType": "created",
  "notificationUrl": "https://your-app.example.com/graph-webhook",
  "resource": "users/requests@company.com/mailFolders('inbox')/messages",
  "expirationDateTime": "2026-06-25T18:00:00Z",
  "clientState": "secret-state-value"
}

Для разовых операций со shared mailbox подойдут делегированные права Mail.Read.Shared / Mail.ReadWrite.Shared. Но для подписки на change notifications (webhooks) делегированные .Shared-права не работают — нужны application-права (Mail.Read / Mail.ReadWrite). По умолчанию application-права дают доступ ко всем ящикам тенанта, поэтому их обязательно ограничивают одним ящиком через application access policy (RBAC for Applications) в Exchange Online. Microsoft Graph не поддерживает доступ к in-place archive mailboxes.

Shared mailbox — естественная модель для support, sales intake, тендеров, бухгалтерских документов и внутренних сервисных адресов: ящик виден команде, а агент работает как первый слой разбора. Для маршрутизации и копий используются Exchange Online mail flow rules.

Copilot в Outlook решает соседнюю задачу — помогает пользователю суммировать цепочки и писать ответы. Но для отдельной агентной роли («агент входящих заявок», «агент тендеров», «агент HR-резюме») обычно нужен собственный workflow через Graph, shared mailbox и внешнюю бизнес-логику.

Яндекс 360

Яндекс 360 важен для российского рынка: корпоративная почта на домене, shared mailboxes и админские правила.

Реалистичная схема подключения агента:

• создать отдельный ящик или shared mailbox, например zayavki@company.ru;
• подключиться к ящику по IMAP/SMTP с OAuth (механизм XOAUTH2, как у Gmail);
• читать входящие письма и вложения;
• отправлять ответы через SMTP или создавать черновики/уведомления во внешней системе;
• при необходимости настроить правила обработки писем в админке (admin.yandex.ru → Почта → Правила для писем).

Бесплатный доступ к Яндекс Почте по протоколам IMAP/SMTP/POP3 сворачивается — для стабильной работы агента нужен платный тариф Яндекс 360. Это стоит заранее заложить в план внедрения и сверить с актуальными условиями Яндекс 360 перед запуском.

Отличие от Google и Microsoft: меньше ощущения «готового webhook-native email API». Поэтому для агента чаще нужен polling или IMAP IDLE, аккуратная обработка повторов, статусов прочтения, папок и ошибок SMTP. Для интеграций есть API Яндекс 360 и сценарий со шлюзом входящей почты.

Mail.ru / VK WorkMail и другие IMAP/SMTP-провайдеры

Для Mail.ru, VK WorkMail и других провайдеров базовая модель такая же: IMAP для чтения, SMTP для отправки, OAuth или пароль приложения для авторизации, если это разрешено настройками безопасности.

Это рабочий путь для небольших компаний, но менее удобен для масштабного агентного продукта:

• нет единого webhook-механизма;
• сложнее аккуратно обрабатывать статусы писем;
• надо отдельно следить за rate limits и блокировками;
• безопасность зависит от правильной настройки паролей приложений, OAuth и доступов;
• audit trail обычно слабее, чем в Google Workspace или Microsoft 365.

Для одного-двух ящиков можно подключаться напрямую через IMAP/SMTP. Для продукта на множество клиентов лучше рассмотреть унифицированную прослойку.

Cloudflare Email Service и Agentic Inbox

Cloudflare Email Service — другой класс решения. Он не подключается к существующему Gmail или Яндекс-ящику как клиент, а строит агентный email-контур на инфраструктуре Cloudflare. В апреле 2026 на Agents Week сервис вышел в public beta и объединил отправку (Email Sending) и входящую маршрутизацию (Email Routing) в один продукт.

Вместе с ним Cloudflare открыла Agentic Inbox — open-source reference-приложение (self-hosted почтовый клиент с AI-агентом), которое показывает, как собрать такой контур целиком.

Как это устроено:

• домен или поддомен обслуживается Cloudflare DNS;
• входящая почта проходит через Cloudflare Email Routing и попадает в Worker;
• каждый ящик изолирован в своём Durable Object с базой SQLite, вложения хранятся в R2;
• агент на Cloudflare Agents SDK и Workers AI читает письмо и готовит черновик ответа;
• встроенный MCP-сервер позволяет внешним агентам готовить черновики на ваше подтверждение;
• человек смотрит inbox и подтверждает отправку.

Обработка входящего письма в Worker выглядит примерно так:

export default {
  async email(message, env, ctx) {
    const from = message.from;
    const subject = message.headers.get("subject");
    const raw = await new Response(message.raw).text();

    // классификация и черновик через Workers AI,
    // состояние ящика — в Durable Object, вложения — в R2
    await env.INBOX.handleIncoming({ from, subject, raw });
  },
};

Сильная сторона подхода — быстрый запуск отдельного агентного адреса без тяжёлой интеграции с корпоративной почтой. Например: brief@ai.company.com, lead@inbox.company.com, tender@agent.company.com, docs@intake.company.com. Основная почта при этом остаётся в Google, Microsoft или Яндекс.

Для Email Routing на основном домене нужны MX-записи Cloudflare. Если company.com уже обслуживается Google Workspace или Яндекс 360, нельзя включить маршрутизацию только для одного адреса agent@company.com без учёта всей почты домена. Чистый путь — отдельный поддомен или пересылка из существующей почтовой системы.

Helpdesk-платформы: Zendesk, Front, Freshdesk, Intercom

Если задача — поддержка клиентов, часто не нужно начинать с низкоуровневого подключения к email. Уже есть платформы, где письмо превращается в тикеты, очереди, SLA, базу знаний и AI-ответы.

Типовые возможности:

• входящие письма превращаются в тикеты;
• AI классифицирует обращение;
• AI предлагает ответ или отвечает сам в разрешённых сценариях;
• сложные обращения эскалируются человеку;
• есть аналитика, SLA, роли, история клиента.

Хороший путь, если у компании уже есть support-процесс или много обращений. Минус: такие системы менее удобны для кастомных задач вроде разбора инвестиционных заявок, тендерных ТЗ или юридического intake — там слишком много helpdesk-логики и мало свободы для своего агента.

Unified email API: Nylas, Unipile, EmailEngine

Если нужно строить агентный продукт, подключающийся к почте разных клиентов, прямые интеграции с Google, Microsoft, Яндекс и IMAP быстро становятся дорогими в поддержке. В этом случае полезны unified email API:

• один API для Gmail, Outlook, Exchange и IMAP;
• единая модель сообщений, потоков, папок и вложений;
• webhooks для новых сообщений;
• хранение и обновление OAuth-токенов.

Минусы: появляется внешний посредник с доступом к почте; нужна проверка безопасности и хранения данных; стоимость растёт с числом ящиков; для российских клиентов важен вопрос юрисдикции.

Провайдер	Модель	Когда подходит
Nylas	Управляемый SaaS, шире по календарю и контактам	Нужны почта + календарь + контакты без своих серверов
Unipile	Управляемый SaaS, multi-channel (почта + мессенджеры)	Несколько каналов общения в одном API
EmailEngine	Self-hosted, фиксированная цена (около $995/год)	Данные не должны покидать вашу сеть, нужен только email

Когда использовать

Каждый сценарий — это отдельный адрес, набор извлекаемых полей и результат.

Приём и разбор заявок — leads@company.com

Извлекает: кто написал, из какой компании, что хочет, бюджет, сроки, регион, насколько заявка подходит, какой следующий вопрос задать.

Результат: карточка в CRM, черновик ответа, уведомление ответственному.

Тендерный ящик — tender@company.com

Извлекает: дедлайн подачи, требования, список документов, критерии оценки, риски, предварительный go/no-go.

Результат: короткая сводка для руководителя и список действий.

Документы, счета, акты, договоры — docs@company.com

Извлекает: тип документа, контрагента, сумму, срок оплаты или подписания, кто согласует, какие вложения пришли.

Результат: запись в учётной системе, задача ответственному, черновик ответа.

HR и входящие кандидаты — jobs@company.com

Извлекает: имя, роль, опыт, ссылки, соответствие вакансии, вопросы для следующего шага.

Результат: short-list, отказной или пригласительный черновик, карточка кандидата.

Support без тяжёлого helpdesk — support@company.com

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

Результат: быстрый первый слой поддержки без полноценной внедрённой системы.

Executive / office intake — office@company.com

Отделяет важные письма от шума, готовит краткую сводку, предлагает ответ, создаёт follow-up задачи.

Результат: руководитель меньше тонет во входящих и не теряет контроль.

Как выбрать подход

Короткая карта решений:

• Google Workspace: для кастомного агента — Gmail API + Pub/Sub; для осторожного пилота — forwarding или dual delivery на агентный адрес; для масштаба — admin review domain-wide delegation.
• Microsoft 365: лучший путь — shared mailbox + Microsoft Graph + change notifications; для маршрутизации — Exchange Online mail flow rules; права приложения ограничить только нужным ящиком.
• Яндекс 360: начать с отдельного ящика или shared mailbox; подключить через IMAP/SMTP OAuth (с платным тарифом); использовать правила обработки писем; заранее продумать polling, дедупликацию и журналирование.
• Не трогая основную почту: создать поддомен ai.company.com или inbox.company.com, подключить его к Cloudflare Email Routing, запустить Agentic Inbox на отдельном адресе, при необходимости настроить пересылку.
• Нужен готовый support: смотреть Zendesk, Front, Freshdesk, Intercom; не писать свой агент, пока не понятно, что helpdesk-платформы не хватает.
• SaaS для разных клиентов: рассмотреть Nylas, Unipile или EmailEngine; отдельно проверить безопасность, хранение данных, OAuth scopes, стоимость и юрисдикцию.

Рекомендуемый MVP

Самый практичный первый шаг — «AI intake mailbox».

Что запускаем:

• один адрес под конкретный процесс;
• агент читает входящие, классифицирует письмо, извлекает structured summary;
• создаёт черновик ответа и задачу или запись в рабочей системе;
• человек подтверждает отправку.

Чего не делаем на первом этапе:

• не даём агенту полный доступ ко всей корпоративной почте;
• не включаем автономную отправку без правил;
• не смешиваем несколько бизнес-процессов в одном ящике;
• не обещаем замену CRM, helpdesk или секретаря.

Хорошие первые адреса: brief@…, leads@…, tender@…, docs@…, support@….

Риски и стоп-линии

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

Стоп-линии для внедрения:

• Агент не выполняет инструкции из письма как системные команды.
• Агент не отправляет деньги, не меняет договоры, не раскрывает персональные данные и не подтверждает обязательства без человека.
• Агент не имеет доступа ко всей почте компании, если нужен только один ящик.
• Секреты, OAuth-токены и API-ключи не попадают в письма, логи и заметки.
• Вложения проверяются и обрабатываются осторожно.
• Ведётся история действий: что пришло, что агент предложил, кто подтвердил.

Безопасная модель простая: агент предлагает, человек подтверждает.

Юридический аспект для России: трансграничная передача и локализация данных

Зарубежная почтовая инфраструктура = персональные данные за границей. Если агент обрабатывает письма с персональными данными граждан РФ через иностранные сервисы (Google Workspace, Microsoft 365, Cloudflare, Nylas, Unipile и т. п.), это подпадает под два требования российского законодательства.

Трансграничная передача данных — ст. 12 Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных». С 1 марта 2023 года оператор обязан до начала передачи подать в Роскомнадзор отдельное уведомление о намерении осуществлять трансграничную передачу (отдельно от уведомления об обработке). Роскомнадзор вправе запретить или ограничить такую передачу.

Локализация данных — ч. 5 ст. 18 того же закона (введена Федеральным законом от 21.07.2014 № 242-ФЗ): сбор, запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан РФ должны выполняться в базах данных на территории России.

На практике: первичную базу с данными россиян держите в РФ, а использование зарубежной почты для агента оформляйте как трансграничную передачу — с уведомлением Роскомнадзора и правовым основанием (например, согласием субъектов). Для чувствительных процессов с данными граждан РФ это весомый аргумент в пользу Яндекс 360, Mail.ru / VK WorkMail и российской инфраструктуры. Это не юридическая консультация — перед внедрением проверьте схему с юристом по 152-ФЗ.

Главная ценность не в том, что агент «умеет читать почту». Ценность в том, что у компании появляется управляемый входной канал: письмо превращается в структурированную работу, черновик ответа и понятный следующий шаг. Если у вас уже есть поток писем, который хочется превратить в управляемый процесс, начать стоит с одного адреса под одну задачу — так быстрее всего увидеть пользу без риска.

Ограничения

Ограничения

Что учитывать

Короткое вводное предложение о том, где граница применимости.

Webhook-native есть не у всех

— Google Workspace и Microsoft 365 дают push-уведомления; Яндекс 360 и Mail.ru чаще живут на polling и IMAP IDLE, что усложняет надёжность и задержки.

Domain-wide delegation

— мощный и опасный — сервисное приложение получает доступ ко всей организации, поэтому обязательны минимальные scopes, отдельный сервисный аккаунт и журналирование.

Watch живёт 7 дней

— users.watch в Gmail требует периодического продления, иначе уведомления тихо прекратятся.

Application-права в Microsoft 365 дают доступ ко всем ящикам

— обязательно ограничивать одним ящиком через application access policy (RBAC for Applications) в Exchange Online.

Cloudflare Email Routing требует MX на основном домене

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

Бесплатный IMAP/SMTP в Яндекс Почте сворачивается

— для стабильной работы агента нужен платный тариф Яндекс 360.

Helpdesk-платформы плохо подходят под кастомные процессы

— для тендеров, юридического intake и инвестиционных заявок слишком много helpdesk-логики и мало свободы.

Unified email API добавляет посредника с доступом к почте

— нужно проверять безопасность, хранение данных, OAuth scopes, стоимость и юрисдикцию; для российских клиентов это критично.

Зарубежная почтовая инфраструктура и персональные данные РФ

— 152-ФЗ требует уведомления Роскомнадзора о трансграничной передаче и локализации первичной базы данных в РФ.

Антипаттерны

Антипаттерны

Чего не делать

Короткое вводное предложение о типичных ошибках внедрения.

Дать агенту полный доступ ко всей корпоративной почте — даже если «временно удобно»:

одно письмо с prompt injection ломает всю организацию.

Включить автономную отправку писем без правил

— агент не должен сам подтверждать обязательства, отправлять деньги или раскрывать персональные данные.

Выполнять инструкции из тела письма как системные команды

— это prompt injection; письмо — недоверенный вход.

Смешивать несколько бизнес-процессов в одном ящике

— теряется и логика разбора, и границы безопасности; один адрес — один процесс.

Забыть продлевать `users.watch`

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

Использовать делегированные `.Shared`-права для подписки на webhooks в Microsoft 365

— для change notifications нужны application-права, иначе подписка не заработает.

Обещать замену CRM/helpdesk/секретаря на первом этапе

— это другой класс задач с другой экономикой и другой зоной риска.

Хранить OAuth-токены и API-ключи в письмах, логах и заметках

— это прямой путь к утечке, отдельная строка в правилах безопасности.

Чеклист

Чеклист

Проверка перед запуском

Короткое вводное предложение о том, что должно быть готово до пилота.

Один адрес под один процесс

— а не общий ящик «на всё».

Права приложения ограничены только нужным ящиком

— без доступа ко всей почте.

Способ получения писем решён

— webhook/push или polling/IMAP IDLE, с учётом продления подписок.

Дедупликация писем

— одно событие не обрабатывается дважды.

Вложения проверяются и обрабатываются осторожно

— без автоматического выполнения инструкций из файлов.

Агент не выполняет инструкции из тела письма как команды

— prompt injection обработан явно.

Деньги, договоры и персональные данные

— только через подтверждение человека.

Журналирование включено

— что пришло, что предложил агент, кто подтвердил.

Секреты и OAuth-токены не попадают в письма, логи и заметки.

Юридическая схема проверена — для данных граждан РФ:

уведомление Роскомнадзора о трансграничной передаче и локализация первичной базы.

Ссылки

Ссылки

• Документация: Gmail API push notifications
• Документация: Gmail API users.watch
• Источник: Google Workspace domain-wide delegation
• Источник: Email routing and delivery options
• Источник: Microsoft Graph mail API overview
• Источник: Outlook change notifications
• Источник: Microsoft Graph change notifications
• Источник: Exchange Online mail flow rules
• Источник: OAuth-авторизация в Яндекс Почте
• Источник: Правила обработки писем
• Источник: API Яндекс 360
• Документация: Стандарт безопасной работы Яндекс 360
• Документация: Cloudflare Email Service
• Документация: Email Routing → Worker handler
• Материал: Email for agents (анонс)
• Репозиторий: Agentic Inbox (GitHub)

По теме

По теме

• База знаний: API как язык между сервисами: что это, зачем нужно и как читать ответы
• База знаний: Google Workspace: как собрать корпоративную почту и рабочий контур на домене компании — без боли, с запасом по безопасности
• База знаний: Границы доверия: что отдать агенту в Notion, а что оставить себе