Сторонние ИИ-агенты вне SSO: что проверить в каталоге ПО
Контролировать «свой» чат с моделью недостаточно: агент часто приезжает внутри уже купленного CRM, мессенджера или облачной платформы и не проходит через единый вход. По данным обзора The Hacker News со ссылкой на отчёт State of Agent Security 2026, в исследованных средах около 1280 сторонних продуктов уже содержат ИИ, из них примерно 282 стоят за SSO, остальные по умолчанию невидимы для инфраструктуры идентификации. Это не расследование Svictor, а пересказ публикации своими словами; цифры и примеры ниже — из первоисточника.
Почему момент выбора важнее набора средств защиты
Пока компания сама покупает модель, ставит шлюз и пишет политику допустимого использования, у службы ИБ есть точка входа: что сканировать, куда вешать инспекцию запросов, кого назначить владельцем. Агент из обновления продукта эту точку пропускает. В августе 2026 Salesforce запустила в Slack функцию Slack Code: достаточно отметить агента в переписке, он читает контекст канала, пишет код и открывает pull request. В анонсе обещают, что агент «наследует» модель безопасности Slack с первого дня. Для ИБ это означает автономного исполнителя с выходом в GitHub и дальше — без отдельного проекта внедрения и без записи в журнале принятых решений.
Стек идентификации управляет только тем, что через него аутентифицируется. Если агент ходит по встроенному токену приложения или по сессии человека, который его вызвал, в каталоге SSO его не будет. Это не сокрытие, а устройство учёта.
Три пути появления, один контур исполнения
В материале разделяют агентов на купленных и собранных своими руками. Третий путь — самый массовый: агент наследуется вместе с обновлением платформы, которой уже пользуются. Второй по масштабу — сконфигурированный: свои промпты и логика на чужом рантайме, модели и коннекторах. Третий — собранный на своей инфраструктуре; только у него есть репозиторий и сборочный конвейер, которые можно поставить под шлюз. Первые два, по оценке источника, растут быстрее: почти каждое крупное приложение становится площадкой для агентов.
Точка исполнения общая. Агент из CRM добирается до хранилища и системы заявок. Агент на облачной платформе держит токены в Salesforce, Slack и диске. Края у этого слоя нет: связность задаёт не карточка агента, а граф приложений вокруг него.
Четыре вопроса, которые не про модель
У агента две части: модель, которая рассуждает, и обвязка, которая решает, к чему он подключён, что может вызвать и когда действует. Почти весь риск — в обвязке и окружении, не в тексте системного промпта. Четыре проверки покрывают любого агента, независимо от вендора.
| Область | Что выяснить |
|---|---|
| Идентичность | Есть ли запись в каталоге. Называет ли кто-то себя владельцем. Или процесс молча работает от имени того, кто его когда-то включил. |
| Права | Что ему разрешено и не шире ли это задачи. Чьи роли и scope OAuth он унаследовал в момент создания, и было ли это решение осознанным. |
| Связность | До чего он дотягивается прямо и транзитом: продукты, гранты, хранилища, другие агенты. Это радиус поражения; с экрана настроек агента ответ обычно не получить. |
| Активность | Что он делает по факту и похоже ли это на заявленную роль. Смотреть поведение, а не описание в промпте. |
Анкеты вендора, фильтр промптов и сканер модели оценивают агента в изоляции. Радиус — свойство среды. Тот же угол уже звучал у крупных заказчиков: в 2025 глобальный CISO JPMorgan Chase Патрик Опет в открытом письме отрасли назвал цепочку поставщиков системным риском; позже ту же логику он применил к агентам — идентичность без прав по умолчанию и явное подтверждение, от чьего имени агент действует, до выхода за свою границу. Обязательства EU AI Act, которые в 2026 вводятся поэтапно, исходят из того, что организацию можно спросить об инвентаре систем ИИ, владельцах и надзоре. Если агентов нельзя перечислить, закрыть этот вопрос не получится. Это требование ЕС, не замена 152-ФЗ.
Где это в модели зрелости
Учёт агентов и снятие лишних прав закрывают направление «Управление доступом»: нечеловеческие учётки и то, что они унаследовали. Карта направлений — на странице зрелости. Локальный контур с моделью на своей машине разбирается отдельно: что не открывать наружу у Ollama.
Как проверить
Пройдите каталог ПО, не каталог моделей. Для каждого продукта с ИИ или «агентом» в описании обновления ответьте: проходит ли он SSO, от чьего имени ходит, какие scope и роли получил при включении, в какие соседние системы пишет. То, чего нет в SSO и нет у владельца, занесите в отдельный список: это и есть наследство, а не выбранный проект.
Сверьте список с заявками на доступ и с журналом OAuth-приложений в IdP. Лишние гранты снимите. Если агент нужен — выдайте ему отдельную учётку без прав по умолчанию и только те роли, без которых задача не решается. Патчи платформы, откуда агент мог приехать, смотрите в том же контуре, что и остальные уязвимости: от скана до закрытия. Смежный случай, когда хватило украденной учётки сотрудника на сторонних платформах: инцидент ASOS.
Источники
- The Hacker News. The Third-Party Agent Problem: Why Security Built for AI You Chose Misses the Agents You Didn’t. URL: https://thehackernews.com/2026/10/the-third-party-agent-problem-why.html.
