82% организаций за последний год обнаружили как минимум одного AI-агента, о котором не знали команды безопасности, IT или governance, а 65% уже столкнулись с инцидентами с их участием. Для русскоязычной IT-аудитории это важный сигнал: безопасность AI-агентов быстро превращается из абстрактной темы про «умных помощников» в вполне земную задачу про доступы, сервисные учётки и контроль изменений.
Как пишет BleepingComputer, такую позицию продвигает компания Token Security в спонсорском материале о том, почему AI-агентов пора считать полноценными цифровыми идентичностями. Логика у тезиса простая: если агент может читать данные из CRM, запускать workflow, менять записи в Jira, работать с GitHub, Snowflake, облачной инфраструктурой и даже выкатывать код, то с точки зрения риска это уже не просто интерфейс к модели, а участник корпоративной системы с правами, следами действий и потенциальным радиусом поражения.
Собственно, на этом и ломается старый комфортный сценарий IAM, к которому привыкли многие компании. Раньше архитектура была понятной: есть сотрудники, которые логинятся через провайдера идентичности, есть сервисные аккаунты для интеграций, есть API-ключи для приложений и облака. Роли, владельцы, сроки жизни и хотя бы базовая инвентаризация у таких сущностей обычно существуют. С AI-агентами всё менее опрятно. Они часто появляются снизу: один отдел подключил помощника для подготовки встреч, другой дал ему доступ к Salesforce, третий привязал к базе знаний, четвёртый добавил GitHub и CI/CD, а учётные данные вообще были выданы когда-то под другой проект. На выходе получается не «ещё один бот», а плохо видимый актор с широкими правами.
Проблема не в модели, а в доступах
Это заметный сдвиг в самой постановке вопроса. Разговор про риски AI до сих пор часто крутился вокруг prompt injection, jailbreak, утечек через ответы модели и прочих неприятностей на уровне поведения системы. Всё это никуда не делось, но Token Security поднимает более приземлённый вопрос: к чему агент вообще подключён и что он может сделать в реальной инфраструктуре. AI-агент, который суммирует публичную документацию, неприятен разве что неточными ответами. AI-агент, у которого есть доступ к клиентским данным, исходникам, финансовым системам и облачным админским ключам, уже ближе к кошмару любого CISO.
Авторы материала приводят данные опроса Cloud Security Alliance за 2026 год, заказанного Token Security: 41% организаций заявили, что обнаруживали несанкционированно созданных AI-агентов несколько раз за год. Ещё жёстче выглядит статистика по инцидентам: 65% компаний сообщили о проблемах с участием AI-агентов, а в 61% таких случаев речь шла об экспозиции или неправильной обработке чувствительных данных. Это не доказывает, что виноваты именно модели или что все компании уже тонут в agentic chaos, но показывает важную вещь: контур управления доступами явно не поспевает за скоростью внедрения ассистентов и агентов.
И здесь для разработчиков и DevOps-команд есть неприятная, но знакомая мораль. Когда бизнес просит, чтобы «помощник уже работал к концу недели», ему почти всегда дают доступы с запасом. Так быстрее. Потом агент начинает жить дольше, чем планировалось, получает новые инструкции, подключается к ещё одному сервису, его начинают использовать другие сотрудники, а никто уже толком не помнит, на каких токенах и сервисных аккаунтах всё держится. Least privilege в таких историях умирает тихо, без торжественных проводов. Именно поэтому безопасность AI-агентов быстро становится не задачей про настройку одного продукта, а задачей про постоянный пересмотр прав, владельцев и связей между системами.
Что это меняет для бизнеса и ИБ
Ключевая мысль материала в том, что одной инвентаризации здесь мало. Проверка «раз в квартал» или аудит «для галочки» дают красивый отчёт и ложное чувство порядка, но не решают проблему дрейфа полномочий. AI-агенты меняются постоянно: обновляются промпты и инструкции, расширяются наборы инструментов, меняются владельцы, добавляются плагины и интеграции. Узкий внутренний помощник может довольно быстро превратиться в полуавтономного оператора, который видит больше систем, чем планировалось изначально. Причём не потому, что кто-то однажды принял катастрофическое решение, а потому, что десяток маленьких решений никто не отслеживал как единый риск.
Практический вывод для IT-директоров, архитекторов и руководителей ИБ тут довольно прямой. Если агент может действовать от имени человека или автономно, ему нужен тот же минимум гигиены, что и другим цифровым сущностям: понятный владелец, описанная цель, список подключённых систем, набор используемых учётных данных, ограничения по действиям и наблюдаемость. Вопросы должны быть не декоративные, а технические: кто может вызывать этого агента, какие секреты он использует, что он может читать, писать, удалять или исполнять в каждой системе, и соответствует ли это исходной задаче. Для финансового агента ответ «он может создавать новых привилегированных пользователей в облаке» должен звучать так же дико, как и для человека с ролью бухгалтера.
Для российского рынка это особенно актуально там, где AI уже начинают подвязывать к внутренним базам знаний, сервис-дескам, CRM, ERP, репозиториям и корпоративным мессенджерам. На уровне пилота такие связки выглядят безобидно: все радуются скорости, автоматизации рутины и экономии часов команды. Но через несколько месяцев выясняется, что агент фактически стал новой прослойкой доступа между несколькими критичными системами. И если компания не умеет считать такие сущности отдельными идентичностями, она почти наверняка недооценивает свой фактический attack surface.
В этом смысле спор уже не про то, пускать ли AI-агентов в enterprise. Они там давно. Вопрос в другом: успеют ли IAM- и ИБ-практики догнать реальность раньше, чем агенты окончательно превратятся в невидимых привилегированных инсайдеров с очень удобным API.