Пролог: "9 секунд до катастрофы"

Не так давно AI-агент для разработки кода (Cursor на базе модели Anthropic Claude Opus 4.6) получил задачу и выполнил её буквально. Слишком буквально. За 9 секунд он уничтожил базу данных компании вместе с резервными копиями. Когда его спросили об этом, агент ответил: "Я нарушил каждый принцип, который мне дали". Этот случай произошел в стартапе PocketOS

Именно эта фраза - приговор целому классу архитектурных решений. Потому что агент не лгал: он нарушил свои же инструкции, заложенные в system prompt. Это означает одно: нельзя полагаться на внутренние ограничения модели как на единственный механизм безопасности.

Это та же логическая ошибка, что и доверять стажёру слова "не делай ничего деструктивного" без каких-либо технических ограничений на уровне инфраструктуры. Нужен внешний контур управления. И именно его Google Cloud реализовал в виде Agent Gateway.

Что такое Agent Gateway

Большинство описаний Agent Gateway сводятся к формулировке «умный прокси для AI-агентов». Это верно, но совсем неполно.

Agent Gateway - это сетевой компонент платформы Gemini Enterprise Agent Platform. Он обеспечивает безопасность и управление подключениями для всех агентских взаимодействий: между пользователями и агентами, между агентами и инструментами, а также между самими агентами.

Ключевое слово здесь - сетевой компонент. Agent Gateway работает на уровне сетевой инфраструктуры, вне цикла рассуждений модели. Это означает, что он не просит агента "сначала проверить политику" , а перехватывает вызов ещё до того, как он достигает цели.

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

Именно это разделение критично. Если бы в той истории с уничтоженной БД был развёрнут Agent Gateway, агент просто не смог бы физически отправить деструктивный запрос, не потому что "передумал" (работая по ограничениям политик безопасности), а потому что шлюз заблокировал бы его на сетевом уровне.

Место в экосистеме: пиллар "Govern"

Чтобы понять Agent Gateway правильно, нужно сначала понять архитектуру Gemini Enterprise Agent Platform в целом.

Платформа организована вокруг четырёх ключевых направлений: Build, Scale, Govern и Optimize. Agent Gateway входит в направление Govern и является центральной точкой применения политик для управления всеми вызовами агентских инструментов, управления аутентификацией и применения политик безопасности.

Схема взаимодействия выглядит так:

• Build — ADK, Agent Studio, Agent Garden (создаём агентов)

• Scale — Agent Runtime, Sessions, Memory Bank (запускаем и масштабируем)

• Govern — Agent Identity, Agent Registry, Agent Gateway, Policies (управляем и защищаем)

• Optimize — Observability, Evaluation, Example Store (улучшаем)

Agent Gateway стоит именно в «Govern», потому что его задача гарантировать, что агент работает только в пределах разрешённых границ.

Четыре интеграции, которые делают Gateway умным

Agent Gateway работает не в "вакууме". Его реальная сила в глубокой интеграции с другими компонентами платформы:

1. Agent Registry

Agent Registry - это центральная библиотека одобренных агентов и инструментов, включая сторонние MCP-серверы. Agent Gateway обращается к метаданным реестра для применения детальных политик доступа.

Практически это означает: агент не может "самовольно" подключиться к новому инструменту или MCP-серверу. Если ресурс не зарегистрирован в реестре, по умолчанию доступ к нему закрыт.

2. Agent Identity

Agent Identity - уникальная, отслеживаемая персона для каждого агента, взаимодействующего с Google Cloud. Agent Gateway использует эти идентификаторы как principals для принятия решений об авторизации. Идентификаторы агентов по умолчанию защищены Context-Aware Access, который обеспечивает сквозную криптографическую аутентификацию с использованием mTLS и DPoP.

При развёртывании агенты должны быть настроены с Agent Identity - уникальным идентификатором в формате SPIFFE, который служит детализированной альтернативой общим сервисным аккаунтам. Поддерживаемый непосредственно в IAM, он позволяет администраторам назначать конкретные разрешения (например на бакеты Cloud Storage или датасеты BigQuery) непосредственно агенту.

3. Agent Platform Policies

Agent Gateway предоставляет делегированную авторизацию политикам Agent Platform, таким как IAM, Semantic Governance и Model Armor, позволяя реализовать богатые наборы мер безопасности и управления агентами.

4. Agent Observability

Agent Gateway генерирует телеметрию наблюдаемости для всех агентских взаимодействий на сетевом уровне и экспортирует её в Agent Observability для обеспечения полного понимания действий агентов.

Два режима работы: ingress и egress

Архитектурно Agent Gateway работает в двух режимах, которые закрывают разные векторы угроз:

Client-to-Agent (Ingress)

Этот режим используется для защиты коммуникаций между клиентами (такими как Cursor, Claude Code, Gemini CLI) и агентами, а также инструментами, запущенными в Google Cloud. В этом режиме Agent Gateway выступает как фронтенд для агента и позволяет контролировать, какие клиенты могут обращаться к агентам и какие политики безопасности применяются к этим взаимодействиям.

Это защита от входящих угроз: prompt injection из ненадёжных клиентов, несанкционированного доступа к агентам, вредоносного контента от внешних систем.

Agent-to-Anywhere (Egress)

Этот режим используется для защиты коммуникаций между агентами, запущенными в Google Cloud, и серверами, агентами, инструментами или API, работающими где угодно. Agent Gateway применяет разрешения доступа и средства защиты для агентов, которым необходимо взаимодействовать с MCP-серверами - как созданными самой организацией, так и удалёнными серверами сторонних производителей.

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

Именно режим Egress защитил бы от инцидента с уничтоженной базой данных.

Система контроля доступа: IAP + IAM + Model Armor

Это самая технически насыщенная часть. Разберём, как выстроены слои контроля:

Identity-Aware Proxy как ядро авторизации

Identity-Aware Proxy выступает стандартным уровнем применения политик для Agent Gateway. Он использует IAM для проверки идентификатора агента и проверяет назначенные разрешения перед тем, как разрешить вызовы к другим агентам или инструментам. IAP включён по умолчанию для Agent Gateway, хотя можно запустить его в режиме audit-only (dry-run).

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

Гранулярные IAM-политики

Можно предоставлять и запрещать отдельным агентам или клиентам доступ к MCP-серверам и инструментам на основе имени инструмента и того, является ли инструмент только для чтения или для чтения-записи. Разрешения можно предоставлять на уровне организации, папки или проекта.

Это именно та гранулярность, которой не хватало: не просто "разрешить/запретить доступ к сервису", а "разрешить только read-only операции к конкретному инструменту".

Model Armor: защита от prompt injection

Model Armor (опционально) можно использовать для контроля исходящего трафика: убедиться, что агент "не утекает" чувствительные данные или не подвергается атакам prompt injection. При использовании в режиме Ingress - для защиты агентов от входящих атак или вредоносного контента от клиентов.

Региональность и требования к развёртыванию

Несколько важных практических деталей:

Agent Gateway является региональным по своей области действия. Каждый шлюз управляет агентскими взаимодействиями в рамках проекта, в котором он развёрнут. Агенты должны быть развёрнуты в том же проекте и регионе, что и шлюз, а также зарегистрированы в том же регионе.

Для Agent Runtime поддерживаются оба режима (Ingress и Egress). Для Gemini Enterprise поддерживается только режим Egress.

Конфигурация через YAML

Развёртывание через gcloud выглядит минималистично - Agent Gateway конфигурируется декларативно:

yaml

name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION

После создания Agent Gateway он служит основной точкой подключения для маршрутизации агентского трафика в вашем проекте и выбранном регионе. Можно использовать этот endpoint для установления безопасных, зашифрованных и аутентифицированных каналов связи между агентами и их назначениями.

Подключение к VPC через Private Service Connect

Для агентов, которым нужен доступ к ресурсам во внутренней сети, Agent Gateway поддерживает конфигурацию VPC-подключения через Private Service Connect network attachment. Минимальный размер подсети для сетевого вложения - /28. Поддерживается также DNS-пиринг для разрешения имён внутри целевых VPC-сетей.

Ограничения

Ни одна технология не идеальна, и важно знать ограничения:

Условия авторизации, основанные на атрибутах агентских протоколов, поддерживаются только для Model Context Protocol (MCP). Другие агентские протоколы не поддерживаются. Для Gemini Enterprise режим Client-to-Agent не поддерживается. Agent Gateway не поддерживает VPC Service Controls.

Что это означает для нас на практике:

• Если вы используете A2A или REST-протоколы, гранулярные условия по атрибутам протокола вам пока недоступны - только IAM-контроль на уровне идентификатора агента.

• Если вы строите architecture с VPC Service Controls как основным инструментом изоляции - нужно будет использовать кастомные organization policy constraints вместо VPC SC.

• Функциональность находится в Private Preview, то есть доступна по заявке. Для получения доступа к Agent Gateway с Agent Runtime необходимо заполнить форму запроса доступа.
  То есть, чтобы использовать связку Agent Gateway и Agent Runtime, необходимо перейти на специальную страницу запроса (access request page) и заполнить форму заявки для включения проекта Google Cloud в «белый список» (allowlist)

Почему это важнее, чем кажется

Давайте посмотрим на ситуацию шире. Мы переживаем принципиально новую эпоху в IT-безопасности: от защиты кода к защите намерений.

Традиционные firewalls и WAF работают с сигнатурами и правилами на уровне байтов. Но что делать с запросом, который синтаксически корректен, проходит все проверки аутентификации и авторизации, но семантически деструктивен? DELETE FROM users WHERE 1=1 - это валидный SQL. Его опасность определяется не форматом, а намерением.

Agent Gateway - это первый enterprise-инструмент от крупного облачного провайдера, который работает именно на семантическом уровне агентских протоколов. Он понимает разницу между вызовом инструмента с read-доступом и write-доступом, умеет проверять контекст запроса через Model Armor и принимать решения на основе семантической политики, а не только байтовых сигнатур.

Это означает сдвиг в модели безопасности: от "что агент имеет право делать" к "что агент пытается сделать прямо сейчас".

Матрица: что защищает Agent Gateway

Вывод

Если вы строите production AI-агентов сегодня и ограничиваетесь только инструкциями в system prompt как механизмом ограничения - вы строите систему с единственной точкой отказа. И эта точка отказа - сама модель, которая может ошибиться, быть взломана через prompt injection или просто "передумать" в непредвиденной ситуации.

Agent Gateway вместе с Model Armor защищает все агентские взаимодействия, применяет политики во время выполнения и помогает защититься от угроз, обеспечивая соответствие операций требованиям.

Правильная enterprise-архитектура для AI-агентов выглядит так: разрабатываете агента без необходимости думать о сетевых примитивах и безопасности (это задача для команды безопасности, не разработчиков), регистрируете его в Agent Registry, определяете IAM-политики с минимально необходимыми правами, развёртываете с маршрутизацией через Agent Gateway. Всё остальное платформа берёт на себя.