В среднем у одной организации уже 22 отдельных проекта с AI-агентами, и для служб безопасности это плохая новость. Проблема не в самом хайпе вокруг GenAI, а в том, что идентификация AI-агентов у большинства компаний до сих пор устроена по старой схеме: как для сервисных аккаунтов, ботов и API-токенов. Для русскоязычных команд это прямой сигнал: если агенты уже трогают репозитории, пайплайны и деплой, привычный IAM здесь начинает давать сбои.
Об этом сообщает Dark Reading в колонке Моры Гозани, вице-президента по стратегии BlueFlag Security, опубликованной 9 июля 2026 года. Ключевой тезис простой и неприятный: AI-агент нельзя считать еще одной разновидностью non-human identity. Сервисный аккаунт действует по жестко заданному сценарию. Агенту задают цель, а путь к ней он выбирает сам: запускает действия, меняет последовательность шагов, подстраивается под контекст и работает без привязки к рабочему дню. Для security-команд это уже не привычная задача про учетку с правами, а отдельный класс риска.
Отсюда и главный сдвиг в логике защиты. Раньше модель управления доступом держалась на двух базовых допущениях. Для людей предполагались человеческая скорость, ограниченное число действий и возможность восстановить ход событий по почте, тикетам, коммитам и логам. Для машинных идентичностей предполагалось детерминированное поведение в узких рамках: токен вызывает API, бот выполняет скрипт, служебная учетка обслуживает конкретный процесс. AI-агенты ломают обе конструкции сразу. Они действуют быстрее людей и менее предсказуемо, чем классические машинные учетные записи. Поэтому идентификация AI-агентов требует не косметического апдейта политик, а другой модели контроля: с учетом автономности, истории действий, контекста решений и жизненного цикла такого агента.
Самый болезненный участок, по версии автора, это среда разработки. Именно там агенты уже встроены глубже всего и получают больше пространства для самостоятельных действий. В материале проводится важная граница между двумя волнами AI в инженерных командах. Первая волна, уже ставшая нормой, это ассистенты вроде GitHub Copilot, Cursor и Claude: они подсказывают код, ускоряют рутину, но человек остается в контуре принятия решения. Вторая волна, которая быстро приближается, это автономные агенты: они сами пишут код, запускают тесты, открывают pull request, одобряют слияния и инициируют деплой. Не каждая компания уже дошла до этой стадии, но сама траектория очевидна. И если в первом сценарии риск чаще обсуждают как проблему качества кода, то во втором речь уже идет о контроле над самостоятельной цифровой сущностью с доступом к критичной цепочке поставки ПО.
На практике это меняет и набор вопросов, которые должны задавать CISO, платформенные команды и тимлиды. Не только «прошел ли код проверку», но и «какой именно агент внес изменение», «какие права у него были в этот момент», «кто и когда выдал эти права», «участвовал ли вообще человек в цепочке действий». Автор точно подмечает: уязвимый код часто оказывается лишь симптомом, а корень проблемы находится раньше, на уровне неуправляемой идентичности. Если компания не может связать конкретный PR, запуск пайплайна или изменение конфигурации с конкретным агентом и его набором разрешений, значит, она в лучшем случае тушит последствия. Идентификация AI-агентов здесь превращается из темы для roadmap в базовый элемент наблюдаемости и расследований.
Dark Reading также ссылается на позицию аналитика Omdia Тодда Тиманна, который выделяет четыре обязательные способности для защиты таких сущностей. Во-первых, нужно знать всех агентов в контуре, а не только официально одобренных. Во-вторых, нужно понимать, к чему каждый агент имеет доступ и чем реально пользовался. В-третьих, нужны поведенческие базовые линии, иначе невозможно отличить нормальную активность от опасной. В-четвертых, обязателен контроль жизненного цикла: если проект завершен, доступ агента должен завершиться вместе с ним, а не доживать свою тихую жизнь в инфраструктуре еще полгода. Звучит не как футуризм, а как базовая гигиена IAM, но именно ее, по мнению автора, у большинства компаний сейчас нет применительно к агентным системам.
Отдельно важен и комплаенс-аспект. В статье напоминают, что аудиторы и регуляторы задают похожие вопросы уже больше 20 лет, в том числе в логике требований Sarbanes-Oxley: кто изменил систему, кто это одобрил, можно ли восстановить цепочку событий. Новизна не в самих вопросах, а в том, что с AI-агентами отвечать на них стало заметно сложнее. Если агент инициировал изменение, воспользовался несколькими правами в разных системах, а человек подключился только в конце или вообще не подключился, стандартный audit trail оказывается дырявым. Для российских и русскоязычных команд это особенно актуально не только в enterprise-контуре, но и в быстрорастущих продуктовых компаниях, где любят ускорять SDLC через ботов, внутренние Copilot-плагины и полуавтономные CI/CD-сценарии. Пока агент выглядит как удобный инструмент, о нем часто думают как о функции. Как только он получает цель, доступы и право действовать без постоянного подтверждения, это уже участник инфраструктуры, а не просто кнопка.
Сильная мысль материала в том, что identity-команды больше не могут позволить себе оставаться «отделом запретов», а security и engineering придется делить эту зону ответственности. Для бизнеса вопрос уже не сводится к тому, внедрять ли AI-агентов. Гораздо важнее, успеет ли компания выстроить правила раньше, чем агенты начнут жить в продакшене собственной жизнью. Кто первым научится видеть такого агента как полноценную идентичность с историей, контекстом и границами полномочий, тот, вероятно, и пройдет следующую фазу автоматизации без неприятных сюрпризов в логах, пайплайнах и на совете по рискам.