Сторонние ИИ-агенты остаются вне контура SSO и контроля доступа
В средах, изученных для отчёта State of Agent Security Report 2026, около 1 280 сторонних продуктов уже содержат ИИ-функции, однако лишь примерно 282 из них находятся за единым входом SSO. Около тысячи агентов не видны инфраструктуре управления идентичностью по умолчанию: они не проходят аутентификацию через этот контур.
Авторы связывают разрыв с изменением способа появления ИИ в компаниях. Раньше организация отдельно выбирала модель или сервис, закупала лицензии, разворачивала шлюз и назначала владельца. Теперь агенты нередко приходят вместе с обновлениями уже используемых приложений, без самостоятельного решения о внедрении.
Агент может появиться без отдельного проекта
В материале выделены три пути появления агентов. Унаследованные агенты поставляются внутри существующих платформ через обновления продукта. Настроенные агенты используют корпоративные промпты и логику, но работают на чужих рантаймах, моделях и коннекторах. Собственные агенты создаются на открытых фреймворках и инфраструктуре компании.
Наиболее распространены первые две категории, тогда как собственные разработки составляют меньшую часть. При этом конечная точка риска не зависит от происхождения агента: агент из CRM может обращаться к хранилищу данных и системе заявок, а собранный в облаке агент — получать токены к Salesforce, Slack и Google Drive.
Права и связность важнее самой модели
Авторы предлагают оценивать каждого агента по четырём направлениям: идентичность, разрешения, связность и активность. Вопрос идентичности сводится к тому, зарегистрирован ли агент и понятно ли, кто за него отвечает. Для разрешений важно определить, какие OAuth-права и роли он унаследовал и необходимы ли они для его задачи.
Связность показывает, до каких приложений, хранилищ, выданных разрешений и других агентов может добраться система — напрямую или через цепочки интеграций. Именно она определяет потенциальный радиус воздействия. Активность следует оценивать по фактическому поведению, а не только по описанию в промпте.
В качестве примера приводится Slack Code от Salesforce, представленный в августе 2026 года. Пользователь может упомянуть кодингового агента в разговоре, после чего тот читает доступный контекст, пишет код и открывает pull request. Salesforce заявляет, что агенты наследуют встроенную модель безопасности Slack, разрешения и административные средства. Для команды безопасности это означает, что автономное действие может опираться на членство в канале чата и одновременно затрагивать GitHub либо производственную инфраструктуру.
Инвентаризация должна быть постоянной
Патрик Опет, глобальный CISO JPMorgan Chase, ранее называл цепочку сторонних поставщиков системным риском, а применительно к агентам предлагает выдавать им идентичность без прав по умолчанию. Прежде чем агент получит доступ за заданными границами, ИТ-служба должна подтвердить, от чьего имени он действует.
Требования EU AI Act, вступающие в силу поэтапно в 2026 году, также предполагают, что организация способна инвентаризировать ИИ-системы, назначать владельцев и подтверждать надзор. Компании, не умеющей перечислить своих агентов, будет сложно выполнить эти ожидания.
Практический вывод для бизнеса: контроль нужно строить вокруг постоянно обновляемой карты агентов, их идентичностей, прав, связей и действий. Квартальные проверки и таблицы не дают такой картины, если новые агенты появляются вместе с обновлениями корпоративных сервисов.