Microsoft 365 Copilot: как принести своих агентов, не теряя контроля daily

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

Проблема контроля и гибкости в M365 Copilot

При попытке интегрировать свои кастомные агентские сервисы в Microsoft 365 Copilot, многие разработчики сталкиваются с серьезными трудностями. «Очевидный путь», предполагающий перестройку агента с использованием стандартных M365 Copilot Agents (декларативных или с кастомным движком), часто приводит к неприемлемой потере контроля. Это означает отказ от собственного выбора фреймворков, логики оркестровки, управления сессиями и способов взаимодействия с нижестоящими сервисами от имени авторизованного пользователя.

Разработчики могут быть недовольны таким подходом, поскольку он ограничивает их свободу в создании сложных, специализированных решений. Теряются такие важные аспекты контроля, как полная собственность над агентской логикой, включая выбор модели большого языка (LLM), настройку промптов, управление инструментами и хранилищем сессий. Стандартные средства M365 Copilot не всегда могут удовлетворить требования к прокодовому подходу, а также к обеспечению пользовательского делегированного доступа к собственным базам данных, API или другим корпоративным ресурсам через цепочку OBO-потоков. Этот метод необходим для тех, кто стремится к полному контролю над всей цепочкой токенов от начала до конца, что критически важно для сложных корпоративных интеграций.

Архитектура решения: Gateway и On-Behalf-Of

Для преодоления описанных ограничений Microsoft предлагает архитектуру, основанную на использовании M365 Gateway — безстейтсового сервиса, который выступает в роли посредника между Microsoft 365 Copilot и собственным агентским сервисом разработчика. Основные функции Gateway включают обработку протокола Bot Framework, валидацию токенов, направленных на канал, выполнение первого обмена токенов по принципу On-Behalf-Of (OBO) и преобразование диалогов Copilot в нативный API для агентского сервиса. Это позволяет сохранять существующий агентский сервис практически нетронутым, оставаясь агностиком по отношению к Bot Framework или Teams.

M365 Gateway отделяет обязанности, связанные с протоколом Bot Framework и аутентификацией канала, от основной бизнес-логики агентского сервиса. Это создает независимые границы доверия, позволяя Gateway масштабироваться для обработки большого числа запросов, в то время как агентский сервис может сосредоточиться на выполнении своей задачи. Если агентский сервис владеет нижестоящим делегированным доступом, он должен самостоятельно валидировать входящий служебный токен на своей границе и использовать это подтверждение для собственной OBO-цепочки.

В этой архитектуре ключевую роль играет поток токенов On-Behalf-Of (OBO). Как объясняется в документации Microsoft, OBO-поток позволяет одному веб-API использовать удостоверение пользователя для вызова другого веб-API. Цель состоит в том, чтобы передать идентификацию и разрешения пользователя по всей цепочке запросов, не требуя от промежуточных сервисов взаимодействия с пользователем для получения согласия. Вместо этого доступ к нижестоящему API предоставляется заранее, как часть шага согласия во время аутентификации. Gateway инициирует первый обмен OBO-токенами, получая токен, представляющий пользователя, и передает его агентскому сервису. Этот механизм гарантирует, что пользовательская идентичность безопасно делегируется между сервисами, без прямого обмена учетными данными или их хранения.

Детальный поток токенов и безопасность

Пользовательская идентичность в предложенной архитектуре передается по цепочке сервисов благодаря двум последовательным OBO-обменам, что является краеугольным камнем безопасности. Главный принцип заключается в том, что ни один сервис никогда не хранит и не кэширует пользовательские пароли. Каждый сервис получает утверждение с ограниченной областью действия (scoped assertion) и обменивает его на токен для следующего перехода в цепочке. Оригинальный пароль пользователя никогда не покидает OBO-цепочку и не виден ни одному из промежуточных сервисов.

Валидация JWT (JSON Web Token) является незыблемым требованием и разделена по границам ответственности. M365 Gateway обязан валидировать токен, обращенный к Bot Framework/каналу, который он получает от Microsoft 365. Это гарантирует легитимность входящего запроса. В свою очередь, агентский сервис должен валидировать входящий токен-носитель (service-scoped bearer), прежде чем использовать его для выполнения OBO-обмена, определения владельца сессии или ограничения области действия пользователя. Это критически важно для предотвращения несанкционированного доступа и поддержания целостности пользовательской сессии.

Рекомендуется разделение границ доверия между Gateway и агентским сервисом. Gateway занимается протоколом Bot Framework и аутентификацией канала, тогда как агентский сервис полностью владеет логикой доступа к данным и бизнес-процессам, никогда не нуждаясь в учетных данных Bot Framework. Такое разделение упрощает управление безопасностью и позволяет применять различные политики безопасности к каждому компоненту. Для повышения безопасности также рекомендуется использовать внутренний (internal-only) доступ к сервису, например, через приватный ингресс в Azure Container Apps. Если сервис остается доступным извне, он все равно должен применять те же самые строгие проверки валидации токенов и авторизации. В источниках нет данных о практических примерах или пошаговых руководствах для реализации этого решения в различных языках программирования или фреймворках, кроме общих указаний, что может усложнить внедрение для некоторых разработчиков. Валидированное утверждение связывается с асинхронно-безопасной ContextVar в промежуточном ПО сервиса, чтобы любой нижестоящий вызов OBO в рамках того же запроса автоматически его подхватывал, обеспечивая бесшовность и безопасность.

Преимущества и сценарии применения

Использование паттерна Gateway + OBO предоставляет разработчикам ряд существенных преимуществ, главным из которых является полная собственность над агентской логикой. Это включает возможность выбора предпочтительной технологии и фреймворка (например, LangChain, Semantic Kernel / Microsoft Agent Framework или собственная реализация), прокодовое управление LLM, промптами, инструментами и хранилищем сессий. Разработчики получают неограниченный контроль над оркестровкой, вызовами инструментов и нижестоящей аутентификацией, что критически важно для сложных корпоративных сценариев.

Этот подход особенно эффективен в случаях, когда стандартные M365 Copilot Agents (декларативные или на кастомном движке) не обеспечивают достаточного уровня контроля. Паттерн Gateway + OBO предпочтителен, если требуется пользовательский делегированный доступ к нижестоящим сервисам (базам данных, API, MCP-серверам) через цепочки OBO-потоков, и разработчик хочет полностью владеть этой цепочкой токенов. Он также позволяет независимое масштабирование компонентов: Gateway может масштабироваться до множества реплик, а агентский сервис — с учетом требований к памяти сессий. Гибкость разработки значительно повышается, так как существующие агентские сервисы можно адаптировать для работы с M365 Copilot, написав лишь Gateway и клиентский адаптер, не меняя основной логики сервиса.

Вместе с тем, в источниках отсутствуют данные о производительности и потенциальных затратах на развертывание и эксплуатацию Gateway и агентского сервиса в Azure Container Apps для больших нагрузок, что является важным аспектом при планировании масштабных внедрений. Тем не менее, возможность адаптировать существующие решения без значительных переработок и сохранение контроля над ключевыми аспектами делают этот паттерн привлекательным для многих корпоративных разработчиков.

Что это значит

Представленный Microsoft подход с использованием Gateway и механизма On-Behalf-Of (OBO) радикально меняет правила игры для разработчиков, желающих интегрировать свои агентские сервисы в Microsoft 365 Copilot. Он устраняет компромиссы между функциональностью и контролем, позволяя создавать высокоспециализированные и безопасные решения. Это открывает путь к созданию индивидуальных пользовательских сценариев с полной ответственностью за логику, фреймворки и управление аутентификацией, что обеспечивает гибкость и масштабируемость для корпоративных приложений.