В программных продуктах, которыми пользуются компании, уже работают агенты, появившиеся без отдельной закупки ИИ. В средах, изученных для доклада «Состояние безопасности агентов — 2026» (2026 State of Agent Security Report), ИИ встроен примерно в 1 280 сторонних продуктов. Около 282 из них находятся за корпоративным единым входом, SSO. Остальные примерно 1 000 по умолчанию не видны системе управления учётными записями: она может контролировать лишь то, что проходит через её вход.
Привычная защита ИИ начинается с решения компании: выбрать систему, купить лицензии, развернуть модель за шлюзом, назначить ответственного. Тогда есть что сканировать и через что проверять запросы. Правила использования тоже адресованы людям, знающим о внедрении. Агент внутри уже установленного приложения может появиться после обновления или действия пользователя. Отдельного решения о внедрении не было, владельца не назначили, шлюза для проверки запросов нет.
У агентов три пути в компанию. Унаследованные приходят с обновлениями продуктов действующих поставщиков. Настроенные используют написанные компанией инструкции и логику, но работают на чужой платформе, модели и подключениях. Собственные создаются на открытых фреймворках и инфраструктуре компании. Последняя группа, описанная как самая маленькая и медленнее всего растущая, удобнее всего для привычной проверки: у неё есть репозиторий и процесс сборки. Основная масса внедрений приходится на унаследованных и настроенных агентов; по мере превращения крупных приложений в платформы для агентов их число растёт экспоненциально.
Показательный случай — Slack Code компании Salesforce, запущенный в августе 2026 года. Пользователь может упомянуть агента в переписке Slack; тот прочитает доступный контекст разговора, напишет код и откроет запрос на включение изменений, pull request. В анонсе Salesforce обещает, что агенты «с первого дня наследуют встроенную модель безопасности Slack, разрешения и административные настройки без дополнительной работы для ИТ-службы». Для команды безопасности это означает иной набор вопросов: есть ли у такого участника доступ к GitHub, может ли он дотянуться до рабочей инфраструктуры и достаточно ли прав, вытекающих из членства в канале Slack, для действий с кодом.
Место рождения агента мало говорит о пределах его работы. Агент внутри CRM может читать хранилище данных и записывать результаты в систему заявок. Агент, собранный на облачной платформе, может хранить токены для Salesforce, Slack и Drive. Все они действуют на уровне корпоративных приложений, у которого нет чёткой внешней границы. Смотреть приходится на цепочку: подключённые продукты, выданные доступы, хранилища и других агентов, через которых открываются дальнейшие пути.
Модель отвечает за рассуждение, а окружающая её программная обвязка определяет, куда агент подключён, что может вызвать и когда действует. Поэтому проверка начинается с личности агента: зарегистрирован ли он, кто по имени ответит «чей это агент», не работает ли он молча под учётной записью создателя. Следом идут полномочия: какие роли и разрешения OAuth он унаследовал, нужны ли они для задачи и выбирал ли их кто-нибудь осознанно. Даже скромное поручение становится опаснее, если агент получил права владельца учётной записи.
Связи определяют радиус возможного ущерба. Прямой доступ виден в настройках агента; косвенный может открываться через токен, приложение-посредник или другого агента. Поэтому экран конфигурации редко даёт полный ответ на вопрос «куда он доберётся?». Анкета поставщика, фильтр запросов и сканер модели оценивают агента по отдельности. Достижимые системы и данные приходится проверять в его окружении, включая транзитные пути.
Есть и четвёртая проверка — действия во время работы. Описание в инструкции говорит, для чего агента задумывали; журнал обращений и изменений показывает, чем он занят. Если помощник по заявкам начинает читать несвязанные файлы или выполнять действия за пределами своей задачи, полезнее увидеть это в текущей работе, чем ждать очередной плановой проверки. Без наблюдения за действиями даже точно составленный список разрешений быстро устаревает.
В 2025 году Патрик Опет, глобальный директор по информационной безопасности JPMorgan Chase, в открытом письме отрасли назвал цепочку сторонних поставщиков системным риском. Он упомянул инциденты, из-за которых банку приходилось изолировать скомпрометированных поставщиков. К агентам Опет предлагает применять столь же строгий порядок: сначала отдельная идентичность и нулевые права по умолчанию, затем подтверждение ИТ-службой того, от чьего имени агент действует, и лишь после этого доступ за пределы первоначальной границы. Требования крупного покупателя вроде JPMorgan Chase могут вскоре попасть в анкеты, которые заполняют поставщики ПО.
У EU AI Act обязательства вводятся поэтапно в течение 2026 года. Для применимых требований организации нужно знать, какие ИИ-системы она использует, кто за них отвечает и чем подтверждается надзор. Перечень агентов, появившихся с обновлениями приложений, здесь становится практической проблемой: невозможно предъявить сведения о владельце и контроле системы, о существовании которой никто не знает.
Таблица и ежеквартальная проверка ещё могут работать для 50 агентов. При 500 такой порядок начинает ломаться; одно обновление продукта способно увеличить счёт до 5 000. Нужна постоянно обновляемая карта: какие агенты работают, что унаследовали, куда проходят напрямую и по цепочке, что сделали и что изменилось со вчерашнего дня. Reco предлагает для этого Reco Graph, связывающий людей, нечеловеческие учётные записи, приложения, разрешения и действия агентов в едином текущем представлении. Описание обнаружения агентов размещено на .
Теме посвящена шестиглавная серия Into the Expanse («На просторах»): среди обозначенных вопросов — происхождение агентов, правила управления ими, их использование атакующими, место защиты во время работы и первоочередные расходы. В сопровождающем публикацию веб-коде также указаны идентификатор LinkedIn 4587841 (
Привычная защита ИИ начинается с решения компании: выбрать систему, купить лицензии, развернуть модель за шлюзом, назначить ответственного. Тогда есть что сканировать и через что проверять запросы. Правила использования тоже адресованы людям, знающим о внедрении. Агент внутри уже установленного приложения может появиться после обновления или действия пользователя. Отдельного решения о внедрении не было, владельца не назначили, шлюза для проверки запросов нет.
У агентов три пути в компанию. Унаследованные приходят с обновлениями продуктов действующих поставщиков. Настроенные используют написанные компанией инструкции и логику, но работают на чужой платформе, модели и подключениях. Собственные создаются на открытых фреймворках и инфраструктуре компании. Последняя группа, описанная как самая маленькая и медленнее всего растущая, удобнее всего для привычной проверки: у неё есть репозиторий и процесс сборки. Основная масса внедрений приходится на унаследованных и настроенных агентов; по мере превращения крупных приложений в платформы для агентов их число растёт экспоненциально.
Показательный случай — Slack Code компании Salesforce, запущенный в августе 2026 года. Пользователь может упомянуть агента в переписке Slack; тот прочитает доступный контекст разговора, напишет код и откроет запрос на включение изменений, pull request. В анонсе Salesforce обещает, что агенты «с первого дня наследуют встроенную модель безопасности Slack, разрешения и административные настройки без дополнительной работы для ИТ-службы». Для команды безопасности это означает иной набор вопросов: есть ли у такого участника доступ к GitHub, может ли он дотянуться до рабочей инфраструктуры и достаточно ли прав, вытекающих из членства в канале Slack, для действий с кодом.
Место рождения агента мало говорит о пределах его работы. Агент внутри CRM может читать хранилище данных и записывать результаты в систему заявок. Агент, собранный на облачной платформе, может хранить токены для Salesforce, Slack и Drive. Все они действуют на уровне корпоративных приложений, у которого нет чёткой внешней границы. Смотреть приходится на цепочку: подключённые продукты, выданные доступы, хранилища и других агентов, через которых открываются дальнейшие пути.
Модель отвечает за рассуждение, а окружающая её программная обвязка определяет, куда агент подключён, что может вызвать и когда действует. Поэтому проверка начинается с личности агента: зарегистрирован ли он, кто по имени ответит «чей это агент», не работает ли он молча под учётной записью создателя. Следом идут полномочия: какие роли и разрешения OAuth он унаследовал, нужны ли они для задачи и выбирал ли их кто-нибудь осознанно. Даже скромное поручение становится опаснее, если агент получил права владельца учётной записи.
Связи определяют радиус возможного ущерба. Прямой доступ виден в настройках агента; косвенный может открываться через токен, приложение-посредник или другого агента. Поэтому экран конфигурации редко даёт полный ответ на вопрос «куда он доберётся?». Анкета поставщика, фильтр запросов и сканер модели оценивают агента по отдельности. Достижимые системы и данные приходится проверять в его окружении, включая транзитные пути.
Есть и четвёртая проверка — действия во время работы. Описание в инструкции говорит, для чего агента задумывали; журнал обращений и изменений показывает, чем он занят. Если помощник по заявкам начинает читать несвязанные файлы или выполнять действия за пределами своей задачи, полезнее увидеть это в текущей работе, чем ждать очередной плановой проверки. Без наблюдения за действиями даже точно составленный список разрешений быстро устаревает.
В 2025 году Патрик Опет, глобальный директор по информационной безопасности JPMorgan Chase, в открытом письме отрасли назвал цепочку сторонних поставщиков системным риском. Он упомянул инциденты, из-за которых банку приходилось изолировать скомпрометированных поставщиков. К агентам Опет предлагает применять столь же строгий порядок: сначала отдельная идентичность и нулевые права по умолчанию, затем подтверждение ИТ-службой того, от чьего имени агент действует, и лишь после этого доступ за пределы первоначальной границы. Требования крупного покупателя вроде JPMorgan Chase могут вскоре попасть в анкеты, которые заполняют поставщики ПО.
У EU AI Act обязательства вводятся поэтапно в течение 2026 года. Для применимых требований организации нужно знать, какие ИИ-системы она использует, кто за них отвечает и чем подтверждается надзор. Перечень агентов, появившихся с обновлениями приложений, здесь становится практической проблемой: невозможно предъявить сведения о владельце и контроле системы, о существовании которой никто не знает.
Таблица и ежеквартальная проверка ещё могут работать для 50 агентов. При 500 такой порядок начинает ломаться; одно обновление продукта способно увеличить счёт до 5 000. Нужна постоянно обновляемая карта: какие агенты работают, что унаследовали, куда проходят напрямую и по цепочке, что сделали и что изменилось со вчерашнего дня. Reco предлагает для этого Reco Graph, связывающий людей, нечеловеческие учётные записи, приложения, разрешения и действия агентов в едином текущем представлении. Описание обнаружения агентов размещено на .
Теме посвящена шестиглавная серия Into the Expanse («На просторах»): среди обозначенных вопросов — происхождение агентов, правила управления ими, их использование атакующими, место защиты во время работы и первоочередные расходы. В сопровождающем публикацию веб-коде также указаны идентификатор LinkedIn 4587841 (
_linkedin_partner_id), объекты window._linkedin_data_partner_ids и window.lintrk, загрузка , а также window.dataLayer и функция gtag(). Запись функции обрывается на function gtag(){dataLayer.`; это код аналитики посещений, а не средство наблюдения за агентами.
