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