Коротко: Okta Agent SSO — це GA-функція Okta для безпечних agent-to-app з’єднань, яка дозволяє реєструвати AI-агентів як workload principals і керувати їхнім доступом до корпоративних застосунків через Cross App Access (XAA). Agent SSO входить до core Workforce SSO plans. Для повного lifecycle management, ownership, discovery та governance агентів Okta пропонує ширший продукт Okta for AI Agents.
Вступ
AI-агенти дедалі частіше працюють із корпоративною поштою, CRM, документами, API та іншими SaaS-системами. Коли такі агенти починають діяти від імені користувача або отримують прямий доступ до бізнес-даних, звичайних API-ключів і разових інтеграцій стає недостатньо.
24 серпня 2026 року Okta оголосила General Availability функції Agent SSO. Вона переносить знайому модель централізованої identity security у світ AI-агентів: агент реєструється в Okta як окремий workload principal, а його підключення до застосунків контролюються через відкритий протокол Cross App Access.
У цій статті розберемо, як працює Agent SSO, яку роль відіграє XAA, чим Agent SSO відрізняється від ширшого Okta for AI Agents і що це означає для компаній, які масштабують agentic AI у корпоративному середовищі.
Що таке Okta Agent SSO і чому про нього варто знати?
Agent SSO — це механізм Okta для secure agent-to-app connections. Адміністратор може зареєструвати AI-агента як workload principal і підключити його до XAA-enabled застосунку з Okta Integration Network або до custom SAML/OIDC application, що підтримує XAA.
У консолі Okta такі агенти відображаються в окремому розділі AI Agents і можуть керуватися поруч із людськими identity. Це дає security-команді централізовану точку, де видно сам агент і його дозволені connections.
Agent SSO є частиною core Workforce SSO plans. Для організацій, яким потрібні discovery, human ownership, lifecycle management, access reviews, agent-to-agent connections та ширший governance, Okta окремо розвиває Okta for AI Agents.
Чому AI-агентам потрібна окрема ідентичність?
Традиційний підхід до інтеграцій часто спирається на static API keys, довгоживучі tokens або service accounts. Для одиничної автоматизації це може бути прийнятно, але зі зростанням кількості агентів така модель швидко створює проблеми з visibility, attribution і least privilege.
Окрема identity для агента дозволяє прив’язати доступ до конкретного workload, політики й owner-а, а не до спільного секрету, яким користується кілька систем.
Типові ризики некерованих агентів:
- статичні або спільні credentials, які важко ротувати й контролювати;
- надмірні permissions, успадковані від користувача або service account;
- слабка attribution: складно зрозуміти, який саме агент виконав дію;
- unmanaged connections між агентами, SaaS і MCP-серверами;
- складність деактивації або відкликання доступу в разі інциденту;
- Shadow AI — агенти, про які security-команда взагалі не знає.
Як працює Agent SSO через Cross App Access?
Cross App Access (XAA) — відкритий OAuth-based протокол для agent-to-app та app-to-app access. Його головна ідея — перенести рішення про доступ із локального consent flow у централізований identity layer.
В типовому XAA flow є requesting application — наприклад AI-агент — і resource application, до якої агент хоче звернутися. Okta створює між ними managed connection і застосовує визначені адміністратором policy.
Для обміну використовується Identity Assertion Authorization Grant (ID-JAG): агент передає identity assertion, а resource side отримує керований access token відповідно до дозволеного connection і policy. Це зменшує залежність від hardcoded API keys і repetitive end-user consent prompts.
Agent SSO не означає, що агент автоматично отримує всі права користувача. Доступ визначається конфігурацією конкретного connection, resource application і політиками Okta.
Agent SSO і Okta for AI Agents: як вони співвідносяться?
|
Можливість |
Agent SSO |
Okta for AI Agents |
|
Agent-to-app connections через XAA |
Так |
Так |
|
Реєстрація агента як workload principal |
Так |
Так |
|
Централізовані access policies |
Так |
Так |
|
Discovery known/shadow agents |
Ні як основна функція |
Так |
|
Human owner для агента |
Потребує O4AA або OIG |
Так |
|
Lifecycle governance |
Обмежено connection-level access |
Так |
|
Agent-to-agent connections |
Ні |
Так |
|
Access certifications / governance workflows |
Ні |
Так |
Тобто Agent SSO — хороший entry point для identity-governed agent-to-app access, а Okta for AI Agents — ширший control plane для повного життєвого циклу агентів.
Що означає first-class identity для AI-агента?
У ширшій моделі Okta for AI Agents агент реєструється в Universal Directory як first-class identity. Він отримує окремий профіль, lifecycle status і може бути пов’язаний із named human owner для accountability.
Okta описує lifecycle agent identity через стани на кшталт STAGED, ACTIVE, INACTIVE і DELETED. Деактивація агента блокує нову автентифікацію та доступ до resources, що дає security-команді зрозумілий механізм kill switch.
Такий підхід робить AI-агента керованим цифровим суб’єктом, а не просто процесом із секретом у environment variable.
Як identity layer зменшує ризики static API keys?
Одне з ключових завдань Okta — замінювати довгоживучі, вручну роздані secrets на identity-aware і short-lived access mechanisms. У XAA доступ видається через стандартизований token exchange, а не через передачу постійного API key від агента до кожного застосунку.
Для інших сценаріїв Okta for AI Agents також підтримує API Access Management і privileged credential management, щоб обмежувати agent permissions, vault-ити credentials і зменшувати blast radius при компрометації.
Least privilege тут важливіший за сам факт SSO: агент має отримувати лише ті connections, scopes і tools, які потрібні для конкретної функції.
Яке місце Agent SSO займає в data governance та security architecture?
Identity не замінює data governance, але стає одним із його контрольних шарів. Якщо агент має доступ до фінансових, персональних або інших sensitive data, організації потрібна відповідь на три питання: хто цей агент, до чого він може підключатися і які дії він може виконувати.
Agent SSO закриває насамперед connection-level identity та access control. Класифікація даних, retention, data loss prevention, application authorization і business approvals залишаються окремими шарами архітектури.
Для компаній це означає, що AI-agent security потрібно будувати разом із API gateways, application permissions, logging, monitoring, secrets management і політиками Data Governance, а не покладатися лише на один identity-продукт.
Як керована identity змінює бізнес-процеси з AI-агентами?
Коли agent identity відома системі, а connections описані централізованими policy, компанії легше переносити агентів із пілотів у production. Security-команда отримує visibility і можливість revoke access, а бізнес — зрозумілий контрольний контур навколо автономних дій.
Це особливо важливо в multi-hop workflows, де один агент звертається до кількох SaaS або MCP resources. XAA зберігає identity context між такими переходами й допомагає уникати ситуації, коли на кожному кроці з’являється новий unmanaged token або окремий consent flow.
Що Agent SSO означає для аудиту та compliance?
Централізована identity й керовані connections покращують auditability: security-команда може бачити, який агент зареєстрований, які connections йому дозволені та які політики діють для його доступу.
Це може підтримувати виконання внутрішніх і регуляторних вимог щодо access control, traceability та lifecycle management. Водночас сам Agent SSO не гарантує автоматичну відповідність GDPR, SOC 2 або ISO 27001 — compliance залежить від усієї архітектури, процесів, конфігурації й операційних контролів компанії.
Скільки коштує Agent SSO?
Agent SSO має статус General Availability і входить до core Workforce SSO plans Okta без окремого Agent SSO add-on. Це робить його доступним як базовий спосіб почати захищати agent-to-app connections для організацій, які вже використовують Workforce SSO.
Ширші можливості Okta for AI Agents — discovery, lifecycle governance, agent-to-agent access та інші advanced controls — належать до окремого продуктового набору й можуть вимагати відповідної ліцензії.
Практичний план впровадження для компанії
Для першого етапу впровадження identity для агентів логічно пройти кілька кроків:
- інвентаризувати AI-агентів, які вже працюють із корпоративними даними й застосунками;
- визначити, які agents можуть використовувати XAA-enabled applications;
- зареєструвати agent workloads в Okta і створити дозволені managed connections;
- мінімізувати permissions і scopes за принципом least privilege;
- призначити human ownership там, де потрібен повний governance;
- налаштувати logging, monitoring і процедуру швидкого revoke/deactivation;
- окремо перевірити data governance та application-level authorization для sensitive data.
FAQ: питання про Okta Agent SSO
Питання: Що таке Okta Agent SSO?
Відповідь: Okta Agent SSO — це GA-функція для secure agent-to-app connections. Вона дозволяє реєструвати AI-агентів як workload principals і підключати їх до XAA-enabled корпоративних застосунків під централізованими політиками.
Питання: Що таке Cross App Access?
Відповідь: Cross App Access — відкритий OAuth-based протокол для керованого agent-to-app і app-to-app доступу. Він переносить контроль connections і consent у identity provider та використовує стандартизований token exchange.
Питання: Чи є Agent SSO тим самим, що Okta for AI Agents?
Відповідь: Ні. Agent SSO відповідає насамперед за agent-to-app access через XAA. Okta for AI Agents — ширший продукт для discovery, onboarding, lifecycle governance, human ownership, agent-to-agent connections та інших controls.
Питання: Чи потрібен окремий тариф для Agent SSO?
Відповідь: Agent SSO включений у core Workforce SSO plans. Advanced agent governance належить до ширшого Okta for AI Agents та пов’язаних governance-продуктів.
Питання: Чи отримує агент окрему identity?
Відповідь: Так. Agent SSO дозволяє реєструвати агента як workload principal, а Okta for AI Agents розширює це до first-class identity в Universal Directory із lifecycle і governance.
Питання: Чи забезпечує Agent SSO compliance автоматично?
Відповідь: Ні. Він покращує access control, visibility та auditability, але відповідність конкретним стандартам і регуляціям залежить від повного набору технічних і організаційних контролів.
Висновок
Okta Agent SSO показує, як enterprise identity адаптується до agentic AI. Агент стає не анонімним процесом зі static API key, а керованим workload principal із визначеними connections і централізованими access policies.
Для організацій, які вже використовують Okta Workforce SSO, Agent SSO дає практичний старт без окремого add-on: можна почати з XAA-governed agent-to-app access, а за потреби перейти до повного Okta for AI Agents для discovery, ownership, lifecycle та governance.
Для data, security і platform-команд головний висновок простий: масштабування AI-агентів потребує такого самого дисциплінованого identity layer, як масштабування людського доступу. Чим раніше агенти потраплять у централізовану модель access control, тим менше unmanaged credentials і blind spots доведеться виправляти пізніше.


