Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор по работе с клиентами и безопасности компании Ory, рассказывает на портале The New Stack о том, как защитить свою инфраструктуру с помощью системы управления идентификацией и доступом агентов (Agent IAM).
Переход от традиционных веб-приложений к агентным экосистемам — это не просто изменение пользовательского интерфейса; это фундаментальный сдвиг в модели угроз Интернета. Мы переходим из мира, где неправильный ввод создает неправильные данные, в мир, где неправильный ввод создает неправильные действия. В условиях, когда агенты ИИ эволюционируют от простых чат-ботов до автономных контроллеров, способных вызывать API, читать конфиденциальные файлы и отправлять электронные письма, наши устаревшие модели безопасности не выдерживают давления.
Поскольку агентов уже на порядки больше, чем людей, если вы сегодня создаете или развертываете агентов ИИ, вы, вероятно, сталкиваетесь с замаскированной проблемой IAM. Согласно недавнему глобальному опросу Enterprise Management Associates (EMA) «Agentic AI Identities», 95% респондентов используют ИИ-агентов в производственной среде или ограниченных пилотных программах.
Рассмотрим, как осуществить переход от человекоцентричной безопасности к эре Agent IAM.
1. В чем проблема: идентификационный вакуум
Основная проблема заключается в том, что агенты ИИ в настоящее время работают в условиях идентификационного вакуума. В большинстве производственных сред агентам предоставляется общий, унаследованный доступ. Они работают как служебные учетные записи с широкими правами доступа или, что еще хуже, наследуют полные права доступа пользователя, который их запустил.
Это создает три критические уязвимости:
• Модель угроз, основанная на действиях (Action-Based Threat Model). В отличие от традиционных приложений, агенты что-то «делают». Если большую языковую модель (LLM) обманут с помощью инъекции промпта, она не просто отобразит неправильный ответ; она выполнит вызов вредоносного инструмента. 80% респондентов сообщают о случаях, когда приложения действуют за пределами предполагаемых границ.
• Поверхность атаки системы RAG. Системы генерации с расширенной выборкой (RAG) уязвимы для косвенной инъекции промптов. Если агент получает документ, содержащий вредоносные инструкции, этот документ становится новым владельцем («мастером») агента, игнорируя меры защиты разработчиков.
• Взрывной рост использования нечеловеческих идентификаторов (NHI). Мы наблюдаем массовый всплеск роста API, сервисов и автономных агентов, которым не хватает централизованного источника достоверной информации об идентификации. 39% респондентов опроса SailPoint «AI agents: The new attack surface» сообщают об инцидентах несанкционированного доступа агентов, и у большинства команд нет возможности отозвать доступ отдельного агента, не нарушив работу всего сервиса.
2. Почему это важно: растущий разрыв в устранении уязвимостей
Недавнее появление Claude Mythos от Anthropic повысило ставки. Модель выявила тысячи уязвимостей нулевого дня в основных ОС и браузерах, включая ошибки, которые пережили более 20 лет проверки людьми.
Это важно, потому что ИИ теперь является множителем силы для обнаружения уязвимостей. Хотя ИИ может находить ошибки со скоростью машины, люди по-прежнему устраняют их в «человеческом темпе» (совещания, бэклоги, циклы обновления).
Если ваша инфраструктура IAM является собственной разработкой или неуправляемым Open Source, вы не сможете достаточно быстро обновлять ее, чтобы угнаться за злоумышленником, использующим ИИ. Идентификация — наиболее уязвимый уровень, поскольку это плоскость управления; если идентификация агента скомпрометирована, вся инфраструктура становится открытой для горизонтального перемещения. Исследование SailPoint показывает, что 33% респондентов сталкивались с ненадлежащим обращением агентов с данными с ограничен доступом.
3. Как решить проблему: план управления идентификацией и доступом для агентов
Для решения проблемы агентной безопасности необходимо перенести ограничительные механизмы с
• 62% заявляют о неготовности к отказоустойчивости агентов;
• 49% утверждают, что не готовы к соответствию нормативным требованиям для агентов;
• 62% сообщают о неготовности к масштабируемости агентов;
• 59% заявляют о неготовности к безопасности агентов.
Относитесь к агентам как к первоклассным идентификаторам. Агенты должны рассматриваться как первоклассные нечеловеческие идентификаторы. Это означает:
• Аутентификация. Агенты должны проходить аутентификацию у провайдера идентификации, используя учетные данные с ограниченной областью действия.
• Токены с коротким сроком действия. Используйте OAuth2 для выдачи токенов, ограниченных областью взаимодействия. Если агент скомпрометирован, токен быстро истекает, ограничивая окно эксплуатации уязвимости.
• Управление доступом на основе отношений (ReBAC). Используйте модель разрешений на основе графа, чтобы точно определить, к чему может получить доступ агент.
Согласование извлечения с авторизацией. В системах RAG разрешение на «просмотр» должно соответствовать разрешению на «извлечение». Прежде чем агент получит документ для размещения в его контекстном окне, система должна проверить: имеет ли этот конкретный Agent ID разрешение на просмотр этого Document ID? Если нет, документ никогда не будет получен, что предотвратит просмотр агентом вредоносного кода и его воздействие на него.
Инженеры как дирижеры. Измените свой инженерный подход. Перестаньте пытаться жестко запрограммировать каждое действие агента. Вместо этого действуйте как дирижер, управляя агентами с помощью политики как кода. Используйте инструменты для визуализации этих сложных цепочек разрешений, чтобы точно видеть, как отношения между агентами разрешаются в «РАЗРЕШИТЬ» или «ОТКАЗАТЬ».
Подводные камни и как их избежать
Даже при наличии продуманного плана часто возникают скрытые издержки и технические ловушки:
• Ловушка унаследованного доступа:
— Проблема: разработчики часто предоставляют агентам права администратора для упрощения разработки.
— Решение: внедрите принцип минимальных привилегий с самого начала. Если агенту нужно только читать маркетинговые документы, не предоставляйте ему доступ ко всему бакету S3.
• Задержка обратной связи:
— Проблема: по мере добавления уровней безопасности задержка агента увеличивается, что заставляет пользователей обходить безопасность ради скорости.
— Решение: используйте высокопроизводительные механизмы управления разрешениями, которые могут обрабатывать сложные запросы за миллисекунды, гарантируя, что безопасность не ухудшает пользовательский опыт.
• Агенты-призраки:
— Проблема: агенты создаются для задачи, задача завершается, но учетные данные остаются активными.
— Решение: внедрите автоматическое управление жизненным циклом. Используйте отзыв цепочки токенов, чтобы, если родительский агент-оркестратор помечен как проблемный, все токены дочерних агентов мгновенно аннулировались.
• Слепота:
— Проблема: модели разрешений для сотен агентов становятся слишком сложными для восприятия человеком.
— Решение: используйте инструменты визуализации для аудита ваших моделей. Если вы не видите граф, вы не можете обеспечить его безопасность.
Резюме: идентификация — это отправная точка
Безопасность — это процесс, а не продукт. Хотя ограничительные механизмы LLM и защита на уровне промптов важны, их легко обойти. Единственная жесткая граница, которая остается неизменной перед лицом автономного агента, — это граница авторизации.
Относитесь к своим агентам как к идентификаторам, определяйте их окружение с помощью ReBAC и обеспечьте профессиональное управление вашим стеком IAM, чтобы идти в ногу с темпами обнаружения, обусловленными ИИ. Будущее Интернета связана с агентами; убедитесь, что ваша безопасность тоже.
