ИИ-агенты выходят в рабочую среду быстрее, чем службы безопасности успевают поставить их на учёт. Они подключаются к приложениям, обрабатывают корпоративные данные, вызывают API и выполняют действия сразу в нескольких бизнес-системах. При этом к агентам часто не применяют те же правила идентификации и контроля доступа, которые давно действуют для сотрудников. В результате компания видит новый инструмент, но не всегда знает, кто разрешил ему работать и насколько далеко простираются его полномочия.
В отчёте Okta Global CISO Insights 2026 приведена довольно неприятная статистика. Лишь 47% директоров по информационной безопасности уверены, что способны обнаружить каждого ИИ-агента в своей инфраструктуре. Даже среди руководителей, уверенных в полноте такого учёта, около 80% опасаются, что избыточные права агентов остаются без проверки. Иными словами, видимость ещё не означает контроль: найти агента мало, нужно установить, какие действия ему разрешены, кто их одобрил и сохраняется ли деловая необходимость в этом доступе.
Только каждая четвёртая из опрошенных организаций внедрила специализированную модель защиты ИИ-агентов. Ещё 21% компаний продолжают использовать общие учётные данные и сервисные аккаунты с широкими полномочиями. Подобная схема пришла из эпохи традиционных служебных записей, но плохо подходит для автономных программ, способных обращаться к разным источникам данных и самостоятельно запускать операции. Если несколько агентов работают под одной записью, журнал событий не даёт точного ответа, кто именно выполнил конкретное действие.
Управление быстро упирается в несколько практических вопросов. Какой агент получил доступ? Кто его согласовал? До каких приложений, API, данных и систем он может добраться? Нужны ли ему прежние разрешения спустя месяц после запуска? Можно ли отключить одного агента, не остановив связанные сервисы? Общая сервисная учётная запись обычно мешает ответить хотя бы на половину этих вопросов, а отзыв её прав способен случайно нарушить работу сразу нескольких процессов.
Рабочая модель предполагает, что каждый ИИ-агент получает статус самостоятельной цифровой личности. За ним закрепляют конкретного владельца, оформляют запись об авторизации и выдают ограниченный набор разрешений. Жизненный цикл агента должен охватывать регистрацию, изменение функций, периодические проверки доступа и вывод из эксплуатации. Когда задача закончилась или риск изменился, права отзывают отдельно и быстро, без поисков того, какие ещё программы скрываются за теми же реквизитами.
Проверка доступа должна учитывать не название агента, а его фактическую работу. Если он собирает сведения из CRM, ему незачем менять финансовые записи; если вызывает один API, доступ ко всему набору интеграций оставлять опасно. Владелец обязан подтвердить назначение агента, перечень доступных ресурсов и срок действия разрешений. Службе безопасности нужны журналы одобрений и понятный маршрут экстренного отключения. Иначе формально зарегистрированный агент продолжит обладать полномочиями, которые давно потеряли смысл.
Отдельная проблема — теневой ИИ, то есть инструменты и агенты, появившиеся вне обычной процедуры корпоративного согласования. Полный запрет редко решает вопрос: сотрудники находят обходные пути, законные проекты замедляются, а сведения о владельцах и доступе всё равно не появляются. Практичнее обнаруживать такие инструменты, выяснять, с какими системами они связаны, назначать ответственного и переводить их под единые правила управления идентификацией. Необоснованный доступ после проверки удаляют, а допустимый оформляют и регулярно пересматривают.
Исследование Okta показывает, что организации со зрелым управлением цифровыми идентичностями сталкиваются с меньшим объёмом теневого ИИ. Они быстрее реагируют на самовольно действующих агентов и реже выражают опасения по поводу инцидентов, усиленных искусственным интеллектом. Причина вполне приземлённая: у службы безопасности уже есть процедуры учёта владельцев, выдачи минимальных прав, проверки разрешений и их отзыва. ИИ-агент в такой системе не превращается в загадочный сервисный аккаунт, который никто не решается отключить.
Практическую сессию по этой теме проводит Мэтт Иммлер, региональный директор по безопасности Okta. На вебинаре разбираются обнаружение уже работающих ИИ-агентов, назначение владельцев, анализ доступных им приложений, данных, API и бизнес-систем, сокращение избыточных полномочий и перенос действующих агентов под правила управления идентификацией. В программу также входят контроль теневого ИИ, реагирование на самовольных агентов и быстрый отзыв доступа при изменении рисков или потребностей бизнеса.
Основанием для обсуждения служит отчёт Okta Global CISO Insights 2026. Конкретная дата вебинара и крайний срок регистрации не указаны. Для подготовки к такой проверке компании достаточно начать с реестра агентов: указать владельца каждого из них, источник одобрения, используемые учётные данные, доступные ресурсы, дату последнего пересмотра прав и способ экстренного отключения. Именно в этих полях обычно обнаруживается разрыв между «мы знаем, что агент существует» и «мы действительно управляем тем, что он способен сделать».
Изображение носит иллюстративный характер
В отчёте Okta Global CISO Insights 2026 приведена довольно неприятная статистика. Лишь 47% директоров по информационной безопасности уверены, что способны обнаружить каждого ИИ-агента в своей инфраструктуре. Даже среди руководителей, уверенных в полноте такого учёта, около 80% опасаются, что избыточные права агентов остаются без проверки. Иными словами, видимость ещё не означает контроль: найти агента мало, нужно установить, какие действия ему разрешены, кто их одобрил и сохраняется ли деловая необходимость в этом доступе.
Только каждая четвёртая из опрошенных организаций внедрила специализированную модель защиты ИИ-агентов. Ещё 21% компаний продолжают использовать общие учётные данные и сервисные аккаунты с широкими полномочиями. Подобная схема пришла из эпохи традиционных служебных записей, но плохо подходит для автономных программ, способных обращаться к разным источникам данных и самостоятельно запускать операции. Если несколько агентов работают под одной записью, журнал событий не даёт точного ответа, кто именно выполнил конкретное действие.
Управление быстро упирается в несколько практических вопросов. Какой агент получил доступ? Кто его согласовал? До каких приложений, API, данных и систем он может добраться? Нужны ли ему прежние разрешения спустя месяц после запуска? Можно ли отключить одного агента, не остановив связанные сервисы? Общая сервисная учётная запись обычно мешает ответить хотя бы на половину этих вопросов, а отзыв её прав способен случайно нарушить работу сразу нескольких процессов.
Рабочая модель предполагает, что каждый ИИ-агент получает статус самостоятельной цифровой личности. За ним закрепляют конкретного владельца, оформляют запись об авторизации и выдают ограниченный набор разрешений. Жизненный цикл агента должен охватывать регистрацию, изменение функций, периодические проверки доступа и вывод из эксплуатации. Когда задача закончилась или риск изменился, права отзывают отдельно и быстро, без поисков того, какие ещё программы скрываются за теми же реквизитами.
Проверка доступа должна учитывать не название агента, а его фактическую работу. Если он собирает сведения из CRM, ему незачем менять финансовые записи; если вызывает один API, доступ ко всему набору интеграций оставлять опасно. Владелец обязан подтвердить назначение агента, перечень доступных ресурсов и срок действия разрешений. Службе безопасности нужны журналы одобрений и понятный маршрут экстренного отключения. Иначе формально зарегистрированный агент продолжит обладать полномочиями, которые давно потеряли смысл.
Отдельная проблема — теневой ИИ, то есть инструменты и агенты, появившиеся вне обычной процедуры корпоративного согласования. Полный запрет редко решает вопрос: сотрудники находят обходные пути, законные проекты замедляются, а сведения о владельцах и доступе всё равно не появляются. Практичнее обнаруживать такие инструменты, выяснять, с какими системами они связаны, назначать ответственного и переводить их под единые правила управления идентификацией. Необоснованный доступ после проверки удаляют, а допустимый оформляют и регулярно пересматривают.
Исследование Okta показывает, что организации со зрелым управлением цифровыми идентичностями сталкиваются с меньшим объёмом теневого ИИ. Они быстрее реагируют на самовольно действующих агентов и реже выражают опасения по поводу инцидентов, усиленных искусственным интеллектом. Причина вполне приземлённая: у службы безопасности уже есть процедуры учёта владельцев, выдачи минимальных прав, проверки разрешений и их отзыва. ИИ-агент в такой системе не превращается в загадочный сервисный аккаунт, который никто не решается отключить.
Практическую сессию по этой теме проводит Мэтт Иммлер, региональный директор по безопасности Okta. На вебинаре разбираются обнаружение уже работающих ИИ-агентов, назначение владельцев, анализ доступных им приложений, данных, API и бизнес-систем, сокращение избыточных полномочий и перенос действующих агентов под правила управления идентификацией. В программу также входят контроль теневого ИИ, реагирование на самовольных агентов и быстрый отзыв доступа при изменении рисков или потребностей бизнеса.
Основанием для обсуждения служит отчёт Okta Global CISO Insights 2026. Конкретная дата вебинара и крайний срок регистрации не указаны. Для подготовки к такой проверке компании достаточно начать с реестра агентов: указать владельца каждого из них, источник одобрения, используемые учётные данные, доступные ресурсы, дату последнего пересмотра прав и способ экстренного отключения. Именно в этих полях обычно обнаруживается разрыв между «мы знаем, что агент существует» и «мы действительно управляем тем, что он способен сделать».
