26 июня 2026 года The Hacker News разобрал проблему, о которой многие ИБ-команды уже догадывались на практике: управление ИИ-агентами в корпоративной среде не укладывается в старую логику IAM. Пока компании подключают агентные сценарии к CRM, репозиториям, внутренним API и документным хранилищам, контроль доступа по-прежнему в основном смотрит на сам факт входа в систему, а не на то, что происходит после него.
Как пишет The Hacker News, речь уже не о теоретическом риске. ИИ-агенты в enterprise-среде наследуют права человека или сервисной учетной записи, переходят между системами, вызывают инструменты и принимают решения на машинной скорости, причем часто без отдельной проверки на каждом шаге. Для русскоязычной IT-аудитории это плохая новость сразу в двух измерениях: разработчики получили удобный инструмент автоматизации, а CISO, IAM-архитекторы и владельцы платформ внезапно обнаружили, что привычные модели контроля покрывают не саму работу агента, а только его старт.
Ключевой тезис материала простой: ИИ-агент нельзя считать еще одной разновидностью service account. У сервисной учетной записи обычно есть понятная функция, ограниченный набор ресурсов и предсказуемый профиль доступа. Агентная система работает иначе. Она получает задачу, сама раскладывает ее на шаги, выбирает инструменты, строит цепочки вызовов, а иногда еще и делегирует подзадачи другим агентам. В рамках одного сеанса такой агент может затронуть CRM, кодовую базу, файловое хранилище и внутренний API, причем не потому, что это кто-то вручную разрешил для конкретной операции, а потому что именно так он решил выполнить инструкцию. В этом и ломается старая модель: объект доступа больше не статичен, а траектория его действий заранее неочевидна.
Самая неприятная часть, по данным источника, связана не просто с избыточными правами, а с их наследованием. Если агент действует от имени, например, директора по продажам, он использует его OAuth-токены, делегированные разрешения и весь исторически накопленный доступ, который у человека мог остаться после смен ролей и проектов. Для IAM это выглядит как обычная авторизованная сущность. Для бизнеса это означает, что агент способен выполнить гораздо больше, чем человек предполагал, когда нажимал кнопку запуска. Он не различает «что пользователь сделал бы сам» и «что ему сейчас поручили в рамках автоматизации». Он просто идет по маршруту с теми полномочиями, которые уже достались по наследству.
Отсюда и следующий вывод: проблема архитектурная, а не конфигурационная. Традиционные IAM-инструменты исторически строились вокруг событий аутентификации. Пользователь вошел, система проверила учетные данные, доступ выдан или отклонен. Но агент аутентифицируется один раз, часто через долгоживущий токен или API-ключ, а дальше работает непрерывно через разные контексты и приложения без нового контрольного рубежа. Итог хорошо знаком тем, кто когда-либо разбирал старые корпоративные права: агент находит «темную материю» идентификационной инфраструктуры, то есть забытые делегирования, лишние разрешения и давно не пересмотренные интеграции, а затем начинает использовать это на скоростях, с которыми ручной аудит уже не конкурирует. То, что годами считалось неприятным, но терпимым техническим долгом, в агентной среде превращается в активную поверхность атаки.
Почему тема резко выстрелила именно сейчас, источник тоже объясняет достаточно приземленно, без магии про «новую эру». Сошлись три фактора: модели научились стабильно проходить многошаговые сценарии, инфраструктура для оркестрации стала заметно проще, а бизнес получил давление на автоматизацию знаний и процессов, которое уже не закрыть одним наймом. Еще год назад надежный multi-agent workflow требовал заметной кастомной инженерии. Теперь для этого есть более стандартные кирпичики: LangGraph, AutoGen и Model Context Protocol. Плюс, как отмечает The Hacker News, стоимость инференса у крупных провайдеров снизилась настолько, что запускать агентные цепочки стало экономически разумно не только по запросу, но и почти в постоянном режиме. Поэтому агенты уже берут на себя закупочные процессы, эскалации в поддержке, code review, финансовые сверки и поиск внутренних знаний.
Для ИБ-команд здесь есть отдельный организационный сюрприз: они часто узнают о таких внедрениях последними. Сценарий повторяется почти одинаково. Команда разработки, ops или бизнес-функция находит рутинный процесс, вендор предлагает агентную интеграцию или API, дальше решение быстро уезжает в прод. Безопасность видит его позже: во время аудита, разбора инцидента или вообще случайно. Причина банальна: агент не проходит привычный жизненный цикл идентичности. Он не подает заявку на доступ, не онбордится в IGA, не получает формального владельца в каталоге. Он просто берет существующие креды и начинает работать. В результате в инфраструктуре растет популяция автономных сущностей без нормальной инвентаризации, без понятного ownership и без поведенческого профиля, с которым можно сравнивать отклонения.
Что такое guardian agents
На этом фоне The Hacker News вводит термин guardian agents, то есть специализированный автономный слой контроля для самих ИИ-агентов. Идея в том, что обычный IAM управляет людьми и статичными machine identities, а guardian agent должен работать на уровне исполнения: наблюдать, какие инструменты вызывает агент, какие данные трогает, между какими системами перемещается и не выходит ли за рамки ожидаемого поведения. По сути, это попытка перенести контроль из точки входа в точку действия. Не квартальный аудит задним числом, а постоянное сопровождение в моменте.
Первая функция такого слоя, согласно материалу, это непрерывная инвентаризация. У каждого агента есть происхождение, владелец, набор унаследованных прав и след в приложениях, но в большинстве компаний все это сегодня собрано максимум по частям. Guardian agent должен сразу регистрировать новую автономную сущность, связывать ее с исходной учетной записью, владельцем и затронутыми системами, а не ждать, пока кто-то когда-нибудь занесет ее в таблицу. Вторая функция еще важнее для практики: построение базовой линии поведения. Если агент обычно ходит в три системы и вызывает предсказуемый набор инструментов, то внезапная попытка лезть в дополнительные API, выгружать другие типы данных или нестандартно пересекать домены должна выглядеть как аномалия, а не как «еще одна успешная сессия» в логе.
Для разработчиков и платформенных команд это значит, что управление ИИ-агентами скоро перестанет быть исключительно темой ИБ-отдела. Придется проектировать агентные сценарии так, чтобы у них были внятные владельцы, минимальные наследуемые права, короткий жизненный цикл токенов и наблюдаемое поведение на уровне вызовов инструментов, а не только на уровне логина. Для бизнеса сигнал тоже предельно ясный: если агент уже умеет ускорять закупки, поддержку и внутренние операции, то он с той же скоростью масштабирует ошибки в правах доступа. Вопрос теперь не в том, появится ли отдельный контур для контроля автономных идентичностей, а в том, успеют ли компании встроить его раньше, чем агентная автоматизация окончательно обгонит их старый IAM по всем фронтам.