29 июня 2026 года BleepingComputer опубликовал спонсорскую колонку Token Security о том, что безопасность AI-агентов быстро превращается в отдельную головную боль для корпоративной ИБ. Проблема не в том, что модель может написать странный ответ, а в том, что агент уже умеет ходить в корпоративные системы, дергать API, запускать процессы и делать это с токенами, OAuth-правами и облачными ролями, про которые в компании нередко никто толком не знает.
Как пишет BleepingComputer, материал подписан Итамаром Апельблатом, CEO и сооснователем Token Security. Его тезис простой: для бизнеса AI-агенты уже не выглядят как очередной SaaS-модуль или чат-бот на витрине. Это цифровые исполнители, которые аутентифицируются, получают разрешения, обращаются к базам данных, пишут код, триггерят workflows и могут действовать в production-среде. Отсюда и сдвиг в постановке вопроса: ИБ-командам нужно разбираться не только с тем, что агент «говорит», но и с тем, кто он такой, какие у него права, кто отвечает за его действия и как быстро этот доступ можно отозвать.
Для русскоязычной IT-аудитории тут нет ничего экзотического. Компании уже проходили похожий сюжет с облаками, SaaS и DevOps: сначала бизнес бежит вперед, потом безопасники пытаются понять, как не превратить все это в публичный аттракцион для атакующих. Разница в том, что AI-агенты совмещают худшие свойства двух миров. С одной стороны, они похожи на машинные учетные записи: сервисные аккаунты, сертификаты, секреты, API-ключи. С другой, ведут себя ближе к человеку: интерпретируют цель, выбирают последовательность действий и принимают решения на ходу. В результате старая логика identity management, заточенная под сотрудников с понятной ролью и менеджером сверху, начинает трещать.
Token Security выделяет три основных риска. Первый — банальная невидимость. В компаниях уже формируется shadow AI: агенты появляются внутри команд разработки, приходят через SaaS-платформы с «умными» функциями, запускаются локально на рабочих станциях и в developer environments, подключаются к тикет-системам, облачным консолям, IdP и автоматизации. Если служба ИБ не знает, что агент вообще существует, дальше разговор заканчивается быстро: невозможно оценить blast radius, нельзя понять, чьи учетные данные он использует, и некого спросить, зачем вся эта конструкция до сих пор живет в проде.
Второй риск — избыточные привилегии. Во время экспериментов доступ почти всегда выдают по принципу «пусть пока работает». Разработчик добавляет API-токен пошире, бизнес-подразделение подключает агента к SaaS-аккаунту с административными правами, команда продукта встраивает секреты в workflow, потому что так быстрее. Для пилота это удобно, для безопасности AI-агентов — плохая новость. Такой технический долг копится не месяцами, а буквально со скоростью развертывания новых агентов. Особенно неприятно это выглядит в сценариях, где один агент лишь суммирует обращение пользователя, а другой уже умеет оформлять возврат, менять данные клиента или запускать команды в production. На бумаге оба называются «AI-агентами», по факту уровень риска у них разный примерно как у стажера и у SRE с root-доступом.
Третий риск — prompt injection и косвенные манипуляции. Если агент читает недоверенный контент и одновременно способен выполнять привилегированные действия, атакующему не обязательно ломать чью-то учетку в классическом стиле. Достаточно подсунуть агенту данные, которые повлияют на его дальнейшее поведение, особенно если ему заранее выдали слишком широкий доступ. Для разработчиков и платформенных команд это неприятный, но полезный разворот оптики: prompt injection перестает быть забавной демонстрацией из презентации и становится частью обычной модели угроз, где слабое место — связка из автономии, доступа и отсутствия четких границ.
Отсюда и главный вывод статьи: управлять нужно не только моделью, но и идентичностью агента. Token Security настаивает, что у каждого такого инструмента должна быть отдельная identity, а не общий сервисный аккаунт и уж тем более не заимствованные человеческие credentials. У агента должен быть владелец, понятная бизнес-цель, согласованный scope действий и жизненный цикл. Права нужно выдавать под задачу, а не «на всякий случай», секреты — ротировать и убирать из мест, откуда агент может их утянуть в лог, ответ или внешний вызов. Ручные ревью раз в квартал тут не спасут: агенты могут создаваться разработчиками, бизнес-пользователями и SaaS-вендорами слишком быстро, поэтому обнаружение, классификация доступа, поиск рискованных путей и отзыв прав придется автоматизировать.
Для CIO, CISO, CTO и руководителей платформенных команд здесь есть еще один неприятный, но честный вывод. Отдельная «AI security strategy» на слайдах сама по себе проблему не решит, если в компании по-прежнему не видно, какие машинные идентичности существуют, кто ими владеет и где у них лишние разрешения. ИБ-команда не сможет стать ручным диспетчером для каждого нового агента, поэтому модель управления будет смещаться к децентрализованной разработке при централизованных правилах: обязательный owner, логирование, ограничение полномочий, срок жизни доступа, возможность мгновенного revoke. Иначе компания получит не цифровых помощников, а парк полуавтономных сущностей с правами, которые выдавались в духе «разберемся потом».
В ближайшие месяцы спор о безопасности AI-агентов, похоже, окончательно уйдет из плоскости «можно ли доверять ответу модели» в плоскость «кому и на каких условиях мы вообще разрешили действовать от имени компании». И это уже вопрос не маркетинга вокруг AI, а базовой дисциплины управления доступом: если агент умеет что-то менять в инфраструктуре, CRM, коде или финансах, к нему придется относиться как к полноценной привилегированной идентичности, а не как к симпатичному интерфейсу поверх LLM.