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

2025 год формируется как год искусственного интеллекта. С быстрым ростом LLM и опыта работы с агентами, нас часто спрашивают: как принять эту новую эру? И какие новые варианты использования аутентификации и авторизации агентов ИИ? В этой статье мы рассмотрим типичный опыт работы с агентами и укажем на сценарии безопасности и аутентификации.

Опыт аутентификации оператора ChatGPT#

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

Во время оформления заказа у меня запросили войти в систему, затем передали контроль обратно мне.

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

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

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

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

Как это обсуждалось в X Threads.

Как обрабатываются учетные данные, и каковы риски безопасности?#

Прямое предоставление агенту ИИ ваших учетных данных#

В этом подходе ИИ вводит открытые учетные данные (например, email и пароль) от вашего имени. Например, агент ИИ может запросить ваши данные для входа и ввести их за вас.

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

Вместо открытых учетных данных Персональные Токены Доступа (PATs) предлагают более безопасный способ предоставления доступа без необходимости ввода пароля или интерактивного входа в систему. PATs полезны для CI/CD, скриптов и автоматизированных приложений, которым нужен программный доступ к ресурсам. Для повышения безопасности лучше ограничивать охват PAT, устанавливать время истечения и позволять отзывать их для предотвращения утечек и захвата учетных записей.

Делегирование пользователя через OAuth#

OAuth (Open Authorization) является широко используемым стандартом для делегированной авторизации в Интернете. Он позволяет пользователям предоставлять стороннему приложению ограниченный доступ к своим данным на другом сервисе без передачи своих учетных данных для входа.

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

Лучший способ обработки этого сценария — авторизовать оператора ChatGPT (или любого другого агента) на чтение и запись на Airbnb без передачи пароля или учетных данных. Вместо того, чтобы позволять оператору входить напрямую, вы можете предоставить доступ через безопасный процесс авторизации.

На мой взгляд, если оператор OpenAI хочет усилить доверие и безопасность идентификации, существует несколько способов достичь этого.

1. Вынести процесс входа за пределы оператора: Обработка входа пользователя вне ChatGPT оператора. Это означает, что вы можете нажать кнопку «Войти с помощью [Сервис]» и быть перенаправленным на защищенную страницу входа сервиса для аутентификации себя, полностью вне чата или оператора ChatGPT. Например, если бы существовал плагин Airbnb, вы были бы отправлены на сайт Airbnb для ввода ваших учетных данных и авторизации ChatGPT, после чего плагин получит токен. ChatGPT получит только временный токен доступа или ключ, который предоставит ограниченный доступ (например, «чтение моего маршрута»), вместо того чтобы видеть ваш фактический пароль.

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

   Страницы подключения Notion

   Вот еще один пример, как интеграция маркетплейса Slack с Notion. Slack запрашивает доступ к конкретному рабочему пространству Notion, он может читать статьи и представлять их в ваших каналах Slack.

В то же время Slack также предоставляет страницу согласия для авторизации Notion на доступ к рабочему пространству в процессе.

Оператор ChatGPT должен принять подобный подход, интегрируя OAuth, позволяя агенту безопасно получить доступ к множеству сторонних сервисов. Таким образом, он может получить доступные токены с необходимыми разрешениями для выполнения задач в безопасности.

Увеличение уровня аутентификации для чувствительных действий#

Агент ИИ может выполнять рутинные задачи самостоятельно и автономно, но для высокорисковых действий требуется дополнительная проверка для обеспечения безопасности, — таких как отправка средств или изменение настроек безопасности — пользователь должен подтвердить свою личность с помощью многофакторной аутентификации (MFA). Это может быть сделано через push-уведомления, одноразовые пароли (OTPs) или биометрическое подтверждение.

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

Для повышения безопасности без ущерба для пользовательского опыта, адаптивная аутентификация и MFA должны использоваться для определения, когда необходима дополнительная проверка. Триггеры на основе рисков, такие как изменения IP или необычное поведение, помогают минимизировать излишние запросы на аутентификацию.

Федеративная идентификация и единый вход (SSO) для многоплатформенных экосистем#

В многоплатформенной корпоративной экосистеме агенты ИИ часто должны взаимодействовать с различными платформами. Чтобы упростить аутентификацию, пользователи проходят аутентификацию один раз через поставщика идентификации (IdP), такого как Okta, Azure AD или Google Workspace. Затем агенты аутентифицируются с использованием SAML, OpenID Connect (OIDC), с управлением доступом через ролевое (RBAC) или атрибутное (ABAC) управление доступом.

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

Управление областью и разрешениями#

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

1. Минимальные привилегии – предоставляйте только те разрешения, которые необходимы для выполнения задачи.
2. Временный доступ – ограничивайте продолжительность доступа для уменьшения рисков безопасности.

Управление доступом на основе ролей (RBAC) помогает управлять областью агента, назначая определенные роли для выполнения конкретных задач. Для более гранулярного контроля атрибутное управление доступом (ABAC) позволяет динамическое, контекстно-зависимое управление разрешениями, гарантируя, что агенты ИИ имеют доступ только к тем данным, которые им нужны в данный момент.

Подключение серверов MCP с аутентификацией#

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

Почему сервер MCP связан с аутентификацией, и почему это важно?#

Мы ранее писали статью, который поможет вам понять что такое сервер MCP.

Сервер MCP является ключевой частью протокола Model Context, выступая мостом между моделями ИИ и внешними источниками данных. Он позволяет выполнять запросы в реальном времени и извлекать данные из таких сервисов, как Slack, Gmail и Google Calendar. Создав сервер MCP, вы можете подключить эти удаленные сервисы к LLM, улучшив ваши приложения с поддержкой ИИ за счет лучшего контекста и более умного выполнения задач.

В отличие от систем Retrieval-Augmented Generation (RAG), которые требуют создания эмбеддингов и хранения документов в векторных базах данных, сервер MCP получает доступ к данным напрямую без предварительной индексации. Это означает, что информация не только более точная и актуальная, но и интегрируется с меньшими вычислительными нагрузками без ущерба для безопасности.

Источник: https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained

Для агентов ИИ, использующих сервер MCP, множество взаимодействий происходит между сервером MCP, LLM, агентом и пользователем.

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

Аутентификация агентов выходит на новый уровень — ваш продукт должен адаптироваться#

Отличный пример — Composio.dev, ориентированная на разработчиков платформа интеграции, которая упрощает, как агенты ИИ и LLM подключаются к внешним приложениям и сервисам. Названо «Аутентификация для агентов ИИ для действий от имени пользователей», по сути, оно предоставляет коллекцию серверов MCP (коннекторы), которые могут быть легко интегрированы в продукты с поддержкой ИИ.

Как человек в области аутентификации, но на самом деле, это всего лишь малая часть широкой области CIAM (Управление идентификацией и доступом клиентов). То, что они создали, на самом деле — это коллекция серверов MCP (коннекторов) — полезно, но только малая часть того, что охватывают полные решения CIAM.

Основываясь на предыдущих примерах, если мы рассматриваем Google Drive (удаленные сервисы) как сервер MCP вместо Airbnb, это становится больше, чем просто интеграция сторонних компаний — это служит внешним источником данных. Это позволяет агенту получить доступ к контекстной информации, взаимодействовать с LLM и потенциально получать разрешения на создание, чтение, обновление и удаление (CRUD) файлов.

Тем не менее, основные требования к аутентификации и авторизации остаются прежними.

Используйте Logto для обработки аутентификации продуктов ваших агентов#

Logto — универсальное CIAM-решение, которое поддерживает продукты SaaS и агентов ИИ, делая аутентификацию и авторизацию беспроблемной. Вот почему:

1. Управляемая аутентификация для продуктов агентов ИИ – Logto поддерживает OAuth 2.0, SAML, ключи API, персональные токены доступа и JWT, позволяя легко интегрироваться с несколькими серверами MCP. Вы даже можете создать свой собственный сервер MCP и подключить его к Logto благодаря его стандарту открытого протокола.
2. Возможности поставщика идентификаций (IdP) – Когда у вашего продукта появятся состоявшиеся пользователи, Logto может действовать как IdP, превращая ваш сервис в сервер MCP и интегрируя его в экосистему ИИ.
3. Продвинутая авторизация
   1. Ролевое управление доступом (RBAC) для управления ролями пользователей
   2. Пользовательский JWT-ориентированный ABAC для детализированного, динамического управления доступом
4. Улучшенная безопасность – такие функции, как многофакторная аутентификация (MFA) и повышение уровня аутентификации, помогают защитить критические действия и повысить безопасность агента.

Есть вопросы? Свяжитесь с нами, чтобы узнать, как Logto может улучшить ваш опыт работы с агентом ИИ и удовлетворить ваши потребности в безопасности.