Системы управления доступом и идентификацией обычно рассчитаны на два типа участников: человека или сервисный аккаунт с фиксированными правами. В DataRobot считают, что ИИ-агенты не подходят ни под одну из этих моделей. В типичном сценарии агент получает доступ к внутреннему API через ключ разработчика, который уже находится в окружении. Из-за этого агент автоматически наследует права сотрудника, а журналы аудита не помогают отделить действия человека от действий агента.
Как пишет DataRobot Blog, проблема связана не с ошибкой настройки, а с самим устройством существующих IAM-подходов. Сервисные аккаунты работают предсказуемо и выполняют однотипные операции. Агент же может выбирать инструменты и последовательность действий уже в процессе выполнения задачи, опираясь на запрос, контекст и результаты других вызовов. Поэтому заранее точно определить, какие операции он выполнит после получения доступа, невозможно.
В компании предлагают проверить уже работающих агентов по трем направлениям. Во-первых, используются ли человеческие API-ключи в не-человеческих процессах. Во-вторых, можно ли в логах разделить действия агента и сотрудника. И наконец, получится ли отключить отдельного агента без ротации пользовательских учетных данных и сопутствующих сбоев.
В дальнейших материалах DataRobot планирует описать подход с отдельной идентичностью для агента, отслеживанием цепочек вызовов между агентами и инструментами, а также динамическим управлением правами во время выполнения задач.
Ключевые факты
DataRobot описывает ИИ-агентов как третий тип участника, который не соответствует модели «человек» или «сервисный аккаунт»
По данным компании, агент может выбирать цепочку инструментов и действий во время выполнения задачи в зависимости от запроса и контекста
В качестве базовой проверки предлагается убедиться, что журналы аудита различают действия человека и агента
DataRobot рассматривает подход с отдельной идентичностью агента и управлением правами доступа во время выполнения задачи