ИИ-агенты проходят аутентификацию, запускают инструменты и действуют в корпоративных системах на основании делегированных полномочий. IAM для ИИ-агентов — это архитектура управления идентификацией, регулирующая деятельность этих субъектов. В данном руководстве рассматриваются ограничения традиционного предоставления доступа, ключевые компоненты, способы оценки вариантов платформ, а также критерии, подтверждающие, что агент вел себя в соответствии с задуманным.
Управление идентификацией и доступом (IAM) для агентов ИИ рассматривает каждого агента как нечеловеческую идентичность, имеющую человеческого владельца, определённую цель, авторизацию с ограниченной областью действия, срок действия и непрерывный мониторинг. Сложность заключается в архитектуре. Платформы IAM отражают намеченный доступ, в то время как приложения и инфраструктура показывают, что агент фактически выполнил.
Между ними находится «тёмная материя» идентичности: агенты, учетные данные, локальные учетные записи приложений и пути аутентификации, о которых центральные данные идентичности никогда не сообщают. Фреймворк, который не может наблюдать эту поверхность, формирует намерения политики, а не гарантии.
Почему традиционные системы IAM не справляются с задачами, связанными с агентами ИИ
Именно этот разрыв между замыслом и исполнением — область, для работы в которой традиционные программы управления идентификацией никогда не были предназначены. Платформы IAM, как правило, работают в двух измерениях. На этапе проектирования они занимаются управлением жизненным циклом, определением политик, предоставлением прав доступа и рабочими процессами, связанными с присоединением, перемещением и уходом пользователей. Во время выполнения они обеспечивают аутентификацию и авторизацию посредством единого входа (SSO) и проверок доступа на периметре приложения.
Оба направления описывают доступ в соответствии с настройками. Ни одно из них не описывает, что автономный агент сделал с этим доступом, оказавшись внутри приложения.
Статические разрешения не могут соответствовать автономности агента
Человек-пользователь обычно следует предсказуемому пути выполнения задач. Агент же цепочкой связывает задачи, динамически выбирает инструменты и комбинирует действия, которые не были предусмотрены при проверке прав доступа. В списке «Топ-10» OWASP для приложений на основе крупных языковых моделей этот режим сбоя прямо назван «чрезмерной автономностью» (LLM06): агент, наделенный широкими функциональными возможностями, разрешениями или автономией, использует возможности, выходящие за рамки утвержденной задачи.
Статическое назначение ролей не может ограничить такое поведение, а проверка конфигурации не может его измерить. Неправильная конфигурация также не означает автоматической возможности злоупотребления. Уязвимость зависит от прав, фактически привязанных к идентичности агента, систем, доступных из его контекста выполнения, и условий выполнения, в которых он работает. Результаты проверки конфигурации описывают возможность; телеметрия описывает то, что произошло.
Риски, связанные с жизненным циклом нечеловеческих идентичностей и учетными данными
Идентичности агентов обычно создаются средствами автоматизации инфраструктуры, конвейерами развертывания или командами разработчиков приложений, а не в результате событий жизненного цикла, инициируемых отделом кадров. Поэтому они обходят рабочие процессы управления, которые выявляют аномалии в доступе людей, и накапливаются вне инвентаризации, на которой основана отчетность о соответствии требованиям.
Повторяющиеся типы сбоев жизненного цикла
- Отсутствие ответственности: ни один конкретный человек не несет ответственности за цель, сферу действия или дальнейшее существование агента.
- Долговечные секретные данные: статические ключи API и токены сохраняются при всех развертываниях, при этом отсутствует событие ротации, связанное с выводом агента из эксплуатации.
- Неограниченная делегация: агенты наследуют все разрешения пользователя или службы целиком, а не получают полномочия, ограниченные рамками конкретной задачи.
- Невидимое создание экземпляров: агенты, запускаемые другими рабочими нагрузками, никогда не регистрируются в поставщике идентификации (IdP) или системе управления.
- Отсутствие срока действия: доступ, предоставленный для пилотного проекта, остается активным еще долго после его завершения.
Не каждая среда демонстрирует все пять признаков, но каждый из них соотносится с уровнем контроля, который должна обеспечивать инфраструктура идентификации агентов.
Основные компоненты инфраструктуры идентификации агентов ИИ
Поскольку эти проблемы охватывают жизненный цикл, авторизацию и время выполнения, инфраструктуру агентов обычно собирают по частям, а не приобретают целиком. Компоненты четко разделяются: установление личности агента, ограничение его действий и подтверждение выполненных действий.
Идентичность агента, аутентификация и управление учетными данными
Каждому агенту требуется уникальная, поддающаяся атрибуции идентичность — ни в коем случае не общая учетная запись службы и не заимствованные у человека учетные данные. Атрибуция является предварительным условием для любого последующего контроля, поскольку аудиторские доказательства, не позволяющие отделить деятельность агента от деятельности человека, не могут обеспечить соответствие требованиям на уровне реализации.
При проектировании учетных данных следует отдавать предпочтение федерации идентичностей рабочих нагрузок и краткосрочным учетным данным с автоматической ротацией, а не встроенным секретам. В случаях, когда агент действует от имени пользователя, механизм обмена токенами OAuth 2.0 (RFC 8693) обеспечивает семантику делегирования и имитации, которая сохраняет различие между собственной идентичностью агента и полномочиями, которые ему были предоставлены. Это различие исчезает в тот момент, когда агент просто повторно использует сессионный токен пользователя.
Мелкозернистая авторизация и обеспечение соблюдения политик
Аутентификация устанавливает идентичность; авторизация определяет радиус действия. Семейство методов контроля доступа (AC) в стандарте NIST SP 800-53 Rev. 5 без изменений применимо к идентичностям агентов, включая принцип минимальных привилегий (AC-6), разделение обязанностей (AC-5) и явные границы авторизации. Однако точка обеспечения соблюдения должна находиться ближе к месту действия, чем шлюз входа в систему.
Механизмы авторизации, ограничивающие поведение агента
- Предоставление прав в рамках конкретной задачи: права выдаются для выполнения конкретной задачи и истекают вместе с ней, а не сохраняются в качестве постоянной роли.
- Белый список инструментов: агент может вызывать только те API и функции, которые требуются для выполнения его задачи.
- Границы данных: источники извлечения данных ограничены, поскольку агенты, анализирующие манипулируемые данные, будут действовать в соответствии с ними.
- Пороги действий: операции с серьезными последствиями требуют одобрения человека или второго пути авторизации.
Механизмы аудита, мониторинга и отзыва полномочий
Меры контроля, заложенные на этапе проектирования, становятся обоснованными только в том случае, если среда может продемонстрировать, что именно выполнил агент. В Рамочной концепции управления рисками ИИ NIST (AI 100-1) подотчётность и прозрачность рассматриваются как характеристики надёжности, зависящие от отслеживаемого поведения системы, а семейство мер «Аудит и подотчётность» (AU) в стандарте SP 800-53 предполагает наличие записей, достаточных для воссоздания последовательности действий, а не просто записи о том, что политика существовала.
Мониторинг агентов должен быть поведенческим, а не основанным исключительно на журналах. Атаки, направленные на подделку идентификационных данных, включая злоупотребление действительными учетными записями (T1078) и методы повышения привилегий, каталогизированные в MITRE ATT&CK, генерируют записи аутентификации, выглядящие нормально, поскольку учетные данные являются легитимными.
Обнаружение зависит от сравнения запланированной задачи агента с её фактическим выполнением в приложениях и инфраструктуре, а также от возможности отозвать делегированные полномочия в случае несоответствия между ними. Именно это сравнение служит критерием выбора самой архитектуры.
Выбор лучшей архитектуры IAM для агентов ИИ: какую архитектуру IAM следует использовать для агентов ИИ?
Скорость отзыва полномочий и качество доказательств — это две возможности, которые при оценке платформ чаще всего упускают из виду, поскольку функции предоставления доступа продемонстрировать проще. На вопрос о том, какую платформу IAM использовать для агентов ИИ, лучше всего ответить, оценивая архитектурные шаблоны с учетом полной цепочки контроля и ответственности на основе доказательств выполнения, а не путем подсчета количества коннекторов. Весовые коэффициенты будут различаться в зависимости от среды: регулируемое предприятие с обязательствами по сертификации оптимизирует систему иначе, чем команда, запускающая единственного внутреннего агента.
Критерии оценки корпоративной системы IAM для агентов ИИ
Критерии принятия решений для архитектур идентификации ИИ-агентов
- Модель ответственности: можно ли проследить каждую идентичность агента до конкретного человека, ответственного за её назначение и срок действия?
- Архитектура учетных данных: поддерживает ли шаблон федеративную идентичность рабочих нагрузок и краткосрочные учетные данные или зависит от хранимых секретов?
- Делегированная авторизация: сохраняется ли собственная идентичность агента отдельно от полномочий пользователя, которые он осуществляет, с делегированием, ограниченным по области действия и подлежащим отзыву?
- Охват обнаружения: обнаруживаются ли идентичности агентов на основе данных из приложений и инфраструктуры или только на основе того, что уже известно IdP и платформе IAM?
- Телеметрия времени выполнения: фиксирует ли архитектура действия на уровне приложений, такие как вызов инструментов, доступ к данным и использование привилегий, а не только события аутентификации?
- Объем применения: Можно ли ограничить или отозвать полномочия в момент действия, в пределах временного интервала выполнения автономной цепочки задач?
- Аудиторские доказательства: генерирует ли система подкрепленные телеметрическими данными доказательства поведения агентов или подтверждения того, что был настроен тот или иной механизм контроля?
Создание, покупка или расширение существующей платформы IAM
Для большинства предприятий, которые уже реализуют программу управления идентификацией, разумным отправным пунктом является расширение существующей платформы IAM. Рабочие процессы жизненного цикла, цепочки утверждений, циклы сертификации и управление политиками уже существуют, и их переработка для агентов приводит к фрагментации программы управления идентификацией, которая и без того обычно достаточно фрагментирована. Платформы управления, такие как SailPoint и Saviynt, решают половину проблемы, связанную с этапом проектирования, и обе обладают функциями управления идентификацией нечеловеческих объектов и агентов, хотя набор функций меняется от версии к версии и должен проверяться по актуальной документации.
Создание собственного решения проще всего оправдать в тех случаях, когда фреймворки агентов являются проприетарными, а авторизация должна быть встроена непосредственно в среду выполнения. Покупка становится актуальной для того уровня, который платформы управления обычно не обеспечивают: обнаружение идентификационных данных агентов непосредственно из приложений и инфраструктуры, а также проверка соответствия выполнения задуманному.
Многие программы в конечном итоге сочетают все три подхода: разработка — для управления жизненным циклом, создание — для обеспечения соблюдения правил внутри приложений, а покупка — для обеспечения наблюдаемости, что и отражено в приведенных ниже моделях реализации.
Реальные сценарии использования и модели реализации
Разделение на «расширение», «создание» и «покупку» приобретает конкретный характер, как только определенные агенты поступают в производственную среду, поскольку каждый класс агентов выходит из строя по-своему. Приведенные ниже сценарии являются иллюстративными шаблонами, а не измеренными примерами из практики.
Обеспечение безопасности агентов ИИ, взаимодействующих с клиентами, и внутренних агентов
Рассмотрим внутренний операционный агент, который обрабатывает заявки в системе CRM, системе управления заявками и внутренней базе знаний. Поставщик идентификации (IdP) фиксирует несколько успешных аутентификаций в день — вполне обычная картина. Внутри приложений этот же агент запрашивает записи о клиентах, экспортирует данные и обновляет права доступа.
При рассмотрении ситуации исключительно с точки зрения поставщика идентификации агент оценивается как хорошо управляемый. Телеметрия на уровне приложений показывает фактический доступ к данным и вызов инструментов. Точность обнаружения зависит от второго представления, поскольку значимое поведение никогда не попадает в журнал аутентификации.
Делегированный доступ через инструменты, API и источники данных
Агент по закупкам точно иллюстрирует проблему делегирования. Его утвержденная задача — получение цен от поставщиков. Предоставленные ему разрешения включают полный набор функций API по закупкам. Выполняемые им действия могут включать инициирование заказов на покупку, поскольку цепочка задач привела его к этому.
Таким образом, мы имеем три отдельных компонента: намерение, права и выполнение. Только третий из них описывает то, что произошло на самом деле.
Агент доставки кода, обладающий идентификацией плоскости управления, ещё больше повышает риски. Учетные данные для автоматизации инфраструктуры требуют широких прав доступа, что делает их ценными целями и позволяет скомпрометированному агенту изменить конфигурацию среды, включая средства контроля, предназначенные для его обнаружения.
Поэтапное внедрение и развертывание системы управления
Стадии зрелости управления идентификацией агентов
- Статическое управление учетными записями и ролями: агенты регистрируются как нечеловеческие идентичности с указанием владельцев, целей и сроков действия; доступ периодически пересматривается. Подходит для пилотных проектов, но недостаточно для автономных действий.
- Автоматизированное управление, управляемое событиями: предоставление прав доступа, ротация учетных данных и их отзыв инициируются событиями развертывания и вывода из эксплуатации, а не в соответствии с графиками проверки.
- Непрерывный мониторинг идентичностей: поведение агентов отслеживается во всех приложениях и инфраструктуре, выполнение задач сравнивается с запланированным объемом работ, а аудиторские доказательства генерируются на основе телеметрических данных.
Третий этап — это сфера деятельности Orchid Security. Orchid обнаруживает идентичности непосредственно в приложениях и инфраструктуре, а не полагается исключительно на данные конфигурации IAM, выявляя идентичности агентов, учетные данные и пути доступа, о которых фрагментированные системы управления идентичностью могут не сообщать. Система разработана для дополнения корпоративных платформ IAM, оставляя управление и предоставление прав в прежнем виде, и добавляет уровень проверки и исправления, призванный превратить настроенные политики в аудиторские доказательства, подкрепленные телеметрическими данными. Охват зависит от того, какие приложения и инфраструктура подключены.
Будущее управления идентификацией в мире, управляемом искусственным интеллектом
На третьем этапе наблюдаемость становится сложнее, а не проще, поскольку агенты начинают авторизовывать друг друга.
Машинно-читаемые политики и доверие между агентами
Когда один агент делегирует подзадачу другому, полномочия распространяются по цепочке, ни один шаг которой не утверждается человеком. Машинно-читаемая политика, то есть авторизация, выраженная в форме, которую агенты могут оценивать и применять во время выполнения, является одним из новых решений наряду с ведущейся в настоящее время работой по стандартизации в области проверяемых учетных данных агентов и ограниченного делегирования. Эти усилия находятся на ранней стадии, и вопрос о взаимодействии между различными средами агентов пока не решен.
Требования к управлению остаются неизменными. Каждое звено в цепочке должно иметь идентификатор, область действия, срок действия и человека, несущего за него конечную ответственность. Каталог MITRE ATLAS содержит описание тактик и методов злоумышленников, направленных против систем на базе ИИ, и служит полезным ориентиром для понимания того, как такие цепочки могут подвергаться атакам.
Непрерывная авторизация для адаптивных систем ИИ
Непрерывная авторизация заменяет однократное решение о допуске на постоянную оценку, пересматривая рейтинг по мере изменения поведения агента, источников данных и контекста выполнения. Она функционирует только при наличии поведенческих сигналов, что возвращает дискуссию к исходной точке.
Инфраструктура идентификации ИИ-агентов, регулирующая предоставление доступа без наблюдения за выполнением, формирует намерения политики, а не операционную гарантию. Агенты уже действуют; вопрос в том, может ли ваша среда доказать, что именно они сделали. Закажите демонстрацию, чтобы увидеть, как Orchid выявляет идентичности агентов в подключенных приложениях и инфраструктуре и сопоставляет обнаруженные средства контроля идентичности с вашими применимыми нормативными обязательствами.