За підтримки JumpCloud
Керування ідентифікацією та доступом традиційно базувалося на людині. Штучний інтелект змінює це припущення.
Працівник може використовувати ШІ-асистент для доступу до систем компанії та виконання дій від його імені. Автономний агент може працювати з цими ж системами без участі людини. Деякі агенти можуть потребувати привілейованого доступу до інфраструктури та продуктивних середовищ.
Для ІТ-відділу це розширює проблему ідентифікації. ШІ створює нових суб’єктів, нові шляхи доступу та нові види активності, які традиційні системи ідентифікації можуть не бачити, особливо якщо вони походять з кінцевої точки.
Що таке Agentic IAM?
Agentic IAM (Identity and Access Management) розширює керування ідентифікацією, доступом та управлінням на робочу силу, яка включає як людей, так і ШІ-агентів.
Асистент може діяти в контексті користувача, добираючись до систем, до яких співробітник ніколи не звертається безпосередньо. Автономний агент може працювати самостійно, маючи власні облікові дані, дозволи, життєвий цикл та історію. Традиційні системи IAM для працівників не були розроблені для жодного з цих сценаріїв.
Agentic IAM об’єднує виявлення, ідентифікацію, керування доступом та управління, щоб ІТ-відділ міг бачити роботу ШІ в своєму середовищі, встановлювати, хто або що діє, контролювати доступ та вести запис активності.
Виявлення особливо важливе, оскільки багато агентів не потрапляють у середовище через традиційну інфраструктуру ідентифікації.
Виявлення починається з пристрою
SaaS-додаток з’являється в постачальнику ідентифікації, коли хтось його федералізує. ШІ-асистент не обов’язково йде цим шляхом. Співробітник може встановити Claude Desktop або Cursor на ноутбук, додати MCP-сервер, відредагувавши локальний конфігураційний файл, помістити особистий API-ключ у dotfile або встановити розширення для браузера з доступом до сторінок, які він відкриває.
Жодне з цих дій не генерує SAML-твердження і не обов’язково з’являється в журналі постачальника ідентифікації. Доступ є реальним і активним, але він може залишатися невидимим для системи керування, яка бачить лише події автентифікації.
Система, що працює лише з ідентифікацією, бачить агента, коли він надає облікові дані чомусь, що вже перебуває під керуванням постачальника ідентифікації. До того моменту ІТ-відділ має лише частину картини. Діяльність ШІ вже може відбуватися локально, використовуючи облікові дані та з’єднання, що знаходяться поза цим шляхом автентифікації.
ШІ все частіше з’являється на кінцевих пристроях. Його виявлення там надає ІТ-відділу видимість агентів та інструментів ШІ ще до того, як вони з’являться на рівні ідентифікації.
Приклад використання 1: Співробітники, які використовують ШІ-асистенти
Співробітники все частіше використовують ШІ-асистенти, такі як Claude, ChatGPT та Cursor, у контексті своєї повсякденної роботи.
Людина все ще ініціює активність, але інструмент ШІ може викликати API, отримувати доступ до додатків або викликати інструменти через MCP-сервери від імені цієї людини. Людська ідентифікація залишається важливою, тоді як шлях між цією ідентифікацією та ресурсами компанії стає складнішим.
ІТ-відділу потрібна видимість того, які інструменти ШІ встановлені, до яких MCP-серверів вони підключаються, які облікові дані існують у локальних файлах та менеджерах паролів, і до яких додатків ці інструменти можуть отримати доступ. Значна частина цього контексту знаходиться на пристрої.
Відкликання доступу демонструє ту саму асиметрію. Вимкнення облікового запису на рівні ідентифікації закриває шлях SSO, але може не анулювати довготривалий API-ключ, збережений локально. Керування роботою за допомогою ШІ вимагає видимості та контролю як на рівні ідентифікації, так і на рівні кінцевих точок.
Приклад використання 2: Автономні агенти, які виконують реальну роботу
Модель ідентифікації змінюється, коли агент діє незалежно, без ініціації кожної дії людиною.
Розгляд автономного агента як звичайного користувача швидко стає непрактичним. Він потребує власної ідентифікації, визначеної мети, призначеного власника, життєвого циклу, призначень додатків, журналу аудиту та незалежного способу відкликання доступу, замість того, щоб ховатися за спільним службовим обліковим записом або довготривалим API-ключем.
Власність також стає більш корисною, коли вона пов’язана з операційним контекстом. Запис ідентифікації може повідомити ІТ-відділу, хто був призначений власником агента. Видимість кінцевих точок може додати інформацію про пристрій, на якому працює агент, контекст користувача, в якому він працює, та стан цього пристрою.
Разом ці сигнали забезпечують більш повний запис про походження агента, хто за нього відповідає та як він працює.
Приклад використання 3: ШІ-агенти з привілейованим доступом
Деякі робочі процеси агентів виходять за межі SaaS-додатків і поширюються на сервери, продуктивні бази даних, хмарну інфраструктуру та інші привілейовані ресурси.
Постійні адміністративні облікові дані створюють ті ж проблеми для агентів, що й для людей, з додатковою складністю того, що агенти можуть працювати безперервно і без людини за клавіатурою. Привілейований доступ повинен бути обмеженим, керованим, аудитованим і таким, що відкликається, без постійних адміністраторських облікових даних або секретів, що накопичуються на машині, де працює агент.
Існуючі принципи управління привілейованим доступом залишаються актуальними. Agentic IAM розширює їх на новий тип суб’єкта.
Чому це категорія IAM, а не функція ШІ
ШІ-асистенти, автономні агенти та робочі процеси з привілейованими агентами можуть виглядати як окремі продуктові проблеми. З точки зору ІТ, це різні прояви однієї й тієї ж проблеми ідентифікації:
Виявити. Зареєструвати. Керувати. Управляти.
Ці етапи формують життєвий цикл Agentic IAM, і порядок має значення. Виявлення дає ІТ-відділу видимість того, що працює в середовищі. Реєстрація встановлює агента як ідентичність з власником і метою. Управління визначає, до чого він може отримати доступ. Управління надає історію активності та засоби контролю життєвого циклу, необхідні для його керування з часом.
Тут також стає критично важливою взаємозв’язок між ідентичністю та кінцевою точкою. Стека ідентифікації, що починається з автентифікації, може пропустити активність ШІ, яка вже відбувається на пристрої. Об’єднання управління пристроями та ідентифікацією забезпечує видимість на ранніших етапах життєвого циклу та пов’язує те, що працює, з пов’язаними ідентифікаціями, обліковими даними та ресурсами.
У JumpCloud ми керуємо пристроями та ідентичністю з однієї платформи. Виявлення ШІ на кінцевій точці — це не новий агент для розгортання. Це нове запитання, поставлене тому, що вже працює. Наша робота охоплює ідентичності агентів, контроль людського володіння та життєвого циклу, групи агентів та призначення додатків, видимість активності, виявлення MCP та тіньового ШІ, видимість ШІ-шлюзу та початкову підтримку привілейованого доступу.
Оскільки ШІ стає частиною повсякденної роботи, ідентифікація більше не може обмежуватися людиною-користувачем. Видимість також не може зупинятися на рівні ідентифікації.
Грег Келлер – технічний директор та співзасновник JumpCloud.
За даними порталу: venturebeat.com