Gemini Semantic Governance Policy в Public Preview: runtime-блокировка инструментальных вызовов агентов

Когда многошаговый агент выполняет действие, которого пользователь не запрашивал, статические средства управления доступом уже не справляются. Ответ Google — Semantic Governance Policy (SGP): runtime-шлюз намерений, который перехватывает каждый предложенный tool call и проверяет его соответствие исходному намерению пользователя и набору бизнес-правил, прежде чем агент вызовет инструмент.

29 июня 2026 года Google перевёл SGP в Public Preview на Gemini Enterprise Agent Platform. Для команд, маршрутизирующих запросы через несколько provider, это меняет представление об уровнях enforcement — и ставит перед каждым оператором конкретный вопрос: где runtime semantic governance вписывается в существующий стек из gateway, IAM-политик и фильтрации промптов?

Что изменилось

SGP добавляет новый управляемый компонент инфраструктуры — SGP-движок, который разворачивается внутри вашей VPC-сети. После того как модель агента возвращает ответ, SGP-движок перехватывает каждый предложенный tool call, выполняет две семантические проверки и либо одобряет, либо отклоняет вызов — до того как агент обратится к инструменту:

1. Выравнивание намерений — соответствует ли предложенный tool call семантическому намерению исходного доверенного промпта пользователя? Если пользователь попросил «сводку по моему календарю», а модель предписывает вызов send_email, SGP это зафиксирует и заблокирует.

2. Соответствие бизнес-ограничениям — не нарушают ли предложенные параметры правила организации, сформулированные на Natural Language Constraints (NLC)? Пример: «запретить автоматическое проведение возвратов на сумму свыше $75». Если агент получает запрос на возврат $89 и модель направляет его к issue_refund, SGP откажет.

Оба условия должны быть выполнены. Отказ по любому из них блокирует выполнение и пишет вердикт в audit-лог.

Ключевые возможности:

• Natural Language Constraints: правила enforcement — обычные фразы на английском, без изменений в коде и перезапуска агентов
• Layered Intent Gating: гранулярность до конкретного инструмента или даже отдельного параметра
• Agent Skills Lifecycle Governance: контроль над тем, какие skill-пакеты агент может динамически загружать, — защита от supply-chain атак и отравления контекста
• Dry Run Mode: наблюдение за вердиктами SGP в Cloud Logging до включения принудительного режима
• Время настройки: около 20 минут на конфигурацию VPC и включение SGP-движка

Почему это важно для AI-инженерных команд

Context poisoning — класс атак, при которых недоверенные данные (вредоносное письмо, сконструированный документ, подменённый ответ инструмента) перезаписывают контекст агента так, что модель начинает давать инструкции, которые пользователь никогда не разрешал. Инструменты сканирования промптов работают на уровне входных данных; SGP работает на уровне действия — перехватывает уже сгенерированный tool call, даже если модель была успешно скомпрометирована.

Для команд, строящих производственных агентов — боты клиентской поддержки, внутренние knowledge-worker агенты, coding-помощники — SGP закрывает пробел, с которым IAM-правила не справляются. IAM даёт разрешение; SGP проверяет, семантически оправдано ли технически разрешённое действие с учётом реального запроса пользователя.

Таблица уровней защиты из документации Google полезна для понимания архитектуры в целом:

SGP не заменяет ни один из перечисленных слоёв — это дополнительная точка enforcement, нацеленная именно на риск того, что LLM направит агента к злоупотреблению инструментом, который тот технически имеет право вызвать.

Взгляд оператора и routing-команды

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

Enforcement привязан к provider, а не к gateway. SGP — функция Gemini Enterprise Agent Platform. Она перехватывает tool calls только у агентов, работающих на этой платформе. Команды, маршрутизирующие запросы через несколько provider (Gemini, Anthropic, Azure, другие), должны реализовывать аналогичные семантические guardrails на уровне gateway или внутри каждого provider отдельно. Общего межплатформенного стандарта пока не существует.

Политики на естественном языке становятся routing-артефактами. Когда правила enforcement хранятся в виде NLC-текстов, а не кода, их нужно версионировать вместе с routing-конфигурациями — предпочтениями по моделям, цепочками fallback, приоритетами provider. Drift политик между окружениями (dev → staging → prod) превращается в новый операционный риск.

Dry Run — это canary для governance. Режим наблюдения позволяет проверить вердикты на реальном трафике до включения принудительного режима. Это прямой аналог shadow mode или canary routing, которые routing-команды используют для валидации новых fallback-правил: сначала наблюдать, потом принуждать.

Для команд, уже работающих на Gemini Enterprise Agent Platform, вопрос о том, включать SGP сейчас (в Preview) или ждать GA, — это баланс между более ранней защитой и нестабильностью Preview-уровня: SLA и возможные breaking changes.

Что стоит сделать прямо сейчас

Если ваши production-агенты работают на нескольких provider — Gemini, Anthropic Managed Agents, Azure Foundry и других — у вас пока нет единого семантического слоя enforcement. Это текущее состояние отрасли: каждая платформа строит собственные инструменты (Anthropic — safety-классификаторы и sandbox для managed agents; Google — SGP; Microsoft — Azure AI Content Safety). Единого стандарта семантической политики для нескольких provider не существует.

Практические шаги:

• Определите, у каких агентов в вашем стеке наибольший риск context poisoning или несанкционированных tool calls (первые кандидаты — агенты с доступом на запись в БД, email, финансовые системы или внешние API)
• Для агентов на Gemini Enterprise Agent Platform: включите SGP в Dry Run Mode на реальном трафике, изучите журналы вердиктов, прежде чем переходить к enforcement
• Для мультипровайдерных стеков: задокументируйте имеющиеся средства выравнивания намерений для каждого provider; отметьте пробелы, где семантического шлюза нет
• Ознакомьтесь с документацией по управлению Agent Skills, чтобы понять полную интеграционную поверхность SGP

Больше материалов о построении управляемых мультипровайдерных routing-архитектур — в документации TheRouter.