Безопасность AI-агентов уперлась не только в логины, токены и роли: агент может не взломать контроль доступа, а аккуратно обойти его через разрешенные инструменты. По данным The New Stack, с идентичностью для агентов базовая рамка уже понятна: каждому агенту нужен собственный короткоживущий, отзывной и строго ограниченный credential. Для русскоязычных команд это означает простую вещь: прикрутить агента к корпоративному SSO мало, придется пересматривать всю модель доверия вокруг действий, данных и инструментов.
Главная мысль материала The New Stack звучит неприятно для тех, кто привык измерять безопасность галочками в IAM: агент не обязан ломать правила, чтобы создать инцидент. Он может работать в рамках выданных прав, но использовать их не так, как ожидал архитектор системы. Например, дернуть разрешенный API, передать чувствительный фрагмент в другой инструмент, собрать данные из нескольких источников или выполнить цепочку действий, которая по отдельности выглядит легитимно, а вместе превращается в утечку или нарушение процесса.
В классической корпоративной безопасности человек, сервисный аккаунт и приложение обычно укладывались в понятные категории. Человек логинится через SSO, приложение получает service account, API живет за gateway, права режутся по ролям. AI-агент ломает эту аккуратную схему не потому, что он мистическое существо из презентации вендора, а потому что он действует автономно, комбинирует инструменты и принимает промежуточные решения внутри задачи. У него может быть доступ к почте, репозиторию, CRM, внутренней базе знаний и среде разработки. Каждая интеграция сама по себе выглядит разумно. Вместе они дают поверхность атаки, которую трудно описать старой матрицей прав.
Отсюда и тезис про отдельную идентичность агента. Нельзя выдавать AI-агенту токен человека или вечный ключ сервисного аккаунта и надеяться, что аудит потом все объяснит. Агенту нужен собственный субъект в системе безопасности: с отдельной учетной записью, сроком жизни credential, возможностью быстрого отзыва, журналированием действий и scope, который не шире конкретной задачи. Это не украшение архитектуры, а минимальная санитария. Без нее расследование инцидента превращается в угадайку: действие сделал пользователь, агент от имени пользователя, плагин агента или внешний сервис?
Но The New Stack подчеркивает вторую, более важную часть: identity решает не весь класс проблем. Если агенту разрешили читать тикеты, писать комментарии в pull request и запускать команды в CI, то риск живет уже не только в credential. Он живет в маршруте выполнения задачи. Агент может получить инструкцию из тикета, интерпретировать ее как рабочую, подтянуть контекст из репозитория, вызвать инструмент и отправить результат туда, куда разработчик не планировал. Формально все шаги могут быть разрешены. Практически это уже обход контроля.
Для разработчиков это меняет требования к интеграции агентных систем. Нужны не только роли, но и политики на уровне действий: какие инструменты можно вызывать, в каком порядке, с какими типами данных, после какого подтверждения и с каким лимитом. Для операций с продакшеном, платежами, персональными данными, секретами и исходным кодом придется вводить дополнительные рубежи: подтверждение человеком, sandbox, dry run, allowlist команд, фильтрацию вывода и запрет на передачу отдельных классов данных во внешние модели или плагины.
Для бизнеса урок еще прозаичнее. Если компания запускает AI-агентов в разработке, поддержке, продажах или HR, ей нельзя считать это обычной автоматизацией уровня «скрипт плюс API». Агент работает с намерением, но без человеческого здравого смысла и без организационного контекста, который люди часто держат в голове. Он может выполнить задачу слишком буквально, слишком широко или слишком старательно. Поэтому безопасность AI-агентов должна включать threat modeling: какие данные агент видит, какие решения принимает сам, где он может ошибиться, кто подтверждает опасные действия и как быстро команда сможет остановить его работу.
Отдельный вопрос — наблюдаемость. Логи в стиле «запрос выполнен успешно» уже не помогут. Командам нужны трассы агентных действий: исходная цель, использованный контекст, вызванные инструменты, промежуточные решения, переданные данные и итоговый результат. Иначе невозможно отличить нормальную автоматизацию от тихого накопления риска. Особенно в больших компаниях, где один агент может быть встроен в десятки рабочих процессов, а его ошибки обнаружатся не сразу, а после странной записи в CRM, лишнего доступа в репозитории или утекшего фрагмента внутреннего документа.
Самый практичный вывод: безопасность AI-агентов начинается с identity, но не заканчивается на ней. Короткоживущий credential, отзыв прав и точный scope — это входной билет. Следующий слой — контроль поведения: ограничения на инструменты, контекст, данные и автономность. И чем быстрее агенты переходят из демо в рабочие процессы, тем меньше смысла спрашивать, «доверяем ли мы модели». Более полезный вопрос: что именно она сможет сделать, когда ошибется, и кто это заметит раньше клиента, регулятора или злоумышленника?