Agent Security Gap: почему 54% компаний уже столкнулись с инцидентом в сфере ИИ-агентов

Автономные ИИ-агенты в действии — а архитектура безопасности ещё дремлет

ИИ-агенты давно перестали быть сценарием будущего. Во всё большем числе компаний они самостоятельно выполняют бизнес-процессы, получают доступ к внутренним системам, обрабатывают конфиденциальные данные и принимают операционные решения — без какого-либо вмешательства человека на каждом отдельном шаге. То, что в инновационных подразделениях воспринимается как повышение эффективности, при ближайшем рассмотрении обнаруживает структурный пробел в безопасности, чья серьёзность недооценивается: так называемый Agent Security Gap.

Актуальный опрос 107 компаний, проведённый VentureBeat Pulse Research, рисует трезвую картину. Более половины опрошенных организаций — конкретно 54 процента — уже столкнулись с подтверждённым инцидентом безопасности с участием ИИ-агентов или были на грани такого инцидента. 18 процентов сообщают о реально произошедшем инциденте, 36 процентов — о почти-инциденте, который был вовремя предотвращён. Лишь 42 процента пока не фиксируют подобных событий. Архитектура ИИ-агентов в компаниях растёт быстрее, чем окружающая её сеть безопасности.

Проблема идентификации: общие учётные данные как точка входа

Структурная суть проблемы лежит в области Agent Identity. Лишь около трети опрошенных компаний (32 процента) присваивают каждому ИИ-агенту собственную, строго определённую идентичность с масштабированными правами доступа — так называемую модель Scoped Identity. Почти половина (48 процентов) указывает, что у некоторых агентов есть собственные идентичности, однако многие по-прежнему используют общие учётные данные. Ещё 32 процента преимущественно опираются на совместно используемые API-ключи или заимствованные данные сервисных аккаунтов реальных пользователей.

Последствия весьма серьёзны: когда агенты совместно используют учётные данные, один скомпрометированный или чрезмерно привилегированный агент распространяет свой охват на всю связанную систему. Blast Radius — то есть масштаб ущерба при потере контроля — растёт пропорционально числу агентов с плохо очерченными границами. Вдобавок: в случае инцидента невозможно криминалистически точно установить, какой агент выполнил то или иное действие. Атрибуция — необходимое условие любого Incident Response — становится практически невозможной.

Данные эмпирически подтверждают эту взаимосвязь: в компаниях, где в парке агентов хоть где-то используются общие учётные данные, частота инцидентов или почти-инцидентов составила 63,5 процента. Там, где каждый агент имеет собственную Scoped Identity, этот показатель снизился до 40,9 процента — разница в 23 процентных пункта, которую невозможно опровергнуть.

«Проблема Non-Human Identity — это самая масштабная нерешённая структурная проблема в корпоративном применении агентов сегодня. Пока агенты делят идентичности, они делят и риски — причём экспоненциально.»

Мониторинг — да, изоляция — нет: разрыв в области Containment

На уровне технических средств контроля прослеживается ещё одна закономерность: мониторинг и применение политик распространены, а изоляция — нет. Около 47 процентов компаний отслеживают активность своих агентов с помощью логирования, ещё 49 процентов используют Runtime Enforcement с масштабированными правами доступа. Однако лишь 30 процентов изолируют своих наиболее рискованных агентов в Sandboxes — единственную меру, которая в критической ситуации действительно ограничивает Blast Radius.

Особенно показательна корреляция с размером компании: с ростом организации частота инцидентов увеличивается (с 49 процентов в среднем бизнесе до 63 процентов у крупных предприятий), однако при этом доля изоляции в песочнице снижается с 35 до 20 процентов. Именно те организации, которые эксплуатируют наибольшее количество агентов в наибольшем числе систем, в наименьшей степени используют единственный действующий инструмент контроля, способный ограничить ущерб в случае сбоя.

Dr. Maik Bunzel, основатель и генеральный директор mabucon.eu, наблюдает эту закономерность и в среднем бизнесе: компании систематически недооценивают тот факт, что KI-агенты — это не просто инструменты автоматизации процессов, а активные субъекты с доступом к системам. Вопрос больше не в том, получит ли агент доступ к критически важным ресурсам, а в том, при каких условиях — и что произойдёт, если эти условия будут нарушены.

Безопасность на основе провайдера: удобно, но недостаточно

Что касается применяемых инструментов безопасности, исследование обнажает опасную беспечность. Стек безопасности большинства компаний является provider-нативным: Guardrails от OpenAI (51 процент), облачные средства контроля безопасности от Google и Microsoft, а также managed-agent Controls от Anthropic занимают доминирующее положение. Специализированные, агент-ориентированные решения безопасности от независимых поставщиков практически не представлены.

Удовлетворённость этими заимствованными архитектурами безопасности remarkably высока — в среднем 4,2 из 5 баллов. При этом явное большинство компаний планирует сменить своё Security-Tooling в течение следующего года. Организации довольны инструментами, от которых уже готовятся отказаться. Лишь треть считает, что собственные KI-защитные меры способны противостоять атакующим, вооружённым KI, — весьма отрезвляющий сигнал.

Бюджет на безопасность, направляемый на агент-специфические меры, остаётся незначительной долей общего бюджета IT-Security. Готовность к инвестициям явно не соответствует той операционной значимости, которую KI-агенты уже приобрели в критически важных бизнес-процессах.

Что компании должны изменить структурно уже сейчас

Выводы для организаций, которые уже используют KI-агентов в продуктивной среде или только планируют их внедрение, ясны и конкретны:

• Agent Identity как архитектурный принцип: Каждый агент требует собственной, строго ограниченной цифровой идентичности с соблюдением принципа минимальных привилегий (Least Privilege). Это не опциональная лучшая практика, а структурная базовая предпосылка.
• Sandbox-изоляция для высокорисковых агентов: Агенты с доступом к критическим системам, финансовым данным или внешним интерфейсам должны функционировать в изолированных средах выполнения, ограничивающих радиус поражения (Blast Radius) при компрометации.
• Purpose-built Agent Security вместо настроек провайдера по умолчанию: Guardrails поставщиков моделей не разрабатывались для сложных мультиагентных архитектур с неоднородным доступом к системам. В среднесрочной перспективе компаниям необходим выделенный уровень безопасности для агентной инфраструктуры.
• Возможность форензики как плановый показатель: Прежде чем агенты выйдут в продакшн, необходимо ответить на вопрос: можем ли мы ретроспективно восстановить, какой агент выполнил какое действие с какими учётными данными? Если нет — архитектура ещё не готова к промышленной эксплуатации.
• Пересмотр бюджета безопасности: Доля бюджета безопасности, направляемая на агент-специфические меры, должна расти пропорционально операционной зависимости от этих систем.

Перспектива: окно для вмешательства закрывается

Данные свидетельствуют: большинство компаний находятся в промежуточном состоянии. KI-агенты уже используются в продакшне, однако структуры управления (governance) ещё не успели за ними. Это окно — когда инциденты чаще являются почти-промахами, а не реальными утечками, — представляет собой стратегическую возможность, а не повод для успокоенности.

Dr. Maik Bunzel, основатель и генеральный директор mabucon.eu, усматривает здесь одно из ключевых направлений следующего этапа развития Enterprise-KI: переход от экспериментальных пилотов с агентами к масштабируемым, governance-зрелым агентным архитектурам требует, чтобы безопасность не встраивалась постфактум, а закладывалась с самого начала. Компании, которые занимаются этим сейчас, создают не только защиту — они формируют предпосылку для надёжного применения KI-агентов в бизнес-критических контекстах.

Agent Security Gap реален, измерим — и устраним. Но лишь при условии, что компании перестанут воспринимать его как технологическую проблему своих поставщиков и начнут рассматривать его как стратегическую управленческую задачу.