Если вы CISO, то, скорее всего, слышите от своего совета директоров нечто подобное: «Какова наша стратегия безопасности ИИ?»
И вы, вероятно, даете примерно такой ответ: «Мы работаем над этим. Политика в отношении ИИ еще разрабатывается. Как только мы поймем, что именно внедряем, мы это защитим».
Шесть месяцев назад этот ответ казался надежным. Теперь — нет.
ИИ-агенты, которые вы только планируете развернуть, не представляют собой текущую угрозу. Угрозу представляют те, которые уже запущены в вашей среде.
Исполнительное резюме
- Пробел в управлении ИИ: Отчет Okta AI at Work за 2025 год показал, что, хотя 91% организаций внедряют ИИ-агентов, только 10% имеют стратегию управления, что делает агентов с избыточными привилегиями источником немедленного риска.
- Слепая зона видимости: Традиционные сетевые инструменты и средства защиты конечных точек не могут отслеживать конкретные действия, владельцев и разрешения скомпрометированных ИИ-агентов.
- Идентификация как плоскость управления: Идентификация — это единственный уровень безопасности, способный ответить на вопросы о том, какой агент сделал что, от чьего имени и было ли это разрешено.
- Единый подход: Решение Okta для ИИ-агентов позволяет обнаруживать, подключать, защищать и контролировать ваших ИИ-агентов.
Переход бизнеса к агентному ИИ — это уже не отдаленное будущее, а производственная реальность. Отчет Okta AI at Work за 2025 год показал, что сегодня 91% организаций уже используют ИИ-агентов для автоматизации сложных рабочих процессов и повышения производительности. Тем не менее, тот же отчет указывает на опасный пробел в управлении: на фоне стремительного развертывания только 10% руководителей сообщают о наличии хорошо разработанной стратегии или дорожной карты для управления нечеловеческими идентификационными данными, включая ИИ-агентов.
Риск теневого ИИ: Управление невидимым персоналом
Стремление отложить оценку идентификационных данных игнорирует фундаментальную истину: риск заключается не только в ИИ, который вы развернете завтра, но и в агентах с избыточными привилегиями, которые уже работают сегодня.
Забудьте на минуту о полной разработке вашей политики в отношении ИИ. Попробуйте ответить на эти вопросы о вашей текущей среде:
- Где находятся мои ИИ-агенты?
- К чему они могут подключаться?
- Что они могут делать?
Большинство руководителей службы безопасности не могут уверенно ответить ни на один из этих вопросов, и это не сбой в вашей программе безопасности. Это структурный пробел. Агенты уже здесь, и ваши существующие средства контроля доступов пока не распространяются на них.
Пока ведутся дебаты о формальных внедрениях, сотрудники часто подключают сторонние ИИ-инструменты к корпоративным аккаунтам с помощью разрешений OAuth (такие как Cursor к GitHub, Claude к Google Workspace и ИИ-помощники для записи встреч к календарям) с такой скоростью, за которой управление просто не успевает.
Каждое такое разрешение создает нечеловеческую учетную запись с делегированными правами на корпоративные данные, зачастую без проверенного владельца или четкого «радиуса поражения».
Реальность теневого ИИ
Недавний инцидент на известной платформе для разработчиков не был связан с уязвимостью или сбоем инфраструктуры — речь шла об OAuth-подключении между корпоративной учетной записью сотрудника и сторонним ИИ-инструментом, созданном полностью вне поля зрения ИТ-отдела. Когда этот ИИ-инструмент был скомпрометирован, предварительно предоставленное доверие превратилось в путь атаки: прямой доступ к внутренним системам, ключам API, токенам и переменным окружения. Именно так теневой ИИ выглядит на практике — это несанкционированное разрешение OAuth, которое никто не одобрял и которое существовало без ИТ-надзора.
Неприятная правда: если вы будете ждать завершения разработки политики в отношении ИИ, прежде чем обеспечивать безопасность своих ИИ-агентов, вы будете применять управление поверх уже накопившихся рисков.
Найдите бреши в безопасности ИИ с помощью нашего 5-минутного симулятора атак.
Почему идентификация является важнейшим слоем для управления ИИ
Традиционные модели безопасности часто отдают приоритет защите сети или конечных точек. Хотя это жизненно важные уровни, они принципиально не видят, какие автономные агенты к чему получают доступ и зачем.
- Сетевые инструменты видят трафик; ИИ-агент, действующий от имени пользователя, выглядит как легитимный трафик API.
- Инструменты защиты конечных точек видят процессы; ИИ-агент выглядит как стандартный авторизованный процесс, запущенный в рамках сеанса легитимного пользователя.
Оба уровня необходимы, но ни один из них не может ответить на вопросы, которые имеют значение при возникновении инцидента: «Какой агент это сделал, от чьего имени, с каким охватом и было ли это разрешено?»
В эпоху агентов идентификация — это единственный уровень безопасности, который понимает намерения и область действия. Именно поэтому 85% руководителей в настоящее время считают управление доступом и идентификацией (IAM) наиболее критическим компонентом своей ИИ-стратегии (Okta, AI at Work Report 2025).
Упомянутый ранее инцидент на платформе разработчиков помогает проиллюстрировать этот момент: это был сбой не на уровне конечных точек или сети. Судя по нашему пониманию, это был сбой идентификации, а именно: то, как сторонним приложениям и ИИ-инструментам предоставляется доступ, что они могут делать и в течение какого времени.
Именно поэтому мы создали Okta для ИИ-агентов — специализированное решение, которое расширяет возможности платформы Okta для обнаружения, подключения, защиты и управления вашими ИИ-агентами в вашей среде. Okta для ИИ-агентов обнаруживает и подключает ИИ-агенты на любой платформе, защищает соединения с помощью доступа с минимальными необходимыми привилегиями и управляет ими с помощью проверок доступа, полных журналов аудита, а также возможности мгновенно вручную деактивировать ИИ-агент с помощью аварийного выключателя для предотвращения запросов новых токенов и будущих авторизаций, когда агент ведет себя непредвиденным образом.
Четыре основные возможности для полной видимости и контроля агентов
Когда идентификация становится плоскостью управления для агентов, в единой системе становятся возможными четыре вещи:
- Полноценная идентификация агентов: ваши агенты — созданные ли собственными силами, встроенные в инструмент SaaS или работающие на ноутбуке сотрудника — регистрируются как принципалы рабочих нагрузок с учетными данными, назначенным человеком-владельцем и управляемым жизненным циклом. Это то, что вы можете сказать своему ИТ-директору, когда он спросит: «Кто владеет этим агентом и кто несет ответственность, если что-то пойдет не так?»
- Криптографическая атрибуция: каждое действие содержит криптографически подписанные идентификационные данные как человека, так и агента. Это то, что вы можете показать своему аудитору, когда он спросит: «Какой агент это сделал и от чьего имени?»
- Принудительное применение наименьших привилегий: токены ограничиваются одним вызовом, а не сеансом или приложением. Постоянные привилегии исчезают. Это то, что вы можете сказать своему совету директоров, когда они спросят: «Каков наш риск, если один из этих агентов будет скомпрометирован?»
- Интегрированное управление: запросы на доступ агентов и подтверждения доступа встроены в платформу идентификации, а не добавлены поверх нее. Это то, что вы можете показать своему аудитору, когда он спросит: «Докажите, что доступ вашего ИИ-агента проверялся человеком за последние 90 дней».
Но возможности имеют значение только в том случае, если они применяются везде, где работают ваши агенты, а это значит, что стратегия агентов должна быть привязана к экосистеме. Ваши агенты могут работать в Salesforce Agentforce, Amazon Bedrock, ServiceNow AI и на любой другой платформе, которую ваши команды выберут следующей. Каждый раз, когда агент пересекает границу экосистемы, управление с платформы, на которой он был создан, остается позади. То, что остается — это пробел.
Именно этот пробел призвана закрыть компания Okta. Решение Okta для ИИ-агентов создано нейтральным к поставщикам: оно абстрагирует брокеры идентификации в Azure, AWS и Google Cloud, так что одни и те же политики применяются одинаково везде — без необходимости создания разовых интеграций.
Разработано для расширения вашей службы идентификации (IdP), а не для ее замены
Главная забота ИТ-архитекторов — «разрастание учетных записей», то есть опасение создания второго хранилища идентификационных данных для ИИ. Современное управление ИИ не должно требовать полной замены существующей системы управления учетными записями сотрудников.
Ваш поставщик идентификационных данных (IdP) является системным журналом учета для вашего персонала. Именно здесь находятся ваши политики входа в систему, принудительно применяется многофакторная аутентификация, настраивается условный доступ и где годы работы по интеграции обеспечивают бесперебойную работу управления цифровыми удостоверениями людей. Ничего из этого не должно меняться из-за того, что вы добавляете в картину агентов.
Решение Okta для ИИ-агентов создано как дополнение. Оно выполняет федерацию с вашим существующим IdP через стандартные протоколы (OIDC, SAML), наследуя доверие от вашего IdP без дублирования учетных данных или требования второго входа. Когда человек вызывает агента, Okta проверяет утверждение об идентификации от вашего IdP и выдает криптографически подписанный токен, содержащий информацию как о человеке, так и об агенте. Люди остаются там, где они есть. Агенты получают созданное специально для них управление.
Результат: вы расширяете уже созданную инфраструктуру идентификации для поддержки нового класса субъектов без изменения платформы, дублирования каталогов или создания дополнительной операционной нагрузки.
Узнайте больше о подходе Okta к предоставлению вендронезависимого уровня, который защищает каждое соединение без необходимости замены вашего текущего IdP.
Начните отсюда: три вопроса, на которые нужно ответить сегодня
Ваша политика в отношении ИИ может подождать, но агенты в вашей среде — нет.
Начните с трех вопросов:
- Где находятся мои ИИ-агенты?
Где находятся мои ИИ-агенты?
- К чему они могут подключаться?
К чему они могут подключаться?
- Что они могут делать?
Что они могут делать?
Идентификация — это единственный уровень, способный ответить на все три вопроса, и основа, на которой будет строиться ваша будущая политика.
Оцените управление ИИ на практике. Попробуйте интерактивную демонстрацию Okta для ИИ-агентов.
Часто задаваемые вопросы
Как сотрудники внедряют теневой ИИ в корпоративную сеть?
Сотрудники обычно внедряют теневой ИИ, предоставляя сторонним ИИ-инструментам прямой доступ по API к корпоративным средам с использованием разрешений OAuth. Эти интеграции, такие как подключение ИИ-ассистента к корпоративному календарю или репозиторию кода, происходят беспрепятственно на уровне пользователя, обходя традиционный ИТ-контроль и создавая неконтролируемые нечеловеческие учетные записи.
Почему средства защиты сети и конечных точек не видят действий ИИ-агентов?
Традиционные сетевые инструменты рассматривают активность автономных ИИ-агентов как легитимный трафик API, в то время как инструменты защиты конечных точек интерпретируют ее как стандартные процессы, выполняемые в рамках сеанса авторизованного пользователя. Поскольку в этих периметрах отсутствует контекст идентификации на уровне приложений, они не могут определить, какой именно агент инициировал действие, от чьего имени оно выполнялось или каков его радиус поражения.
Можно ли защитить ИИ-агентов до завершения разработки официальной корпоративной политики в отношении ИИ?
Да. Ожидание официальной корпоративной политики управления оставляет существующие уязвимости безопасности без внимания. Команды безопасности могут снизить риски, расширив свою существующую архитектуру IdP для обнаружения, авторизации и управления автономными рабочими нагрузками с помощью протоколов нечеловеческих учетных записей, не дожидаясь структурного утверждения политики.
Требует ли внедрение безопасности ИИ-агентов создания совершенно отдельного каталога учетных записей?
Нет. Эффективное управление ИИ должно избегать «разрастания учетных записей» посредством дополнительной интеграции с вашим основным IdP. Используя открытые стандарты федерации, такие как OpenID Connect (OIDC) и SAML, такие платформы, как Okta, могут выдавать ограниченные по области действия токены, которые связывают идентификаторы машинных агентов с существующими правилами аутентификации пользователей без дублирования учетных данных.
Любые упоминания будущих продуктов, функций, возможностей или сертификаций в этом блоге носят исключительно информационный характер. Эти пункты не являются обязательствами по поставке и не должны служить основанием для принятия решений о покупке.
Эти материалы предназначены исключительно для общей информации и не являются юридическими, конфиденциальными, экспертными рекомендациями по безопасности, соблюдению нормативных требований или ведению бизнеса.
Содержимое может не отражать самые актуальные события в области безопасности, права и/или конфиденциальности. Вы несете единоличную ответственность за получение консультаций у собственного юриста и/или профессионального советника и не должны полагаться на эти материалы.
Okta не делает никаких заявлений или гарантий в отношении данного контента и не несет ответственности за любые убытки или ущерб, возникшие в результате реализации вами этих рекомендаций. Информацию о договорных обязательствах Okta перед своими клиентами можно найти на странице okta.com/agreements.
