Как агенты ИИ выявляют фундаментальные недостатки традиционной архитектуры IAM

Основная проблема: люди не всегда за клавиатурой

Традиционные системы управления идентификацией и доступом (IAM) строились на одном предположении — что кто-то действительно есть для аутентификации. Человек сидит на экране входа, вводит пароль, получает уведомление MFA, подтверждает его. Этот рабочий процесс определял безопасность на протяжении десятилетий.

Но агенты ИИ полностью разрушили это предположение.

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

Настоящая проблема: традиционный IAM не может отличить законный запрос агента от скомпрометированного, работающего с действительными учетными данными. Когда у субъекта нет доступа к API через обычные каналы авторизации, система это обнаружит. Но когда учетные данные этого субъекта украдены или когда намерения агента становятся злонамеренными через отравление контекста, у традиционных систем нет средств защиты. Этот разрыв между технической проверкой личности и реальной доверительностью определяет основную проблему агентной аутентификации.

Две принципиально разные модели агентов, два разных требования к идентичности

Делегированные человеком агенты: проблема области и минимальных привилегий

Делегированный человеком агент работает на основании делегированных полномочий — вы разрешаете AI-ассистенту управлять вашим календарем. Но есть опасность: большинство современных систем либо предоставляют агенту полный набор ваших разрешений, либо требуют вручную определить ограничения. Ни одна из этих стратегий не подходит.

Агенту не нужно наследовать всю вашу идентичность. Ему нужны точно ограниченные разрешения. Вы интуитивно понимаете, что сервис оплаты счетов не должен переводить средства на произвольные счета. Вы автоматически предотвращаете неправильное толкование финансовых инструкций. У систем ИИ отсутствует эта способность контекстного мышления, поэтому минимальные привилегии — не опция, а обязательное требование.

Как это работает технически:

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

• Ваша идентичность (человек, делегирующий полномочия) с полными разрешениями
• Ограниченная идентичность агента с явными границами области

Когда вы делегируете авторизацию, происходит обмен токенами. Вместо того чтобы агент получал ваши учетные данные, он получает токен с ограниченными правами, содержащий:

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

Вот как выглядит этот поток: