Хто контролюватиме AI-агента, якщо одного дня він отримає доступ до всієї компанії?

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

За останні 12+ років я підтримував, розвивав і будував з нуля не одну IAM-платформу — від банківського сектору (Oschadbank, OTP Bank, УкрСоцбанк, Райффайзен) до телеком-операторів (Київстар, lifecell) та енергетичних холдингів (група компаній ДТЕК). І от що я останнім часом ловлю себе на думці набагато частіше, ніж на обговоренні чергової нової фічі в IAM-продуктах:

Що станеться з корпоративним IAM через кілька років, коли доступ до систем масово почнуть отримувати не люди, а AI-агенти?

Ми звикли думати про Identity & Access Management досить просто: є людина → є identity → є роль → є permissions → є доступ до систем. Ця модель відпрацьована десятиліттями, і саме на ній я будував великі впровадження — наприклад, у групі компаній ДТЕК — це понад 150 компаній у холдингу, 50 000+ співробітників, частина з яких обіймає суміжні посади в різних компаніях групи, плюс підрядники. SAP з мільйонами permission-ів і ролей вдалося звести в єдине вікно управління доступом, з сотнями інтеграцій та єдиною RBAC-моделлю.

Але ця модель починає ламатися.

Від Copilot до учасника організації

Сьогодні більшість корпоративних AI-рішень я б назвав асистентами. Вони допомагають написати лист, знайти документ, проаналізувати код, зробити summary зустрічі, згенерувати SQL-запит.

Але це лише початок. Наступний етап — агент, який може не просто порадити, а виконати дію.

Наприклад: «Перевір, чому production database недоступна». Агент знаходить проблему, перевіряє monitoring, аналізує логи, дивиться останні deployments, перевіряє incident history, знаходить пов’язаний change request і, можливо, навіть запускає remediation.

Тут AI вже перестає бути просто інтерфейсом. Він стає учасником корпоративного процесу. А якщо він учасник процесу — у нього має бути identity. А якщо у нього є identity — у нього мають бути permissions. А якщо у нього є permissions — нам потрібні governance, audit, risk management і контроль.

І саме тут традиційний IAM стикається з новою реальністю.

Зараз ми намагаємося керувати цим як окремою сутністю на кшталт service-акаунта, який має свого власника і часто отримує привілеї, що не поступаються адміністративним обліковим записам. Але вся відповідальність лягає на власника цієї «сутності» — а це часто призводить до проблеми вже після звільнення співробітника, коли service-акаунт з широкими правами лишається без реального власника.

MCP вирішує одну проблему. A2A — іншу

Останнім часом багато говорять про MCP (Model Context Protocol) та A2A (Agent-to-Agent). І це логічно: MCP дозволяє агенту взаємодіяти з інструментами та даними, A2A дозволяє агентам взаємодіяти між собою. Це важливі будівельні блоки.

Але, на мою думку, залишається третє питання: як агент розуміє саму організацію?

Уявімо великий банк — і тут я говорю не абстрактно, а по пам’яті реальних впроваджень. У ньому є десятки тисяч співробітників, сотні команд, тисячі застосунків, бази даних, хмари, endpoint-пристрої, GitHub, корпоративні месенджери, SIEM, HR-система, IAM/IGA, системи фінансового контролю, десятки тисяч permission-ів і сотні тисяч взаємозв’язків між ними.

Але найважливіше — між усіма цими об’єктами існують бізнес-контексти. Хто кому підпорядковується? Хто за що відповідає? Чому конкретній людині потрібен цей доступ? Хто є власником системи? Чому ця роль має саме такі permissions? Яке рішення було прийняте шість місяців тому і чому?

Ця інформація розкидана по десятках систем. У компанії немає одного місця, де зберігається її контекст. І я думаю, що саме тут може з’явитися новий клас систем.

Identity Intelligence

Я називаю цю концепцію Identity Intelligence Platform. Це не ще одна IAM-система і не заміна Okta, Microsoft Entra, SailPoint, Saviynt чи інших IGA/IAM-рішень, з якими я працював — а саме впроваджував Oracle Identity Suite, One Identity Manager, ForgeRock та подібних «монстрів».

Навпаки. IAM залишається тим самим фундаментом: політика → авторизація → enforcement → audit. А над ним з’являється інтелектуальний шар, завдання якого — зрозуміти контекст.

Я уявляю це приблизно так:

Центральним об’єктом тут стає не просто identity, а контекст identity.

А що, якщо кожна роль матиме свого AI-компаньйона?

Це, мабуть, найбільш нетривіальна частина моєї концепції. Ми часто говоримо: «Давайте зробимо AI-assistant для кожного співробітника». Я б пішов трохи далі: не AI для конкретної людини, а AI для ролі — наприклад, Senior Database Administrator.

Чому? Тому що люди приходять і йдуть. Роль залишається.

Уявімо, що в компанії звільняється досвідчений DBA. Формально все просто: старий employee → disable account → новий employee → create account → assign roles. Але на практиці компанія часто втрачає набагато більше — вона втрачає контекст.

У мене був реальний випадок на одному з проєктів: мобілізація двох DBA буквально паралізувала роботу підприємства. Все просто — вони пропрацювали в компанії понад 10 років, і, як це часто буває, документуванню приділялося недостатньо часу. Все трималося на їхній пам’яті.

Новий DBA починає ставити запитання: чому ця база налаштована саме так? Чому цей backup запускається в цей час? Чому цей account має такі permissions? Хто знає цю legacy-систему? Частина відповідей є в документації. А частина — ніде. Вона просто була в голові попереднього співробітника.

Організаційна пам’ять

А тепер уявімо, що разом із роллю існує AI-агент. Він знає, які системи належать до цієї ролі, які permissions є типовими, які процеси виконує роль, які залежності існують, які рішення приймалися раніше, які зміни відбувалися, які інциденти траплялися, з якими іншими ролями потрібно взаємодіяти.

Коли людина залишає компанію, агент не звільняється. Він залишається з роллю. Приходить новий співробітник — і замість того, щоб починати з нуля, отримує: identity + access + organizational context.

На мою думку, це може стати одним із найцінніших застосувань enterprise AI. Не просто «поговорити з корпоративним ChatGPT», а зберегти організаційну пам’ять.

Але тут виникає проблема з доступами

І ось тут ми повертаємося до IAM. Якщо role-agent знає все про роль, чи повинен він мати всі permissions цієї ролі? Я вважаю, що ні — і це дуже важливий принцип. AI не повинен автоматично успадковувати всі права людини. Інакше ми просто створимо нову privileged identity з величезним blast radius.

Я бачу іншу модель: AI отримує мінімально необхідні permissions, а рішення про доступи проходить через policy layer.

Наприклад: співробітник запитує доступ до бази даних. Employee Agent розуміє, навіщо цей доступ потрібен. Role Agent знає, чи відповідає це типовим обов’язкам ролі. Manager Agent розуміє бізнес-контекст. Security Agent оцінює ризик. Identity Agent перевіряє policy. IAM виконує остаточне рішення.

Тобто: AI provides intelligence. IAM provides enforcement. Це принципове розділення відповідальності.

Multi-Agent Enterprise

У такій моделі я вже не бачу одного «суперагента», який контролює всю компанію. Навпаки — я бачу мережу спеціалізованих агентів:

• Employee Agent — представляє інтереси конкретного співробітника, розуміє його роль, задачі та поточний контекст.
• Manager Agent — розуміє цілі команди, структуру підрозділу та відповідальність менеджера.
• Identity Agent — працює з identity lifecycle, ролями, entitlement-ами та access policy.
• Security Agent — оцінює ризики та шукає небезпечні відхилення.
• Audit Agent — фіксує рішення, дії та історію.
• Role Agent — зберігає контекст конкретної корпоративної ролі.

І ці агенти можуть взаємодіяти між собою не лише вертикально (employee → manager → department → organization), а й горизонтально (DBA ↔ Security ↔ Application Owner ↔ Compliance). Фактично ми починаємо будувати граф агентів.

А тепер найцікавіше: хто контролює самих агентів?

Як тільки AI отримує можливість діяти самостійно, він стає новим типом identity. У нього повинні бути: Identity, Role, Permissions, Trust Level, Policy, Audit History, Ownership, Lifecycle.

І це вже дуже схоже на класичний IAM. Тільки тепер суб’єктом є не лише людина. Суб’єктами стають: Human + Service + AI Agent.

І я думаю, що саме тут IAM може почати еволюціонувати в щось значно ширше. Від Identity & Access Management до Identity & Agent Governance.

Рівні автономності

Я б навіть ввів кілька рівнів автономності:

• Level 0 — Observe. Агент тільки збирає контекст.
• Level 1 — Recommend. Знаходить аномалії та рекомендує рішення.
• Level 2 — Prepare. Сам готує access request або remediation workflow.
• Level 3 — Execute Low Risk. Може автоматично виконувати низькоризикові дії в межах policy.
• Level 4 — Autonomous. Може самостійно приймати рішення в чітко визначеному домені.

І тут дуже важливо: автономність агента не повинна визначатися лише можливостями моделі. Вона повинна визначатися рівнем довіри до identity агента та політиками організації.

Що відбувається з MCP та A2A?

У цій архітектурі вони не зникають — навпаки, стають частинами системи:

• MCP — як агент взаємодіє з інструментами.
• A2A — як агенти взаємодіють між собою.
• Identity Intelligence — чому агент має право це робити і в якому контексті.
• IAM — механізм, який забезпечує enforcement.

Це чотири різні рівні однієї архітектури.

І тут з’являється зовсім нова проблема

Уявімо enterprise AI, розгорнутий всередині великої компанії. Він може читати корпоративні документи, аналізувати код, викликати API, дивитися telemetry, працювати з базами даних, спілкуватися з іншими агентами, отримувати нові інструменти і, можливо, з часом — адаптувати свою поведінку.

Тоді питання «Хто контролює AI?» вже недостатньо. Потрібно запитувати: хто контролює identity AI? Які дані він може бачити? Які системи може викликати? Які дії може виконувати? Хто відповідає за його рішення? Хто може змінити його permissions? Як відкликати його доступ? Що станеться, якщо агент буде скомпрометований?

І найцікавіше: чи повинні два AI-агенти довіряти один одному? Якщо один агент просить іншого виконати дію — на чому базується ця довіра? На identity? На ролі? На reputation? На policy? На попередній історії?

Можливо, нам знадобиться щось на кшталт Agent Trust Management.

Мені здається, ми рухаємося від IAM до Identity Intelligence

Я не думаю, що традиційний IAM зникне. Навпаки — він стане ще важливішим. Але його роль може змінитися.

Сьогодні IAM значною мірою відповідає на питання: Who can access what?

Майбутня Identity Intelligence Platform повинна відповідати на набагато складніше питання: Who is this entity, what is it trying to do, why is it doing it, what context surrounds this action, what risk does it create, and should it be trusted to act?

І entity тут уже не обов’язково людина. Це може бути employee, contractor, service account, application, machine, AI agent.

Це не про заміну людей

Мені подобається ця концепція саме тому, що вона не починається з «AI замінить IAM-команду». Я думаю, перший ефект буде зовсім іншим: AI забере на себе величезну кількість рутинної роботи — аналіз доступів, пошук аномалій, підготовку Access Review, порівняння ролей, аналіз permission-ів, пошук історичного контексту, підготовку onboarding, аналіз ризиків, підготовку audit evidence.

А люди залишаться там, де потрібні відповідальність, judgment і бізнес-рішення. IAM Engineer майбутнього витрачатиме менше часу на «чому цей користувач досі має доступ до системи X?» і більше — на «яку політику довіри ми хочемо побудувати для цієї категорії AI-агентів?». Це вже зовсім інша професія.

Постійна робота інженера другої лінії підтримки — це підготовка до access review, оптимізація RBAC, додавання правил доступу до ролей, підготовка й запуск атестації, аппрув заявок та інша щоденна рутина.

Можливо, саме тут буде наступна категорія enterprise software

За останні десятиліття ми створили величезну кількість систем: HRM, CRM, ERP, IAM, SIEM, ITSM, IGA, EDR. Але кожна з них бачить лише частину організації.

AI-агентам потрібен не просто доступ до цих систем. Їм потрібен контекст між ними. Саме тому я бачу Identity Intelligence не як ще одну систему в цьому списку, а як intelligence layer над існуючою enterprise infrastructure — той, що об’єднує People, Roles, Systems, Data, Permissions, Policies, Agents, Events, Relationships в одну динамічну модель організації. І вже поверх цієї моделі можна будувати AI.

Питання, на яке я поки не маю остаточної відповіді

Можливо, ми зараз дивимося на enterprise AI занадто вузько. Ми намагаємося зробити «розумнішого співробітника». А можливо, наступний крок — створити AI-native organization, де люди та агенти працюють як єдина система.

У такій організації кожна людина має свого AI-компаньйона. Кожна роль має пам’ять. Кожен агент має identity. Кожна дія має контекст. Кожен доступ має policy. А вся організація поступово перетворюється на живий граф взаємодії людей, систем і агентів.

І тоді питання безпеки стає вже не «Чи можемо ми дати AI доступ?», а «Чи можемо ми створити систему, в якій AI завжди розуміє контекст, межі своїх повноважень і відповідальність за свої дії?».

Мені здається, саме над цим варто працювати вже зараз. Я поки розглядаю це як архітектурну гіпотезу та R&D-напрям, що виріс із мого практичного досвіду в IAM у банках та енергетиці, а також з мого поточного занурення у вивчення AI-інструментів для роботи — і для особистих оптимізацій, і для робочих процесів.

І мені цікаво почути думку людей, які вже будують enterprise AI, IAM, IGA, cybersecurity та agentic systems:
Де, на вашу думку, має проходити межа між автономністю AI-агента та контролем людини?
І ще цікавіше: чи потрібен нам окремий клас Identity Management саме для AI-агентів?