Что изменилось и что осталось прежним в области аутентификации и идентификации для агентных приложений
По мере того, как ИИ-агенты становятся более способными и связанными, создание безопасных и масштабируемых агентных продуктов требует прочной основы в аутентификации и идентификации. Это руководство разбивает по пунктам, что изменилось, что осталось прежним и что каждый разработчик должен знать, чтобы ориентироваться в новом ландшафте.
GuamianProduct & Design
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Недавно я просматривал эту статью, и упоминалась аутентификация агентов:
Мы видим намеки на то, как это может выглядеть. Например, последняя спецификация MCP включает фреймворк авторизации, основанный на OAuth 2.1, сигнализируя о возможности перехода к предоставлению ИИ-агентам ограниченных и отменяемых токенов вместо сырых секретов. Мы можем представить себе сценарий, где ИИ-агент не получает ваши настоящие ключи AWS, а вместо этого получает краткосрочные учетные данные или токен возможностей, позволяющий ему выполнять строго определенное действие.
Многие друзья и люди, не разбирающиеся в безопасности или CIAM, считают, что это что-то новое, но это определенно не так. OAuth — это стандартный протокол авторизации на основе токенов, который использует токены с ограниченными разрешениями (токены доступа). Эти токены имеют временные ограничения и ограничения по области, что обеспечивает безопасность и надлежащий контроль доступа к ресурсам и сервисам. На глобальном рынке программного обеспечения как услуги (до AI) большинство профессиональных решений для идентификации уже построено на этом.
Когда вы подключаете свою учетную запись Google к приложению третьей стороны, такому как Notion или Zoom, оно использует OAuth для запроса только необходимых разрешений, таких как доступ к вашему календарю или контактам, не раскрывая ваш пароль Google. Вы можете отозвать этот доступ в любое время через настройки своей учетной записи Google. Этот узел делегированного доступа — именно то, для чего предназначен OAuth, и это та же основа, которая распространяется на агентные приложения сегодня.
MCP сосредоточен на взаимодействии между LLM и инструментами и контекстом вашего приложения.
A2A сосредоточен на обеспечении обмена заданиями между агентами.
Но когда дело доходит до аутентификации и авторизации, оба по-прежнему полагаются на хорошо зарекомендовавшие себя промышленные стандарты, такие как OAuth.
Серверы авторизации MCP ДОЛЖНЫ реализовывать OAuth 2.1 с надлежащими мерами безопасности для конфиденциальных и неконфиденциальных клиентов.
Клиент A2A отвечает за получение необходимых учетных данных (например, токенов OAuth 2.0, ключей API, JWT) через процессы, внешние для самого протокола A2A. Это может включать потоки OAuth (authorization code, client credentials), безопасное распределение ключей и т.д.
Как говорит Google:
Вместо изобретения новых, проприетарных стандартов для безопасности и операций A2A стремится интегрироваться с существующей корпоративной инфраструктурой и широко принятыми лучшими практиками.
Много шумихи и контента FOMO утверждает, что по мере того, как агенты становятся все более распространенными, нам нужна система для управления идентичностями агентов.
Ответ: да и нет.
Да, потому что мы вводим новый слой между людьми и машинами. Есть реальные потребности в:
Управлении и идентификации агентов
Присвоении уникальных идентификаторов
Отслеживании логов
Аудите действий (чтобы знать, выполнена ли задача человеком или агентом)
Однако в большинстве технических случаев нет необходимости создавать формальную концепцию “Идентичность агента”.
Агент ≠ пользователь, ≠ учетная запись службы.
За каждым агентом все еще стоит пользователь, и идентичности пользователя обычно достаточно.
Сегодня большинство агентов:
Действуют на основе авторизации пользователя (например, токены OAuth)
Выполняют логику или вызывают API
Выполняют краткосрочные, одноразовые задачи (без необходимости отслеживания)
В этом смысле агент — это всего лишь функция как инструмент и не нуждается в глобально уникальном идентификаторе.
Например:
Агент GPT, вызывающий ваш API календаря, нуждается только в предоставленном вами доступе.
Агент LangChain не нуждается в идентичности, пока он может вызывать правильные инструменты, он работает.
M2M означает автоматизированный обмен данными между сервисами, без участия человека.
В этом контексте аутентификация часто использует клиентское приложение или учетные записи служб.
Если вы действительно хотите, чтобы ваш агент имел идентичность (для аудита и т.д.), вы можете использовать идентификатор приложения, и этого будет достаточно.
Вам все еще нужно определить архитектуру вашего продукта#
Это не изменилось. Независимо от того, включает ли ваш продукт агентов или нет, архитектура вашей системы идентификации зависит от того, кто ваши пользователи и как ваша система взаимодействует с ними.
Если вы создаете продукт для конечного пользователя с агентами:
Вам понадобятся легковесные методы входа (электронная почта, телефон, социальный логин) и единый пул пользователей для управления индивидуумами, которые взаимодействуют с вашим приложением и его агентами. Агенты действуют от имени этих пользователей, используя делегированные токены (например, через OAuth).
Пример:
Представьте, что вы создаете ИИ-ассистента по планированию или ИИ-бота календаря.
Каждый пользователь входит в систему с личной учетной записью Google. Ваша система использует OAuth, чтобы получить разрешение на доступ к их календарю. Агент не имеет собственной идентичности, он использует токен пользователя для планирования встреч, проверки доступности или отправки напоминаний. Архитектура идентификации проста: один глобальный пул пользователей, хранение токенов и отслеживание согласия для каждого пользователя.
Если вы создаете B2B платформу с агентами:
Вам нужно поддерживать идентификацию на уровне организации, а не только индивидуальных пользователей. Это включает:
Одноразовое Вход SSO для корпоративных клиентов
Разделение на уровне рабочих пространств или арендаторов
Политики делегирования агентов на уровне организации (например, управление тем, что агенты могут делать в рамках команд)
Видимость и логи на уровне администратора для всех действий агентов от имени сотрудников
Пример:
Представьте, что вы создаете платформу, предоставляющую ИИ-агентов для автоматизации внутренних рабочих процессов, например, бота-аналитика безопасности, который мониторит логи и отправляет оповещения, или помощника по продажам, который составляет электронные письма из данных CRM.
Каждая компания, использующая вашу платформу, хочет:
Входить в систему с использованием своего существующего SSO
Управлять тем, к чему агенты могут получить доступ (например, внутренние инструменты, системы документов)
Видеть, какой агент выполнял какую задачу под авторизацией какого сотрудника
В этом случае ваша архитектура идентификации должна поддерживать многопользовательский дизайн, ограниченные доступа агентов и организационные политики. Агенты все еще действуют от имени пользователей, но разрешения и границы идентичности применяются для каждого бизнес-арендатора.
В обоих случаях модель идентификации определяет, как агенты работают, к чему они могут получить доступ, и как ваша система обеспечивает подотчетность.
Используйте это руководство, чтобы помочь вам планировать архитектуру идентификации и продукта.
Предотвращает несанкционированный доступ даже если учетные данные скомпрометированы.
Пример: Если агент помогает вам выполнить высокорискованное действие, как транзакция или изменение настроек идентичности, он должен держать человека в цикле и использовать MFA для подтверждения действия перед его выполнением.
Обеспечивает доступ пользователей и агентов только к тому, на что они имеют разрешение.
Пример: АИ-ассистент в рабочем пространстве компании может читать события календаря, но не может получить доступ к данным о выставлении счетов, если явно не назначена более высокая роль.
Пример: Позвольте пользователям входить в систему с использованием магической ссылки, отправленной на их e-mail, или биометрической подсказки, такой как Face ID.
Эти возможности актуальны как для традиционных, так и для приложений на основе агентов, особенно по мере того, как агенты начинают работать с конфиденциальными данными и системами.
По мере появления агентов и многозадачных рабочих процессов, мы наблюдаем появление новых случаев использования, где пользователи, агенты, API и серверы MCP все взаимодействуют. Количество и разнообразие этих сценариев быстро растет, гораздо более чем в прошлом.
Каждый раз, когда происходят эти соединения, авторизация становится более заметной, чем когда-либо ранее. Пользователям необходимо дать четкое согласие, а разрешения должны тщательно управляться через системы. Вот почему все сейчас говорят о том, чтобы в процессах оставался “человек в цикле”, чтобы пользователи имели достаточно контроля и видимости над тем, что могут делать агенты и на что они имеют разрешение.
Ваше AI-приложение может нуждаться в интеграции с многими внешними сервисами#
Экоcистема MCP расширяется, и это означает, что ваше приложение больше не является просто отдельным сервисом: это часть большего, связанного сети.
Чтобы предоставить богатый, полезный контекст для LLM, ваши агенты могут нуждаться в:
Доступе к нескольким серверам MCP
Пример: Представьте, AI-менеджер проекта, который получает обновления задач из Jira, доступность команды из Google Календаря, и данные о продажах из Salesforce и каждый из них может быть поддержан различным сервером MCP. Чтобы создать один еженедельный отчет, агент должен безопасно взаимодействовать с несколькими источниками данных. Вот где аутентификация и авторизация входят в дело, чтобы защитить каждое соединение и контролировать обмен данными.
Подключении к внешним API и инструментам
Пример: Агент поддержки клиентов может нуждаться в получении истории заказов из Shopify, обновлении тикетов в Zendesk и запуске рабочих процессов в Slack. Без интеграций агент становится изолирован и неэффективен.
По мере того, как агенты берут на себя больше обязанностей, интеграция становится ключом к полезности. Ваш ИИ-продукт не только о том, что он может делать сам, это о том, к чему он может получить доступ, организовать и обдумать в связанном экосистеме. Вот почему создание для совместимости, безопасной и гибкой, становится важнее, чем когда-либо.
Вам нужно принимать открытые стандарты: OAuth/OIDC важнее, чем когда-либо#
В эпоху ИИ потребность в безопасных, гибких интеграциях растет. Это делает OAuth 2.0 и OIDC более важными, чем когда-либо.
Ключевые случаи использования включают:
Удаленные серверы MCP: Позволяйте агентам третьих сторон безопасно получать доступ к вашему продукту, используя делегированные токены.
Интеграции третьих сторон: Позволять другим инструментам или агентам подключаться к вашему приложению (например, платформа управления проектами) без необходимости использования сырых учетных данных.
Разработка агентов: Создание ИИ-агентов, которые безопасно действуют от имени пользователей через сервисы.
Умные устройства: Использование OAuth/OIDC для таких вещей, как AI-помощники с заметками, чтобы аутентифицировать пользователей и подключать их к облаку — особенно с минимальным пользовательским интерфейсом.
Эти протоколы обеспечивают безопасный доступ на основе токенов, который согласован пользователями.
Это критически важно в мире агентических, связанных систем. Ознакомьтесь с этой статьей, чтобы увидеть почему OAuth и OIDC важны.
Проектирование для доверия и масштабирования в эпоху агентов#
По мере эволюции агентных продуктов, основные принципы идентификации и авторизации остаются неизменными, но контекст меняется. Агенты вводят новые поверхности для делегирования, согласия и доступа. Вот почему соблюдение открытых стандартов, таких как OAuth, построение четкой архитектуры и внедрение надежных практик безопасности не просто лучшие практики, они основополагающие. Тщательное проектирование сейчас означает, что ваша система будет масштабироваться с уверенностью, гибкостью и доверием в будущую эру, управляемую ИИ.
