17 из 40 команд, заявляющих, что обеспечивают соблюдение разрешений для ИИ-агентов, по-прежнему делятся учетными данными, лежащими в их основе

В сентябрьском исследовании VentureBeat за 2026 год о безопасности и идентификации ИИ-агентов приняли участие 102 компании. Их спросили, как они защищают доступ ИИ-агентов и отзывают его. Сорок компаний описали программу, которая обеспечивает идентификацию с ограниченной областью действия и проверку разрешений во время выполнения. Однако 17 из этих 40 затем сообщили, что некоторые или большинство их агентов по-прежнему используют общие учетные данные. Только 14 из всех 102 компаний заявили, что могут отозвать доступ за несколько минут.

Ранее в этом месяце компания Zenity Labs, специализирующаяся на безопасности ИИ-агентов, показала, к чему может получить доступ одна скомпрометированная учетная запись, если роль выполнения распространяется на всех агентов в аккаунте. Один запрос к общедоступному агенту с инструментом для получения данных по URL-адресу на платформе Amazon Bedrock AgentCore вернул временные учетные данные AWS. Поскольку роль управления идентификацией и доступом (IAM) по умолчанию распространялась на все ресурсы AgentCore в том же аккаунте и регионе, эти учетные данные позволяли запускать других агентов, читать их сессии и извлекать секреты.

На следующий день Fireworks AI опубликовала бюллетень безопасности, в котором сообщила, что неавторизованная третья сторона воспользовалась скомпрометированными внутренними учетными данными, чтобы получить доступ к переменным среды в заданиях по оценке продуктов клиентов. Fireworks считает, что злоумышленник похитил ключи API и токены, хранившиеся в виде секретов в некоторых затронутых аккаунтах. Через четыре дня после обнаружения инцидента Fireworks завершила одну проверку учетных данных и добавила, что работы по их ротации продолжаются.

Изначально AWS отметила ошибку как «информационную» и заявила, что для ее эксплуатации потребуются действия разработчика. Однако избыточные разрешения сохранялись как минимум до 22 июня 2026 года, согласно последней проверке Zenity; по всей видимости, проблема была полностью устранена к 29 сентября.

Что исследование показало о скорости отзыва доступа

Из 102 участников опроса VentureBeat, ответивших на вопросы об отзыве доступа, 14 назвали ответственного сотрудника, который мог бы отозвать доступ за несколько минут, а 45 указали на команду безопасности или платформенную команду, способную сделать это в течение нескольких часов.

Семнадцать участников предположили, что на это потребуется больше суток или сначала придется отследить учетные данные; 10 не были уверены, что вообще смогут отозвать доступ у всех агентов, а 14 не знали ответа.

Семнадцать участников, указавших на задержки, и 10 тех, кто не был уверен, — всего 27 человек с медленным или неопределенным ответом. Тринадцать из этих 27 относились к группе из 44 участников, использующих общие учетные данные; трое — к группе из 34 участников, у каждого агента которых была собственная идентификация; еще 11 — к группе из 22 участников, не знавших, как проходят аутентификацию их агенты. В последней группе этот показатель был самым высоким среди всех сегментов.

Эндрю Обадиару, директор по информационной безопасности компании Cobalt, рассказал VentureBeat, что агенты нарушают модель сервисных учетных записей именно в этом месте. В случае обычной сервисной учетной записи отзыв учетных данных прекращает отправку новых запросов, «но с агентами и связанными с ними токенами все немного иначе. Даже после отзыва этих токенов они иногда действуют так быстро, что их уже не успеваешь перехватить». Агенты работают быстрее, чем происходит ротация учетных данных.

Общие учетные данные затрудняют независимый отзыв доступа

Общие учетные данные могут подтвердить подлинность запроса, не указывая, какой именно агент его отправил. Отзыв таких данных также может нарушить работу других использующих их процессов. Плановая ротация и менеджеры секретов позволяют управлять жизненным циклом учетных данных, но не решают вопрос об отзыве доступа: можно ли закрыть доступ одному агенту, не нарушив работу остальных.

2 сентября, в тот же день, когда CrowdStrike объявила о запуске нового поставщика идентификации для ИИ-агентов, президент компании Майк Сентонес на конференции Fal.Con наглядно сформулировал проблему определения области действия доступа: «С кем используется общий доступ? К каким сторонним системам он может обращаться?»

Девятнадцать из 102 участников сентябрьского опроса сообщили, что их агенты в основном используют учетные данные людей или сервисных аккаунтов.

Без идентификации контроль — лишь видимость

Семнадцать из 40 участников, описавших свою программу как обеспечивающую контроль, признали, что некоторые или большинство их агентов используют одни и те же ключи. Они отметили наличие идентификации с ограниченной областью действия, а затем сообщили, что некоторые из этих агентов работают с учетными данными, принадлежащими кому-то другому.

Джая Балу, соосновательница AISLE, которая в четверг сообщила о подписании письма о намерениях быть приобретенной компанией Cohere, где Балу станет глобальным директором по информационной безопасности, связала это противоречие с уровнем, лежащим ниже агентов. «В средней компании десятки тысяч сервисных учетных записей. Мы понятия не имеем, чем они занимаются. А теперь к этому добавляется ИИ с ключами API, и вы вообще не знаете, что они делают».

Крис Геттль, вице-президент по управлению продуктами компании Ivanti, рассказал VentureBeat на конференции RSAC, что идентификация и данные — это «два дополнительных направления угроз, которые сейчас развиваются и становятся все более критичными». Злоумышленники заранее скупают учетные данные — еще до начала вторжения. «У меня тоже есть три идентификатора для разных подразделений ACME Corp. Почему бы тебе просто не купить их?»

Общие ключи — самый быстрый путь. Агент начинает работать в первый же день, используя любые учетные данные, которые уже есть у разработчика, и никто не подает заявку на создание новой учетной записи. Среди всех участников опроса VentureBeat у 35 из 102 для каждого агента предусмотрена отдельная идентификация, 45 в той или иной степени используют общие учетные данные, а 22 не смогли ответить.

Срок действия учетных данных истекает по расписанию, а разрешения дают доступ ко всему

NIST и CISA 15 сентября утвердили межведомственный отчет 8587, в котором рекомендуется ограничить срок действия токенов доступа и идентификации одним часом. Отчет касается подписанных токенов и утверждений, а статический ключ API не относится ни к одной из этих категорий. Три недели спустя Fireworks сообщила, что среди предположительно похищенных учетных данных были и те, которые отчет не рассматривал. Учетные данные AgentCore были временными, но все равно давали доступ ко всем агентам, поскольку разрешения роли выполнения распространялись на все ресурсы AgentCore в том же аккаунте и регионе. Срок действия учетных данных истекал по расписанию, однако пока они действовали, предоставляемые ими разрешения охватывали всех агентов в аккаунте.

В мае Геттль рассказал Cyber Magazine, что ИИ «сжимает весь цикл уязвимости», а «в результате сроки атак стремительно сокращаются: промежуток между обнаружением уязвимости и ее эксплуатацией уменьшается с недель до часов». Геттль добавил, что команды безопасности «не могут вручную анализировать тысячи новых уязвимостей со скоростью машин каждый день или даже каждую неделю». Статический ключ API без срока действия находится не на той стороне этого временного окна.

Эгизиаго Чоффи, корпоративный архитектор и генеральный директор SynSphere Italia, заметил, что работающий в Azure OpenAI помощник отвечал всем пользователям, опираясь на разрешения задания индексирования, а не на разрешения конкретного человека. В письменном ответе VentureBeat он рассказал, что перенес проверку прав доступа на этап извлечения данных, чтобы помощник проверял, кто отправляет запрос, при каждом обращении. Исправление заключалось в изменении разрешений, а не в создании механизма отзыва доступа, но, по словам Чоффи, после его внедрения 60% запросов по-прежнему обрабатываются автоматически.

Okta, Microsoft и CrowdStrike уже представили продукты для идентификации ИИ-агентов. Среди 99 участников сентябрьского опроса VentureBeat, указавших используемые инструменты, только один назвал Entra Agent ID от Microsoft. Компании, использующие общие ключи, не упомянули ни один из этих продуктов.

Проверка, которую можно провести на этой неделе

Выберите одного агента, которого можно безопасно отключить, и засеките, сколько времени потребуется, чтобы отозвать его доступ, не затронув других агентов. Если для начала нужно выяснить, какой ключ он использует, значит, учет ваших ресурсов сам по себе стал частью проблемы с локализацией инцидента. Именно в такой ситуации оказались 22 участника, не знавшие, как их агенты проходят аутентификацию; 11 из них дали медленный или неопределенный ответ.

Сорок из 102 участников сообщили о подтвержденном инциденте безопасности с агентами или потенциальном инциденте за последний год, а 12 вообще не отслеживают инциденты с агентами. Двадцать участников не смогли сказать, сколько идентификаторов агентов используется в их организации.

На конференции RSAC Геттль описал эту проблему недостаточной видимости в терминах управления активами. «Если я смотрю только на то, что мне известно, я теряю перспективу, потому что не знаю, каким угрозам подвергает мою среду то, о чем я знаю, но чего не понимаю, и то, о чем я даже не подозреваю». Семьдесят два участника планируют в ближайшие 12 месяцев внедрить новое или заменяющее решение для защиты ИИ-агентов. Одного внедрения недостаточно, если учетные данные, которыми управляют эти инструменты, по-прежнему используются совместно.

Вопросы Обадиару об учете сервисных аккаунтов стоит задавать и применительно к агентам. «Кому он принадлежит? Для чего его создали? Какой уровень доступа у него есть? Когда им пользовались в последний раз? Если вы не знаете, что у вас есть, вы не сможете это защитить».