Ping Identity расширяет Runtime Identity на AWS, Google Cloud и Cloudflare для защиты ИИ-агентов

Ключевой технический принцип: делегирование без имперсонации

В основе всех трех интеграций лежит механизм обмена токенами OAuth 2.0. Когда человек делегирует задачу агенту, агент не начинает просто «притворяться» пользователем с его полными правами. Вместо этого инфраструктура Ping обменивает первичный токен пользователя на новый, с урезанными правами. Этот токен делегирования несет в себе как идентификационные данные человека (через атрибут act), так и данные самого агента (may_act), создавая надежную цепочку ответственности для каждого последующего действия . Это значит, что службы безопасности всегда могут получить ответы на вопросы: кто из людей это поручил, какой агент выполнил действие и какие именно права у него были?

AWS: Защита идентификаторов агентов в облачных рабочих нагрузках

Интеграция с AWS сосредоточена вокруг Amazon Bedrock AgentCore — сервиса управления идентификацией и учетными данными, созданного Amazon специально для ИИ-агентов и автоматизированных рабочих нагрузок .

Как это работает:

Провайдеры идентификации Ping — PingOne, PingOne Advanced Identity Cloud и PingFederate — можно настроить в двух режимах:

• Как входящий IdP для AgentCore Gateway и Runtime, который аутентифицирует конечных пользователей и выдает токены OAuth с ограниченным доступом, которые агент обязан предъявить перед доступом к ресурсам .
• Как исходящий поставщик учетных данных, позволяющий агентам безопасно получать токены доступа к сторонним сервисам, не раскрывая долгосрочные ключи .

Практические возможности:

• Уникальные идентификаторы для каждого агента — Каждый ИИ-агент получает собственную цифровую личность с метаданными. Администраторы могут применять политики минимальных привилегий в средах с множеством аккаунтов AWS .
• Управление в реальном времени — Авторизация динамически применяется по мере взаимодействия агентов с API, инструментами и хранилищами данных, что приводит поведение агента в соответствие с корпоративными политиками по работе с чувствительными данными, регулируемыми нагрузками и операционными лимитами .
• Мониторинг и аудит — Amazon Bedrock AgentCore предоставляет журналы входящей и исходящей аутентификации. Встроенные возможности Ping по обнаружению агентов позволяют организациям находить, отслеживать и аудировать ИИ-агентов во всей цифровой экосистеме AWS .

Google Cloud: Встроенная авторизация для трафика агентов и инструментов

Интеграция с Google Cloud решает задачу на другом уровне: контроль трафика между ИИ-агентом и серверами (включая MCP-серверы), к которым он обращается. Ping Identity встраивается в Google Cloud Agent Gateway — управляемую точку контроля, которая перехватывает запросы от агента к инструменту и применяет политики до того, как запрос достигнет цели .

Как это работает:

Решение PingOne Authorize размещается непосредственно на пути трафика Agent Gateway через интеграцию ext_proc. Каждый запрос от агента к MCP-серверу или инструменту вызывает оценку политики в реальном времени: проверяется, кто делегировал задачу, какой агент действует, к какому ресурсу идет обращение и какое именно действие запрашивается .

Практические возможности:

• Непрерывная встроенная авторизация — Если политика разрешает запрос, он проходит. Если запрещает — блокируется на подходе к инструменту или API. Никаких изменений в коде приложений не требуется .
• Детализированные, контекстные политики для инструментов — Специалисты по безопасности могут устанавливать правила, основанные на контексте, без правки самого приложения или MCP-сервера. Например: «Любой сотрудник может инициировать покупку на $100, но одобрить закупку на $10 000 может только руководитель» .
• Централизованное управление политиками — Логика авторизации выносится из отдельных серверов и агентов, что упрощает поддержку, аудит и обновление правил по мере масштабирования архитектуры .
• Полная наблюдаемость — Журналы Agent Gateway и идентификаторы трассировки в сочетании с моделью Runtime Identity от Ping обеспечивают сквозную прозрачность: какой пользователь инициировал задачу, какой агент вызвал инструмент, какой скрипт исполнился и какая политика разрешила или заблокировала действие .

Cloudflare: Контроль Zero Trust на периферии сети

Для организаций, развертывающих ИИ-агентов в глобально распределенной инфраструктуре, интеграция с Cloudflare выводит контроль идентификации на периферию сети. Глобальная сеть Cloudflare, охватывающая более 220 городов с узлами инференса на GPU, работает за пределами традиционного корпоративного периметра .

Как это работает:

Cloudflare Workers Model Context Protocol (MCP) сервер функционирует как OAuth-сервер ресурсов. Он делегирует аутентификацию провайдерам Ping — PingOne DaVinci, PingOne Advanced Identity Cloud или PingFederate — чтобы проверить агентов перед тем, как они получат доступ к нижестоящим API .

Практические возможности:

• Надежные, ограниченные учетные данные на периферии — ИИ-агенты аутентифицируются через Cloudflare Workers OAuth Provider для получения токенов с ограниченным доступом перед вызовом любого защищенного API. Незарегистрированные или неаутентифицированные MCP-клиенты блокируются .
• Применение политик Zero Trust — Ping и Cloudflare применяют политики Zero Trust ко всему трафику ИИ-агентов, обращающихся к моделям и корпоративным данным по всему миру, а не полагаются на корпоративный периметр, которого в периферийных средах попросту нет .
• Аудит и прозрачность — Активность агентов в распределенной периферийной инфраструктуре регистрируется и доступна для аудита. Это дает службам безопасности полную картину: к чему обращался агент, когда и по чьему поручению .

Почему три платформы и почему сейчас

Эти интеграции не дублируют, а дополняют друг друга, закрывая разные архитектурные слои: AWS — для идентификации облачных рабочих нагрузок, Google Cloud — для встроенного контроля трафика, Cloudflare — для контроля на периферии. Все три построены на едином фундаменте Identity for AI, а это значит, что организации могут применять согласованную логику авторизации, шаблоны обмена токенами и политики независимо от того, где именно работают их агенты .

Время для такого решения выбрано не случайно. Предприятия внедряют ИИ-агентов быстрее, чем службы безопасности успевают адаптировать традиционные инструменты Identity и Access Management (IAM). Интеграции позволяют централизовать авторизацию и применение политик вместо того, чтобы встраивать разрозненные механизмы контроля в каждого отдельного агента и каждый API-интерфейс .

Для архитекторов по безопасности, работающих над проектами с агентным ИИ, практический вопрос больше не звучит как «Аутентифицирован ли агент?». Теперь он звучит так: «В данный момент, с учетом контекста, разрешено ли это конкретное действие?». Новые интеграции делают этот вопрос разрешимым в реальном времени, в любом масштабе и на всех платформах, где агенты действительно обитают.