Як агенті ШІ виявляють фундаментальні недоліки традиційної архітектури управління ідентифікацією та доступом

Основна проблема: Люди не завжди за клавіатурою

Традиційні системи управління ідентичністю та доступом були побудовані на одному припущенні — хтось дійсно там, щоб пройти автентифікацію. Людина сидить на екрані входу, вводить пароль, отримує повідомлення MFA, підтверджує його. Цей робочий процес визначав безпеку протягом десятиліть.

Але агенти ШІ цілком руйнують це припущення.

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

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

Дві принципово різні моделі агентів, дві різні вимоги до ідентичності

Людські делеговані агенти: проблема обсягу та мінімальних привілеїв

Агент, делегований людиною, працює на підставі делегованих повноважень — ви дозволяєте AI-помічнику керувати вашим календарем. Але ось небезпечна частина: більшість сучасних систем або надають агенту повний набір ваших дозволів, або вимагають вручну визначити обмеження. Жоден з підходів не є оптимальним.

Агенту не потрібно успадковувати весь ваш обліковий запис. Йому потрібні точно визначені дозволи. Ви інтуїтивно розумієте, що сервіс оплати рахунків не повинен переказувати кошти на будь-які рахунки. Ви автоматично запобігаєте неправильному тлумаченню фінансової інструкції. Системи ШІ позбавлені цієї здатності контекстуального мислення, тому мінімальні привілеї доступу — це не опція, а обов’язкова вимога.

Як це працює технічно:

Система реалізує подвійне підтвердження ідентичності. Агент працює під двома ідентичностями одночасно:

• Ваша ідентичність (людина, що делегує) з повними дозволами
• Обмежена ідентичність агента з чітко визначеними межами

Коли ви делегуєте авторизацію, відбувається обмін токенами. Замість того, щоб агент отримав ваші облікові дані, він отримує обмежений токен, що містить:

• agent_id: унікальний ідентифікатор цього конкретного екземпляра агента
• delegated_by: ваш ID користувача
• scope: межі дозволів (наприклад, “банкінг:оплата-рахунків”, але явно НЕ “банкінг:переказ”)
• constraints: політичні обмеження, такі як списки дозволених отримувачів, ліміти суми транзакцій і час дії

Ось як виглядає цей процес: