ADK не делает Gemini-агента zero trust: как собрать защищённый контур

Почему агент с инструментами становится задачей IAM

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

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

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

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

Цитата в переводе

«Построить AI-агента, который хорошо работает в демо, это одно; запускать его в production требует серьёзной инфраструктуры.»

Практика production-агента

«Построить AI-агента, который хорошо работает в демо, это одно; запускать его в production требует серьёзной инфраструктуры».

Источник: Addy Osmani - Director, Google Cloud AI

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

Что делает ADK, а что он не делает

Agent Development Kit, или ADK, Google позиционирует как открытый code-first фреймворк для создания, тестирования, оркестрации и развёртывания агентных систем. В нём описывают агентов, цепочки и графы workflow, инструменты, callbacks и взаимодействие нескольких специализированных агентов. Python-репозиторий проекта также указывает на интеграции с function tools, OpenAPI, MCP и сценариями human-in-the-loop.

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

Однако фреймворк не выдаёт минимальные IAM-роли, не хранит секреты за команду, не закрывает исходящий трафик в сеть и не превращает API-ключ Gemini в индивидуальную криптографическую личность агента. Безопасность определяется не только кодом ADK, но и runtime, облачным проектом, сетевыми политиками, аутентификацией и инструментами, с которыми соединён этот код.

Здесь проходит граница между AI Studio и production-платформой. AI Studio и Gemini API удобны, когда нужно проверить промпт, структурированный вывод или базовый tool calling. Но ключ API идентифицирует приложение либо проект и сам по себе не решает вопрос индивидуальных полномочий агентов, пользовательского делегирования и аудита корпоративных операций. Для таких задач Google развивает контур Vertex AI Agent Engine и Gemini Enterprise Agent Platform.

• ADK: логика агентов, workflows, инструменты, callbacks и подтверждение действий.
• Gemini API: вызов модели и прототипирование модельных сценариев.
• AI Studio: среда для экспериментов с Gemini и API-интеграциями.
• Cloud-уровень: identity, IAM, runtime, журналирование, сетевые ограничения и политика доступа.

Цитата в переводе

«Agent Identity назначает каждому агенту уникальный криптографический идентификатор для полной трассируемости и аудита.»

Отдельная identity вместо одной суперучётки

Ключевой элемент подхода, который Google связывает с Agent Engine и Gemini Enterprise, называется Agent Identity. Компания описывает его как уникальную криптографическую идентичность для каждого агента, предназначенную для трассируемости и аудита. В такой модели агент не должен делить одну service account с десятком других workloads и не должен получать долгоживущий ключ, который легко скопировать в конфигурацию или случайно отправить в репозиторий.

Практический смысл заключается в least privilege, то есть в принципе минимально необходимых прав. Агент, который суммирует отчёты из конкретного хранилища, получает доступ на чтение к этому набору объектов. Агент для подготовки черновиков писем не получает права создавать пользователей. Агент, запускающий регламентный job, не должен автоматически читать все таблицы BigQuery или менять настройки проекта.

Важно не смешивать собственные полномочия агента с действиями от имени сотрудника. В первом случае агент обращается к разрешённому ресурсу в пределах своей роли. Во втором ему может понадобиться OAuth-делегирование: пользователь соглашается на ограниченный доступ к почте, задачам или внешнему сервису. Безопасная схема позволяет ограничить scope, отозвать согласие и связать действие с конкретным пользователем.

Платформенные механизмы идентичности и доступа нельзя заранее считать полностью зрелым универсальным стандартом: доступность зависит от конкретного сервиса и стадии релиза. Для критичного контура нужен резервный путь: раздельные custom service accounts, обычный IAM, централизованный secrets manager и отдельная процедура ревизии прав.

• Один production-агент, одна отдельная identity или service account.
• Раздельные роли для чтения, записи, администрирования и выполнения job.
• Минимальные OAuth scope для пользовательского делегирования.
• Регулярная проверка неиспользуемых ролей, токенов и интеграций.
• Запрет на общие ключи, встроенные в код, .env-файлы и инструкции модели.

Идентичность нужна для аудита

«Agent Identity назначает каждому агенту уникальный криптографический идентификатор для полной трассируемости и аудита».

Источник: Brian Delahunty; Michael Gerstenhaber - Gemini Enterprise

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

Tool Confirmation полезен, но не заменяет авторизацию

ADK поддерживает Tool Confirmation: вызов инструмента можно остановить до исполнения и передать на подтверждение человеку либо внешней системе принятия решения. Это естественный рубеж для перевода денег, удаления данных, отправки сообщения внешнему адресату, изменения прав или публикации в production. Оператору полезно показывать не текстовое объяснение модели, а нормализованные параметры будущего вызова: получателя, сумму, идентификатор объекта, endpoint и предполагаемый эффект.

Confirmation не следует путать с авторизацией. Подтверждение отвечает на вопрос, нужно ли выполнить конкретный вызов сейчас. IAM и policy layer отвечают на другой вопрос: имеет ли эта identity право выполнить его в принципе. Даже внимательный сотрудник может машинально согласовать опасное действие, а approval-сервис не исправит инструмент, которому изначально выданы чрезмерные права.

Надёжнее строить workflow с разделением reasoning и execution. Gemini предлагает план или формирует структурированный запрос. Затем детерминированный код валидирует схему, проверяет лимиты, сверяет пользователя и ресурс с политикой, а при необходимости создаёт approval-задачу. Только после этого отдельный исполнительный компонент вызывает API.

Для низкорисковых read-only операций человеческое подтверждение на каждом шаге может быть избыточным. Для необратимых и внешних действий стоит заранее определить пороги: какие операции полностью запрещены, какие требуют одобрения, а какие разрешены автоматически в строго очерченном контексте. Это политика компании, а не свойство Gemini или ADK.

• Автоматизировать чтение только из заранее разрешённых источников.
• Выносить операции записи в отдельные детерминированные workflow-узлы.
• Показывать в approval-интерфейсе параметры вызова, а не пересказ модели.
• Проверять лимиты, получателя, ресурс и назначение операции до tool call.
• Логировать решение модели, policy decision, одобрение и итог вызова.

Gateway, Model Armor и sandbox: как уменьшать радиус ошибки

Когда агент подключён к MCP-серверам, OpenAPI-инструментам, внешним моделям или другим агентам, появляется задача контроля трафика между компонентами. Google описывает Agent Gateway как уровень управления взаимодействиями «агент—агент» и «агент—инструмент», а Model Armor связывает с проверкой текстового входящего и исходящего трафика на ряд рисков, включая prompt injection, jailbreak и возможные утечки чувствительной информации.

Эти механизмы не стоит воспринимать как магическую защиту. Фильтрация текста может остановить часть вредоносных инструкций или нежелательных ответов, но не заменяет контроль доступа. Если агенту разрешено скачать всю базу клиентов и отправить файл на любой домен, одной проверки промпта недостаточно. Нужны ограничения на данные, схему инструмента, разрешённые endpoint’ы, объём выгрузки и сетевой маршрут.

Отдельный риск связан с кодом и browser automation. Агент может предложить скрипт, открыть сайт или загрузить артефакт, но выполнение не должно по умолчанию происходить на рабочей машине разработчика или хосте с широким доступом к корпоративной сети. В экосистеме ADK Google упоминает исполнение через Vertex AI Code Execution Sandbox API и интеграцию с управляемыми Cloud-runtime.

Базовая логика sandbox проста: короткое время жизни, ограниченные CPU и память, отсутствие секретов в контексте модели, закрытый исходящий трафик по умолчанию и доступ только к конкретно разрешённым ресурсам. Sandbox не делает опасный инструмент безопасным автоматически, но сокращает масштаб последствий, если агент ошибся или неправильно интерпретировал задачу.

• Добавлять MCP и OpenAPI-инструменты через allowlist, а не по произвольному URL.
• Фиксировать схемы вызовов и ограничивать набор endpoint’ов.
• Не выдавать sandbox доступ к metadata-службам и production-secrets.
• Закрывать исходящий сетевой трафик, затем открывать только нужные направления.
• Сканировать и журналировать входящие и исходящие текстовые данные, не считая это заменой IAM.

Почему prompt injection остаётся архитектурной проблемой

Indirect prompt injection возникает, когда агент читает документ, письмо, тикет или страницу ради полезной задачи, а внутри материала находится инструкция, пытающаяся изменить его поведение. Например, документ может требовать игнорировать правила, выгрузить контекст в сторонний сервис или вызвать другой инструмент. Модель не обязана отличать такую инструкцию от легитимного содержания с абсолютной надёжностью, особенно если задача требует анализа естественного языка.

Недоверенный контент может влиять на рассуждение агента, но не должен напрямую получать способность расширить его полномочия. Документ не должен добавлять новый MCP-инструмент. Веб-страница не должна менять сетевой allowlist. Текстовое указание не должно превращаться в разрешение на экспорт данных. Такие решения должны находиться за пределами контекста модели: в policy-коде и инфраструктурной конфигурации.

Компоненты Google для production-агентов не отменяют необходимость проектировать инструмент с узкой функцией. Универсальный tool вида run_any_command, широкая service account и доступ к произвольному URL создают опасную комбинацию даже при наличии контентной фильтрации. Напротив, инструмент create_draft_invoice с жёсткой JSON-схемой, лимитами и обязательным approval проще контролировать и тестировать.

• Не позволять модели самостоятельно подключать новые инструменты и источники данных.
• Разделять инструкции системы, пользовательские данные и содержимое внешних документов.
• Передавать агенту минимальный фрагмент данных, необходимый для текущего шага.
• Запрещать инструментам выполнять произвольные команды и запросы без схемы.
• Проводить red-team-проверки на документах, письмах и страницах с инъекциями.

Российский контекст: сначала определить границы данных и runtime

Для российских компаний вопрос не сводится к выбору между ADK и другим фреймворком. Нужно заранее установить, где будут находиться промпты, файлы, логи сессий, результаты tool calls, резервные копии и пользовательские OAuth-данные. Отдельно следует проверить, доступен ли выбранный зарубежный cloud runtime для конкретной организации, сценария и типа информации.

Ни ADK, ни Gemini Enterprise сами по себе не означают соответствие требованиям российского регулирования: такого обещания в доступных материалах Google нет. Для корпоративного внедрения потребуются собственная модель классификации данных, формальный список разрешённых интеграций, журналирование, процесс отзыва прав и юридическая оценка передачи информации.

Практичный путь состоит в разделении контуров. Для эксперимента подходят синтетические, публичные или качественно обезличенные данные, один read-only инструмент и отсутствие production-доступов. Для корпоративного внедрения необходима организационная надстройка над любой агентной платформой.

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

• Пилот: только разрешённые данные, отдельный проект, read-only доступ, тестовые интеграции.
• Production: классификация данных, IAM-матрица, журналирование и процедуры отзыва.
• Не считать API-ключ доказательством достаточной идентификации агента.
• До запуска проверить размещение логов, файлов, сессий и резервных копий.
• Документировать, какие действия агенту запрещены независимо от запроса пользователя.

Чек-лист перед запуском Gemini-агента в production

Начинать стоит не с агентной команды из нескольких ролей, а с одного узкого сценария. Пусть первый агент читает один тип данных и вызывает один read-only инструмент. Если команда не может объяснить, от чьего имени он работает, какие данные видит и где остаётся след его вызовов, добавлять браузер, запись в CRM или multi-agent-оркестрацию преждевременно.

После этого автономность можно повышать постепенно. Для каждой новой интеграции нужна отдельная оценка: какие scopes требуются, какие параметры допустимы, что будет при ошибке, нужен ли approval и как быстро отозвать доступ. ADK делает агентную логику прозрачнее и модульнее, но зрелость внедрения определяется ревизией ролей, тестированием, наблюдаемостью и готовностью остановить систему.

• Назначить агенту отдельную identity или отдельную service account.
• Выдать минимальные IAM-роли только на конкретные ресурсы.
• Разделить инструменты чтения и изменения данных.
• Добавить allowlist интеграций, endpoint’ов и допустимых операций.
• Поставить approval gate на деньги, удаление, внешнюю отправку, выдачу прав и production-deploy.
• Исполнять сгенерированный код и browser-задачи в изолированном runtime.
• Вести логи запросов, tool calls, решений политик, делегирования и результатов.
• Проверить kill switch, отзыв OAuth-согласий и ротацию доступов.
• Отдельно оценить preview-компоненты и подготовить fallback на стандартные IAM и gateway-средства.

Что это означает на практике

ADK не следует называть самостоятельным zero-trust-решением. Это фреймворк для агентной логики; защита появляется в связке с identity, IAM, runtime, сетевыми правилами и аудитом.

Первым production-пилотом должен стать узкий read-only сценарий с отдельной identity, а не multi-agent-схема с широкими интеграциями. Собственные права агента и OAuth-делегирование от пользователя также нужно разделять: общий постоянный административный токен для обоих режимов создаёт избыточный риск.

Tool Confirmation полезен для высокорисковых операций, но не подменяет IAM и проверку политик. Model Armor и gateway остаются дополнительными рубежами: они помогают контролировать текстовый трафик, но не исправляют чрезмерные права и небезопасный дизайн инструментов.

Перед архитектурным решением нужно проверить статус каждого облачного компонента. Preview-возможности уместны в пилотах, но для критичных сценариев нужен fallback.

Вывод

Google постепенно формирует для ADK не просто набор библиотек, а более широкий контур эксплуатации агентных систем. В нём Gemini отвечает за рассуждение и генерацию, ADK описывает процесс и инструменты, а Cloud-слой ограничивает идентичность, доступ, трафик и выполнение.

Эта конструкция не появляется автоматически после установки SDK или создания ключа Gemini API. Zero trust остаётся результатом решений команды: отдельных учётных сущностей, минимальных прав, узких инструментов, изоляции, approval-процедур и постоянного аудита. Чем раньше эти ограничения заложены в пилот, тем меньше шансов, что успешная демонстрация превратится в небезопасный production-сервис.

Источники

• Google Cloud: Five guides to building and scaling production-ready AI agents
• Google Cloud: The new Gemini Enterprise, one platform for agent development
• Google Cloud: Agent Factory recap, securing AI agents in production
• Google ADK documentation: Agents
• Google ADK for Python
• Google ADK Python: Project overview and architecture
• Google Cloud: More ways to build and scale AI agents with Vertex AI Agent Builder
• Google Cloud: Build your first ADK agent workforce

Частые вопросы

Можно ли считать Google ADK готовым zero-trust-решением?

Нет. ADK предназначен для описания и оркестрации агентной логики. Zero-trust-контур требует отдельных identity, IAM-ролей, управления секретами, сетевых ограничений, изолированного runtime, аудита и правил для инструментов.

Чем Tool Confirmation отличается от IAM?

Tool Confirmation позволяет остановить конкретный вызов инструмента и запросить одобрение. IAM определяет, имеет ли identity право выполнить операцию вообще. Для рискованных действий нужны оба уровня контроля.

Зачем Gemini-агенту отдельная service account?

Раздельная identity ограничивает права конкретным агентом, упрощает аудит и снижает риск, что компрометация одного workload даст доступ к ресурсам других агентов.

Защищает ли Model Armor от всех prompt injection?

Нет. Проверка входящего и исходящего текста может стать дополнительным рубежом, но не заменяет узкие схемы инструментов, allowlist endpoint’ов, минимальные права и контроль экспорта данных.

С чего начать production-пилот на ADK?

С одного узкого сценария: разрешённые данные, отдельный проект, отдельная identity, read-only инструмент, журналирование и понятная процедура отзыва доступа.

Практический чек-лист

Чек-лист запуска Gemini-агента в production

Памятка повторяет практический чек-лист из статьи. Её можно сохранить в PDF перед запуском пилота или ревизией существующего агентного контура.

Идентичность и доступ

• Назначить агенту отдельную identity или service account.
• Выдать минимальные IAM-роли только на конкретные ресурсы.
• Разделить инструменты чтения и изменения данных.
• Проверить OAuth scope и процедуру отзыва согласий.

Инструменты и выполнение

• Добавить allowlist интеграций, endpoint’ов и допустимых операций.
• Настроить approval для денег, удаления, внешней отправки, прав и production-deploy.
• Исполнять код и browser-задачи в изолированном runtime.
• Закрыть исходящий трафик по умолчанию и открыть только нужные направления.

Наблюдаемость и устойчивость

• Логировать запросы, tool calls, policy decisions, делегирование и результаты.
• Проверить kill switch и ротацию доступов.
• Оценить preview-компоненты и подготовить fallback на стандартные IAM и gateway-средства.