AI-агенты требуют больше, чем OAuth: новая модель разрешений

AI-агенты переходят от демонстраций к рабочим системам с доступом к данным клиентов, внутренним инструментам, процессам биллинга и операциям. Это ставит перед организациями вопрос, на который многие ещё не нашли ответа: какая модель разрешений нужна ПО, способному принимать решения, цеплять действия и адаптироваться в реальном времени?

Традиционное решение — использовать существующие схемы идентификации. Команды выдают агентам API-ключи, сервисные аккаунты или OAuth-доступ, потому что эти механизмы уже встроены в инфраструктуру. Проблема не в том, что технологии сломаны, а в том, что они рассчитаны на других участников.

По данным Auth0, AI-агенты находятся в неудобной промежуточной позиции: они не человек, работающий в сессии, и не детерминированная служба с фиксированным потоком. С ростом доступа к критическим бизнес-системам это различие становится ключевым.

Источник: https://auth0.com/blog/why-ai-agents-need-their-own-permission-model/

Что изменилось#

Главная мысль проста: современные агенты ведут себя иначе, чем системы, для которых разрабатывались существующие модели контроля доступа.

Человеческий пользователь действует через интерфейс, в рамках сессии и с видимым контекстом для каждого решения. Сервисный аккаунт обычно выполняет предсказуемый сценарий, заданный кодом.

Агенты ломают оба предположения.

Один и тот же запрос может приводить к разным последовательностям использования инструментов при каждом запуске. Агенты комбинируют системы, интерпретируют недоверенные данные, принимают промежуточные решения и могут делегировать задачи другим агентам. Путь выполнения заранее неизвестен.

Это создаёт разрыв между полномочиями и контролем.

OAuth-скоп изначально рассчитан на человека. Сервисный аккаунт — на узкую автоматизацию. Если агент наследует эти права без дополнительных ограничений, он получает широкие полномочия без механизмов ответственности, изначально обеспечивавших безопасность.

Результат — не просто увеличенная поверхность атаки, а новый тип операционного риска.

Значение для безопасности#

Много обсуждений безопасности AI фокусируются на поведении моделей. Более насущная проблема — авторизация.

Пример поддержки клиентов показателен: агент может читать записи CRM, суммировать беседы, открывать тикеты, обновлять платформы для совместной работы и выполнять ограниченные действия с клиентами.

Каждое действие разумно само по себе.

Проблема возникает, когда агент получает доступ ко всем возможным действиям в системе, а не только к необходимым для конкретной задачи.

Это критично для:

• записей клиентов
• биллинговых платформ
• внутренних админ-инструментов
• систем поддержки
• операционных панелей
• платформ совместной работы

Ошибки не обязательно исходят от злоумышленника. Неправильная интерпретация, манипуляции с запросом, неожиданный ответ инструментов или некорректное рассуждение могут создавать последствия, для которых традиционная автоматизация не была рассчитана.

Команды безопасности годами снижали привилегии пользователей. То же принципиально применимо к автономным системам.

Разница в том, что разрешения агента нужно оценивать не только по идентичности, но и по контексту выполнения, объему задачи и намерению в реальном времени.

Три проблемные схемы#

Auth0 выделяет несколько распространённых подходов при внедрении агентов.

Долговечные креденшелы#

Встраивание долгоживущих API-ключей в конфигурации агента или переменные окружения.

Проблема не новая, но агенты увеличивают возможные последствия. Если агент получает ключ и может реагировать на внешние данные, путь от компрометации к злоупотреблению сокращается. Ротация помогает, но не решает проблему чрезмерных полномочий. Мощный ключ остаётся мощным независимо от частоты смены.

Наследование полного скопа пользователя#

Предоставление агенту тех же OAuth-пермишнов, что у пользователя. Сначала кажется логичным: если пользователь может, почему агент нет?

Проблема в том, что пользователи применяют суждение: решают, когда и как использовать права. Агент может иметь доступ постоянно, без понимания контекста.

Со временем широкие права становятся сложными для контроля, так как каждая будущая задача наследует полномочия, изначально предназначенные для конкретного сценария.

Эффективный суперпользователь#

Самая опасная схема — дать агенту самый широкий доступ, если более точные права отсутствуют. Часто встречается при интеграции старых платформ.

Поддержка клиентов может требовать только ограниченных возвратов по правилам, но доступ может позволять отмену подписки, смену платежного метода или финансовые операции без ограничений.

Работа агента узкая, но полномочия — широкие. Именно здесь возникают будущие инциденты.

Что проверить перед запуском агентов#

Фокус следует делать не на том, может ли агент выполнить задачу, а как предоставляются права.

Вопросы для проверки:

• Получает ли агент постоянные креденшелы или доступ по задаче?
• Привязаны ли права к возможностям, а не к владению ресурсами?
• Требуют ли высокорисковые действия одобрения человека?
• Разделена ли идентичность и логика авторизации/выполнения?
• Могут ли права автоматически истекать после завершения процесса?
• Есть ли видимость, какие права использовались и почему?

Эти проверки становятся частью рутинной безопасности.

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

Чего не стоит преувеличивать#

Речь не о том, что OAuth, сервисные аккаунты или API-ключи устарели. Auth0 отмечает, что механизмы работают при строгой сегментации, слоях посредничества и runtime-контроле.

Проблема — архитектурная совместимость. Системы идентичности для предсказуемых сценариев сложно использовать, когда ПО может самостоятельно решать, что делать дальше.

Это не делает агентов небезопасными, но требует большего внимания к принципу минимальных прав, границам авторизации и процедурам одобрения.

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