IBM дала ИИ-агентам отдельные учётные личности в watsonx Orchestrate

Почему общих учётных записей больше не хватает

Раньше агентов подключали к корпоративным системам так же, как сервисы: общая служебная учётная запись, статический API-ключ или просто учётные данные пользователя. IBM прямо называет эти подходы недостаточными по мере роста автономности агентов.

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

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

IBM формулирует задачу как четыре вопроса для служб безопасности и команд управления доступом: кто этот агент, что ему разрешено, какой доступ выдан в момент выполнения и что агент в итоге сделал.

Что такое личность агента

Личность агента — это уникальная проверяемая корпоративная учётная запись, назначенная ИИ-агенту и отдельная от личности его создателя, владельца или конечного пользователя.

Когда агент действует от чьего-то имени, контекст выполнения сохраняет обе стороны: субъект — пользователь, для которого выполняется действие, а актор — агент, который его выполняет. Вместо записи вида «Julius зашёл в Workday» журнал может показать, что конкретный агент обратился к Workday от имени Julius.

Три принципа подхода

Первый принцип — отдельная личность каждому агенту вместо общей служебной учётной записи, встроенного секрета или заимствованных пользовательских данных. При создании или регистрации агента в watsonx Orchestrate его личность может быть зарегистрирована у подключённого провайдера идентичности: у службы безопасности появляется централизованный обзор того, какие агенты существуют, кому принадлежат и сохраняют ли право работать. Если личность агента отключают или удаляют у провайдера, агент можно остановить — это и есть способ выявлять «теневых агентов», которые иначе жили бы вне надзора.

Второй принцип — доступ по минимуму и вовремя. Пользователь может иметь административные права в HR-системе, но агенту, который выгружает список открытых вакансий, достаточно чтения; вместо автоматического наследования всех разрешений агент должен получать короткоживущий токен, ограниченный задачей. Сокращая срок и широту доступа, компания уменьшает последствия компрометации или неверной настройки агента.

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

Как это работает в Orchestrate

На входе администратор устанавливает доверие между тенантом watsonx Orchestrate и поддерживаемым провайдером идентичности. После настройки интеграции агенты, созданные в Orchestrate или зарегистрированные извне, можно связать с учётными записями в корпоративной системе — события жизненного цикла синхронизируются, чтобы провайдер идентичности оставался точкой контроля выделения и отзыва доступа.

Дальше включается выполнение с учётом личности агента. Пользователь аутентифицируется у провайдера идентичности, его запрос вызывает конкретного агента в watsonx Orchestrate, а Orchestrate получает токен личности агента и проверяет, что агент распознан и доступен этому пользователю. При обращении к защищённому инструменту токен on-behalf-of может представлять обе стороны — пользователя как субъекта и агента как актора. Система авторизации оценивает запрос и определяет, какой доступ следует предоставить, а записи аудита сохраняют связь между пользователем, агентом и действием в нижележащей системе.

IBM подчёркивает, что подход интеграционный: вместо отдельного изолированного хранилища идентичностей Orchestrate подключает агентов к корпоративным провайдерам идентичности, таким как IBM Verify и Microsoft Entra. Провайдер остаётся источником истины для управления пользователями и агентами, а Orchestrate выступает агентной плоскостью управления, где агентов создают, регистрируют, оркестрируют и запускают.

Границы preview и место в стеке

В рамках preview заказчики могут пробовать интеграции watsonx Orchestrate с IBM Verify или Microsoft Entra для управления личностями агентов, аутентификации и авторизации; другие провайдеры идентичности и паттерны workload identity заявлены в дорожной карте.

Agent Identity не единственный элемент конструкции. IBM Agent Identity на базе IBM Verify отвечает за регистрацию личностей, владение, делегированную авторизацию, применение политик и аудируемость для ИИ-агентов. Со стороны секретов HashiCorp Vault даёт короткоживущие учётные данные по требованию и применяет политики авторизации при доступе агентов к корпоративным ресурсам, включая системы, которые не умеют напрямую принимать делегированные OAuth-токены.

IBM относит Agent Identity к портфелю IBM Verify и описывает его как согласованную агентную плоскость управления идентичностью, связанную с концепцией Identity Fabric. В интеграции с watsonx Orchestrate компании получают безопасное подключение агентов, созданных в оркестрационных средах, при централизации идентичности, авторизации и управления в IBM Verify. Через HashiCorp Vault выдаются короткоживущие учётные данные по требованию для доступа к системам, которые не принимают делегированные токены: они действуют в рамках одобренного делегирования, истекают автоматически и попадают в журнал аудита, что убирает постоянные секреты из кода агентов и коннекторов.

Что это значит для предприятий

Личность агента становится задачей управления доступом, а не настройкой конкретного бота. watsonx Orchestrate заявляется как платформа управления агентами, способная подключать агентов сторонних сред — включая, например, работающих в Amazon Bedrock — в единую плоскость управления.

Практический смысл preview в том, что связка «человек — агент — ресурс» описывается формально: у каждой стороны есть своя личность, у доступа — срок и границы, у действия — запись в журнале. Именно это, по логике IBM, и позволяет запускать агентов в чувствительные рабочие процессы без постоянных секретов и с возможностью разобрать инцидент по цепочке.