В 83% организаций нечеловеческих учетных записей уже больше, чем пользователей-людей, а отдельные правила управления для них внедрили лишь 21% компаний. На этом фоне безопасность ИИ-агентов перестает быть темой для пилотов и хакатонов: для ИТ-команд это уже вопрос инвентаризации, доступа и персональной ответственности за действия ботов в рабочих системах.
Об этом сообщает VentureBeat в спонсорской колонке JumpCloud, где CTO и сооснователь компании Грег Келлер предложил четырехшаговую схему для защиты так называемых workforce identities. Логика у текста неприятно практичная: если агент умеет заходить в Salesforce, создавать задачи в Jira, поднимать инфраструктуру, проводить финансовые операции или писать от имени команды, то он уже не «просто автоматизация». Это полноценный участник контура доступа, только без нормального онбординга, без владельца и часто без процедуры отключения, когда эксперимент закончился или проект quietly закрыли. Важная оговорка тоже на месте: перед нами не нейтральный академический обзор, а вендорский playbook. Но именно поэтому материал полезен не лозунгами, а списком процессов, которые либо есть, либо их нет.
Первый шаг в этой схеме звучит скучно, а потому особенно полезно: сначала надо понять, сколько агентов вообще живет в компании. Проблема теневого ИИ в том, что ИТ-отдел обычно узнает о новом агенте постфактум, когда тот уже подключен к SaaS-сервисам, облаку или внутренним системам. JumpCloud предлагает вести не разовый аудит, а постоянный реестр по всем средам: облачные платформы, управляемые устройства, SaaS-интеграции и on-prem. Для каждого агента нужны минимум три ответа: к чему он имеет доступ, на какие процессы влияет и что запускает его действия. Без этого безопасность ИИ-агентов быстро превращается в гадание по логам и надежду, что ничего критичного бот не тронет.
Второй этап еще важнее: каждый агент должен быть зарегистрирован как формальная identity в корпоративном каталоге, с понятной целью, границами полномочий и именем живого владельца. Именно владелец отвечает за продление доступа, пересмотр прав и отключение агента, если его задача исчезла. Здесь авторы бьют по очень распространенной практике, когда весь агентный слой держится на сервисных аккаунтах и API-ключах в переменных окружения. Такой подход удобен ровно до первого инцидента. Потом внезапно выясняется, что агент живет уже полгода дольше проекта, накопил лишние права и никто толком не может объяснить, зачем он вообще все еще работает. Так появляются зомби-агенты, которые формально никому не нужны, а фактически продолжают ходить по продовым системам.
Третий этап касается доступа: только least privilege и никакой любви к постоянным секретам. JumpCloud прямо пишет, что статические ключи в environment variables и учетные данные, которые никогда не ротируются, становятся постоянным источником риска. Вместо этого предлагается выдавать привилегированные права just-in-time, включать обязательное человеческое согласование перед чувствительными действиями и держать аварийный стоп-кран, который срабатывает быстро, а не после бесконечной эскалации. Для агентов, которым нужен доступ к веб-приложениям, SSH или базам данных, добавляется еще одно требование: модель должна выполнять задачу, не видя исходный пароль или ключ. Иначе это не контроль доступа, а самообман с красивым интерфейсом. Отдельно подчеркивается и необходимость записи всех привилегированных сессий для аудита.
Четвертый этап переносит разговор из стадии внедрения в нормальную эксплуатацию. Если агент заведен в каталог, это еще не значит, что им управляют. Управление начинается там, где каждая его операция логируется, права регулярно пересматриваются, а отклонения от разрешенного поведения заметны до инцидента, а не после него. Келлер формулирует жесткий критерий: компания должна уметь восстановить цепочку «что агент открыл, что сделал, кто это разрешил и чем все закончилось». Если такой цепочки нет, значит организация не управляет агентом, а просто надеется, что он не сломает ничего дорогого. Для CISO и платформенных команд это, по сути, знакомый IAM-подход, только примененный к новому классу пользователей, которые не ходят в отпуск и не забывают пароль, зато могут очень быстро масштабировать ошибку.
Отдельный акцент в колонке сделан на устройстве ИТ-ландшафта. По данным JumpCloud, компании с полностью унифицированной средой в пять раз чаще используют агентов в бизнес-критичных процессах, чем организации с разрозненным стеком. В компании это называют Agentic IAM: единый слой управления людьми, устройствами и агентами. Для разработчиков, платформенных команд, продактов и ИТ-директоров вывод получается довольно земной. Проблему нельзя закрыть одной новой моделью или еще одним оркестрационным фреймворком. Если агент умеет создавать тикеты, дергать инфраструктуру, проводить платежную операцию или отвечать клиенту от лица команды, ему нужен владелец, жизненный цикл и понятная процедура отключения. Иначе безопасность ИИ-агентов упрется в старые сервисные аккаунты с админскими правами, о которых вспоминают только после утечки, ошибочного платежа или странной активности в логах.
Следующая большая развилка для корпоративного ИИ выглядит уже не как спор о качестве моделей, а как спор о дисциплине доступа. Кто раньше встроит агентов в обычный joiner-mover-leaver-цикл, ревью прав и быстрый офбординг, тот сможет масштабировать автоматизацию без коллекции бесхозных учеток на балансе. Исходный материал с цифрами и рамкой JumpCloud опубликован на .