Ключевые особенности продукта
Единое обнаружение агентов: Централизует видимость агентов на таких платформах, как Cursor, Databricks и Workato, в едином реестре.
Автоматизированное управление учетными данными: Использует стандарты CIMD для исключения ручных секретов клиентов и автоматизации ротации учетных данных.
Упрощенное управление MCP: Защищает соединения с каталогизированными и пользовательскими MCP-серверами с помощью DCR и авторизации на основе единой политики.
Что нового в Okta для AI-агентов: Более простое подключение и подключение MCP на большем количестве платформ
В Okta для AI-агентов добавлены новые возможности, которые помогают организациям обнаруживать и подключать AI-агентов с большего числа платформ, регистрировать их с меньшими затратами ручного труда и проще управлять их подключением к серверам Model Context Protocol (MCP).
- Визуализация агентов с большего числа платформ разработки: Дополнительные интеграции AI Agent Import переносят идентификаторы агентов с таких платформ, как Cursor, Snowflake, Databricks, Workato и Tines, в централизованный реестр, позволяя видеть их и управлять ими из одного места, вместо того чтобы искать информацию в разных инструментах.
- Регистрация агентов без рутинной работы с учетными данными: Регистрация AI-агентов с помощью документа метаданных идентификатора клиента (Client ID Metadata Document, CIMD) позволяет агентам регистрироваться через размещенный у поставщика URL-адрес метаданных, избавляя администраторов от необходимости вручную обрабатывать учетные данные. Учетные данные ротируются автоматически, а каждый агент получает запись с деталями, необходимыми вашей организации для отслеживания. Схема агентов из нескольких источников (Multi-Source Agent Schema) позволяет добавлять пользовательские поля в регистрационную запись каждого агента, например цель агента или информацию о том, работает ли он в рабочей среде. Okta извлекает данные с той платформы, на которой был создан каждый агент.
- Подключение к MCP-серверам без необходимости каждый раз запускать новый проект настройки: Каталог MCP-серверов Okta Integration Network и регистрация MCP-серверов с динамической регистрацией клиентов (Dynamic Client Registration, DCR) помогают настраивать каталогизированные и пользовательские MCP-серверы и подключаться к ним всего за несколько шагов. Пользовательские серверы авторизации Multi-MCP объединяют несколько пользовательских серверов за единым сервером авторизации, устраняя необходимость настраивать их по отдельности.
Рост числа агентов требует более простого способа их регистрации и подключения к инструментам искусственного интеллекта
Gartner® прогнозирует, что «к 2028 году среднее глобальное предприятие из списка Fortune 500 будет использовать более 150 000 агентов», однако «только 13% организаций считают, что у них внедрено правильное управление AI-агентами».*
Команды безопасности сталкиваются с трудностями при отслеживании агентов на разных платформах, фиксации нужных сведений для каждого из них (таких как владелец, назначение или классификация данных) и управлении тем, к каким MCP-серверам они могут получить доступ. Каждый новый агент усложняет эту задачу. Команды разработчиков ИИ, в свою очередь, не могут позволить себе ждать завершения регистрации и настройки, прежде чем их агенты смогут выполнять реальную работу.
В этом и заключается разрыв: агенты внедряются быстро, но их регистрация и подключение к инструментам ИИ по-прежнему остаются медленными и ручными процессами. Последний выпуск Okta для AI-агентов устраняет этот разрыв. Okta для AI-агентов теперь упрощает регистрацию агентов и их масштабное подключение к MCP-серверам, привлекая агентов с большего числа платформ разработки, добавляя необходимые для каждого из них сведения для управления и сокращая объем ручной работы с учетными данными и настройки для каждого сервера, которые замедляют каждый запуск.
Регистрация агентов и обеспечение безопасности их соединений обычно представляют собой отдельные проекты, каждый со своими собственными инструментами. Okta объединяет их в одно целое на базе уровня идентификации, которому ведущие предприятия уже доверяют в отношении своих сотрудников и приложений. Возможности этого выпуска сосредоточены на двух из четырех критически важных вопросов из руководства Blueprint Alliance для защищенного агентного предприятия:
- Где мои агенты?
- Что они умеют?
Где мои агенты?
Сначала ответим на вопрос: где мои агенты? Видимость ваших агентов — это первый шаг к управлению ими. Вам нужен единый обзор каждого агента на всех платформах с привязанными к нему правильными деталями, в то время как исторически каждый новый агент означал еще одну ручную регистрацию, которую нужно отслеживать.
Прямой импорт агентов с большего числа платформ, которые уже используют ваши команды
Агенты не ждут одобрения ИТ-отдела. Они появляются везде, где уже работают ваши команды. Разработчик запускает агента внутри Cursor для автоматизации проверки кода в запросах на слияние (pull requests).
Кто-то в отделе аналитики данных создает агента в Snowflake для запросов к корпоративным хранилищам данных. Другая команда создает агента в Databricks для ответов на вопросы по внутренним данным.
Интеграции AI Agent Import уже поддерживают импорт агентов с распространенных платформ, таких как Salesforce Agentforce, Amazon Bedrock AgentCore, AWS IAM Identity Center и других. Теперь эта поддержка распространяется на Cursor, Snowflake, Databricks, Workato и Tines, благодаря чему все они отображаются в едином централизованном реестре. Okta фиксирует источник происхождения каждого агента, позволяет назначить владельца и обновляет существующие записи при последующих импортах, избавляя от необходимости регистрировать агентов заново. Этот подход не зависит от поставщика. Ваши команды могут выбирать агента, наиболее подходящего для задачи, а реестр помогает поддерживать полную картину на различных используемых ими платформах.
Фиксация метаданных агента, которые действительно необходимы вашей организации
После импорта агента следующий вопрос касается того, что вам действительно известно о нем. Общие название и идентификатор редко дают на него исчерпывающий ответ. Например, клиенту из финансового сектора может потребоваться отслеживать, какому бизнес-подразделению принадлежит конкретный агент и к какому уровню классификации данных у него есть доступ, так как это определяет требования к прохождению аудита соответствия. Клиенту из сферы здравоохранения может потребоваться зафиксировать, для поддержки какой клинической системы был создан агент, чтобы аудитор мог проследить связь каждого агента с конкретным вариантом использования.
Схема агентов из нескольких источников (Multi-Source Agent Schema, общедоступна) позволяет добавлять такой уровень детализации в любую запись агента, например цель агента или уровень риска. Она сохраняет данные с исходной платформы каждого агента и сопоставляет их с общими полями, позволяя единообразно определять и контролировать каждого агента, где бы он ни был создан.
Рисунок 1: Схема агентов из нескольких источников
Теперь, когда ваши агенты находятся в одном месте с необходимой информацией, следующим шагом является обеспечение масштабируемости процесса регистрации без ручной работы по созданию и ротации учетных данных для каждого из них.
Регистрация агентов без ручного управления учетными данными
Регистрация агента сегодня означает создание для него учетных данных и необходимость помнить о его ротации — это медленно и чревато ошибками.
Представьте типичный процесс развертывания: ваша команда внедряет Claude для нового рабочего процесса, который суммирует тикеты поддержки. Сегодня вывод такого агента в рабочий режим означает, что кто-то в вашей команде создает для него учетные данные, сохраняет их где-либо, передает лицу, управляющему рабочим процессом, и ставит напоминание в календарь или настраивает автоматическое сообщение в Slack для ротации этих учетных данных до истечения их срока действия.
Каждый новый агент, которого вы внедряете, добавляет учетные данные, которые кто-то должен создать, сохранить, передать и обновить. Учитывая всех агентов, которых ваша организация внедряет в этом году, получается растущий список учетных данных, зависящих от того, не забудет ли кто-то их поддерживать. На практике об этом напоминании забывают чаще, чем кто-либо хочет признать, и устаревшие, необновляемые учетные данные, остающиеся в рабочем процессе в течение месяцев, — это именно тот скрытый риск, который со временем превращается в потенциальный инцидент.
Регистрация агентов ИИ с помощью CIMD (в общей доступности) полностью исключает этот этап ручного создания и ротации учетных данных. Например, Claude, как и растущее число платформ для агентов, публикует документ метаданных идентификатора клиента (Client ID Metadata Document): размещенный файл по глобально уникальному URL-адресу, который описывает личность агента. Вместо ручной генерации и отслеживания учетных данных Okta считывает этот URL-адрес напрямую для регистрации агента. Его ключи подписи хранятся в документе метаданных, поэтому нет необходимости выпускать, хранить или ротировать секрет клиента.
Это означает, что ваша команда настраивает это один раз и, как правило, не нуждается в ручном обновлении, независимо от того, сколько раз базовые учетные данные меняются за кулисами. А поскольку CIMD основан на открытом стандарте, вы не привязаны к проприетарному методу регистрации клиентов.
Рисунок 2: Регистрация агентов ИИ с помощью CIMD
В совокупности эти возможности означают, что каждый агент отображается в едином реестре, независимо от того, был ли он создан собственными силами, импортирован с другой платформы или зарегистрирован внешним разработчиком. Каждый из них содержит метаданные, которые действительно необходимы вашей организации, а регистрация больше не зависит от ручной работы с учетными данными.
Что они умеют делать?
Упрощение регистрации и управления агентами с разных платформ решает лишь одну часть проблемы управления. Вам также необходимо контролировать, к чему разрешен доступ каждому из них, и исторически каждый новый MCP-сервер означал еще один разовый проект интеграции.
Подключение к готовым MCP-серверам с минимальной настройкой
Допустим, ваша команда хочет подключить агента к широко используемому MCP-серверу, такому как GitHub, Slack или Salesforce. Часто это означает ручную настройку такой интеграции с нуля.
Каталог MCP-серверов Okta Integration Network (в общей доступности) превращает эту избыточную работу в процесс поиска и подключения. Найдите сервер в каталоге, выберите области видимости (scopes), предоставьте учетные данные — и вы подключены. Okta проверяет доступность сервера и действительность учетных данных до того, как соединение заработает, поэтому администраторы могут выявить проблемы настройки до того, как какой-либо агент сможет использовать это соединение.
Результат: каждое подключение попадает в единое центральное место, которое служба безопасности может видеть и контролировать, независимо от того, какой вендор создал сервер.
Рисунок 3: Каталог MCP-серверов Okta Integration Network
Подключение новых MCP-серверов без узких мест подготовки ресурсов
Не каждый MCP-сервер, необходимый вашим командам, будет находиться в каталоге. Тем не менее вы можете оптимизировать процесс настройки с помощью динамической регистрации клиентов (Dynamic Client Registration, DCR).
Регистрация MCP-серверов с помощью DCR (в общей доступности) позволяет администраторам избежать ручного процесса настройки клиентских учетных данных для таких MCP-серверов, как Figma, Gong и Sourcegraph. Okta находит конечную точку регистрации провайдера, выполняет регистрацию клиента для администратора и сохраняет учетные данные для аутентификации во время выполнения, поэтому никому не нужно их запрашивать, копировать или передавать. Если провайдер меняет свой сервер авторизации, администраторы могут выполнить повторную регистрацию из Okta без пересоздания подключения. Команде, которая хочет, чтобы ее агенты получали доступ к Figma, больше не нужно добиваться учетных данных от провайдера. Администратор добавляет сервер, Okta регистрируется в нем, и агенты могут начинать работу.
Рисунок 4: Регистрация MCP-серверов с помощью DCR
Управление несколькими пользовательскими MCP-серверами в рамках единой общей политики
Когда у вас есть несколько агентов, обращающихся к нескольким MCP-серверам, вам не захочется настраивать авторизацию отдельно для каждого из них. Это особенно актуально для серверов, создаваемых вашими собственными командами. Представьте, что ваша организация запускает пять пользовательских MCP-серверов в разных продуктовых командах: один для внутренней документации, один для системы тикетов, один для базы данных клиентов и так далее.
Без общей настройки это пять отдельных конфигураций авторизации, каждая из которых поддерживается той командой, которой принадлежит данный сервер. Кроме того, каждая из них может со временем рассинхронизироваться с остальными, пока никто не сможет с уверенностью сказать, что все пять действительно применяют одни и те же правила.
Пользовательские серверы авторизации Multi-MCP (в общей доступности) позволяют разместить все ваши пользовательские MCP-серверы за единым сервером авторизации, управляемым единой политикой, благодаря чему изменения в этой политике применяются везде одновременно, а не через отдельные обновления. Каждый сервер по-прежнему получает собственную аудиторию и области видимости, поэтому токен, выданный для одного, отклоняется остальными. А поскольку каждый токен фиксирует пользователя и задействованных агентов, вы знаете, какого агента отключить и кому он принадлежит, если что-то пойдет не так.
Рисунок 5: Пользовательские серверы авторизации Multi-MCP
Все это в сумме обеспечивает более простые и быстрые подключения к уже используемым MCP-серверам с единой политикой, которая масштабируется по мере роста числа серверов.
Уровень идентификации как основа всего
Каждая упомянутая здесь функция помогает обнаружить местонахождение ваших агентов и контролировать их действия, одновременно сокращая количество ручных многоэтапных процессов, которые замедляют развертывание агентов и увеличивают риски безопасности.
Множество решений могут зарегистрировать агента или защитить соединение с конкретным сервером. Лишь немногие могут делать и то, и другое, и еще меньше тех, кто способен делать это стабильно на разных платформах и в типичных сценариях использования агентов. Управление полным жизненным циклом агента — от момента его обнаружения до момента, когда вам нужно задействовать аварийный выключатель (kill switch), если что-то пойдет не так, — требует нахождения на том уровне идентификации, через который ваши сотрудники и приложения проходят каждый день.
Okta for AI Agents объединяет все это в едином уровне идентификации для обнаружения, адаптации, защиты и управления вашими агентами, опираясь на ту же основу идентификации, которой уже доверяют тысячи предприятий для управления своими сотрудниками и приложениями.
Решение Okta for AI Agents создано для того, чтобы ответить на все четыре вопроса, на которые службы безопасности должны получить ответы в отношении своих агентов:
- Где мои агенты?
- Что они умеют делать?
- Чем они занимаются?
- Как мне реагировать?
Готовы ли вы превратить свое предприятие в безопасное предприятие на базе агентов? Узнайте, как Okta for AI Agents поможет вам в этом.
* Пресс-релиз Gartner, «Gartner Identifies Six Steps to Manage AI Agent Sprawl», 28 апреля 2026 г., https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl. Gartner является товарным знаком компании Gartner, Inc. и/или ее филиалов.
Эти материалы предназначены только для общих информационных целей и не являются юридическими, конфиденциальными, охранными, нормативными или деловыми консультациями. Вы несете ответственность за получение консультаций по вопросам безопасности, конфиденциальности, соответствия требованиям или ведения бизнеса у собственных профессиональных консультантов. Упоминание каких-либо будущих продуктов, функций, возможностей или сертификаций в этом блоге носит исключительно информационный характер. Эти пункты не являются обязательствами по поставке и не должны служить основанием для принятия решений о покупке. © Okta, Inc. и/или ее аффилированные лица 2026.
