У корпоративного ИИ появилась новая проблема, и дело не в галлюцинациях. Всё чаще безопасность ИИ-агентов упирается в банальную вещь: таким системам выдают слишком широкие права, хотя сами они действуют не по жёсткому сценарию, а через подбор шагов и обходные пути.
Для российских команд, которые уже автоматизируют через агентов DevOps, аналитику, поддержку и внутренние процессы, вывод неприятный, но практичный: цена ошибки теперь зависит не только от качества запроса к модели, но и от масштаба доступа, который ей выдали.
На этом акцентирует внимание BleepingComputer со ссылкой на позицию Token Security. Логика простая: фильтрация запросов и поведенческие ограничения мало помогают, если агент уже получил доступ к рабочим системам, данным или административным функциям. Если цифровому помощнику дали ключи от половины инфраструктуры, вопрос уже не в том, ошибётся ли он, а в том, во сколько эта ошибка обойдётся.
Проблема сместилась с ответов модели к правам доступа
Агент отличается от обычного скрипта тем, что не идёт по одному заранее заданному маршруту. Он пробует действие, смотрит на результат, корректирует курс и продолжает. В материале приводят показательный пример: модель может несколько минут пытаться открыть CSV-файл, который на деле оказался папкой, затем сменить подход, написать вспомогательный скрипт, вывести содержимое каталога и всё же добраться до нужных данных.
Именно эта способность искать обходной путь и делает ИИ-агентов полезными. Но она же превращает избыточные права в риск. Когда системе разрешили «почти всё, на всякий случай», любой неверный шаг получает гораздо больший радиус поражения.
Отсюда и типичная ловушка внедрения. Команде нужно быстро запустить агента, подключить его к SaaS-сервисам, облаку, журналам событий, базе знаний, а иногда и к рабочим инструментам. Дальше начинаются скучные, но критичные вопросы: давать ли все интеграции сразу, нужен ли административный доступ для редких случаев, ограничивать ли права под конкретную сессию или один раз выдать широкие полномочия. На практике часто побеждает самый ленивый сценарий. Полный доступ ускоряет запуск и помогает быстрее показать результат бизнесу. Только потом выясняется, что никто толком не знает, сколько таких агентов уже работает, от чьего имени они заходят в системы и какие привилегии накопили.
Классический IAM уже не закрывает весь риск
Рынок ИИ-безопасности последние два года в основном занимался ответами модели: фильтрацией запросов, ограничением нежелательных тем, контролем входа и выхода, поиском аномального поведения. Всё это полезно, пока проблема остаётся на уровне текста. У ИИ-агентов слабое место сместилось глубже — к идентификации и доступу.
Фильтр может запретить модели сказать лишнее, но он не отзовёт уже выданный API-ключ, OAuth-токен, сервисную учётную запись или облачную роль. Если агент авторизован в боевой системе, граница защиты уже осталась у него за спиной.
Классический IAM тоже работает неидеально, если применять его без поправки на специфику агентного ИИ. Для человека обычно достаточно ролей, регламентов, пересмотра прав раз в квартал, MFA и понятного владельца. С агентами картина другая: они не спят, не проходят MFA в человеческом смысле, создаются за минуты и могут годами висеть в инфраструктуре без внятного жизненного цикла. Два агента с одинаковыми правами способны вести себя совершенно по-разному, потому что у них разная цель. Один разбирает сбойный выпуск, другой при похожей цепочке действий уже вытаскивает чувствительные данные.
Отсюда и идея контроля доступа с учётом задачи агента, а не только списка ресурсов. Вопрос уже не в абстрактном «что он может открыть», а в более жёстком «что именно ему нужно для этой конкретной работы и ничего сверх этого». В таком подходе принцип наименьших привилегий перестаёт быть красивым лозунгом из презентации и становится рабочим правилом.
Рост числа агентов превращает риск в операционную задачу
Самая заметная цифра в материале — оценка Palo Alto Networks: на одного сотрудника в компаниях уже приходится 109 нечеловеческих сущностей доступа, из них 79 — ИИ-агенты. Даже если спорить о методике подсчёта, направление движения очевидно: машинных учётных записей в корпоративной среде уже больше, чем живых сотрудников, а агентный ИИ только ускоряет этот перекос.
Нового помощника можно запустить за часы, а иногда и за минуты. И чаще всего это происходит не после долгого согласования с ИБ, а прямо внутри продуктовой, инженерной или операционной команды. Иными словами, теневой ИИ здесь уже не побочный эффект, а обычный сценарий роста.
Для разработчиков это меняет саму постановку вопроса. Разговор об ИИ-агентах быстро уходит из плоскости «какую модель выбрать» в плоскость «от чьего имени она действует и кто потом заберёт у неё права». Для бизнеса вывод ещё проще: риск определяется не только качеством модели, но и сочетанием двух факторов — уровня доступа и степени автономности. Чем шире права и чем меньше окно для вмешательства человека, тем выше цена ошибки.
Что это меняет для российских ИТ-команд
Практический минимум выглядит прозаично. Сначала нужна инвентаризация: какие агенты уже запущены, через какие сервисные учётные записи, токены и роли они работают, и какие из них давно живут без владельца. Затем — привязка прав к конкретной функции агента, а не к желанию «пусть умеет побольше». Последний слой — полный жизненный цикл доступа: выдача, пересмотр, ограничение и отзыв после вывода из эксплуатации.
Для рынка России и СНГ это особенно актуально там, где агенты уже подключают к внутренним контурам: в банках, телекоме, интеграторах и крупных ИТ-командах. Если агент может читать журналы событий, вызывать API, заходить в базы и менять настройки инфраструктуры без подтверждения, проблема уже не в том, что он иногда ошибается. Проблема в том, что он ошибается быстро, формально легально и с правами, которые ему никто вовремя не урезал.
В ближайшие кварталы компании будут соревноваться уже не только в скорости внедрения ИИ-агентов, но и в том, кто быстрее научится выдавать им минимально достаточный доступ, а не ключи от всей серверной сразу.