Краткий обзор
Внутреннее управление идентичностью корпоративных ИИ-агентов быстро превращается в постоянную нагрузку, связанную с обеспечением соответствия требованиям и контроля. Это требует централизации аутентификации, авторизации, управления жизненным циклом токенов и ведения журналов аудита для всех внутренних, сторонних и теневых агентов. Создание собственного уровня доступа приводит к появлению слепых зон в безопасности, прохождению аудита с нарушениями и постоянным инженерным затратам по мере развития спецификаций MCP и OAuth.
Инвестиции в централизованный уровень идентификации агентов позволяют предприятиям отделить доступ к инструментам от управления учетными данными, обеспечивая при этом непрерывную проверяемость и безопасность по принципу Zero-Trust, а также позволяют вашим инженерам сосредоточиться на разработке агентов, помогающих решать критически важные для бизнеса задачи.
Что такое уровень идентичности ИИ-агента и как он создается?
Когда ИИ-агенты начали совершать действия, а не просто отвечать на вопросы, командам разработчиков пришлось быстро подключать их к реальным инструментам и данным. Многие команды в итоге создали уровень доступа самостоятельно, который обычно состоит из трех основных компонентов:
- Шлюз Model Context Protocol (MCP), который направляет трафик агентов на серверы MCP
- Брокер токенов, который хранит и обновляет учетные данные каждого пользователя для SaaS-приложений, вызываемых агентами
- Фильтрация областей видимости на основе ролей (Role-based scope filtering), которая ограничивает набор доступных агенту инструментов в зависимости от роли пользователя
Эта разработка заняла месяцы инженерной работы, вывела агентов в продакшн и уберегла учетные данные от попадания в промпты. Для большинства команд на тот момент это был единственный вариант.
Загрузите нашу белую книгу «Идентичность ИИ-агентов: собственная разработка или покупка» (AI Agent Identity: Build vs. Buy), чтобы узнать, почему приобретение специализированного уровня идентичности — это наиболее эффективный способ управления ИИ-агентами на протяжении всего их жизненного цикла, избавляющий вашу инженерную команду от бесконечного обслуживания системы идентификации.
Шесть ключевых вопросов идентичности для корпоративных ИИ-агентов
По мере роста популярности агентов и того, как они берут на себя все более важные для бизнеса задачи, команды понимают, что им нужно отвечать на все большее число вопросов:
- Идентичность агента: Кто представляет собой каждый конкретный агент?
- Владение: Кто владеет агентом?
- Делегирование: От чьего имени действует агент?
- Область видимости (Scope): К каким инструментам и ресурсам он имеет доступ?
- Журнал аудита: Какие конкретные действия он совершил?
- Кнопка экстренного отключения (Kill switch): Как команды могут быстро отозвать доступ или выключить его?
Как расширяется сфера применения
Первая версия создания уровня доступа для агентов вполне управляема. Одна команда создает несколько агентов, присваивает каждому сервисную идентичность, сохраняет токены SaaS пользователей в брокере и ведет список существующих агентов и их создателей. Для отдельной команды, чьи агенты остаются в рамках собственной платформы, такой подход работает отлично.
Затем количество агентов и бизнес-потребности продолжают расти. Каждое новое SaaS-приложение, к которому получают доступ ваши агенты, запускает собственный сервер авторизации со своей моделью согласия, временем жизни токенов и поведением при отзыве, поэтому брокеру требуется дополнительная интеграция. Другие команды начинают выпускать агентов по собственному графику, и некоторые из них никогда не проходят через уровень, созданный вашей платформенной командой.
Разработчики запускают такие агенты для написания кода, как Claude Code, Codex и Cursor, на своих ноутбуках, и эти агенты подключаются напрямую к серверам MCP и репозиториям кода путем вставки токенов в локальный файл конфигурации, поскольку они никогда не проходят через централизованную систему. Агенты на вендорских платформах получают доступ к вашим данным через собственные коннекторы вендора. Внедренные агенты, рои агентов и локальные модели создают новые пробелы, и каждая новая интеграция увеличивает нагрузку на стек идентификации, от которого теперь зависят более важные рабочие процессы.
К тому моменту команда, создавшая уровень доступа для собственных агентов, занимается поддержкой продукта для управления идентичностью для всей компании.
Управление собственным соответствием требованиям означает, что сезон аудита никогда не заканчивается
Многие организации начинают с простого реестра агентов: списка каждого агента, его владельца, а также инструментов и приложений, к которым он имеет доступ. Он перестает работать, когда другие команды выпускают агентов, владельцы меняют роли или уходят из компании, а аудиторы требуют доказательств того, что кто-то проверял доступ каждого агента в текущем квартале.
Такие доказательства редко хранятся в одном месте. Шлюз регистрирует одно, брокер — другое, а SaaS-приложения, к которым обращался агент — третье, поэтому доказательство того, что произошло, означает сбор записей из каждой системы и их ручную корреляцию.
Чтобы эффективно масштабировать использование агентов, большинство команд приходят к выводу, что реестр также должен выполнять и другие функции: переназначать или выводить из эксплуатации агентов, чьи владельцы ушли, проводить плановые проверки доступа, а также показывать, кто авторизовал действие, для кого и в рамках какой политики, спустя месяцы после того, как это произошло. Эта работа повторяется каждый цикл аудита и увеличивается с каждым новым агентом, добавляемым вашей организацией.
OWASP ranks agent identity and privilege abuse No. 3 среди главных рисков для агентских приложений, ссылаясь на нечеткое владение, унаследованные учетные данные и кэшированные токены. Именно эти пробелы возникают по мере расширения возможностей созданного собственными силами реестра.
Стандарты безопасности MCP и OAuth продолжают меняться
Стандарты авторизации агентов все еще пишутся. За последние 12 месяцев мы стали свидетелями серьезных изменений в рекомендациях:
Кроме того, в рекомендациях АНБ по безопасности MCP отмечается, что протокол не определяет обновление и отзыв токенов, поэтому каждая команда, создающая собственный уровень, должна проектировать и защищать такое поведение самостоятельно.
Каждое изменение спецификации означает, что кто-то должен прочитать новую спецификацию, обновить код и провести повторное тестирование.
Почему созданные собственными силами брокеры токенов не справляются с корпоративной авторизацией SaaS
Брокер собственной разработки может хранить и обновлять токены, которые SaaS-приложения уже выдали, но он не может предоставлять доступ от собственного имени. Каждое SaaS-приложение решает, каким поставщикам идентичности оно доверяет для подтверждения подлинности ваших пользователей, и разработчики приложений создают это доверие для небольшого списка авторитетных поставщиков идентичности. Если брокер, управляемый одной компанией внутри организации, отсутствует в этом списке, каждое новое приложение означает еще один раунд экранов согласия для каждого пользователя или ручную выдачу прав администратором.
Межприложений доступ (Cross App Access) работает иначе. Ваш поставщик идентичности предоставляет агенту ограниченный доступ напрямую, поэтому ИТ-отдел настраивает политику один раз, пользователи пропускают экран согласия, а контроль доступа централизуется. Все большее число SaaS-приложений поддерживает эту функцию, и Model Context Protocol принял тот же шаблон в качестве авторизации, управляемой предприятием.
Создание против покупки: перенаправление инженерной скорости на ключевые бизнес-потребности
Ценность агента заключается в том, что он делает для бизнеса: автоматизируемом им рабочем процессе, объединяемых им данных и ускоряемых им решениях. Каждый час, который ваши инженеры тратят на поддержку логики обновления токенов, перестройку потоков согласия для следующего SaaS-приложения или подготовку отчетов о проверке доступа для аудиторов, — это час, который они не тратят на самих агентов.
Большинство инженеров платформ предпочли бы создавать функциональные возможности агентов, а не управлять службой идентификации.
Сохраните то, что построили, купите то, что находится под капотом
Уровни доступа, созданные командами для своих первых агентов, решили насущную проблему. Уровень идентичности под ними — это обязательство иного рода. Он должен охватывать каждого агента на предприятии, включая те, которые ваша команда никогда не создавала, получать доступ к приложениям, которые ваша организация не контролирует, идти в ногу со стандартами, которые все еще меняются, и предоставлять аудиторские доказательства в каждом цикле до тех пор, работают ли агенты.
Инвестиции в уровень безопасности позволяют вашим инженерам сосредоточиться на агентах, развивающих бизнес, дают командам безопасности и ИТ единое пространство для мониторинга и контроля агентов, а также перекладывают постоянную работу по управлению стандартами, интеграциями и комплаенсом на команду, единственной задачей которой является работа с идентификационными данными.
Okta® for AI Agents — это уровень идентификации агентов, который работает совместно с уже используемыми вами поставщиком удостоверений (IdP) и шлюзами. Он отвечает на четыре жизненно важных вопроса обо всем вашем парке агентов:
- Где находятся мои агенты? Обнаружение и регистрация
- Что они могут делать? Управление областями видимости и правами доступа
- Что они делают? Единый журнал аудита
- Как реагировать? Автоматическое отзыв прав и изоляция угроз
Руководство для покупателя: Технический разбор и структура проверки безопасности
Полный анализ, включая вопросы, которые следует задать любому вендору средств идентификации при проверке безопасности, читайте в техническом документе AI Agent Identity: Build vs. Buy.
Эти материалы предоставляются исключительно в общих информационных целях и не являются юридическими, конфиденциальными, охватывающими безопасность, соблюдение требований или деловыми консультациями.
Содержимое может не отражать самые последние события в области безопасности, права и/или конфиденциальности. Вы несете единоличную ответственность за получение консультаций от собственного юриста и/или профессионального советника и не должны полагаться на эти материалы при принятии решений о соответствии требованиям, внедрении или покупке.
Okta не дает никаких заверения или гарантий в отношении данного контента и не несет ответственности за любые убытки или ущерб, возникшие в результате реализации вами этих рекомендаций. Информацию о договорных гарантиях Okta для своих клиентов можно найти на сайте okta.com/agreements.
