Google создал «надзирателя» за AI-агентами: система ловит rogue agents, misuse инструментов и скрытые аномалии

Проблема AI-агентов: они могут сделать опасную вещь без единой «ошибки»

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

Именно эту проблему Google пытается закрыть новым Agent Anomaly Detection в Gemini Enterprise Agent Platform. Система запущена в Private Preview и работает как отдельный слой надзора, анализирующий не только результат, но и поведение агента на протяжении всей сессии.

Что именно видит система

Agent Anomaly Detection читает логи, OpenTelemetry traces, вызовы инструментов и последовательность выполнения. Вместо вопроса «упал ли агент?» система задаёт другой: «действовал ли агент так, как от него ожидали?». Это принципиально другая модель безопасности.

Google называет решение reasoning-based oversight and audit layer. Оно ищет подозрительное намерение, нарушения политик и поведенческие аномалии, даже когда каждый отдельный API-вызов формально разрешён.

Почему анализ не замедляет ответы

Google запускает проверку асинхронно, вне основного пути живого запроса. Пользователю не приходится ждать, пока отдельная модель безопасности прочитает всю сессию. Для production это критично: если каждое действие агента будет ждать ещё один LLM, задержка и стоимость быстро станут непрактичными.

Но есть компромисс: out-of-band анализ не является магическим фильтром, который гарантированно остановит первую опасную операцию до выполнения. Его сила — в быстром обнаружении паттерна, расследовании и возможности блокировать последующие шаги через API.

Два уровня проверки: статистика плюс LLM

Pipeline построен слоями. Сначала лёгкий статистический этап просматривает весь трафик и ищет отклонения. Только подозрительные сессии передаются более глубокому LLM-уровню, который читает контекст и объясняет, почему поведение выглядит опасным.

Это важно экономически. Прогонять reasoning-модель через каждую сессию дорого. Фильтр первого уровня уменьшает объём работы, а сложный анализ концентрируется на случаях с сигналами аномалии.

Пример Google: агент «просто» просматривает весь склад

В демонстрации Google пользователь просит Inventory Agent показывать инвентарь по 100 позиций. Агент начинает ходить крупными batch-запросами и прыгать по offsets, фактически собирая весь каталог. Ни один вызов не падает, а инструмент list_inventory формально разрешён.

Первый уровень замечает необычный объём и повторяющиеся вызовы. Второй читает сессию и распознаёт систематический scraping, а третий при необходимости реконструирует отдельные tool calls. В примере результат помечается как Resource exhaustion с Critical severity и 95% probability.

Что происходит после срабатывания

Находка не остаётся в отдельной AI-консоли. Google публикует её в Security Command Center, где команда безопасности может разбирать её рядом с другими инцидентами. Для каждой аномалии система формирует уровень критичности, объяснение обычным языком и рекомендуемые действия.

Через API разработчик может получить severity и probability конкретной сессии и в callback или plugin заблокировать следующий tool call либо остановить следующий turn. Продукт пытается соединить аудит с реакцией до того, как аномальная сессия успеет сделать больше.

OWASP Agentic Top 10 превращается в реальные детекторы

Google привязывает набор детекторов к OWASP Top 10 for Agentic Applications 2026. В текущем наборе упоминаются tool misuse, identity and privilege abuse, cascading failures и rogue agents, а также практические риски вроде resource exhaustion и резкого роста использования токенов.

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

Чего Agent Anomaly Detection пока не решает

Во-первых, это Private Preview, а не общедоступный продукт. Он рассчитан на команды, разворачивающие агентов в Gemini Enterprise Agent Platform с ADK 1.2 или новее. Во-вторых, система сама по себе не делает опасный инструмент безопасным: авторизация, least privilege, rate limits и проверка параметров всё равно обязательны.

В-третьих, модельный детектор тоже способен ошибаться. Probability — не приговор, а сигнал для политики. Если автоматически останавливать бизнес-процесс при каждом среднем риске, можно получить новый класс проблем — от false positives до поломанных рабочих сценариев.

Что это значит для украинских команд

Украинские SaaS-компании, аутсорсинговые команды и продуктовые бизнесы активно добавляют LLM в поддержку, аналитику, DevOps и внутренние операции. Следующий этап — агенты, которые не просто пишут текст, а имеют доступ к CRM, биллингу, репозиториям, почте и административным инструментам.

Здесь подход «мы дали модели системный prompt и список разрешённых tools» уже недостаточен. Нужны отдельные уровни контроля: минимальные права, журналирование, OpenTelemetry, политики на уровне инструментов, контроль секретов и независимый анализ поведения.

Новая норма: AI-агенту нужен собственный SOC

Agent Anomaly Detection интересен не только как продукт Google, но и как признак зрелости отрасли. Когда агенты выполняют реальные бизнес-операции, им нужна инфраструктура, похожая на ту, что давно существует для пользователей, серверов и сетей: аудит, обнаружение аномалий, правила эскалации и автоматическая блокировка.

В ближайшие годы конкурентным преимуществом AI-платформ станет не только качество модели. Не менее важен вопрос: может ли компания доказать, что знает, что её агент делал вчера в 03:17, почему вызвал конкретный инструмент и кто остановит его, если следующий шаг выглядит опасным.

Галерея

↗

↗

↗

↗