Как устроена идентификация ИИ-агентов: от статических API-ключей к Non-Human Identity
В 2026 году массовое внедрение автономных ИИ-агентов в корпоративные процессы вскрыло ограничения классической модели управления доступом. Использование долгоживущих сервисных идентичностей и статических API-ключей создает неконтролируемые риски — из-за этого NIST и Cloud Security Alliance сфокусировались на вопросах идентификации и управления доступом для нечеловеческих сущностей (Non-Human Identities, NHI). Разбираем, как меняются подходы к авторизации агентов и почему безопасность автономных систем требует переноса контроля непосредственно на уровень выполнения действий.
TL;DR: Вся статья на одной схеме
Если нет времени читать лонгрид целиком, вот краткая схема того, почему традиционная модель сервисных аккаунтов плохо подходит для ИИ-агентов, как устроен контур Non-Human Identity и на каком уровне должен работать превентивный контроль:
Проблема идентификации автономных систем выходит за рамки привычного спора о безопасном хранении секретов. Чтобы понять, где традиционный IAM теряет эффективность, необходимо разобрать принципиальную разницу между детерминированным скриптом и вероятностным агентом.
Иллюзия сервисного аккаунта: почему старая модель IAM дает сбой
На протяжении десятилетий корпоративная безопасность опиралась на разделение двух сущностей:
- людей, входящих через двухфакторную аутентификацию;
- фоновых сервисов, использующих статические ключи или сертификаты.
Эта модель строилась на предположении, что программный сервис выполняет строго определенный, предсказуемый набор инструкций.
Автономный ИИ-агент не укладывается ни в одну из этих категорий. В отличие от классического детерминированного сервиса, LLM-агент принимает решения на основе вероятностной модели:
- самостоятельно интерпретирует неструктурированные входящие данные;
- динамически выбирает инструменты;
- выстраивает многошаговые цепочки действий.
Если выдать такому агенту стандартный сервисный аккаунт с долгоживущим токеном, компания фактически создает невидимого цифрового оператора с постоянными правами доступа, чьи конкретные шаги невозможно предсказать заранее.
В журналах аудита действия сотен параллельных запусков смешиваются под единой учетной записью. Служба безопасности видит факт обращения к базе данных от имени сервиса, но не может определить, какой именно агент инициировал запрос, в рамках какой пользовательской задачи и на каком основании было принято решение.
Анатомия риска: почему постоянные права опасны для агентных сред
Использование статических креденшелов в агентных средах существенно расширяет поверхность атаки и создает три системные проблемы:
- Чрезмерные полномочия (Over-permissioning): Чтобы агент не спотыкался об ошибки доступа при решении сложных задач, разработчики часто выдают ему широкие административные права, которые остаются активными месяцами.
- Расширение зоны поражения при Prompt Injection: Уязвимость перед вредоносными инструкциями во внешних данных не создает доступ из ниоткуда, но позволяет атакующему заставить агента злоупотребить уже имеющимися у него правами — например, выгрузить конфиденциальные данные в сторонний сервис.
- Отсутствие контекста делегирования: Традиционные токены не разделяют идентичность конечного пользователя (делегатора) и идентичность выполняющего задачу агента, что делает невозможным разграничение прав при многопользовательской работе.
В результате попытка опереться на статические права превращает любую локальную ошибку модели или инъекцию промпта в инцидент с непредсказуемым масштабом ущерба.
Концепция Non-Human Identity: от постоянных ключей к динамическим креденшелам
Одним из ответов индустрии стало развитие концепции Non-Human Identity (NHI) — подхода к управлению идентификацией и доступом для всех типов нечеловеческих субъектов, от микросервисов до автономных ИИ-агентов. Как подчеркивают эксперты Cloud Security Alliance, ключевое отличие состоит в разделении самой сущности агента и используемых им временных учетных данных.
Архитектура управления идентичностью агентов строится на цепочке динамической авторизации:
Агент подтверждает свою идентичность (Workload Identity через платформы вроде SPIFFE) → Брокер авторизации валидирует контекст и задачу → Генерируется короткоживущий токен (Ephemeral Credential) с минимально необходимым скоупом → Токен используется для вызова API и автоматически сгорает.
В ряде разрабатываемых стандартов, таких как черновики Agentic JWT в IETF, предлагается дополнительно связывать идентичность агента с криптографическим хэшем его конфигурации, системного промпта и набора доступных инструментов. Использование короткоживущих токенов не исключает атаки полностью, но существенно сокращает окно возможностей для злоумышленника и жестко ограничивает зону потенциального поражения.
Runtime-контроль: перенос принципов Zero Trust на уровень действий агента
Переход к динамической идентификации дополняет классическую концепцию Zero Trust. Если традиционные системы контроля доступа часто опираются на решение, принятое в момент авторизации запроса, то в случае ИИ-агентов критически важно проверять допустимость каждого конкретного действия непосредственно во время его выполнения.
Этот подход, развивающийся в рамках концепции Runtime Trust, фокусируется не на попытках контролировать скрытые внутренние рассуждения модели, а на строгом анализе ее внешних действий: вызовов инструментов, обращений к API и изменений состояния данных.
На практике это работает через пошаговую оценку контекста. Например, когда агент обрабатывает входящий документ, содержащий скрытую инструкцию на удаление записей в CRM, система безопасности фиксирует попытку вызова деструктивного инструмента, сверяет ее с исходной задачей пользователя и блокирует операцию на уровне политики доступа, при необходимости запрашивая подтверждение у человека.
Стандартизация взаимодействия агентов с внешними сервисами через протоколы вроде Model Context Protocol (MCP) может упростить реализацию такого контроля: механизмы авторизации на базе OAuth и гранулярная привязка разрешений к конкретным ресурсам позволяют отсекать несанкционированные вызовы до их выполнения.
Практические шаги для CISO и CTO: как выстроить безопасный контур
Адаптация корпоративной безопасности к агентным нагрузкам требует поэтапного обновления инфраструктуры управления доступом. Для организаций это выражается в нескольких ключевых шагах:
- Инвентаризация нечеловеческих идентичностей: Провести аудит всех работающих агентов, выявить жестко прописанные в коде статические ключи и разделить общие сервисные аккаунты на отдельные сущности.
- Переход на короткоживущие креденшелы: Внедрить брокеры идентификации и механизмы Token Exchange, выдающие токены с временем жизни в минуты или секунды строго под конкретную операцию.
- Разграничение интерфейсов доступа к инструментам: Использовать стандартизированные шлюзы вызова API с проверкой прав на стороне принимающего сервиса.
- Аудит действий и контекста: Фиксировать в защищенном журнале идентификатор агента, инициатора задачи, параметры вызова инструмента, принятое политикой решение и контрольную сумму конфигурации.
В результате у агента остаётся ровно тот набор полномочий, который нужен ему для конкретной задачи, а не постоянный доступ ко всему, что когда-то понадобилось разработчику.
Для тех, кто предпочитает слушать
Выпустили аудиоверсию этого материала. В выпуске подробный разбор того, почему статические сервисные аккаунты не подходят для ИИ-агентов, как устроен подход Non-Human Identity (NHI) и как принципы Zero Trust адаптируются к миру автономных алгоритмов.
Слушайте нас на своих любимых подкаст-платформах: