Ping Identity захищає AI-агентів безперервним контролем доступу на AWS, Google Cloud і Cloudflare

Для цього фреймворк Ping Identity for AI, який став загальнодоступним у березні 2026 року, розглядає AI-агентів як повноцінні цифрові ідентичності, а не людські облікові записи. Фреймворк забезпечує реєстрацію агентів та управління їхнім життєвим циклом, обмін токенами OAuth 2.0 для делегованої авторизації та централізовану видимість дій агентів у різних середовищах .

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

Центральним елементом усіх трьох інтеграцій є обмін токенами OAuth 2.0. Коли людина-користувач делегує завдання агенту, агент не просто імперсонує (видає себе за) користувача з усіма його привілеями. Натомість інфраструктура Ping обмінює токен суб'єкта-користувача на новий токен зі звуженим обсягом прав (downscoped). Цей токен делегування містить як ідентичність користувача (через клейм act), так і власну ідентичність агента (через клейм may_act), створюючи безпечний ланцюжок відповідальності для кожної наступної дії . Це означає, що команди безпеки завжди можуть відповісти на питання: хто з людей авторизував цю дію, який агент її виконав і які саме обмежені дозволи він мав?

AWS: захист ідентичностей агентів у хмарних робочих навантаженнях

Інтеграція Ping Identity з AWS зосереджена навколо сервісу Amazon Bedrock AgentCore — сервісу керування ідентичністю та обліковими даними, який Amazon створив спеціально для AI-агентів та автоматизованих робочих навантажень .

Як це працює:

Провайдери ідентичності Ping — PingOne, PingOne Advanced Identity Cloud і PingFederate — можна налаштувати двома способами:

• Як вхідний IdP (провайдер ідентичності) для AgentCore Gateway і Runtime, який автентифікує кінцевих користувачів і видає токени OAuth з обмеженим обсягом, які агент повинен пред'явити перед доступом до ресурсів .
• Як вихідний постачальник облікових даних, що дає змогу агентам безпечно отримувати токени доступу для зовнішніх сервісів, не розкриваючи довгострокові облікові дані .

Практичні можливості:

• Унікальні ідентичності агентів — Кожен AI-агент отримує окрему ідентичність з пов'язаними метаданими. Адміністратори можуть застосовувати політики найменших привілеїв (least-privilege) у середовищах AWS з багатьма обліковими записами .
• Управління в реальному часі — Авторизація застосовується динамічно, коли агенти взаємодіють з API, інструментами та сховищами даних, узгоджуючи поведінку агента з корпоративними політиками щодо конфіденційних даних, регульованих робочих навантажень та операційних обмежень .
• Моніторинг — Amazon Bedrock AgentCore надає журнали вхідної та вихідної автентифікації, а можливості Ping з виявлення агентів дають змогу організаціям знаходити, відстежувати та аудитувати AI-агентів у своїй цифровій екосистемі AWS .

Google Cloud: авторизація трафіку між агентами та інструментами «на льоту»

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

Як це працює:

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

Практичні можливості:

• Безперервна авторизація наскрізно — Якщо політика дозволяє запит, він проходить. Якщо забороняє — блокується ще до того, як досягне інструмента чи API. Жодних змін у коді застосунку не потрібно .
• Деталізовані, контекстні політики для інструментів — Команди безпеки можуть застосовувати контекстно-залежні правила, як-от «будь-який співробітник може придбати товар на $100, але тільки менеджер може затвердити покупку на $10 000», і все це без модифікації коду застосунку чи MCP-сервера .
• Централізоване управління політиками — Логіка авторизації виноситься за межі окремих MCP-серверів і реалізацій агентів, що робить правила легшими в обслуговуванні, аудиті та оновленні в міру масштабування архітектур агентів .
• Наскрізна спостережуваність — Журнали Agent Gateway та ідентифікатори трасування (trace ID) у поєднанні з моделлю Runtime Identity від Ping забезпечують повне відстеження: хто з користувачів делегував, який агент викликав, який інструмент виконав і яка політика дозволила чи заблокувала дію .

Cloudflare: Контроль Zero Trust на границі мережі

Для організацій, що розгортають AI-агентів у глобально розподіленій інфраструктурі, інтеграція Ping Identity з Cloudflare виносить контроль ідентичності на границю мережі. Глобальна мережа Cloudflare, що охоплює понад 220 міст із вузлами інференсу на GPU, працює поза межами традиційного корпоративного периметра .

Як це працює:

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

Практичні можливості:

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

Чому три платформи і чому зараз

Три інтеграції не є надлишковими — вони стосуються різних архітектурних рівнів: AWS — для ідентичності хмарних робочих навантажень, Google Cloud — для контролю трафіку «на льоту», а Cloudflare — для контролю на границі мережі. Усі три побудовані на спільній основі Identity for AI, що означає, що організації можуть застосовувати узгоджену логіку авторизації, шаблони обміну токенами та політики незалежно від того, де працюють їхні агенти .

Час цих запусків відображає реальність ринку: підприємства розгортають AI-агентів швидше, ніж команди безпеки можуть адаптувати традиційні інструменти для управління ідентичністю. Інтеграції дають змогу підприємствам централізувати авторизацію та застосування політик, замість того, щоб вбудовувати фрагментовані засоби контролю в окремих агентів та API .

Для архітекторів безпеки, які працюють над розгортанням агентного AI, практичне питання більше не звучить як «чи автентифікований агент?», а «в цей момент, у цьому контексті, чи авторизована ця конкретна дія?». Ці інтеграції дають змогу відповісти на це питання в реальному часі, в масштабі та на тих платформах, де агенти насправді працюють.