Google Cloud IAM MCP: роли, deny-политики и OAuth
10 сентября 2026 года Google Cloud перевела удалённый сервер Identity and Access Management для Model Context Protocol в статус общедоступного продукта — General Availability. Через него AI-приложения и агенты могут проверять и изменять конфигурации пользовательских IAM-ролей и deny-политик в Google Cloud.
Поддерживается подключение из Gemini CLI, ChatGPT, Claude и собственных приложений. Сервер работает на инфраструктуре Google и предоставляет HTTP-endpoint https://iam.googleapis.com/mcp. Для доступа используется OAuth 2.0; API-ключи не поддерживаются.
Для бизнеса это заметный шаг: AI-агент получает стандартизированный интерфейс к одному из самых чувствительных слоёв облака — управлению доступом. Поэтому практическая ценность релиза неотделима от риска. Подключать IAM MCP следует с отдельной идентичностью, минимальными ролями, аудитом и подтверждением операций, изменяющих права.
Что умеет IAM MCP Server
Согласно документации Google, сервер предназначен для просмотра и управления пользовательскими ролями и конфигурациями deny-политик на ресурсах организации. Доступные сценарии включают поиск и получение метаданных ролей, их создание, обновление, удаление и восстановление, а также работу с deny-политиками.
MCP стандартизирует способ, которым AI-приложение обнаруживает инструменты и вызывает их. Вместо запуска локального посредника клиент обращается к управляемому endpoint Google по HTTP. Такой подход упрощает централизованное обнаружение сервиса, авторизацию и аудит, но не делает каждое действие безопасным автоматически.
Список инструментов можно получить стандартным методом tools/list; для этого запроса аутентификация не требуется. Реальные вызовы инструментов проверяются через Google Cloud IAM и OAuth-токен пользователя либо отдельной агентной идентичности.
Права доступа для работы с Google Cloud IAM MCP
Для вызова MCP-инструментов Google указывает роль MCP Tool User — roles/mcp.toolUser — на уровне проекта. Она содержит разрешение mcp.tools.call. Дополнительные права зависят от операции.
Для управления пользовательскими ролями требуется Role Administrator — roles/iam.roleAdmin — на проекте. Для deny-политик документация приводит Deny Admin — roles/iam.denyAdmin — на уровне организации. Последняя роль особенно чувствительна: ошибка в deny-политике способна заблокировать доступ даже тем субъектам, которым он разрешён обычной allow-политикой.
Google рекомендует создавать отдельную идентичность для агентов, чтобы её полномочия и действия можно было контролировать независимо. Это важнее удобства подключения: использование личной учётной записи администратора затрудняет расследование и увеличивает последствия ошибочной команды.
Как устроена аутентификация
IAM MCP не принимает API-ключи. Клиент должен использовать OAuth 2.0 и одну из поддерживаемых Google Cloud идентичностей. Для подключения указываются endpoint, HTTP-транспорт и scope https://www.googleapis.com/auth/cloud-platform либо https://www.googleapis.com/auth/iam.
Широкий OAuth-scope не заменяет проверку IAM: фактические возможности определяются одновременно токеном, ролями субъекта и политиками ресурсов. Тем не менее принцип минимальных полномочий нужно применять на обоих уровнях — выбирать минимальный scope и выдавать только те роли, которые нужны конкретному сценарию.
Для web- и некоторых desktop-клиентов необходимо заранее добавить разрешённый redirect URI в настройках OAuth. Произвольные redirect URI не поддерживаются, поэтому совместимость следует проверять по инструкции выбранного клиента до производственного внедрения.
Безопасный пилот для команд в Узбекистане
Первый пилот лучше проводить в отдельном Google Cloud проекте без production-нагрузки. Агенту можно выдать roles/mcp.toolUser и временную пользовательскую роль с ограниченным набором разрешений. Доступ к организационным deny-политикам на первом этапе разумно оставить только человеку-администратору.
Практический план проверки:
- подключить отдельную агентную идентичность и включить IAM API;
- разрешить сначала только чтение и инвентаризацию пользовательских ролей;
- фиксировать активный проект, организацию, OAuth-клиент и имя вызываемого инструмента;
- требовать ручное подтверждение перед созданием, изменением, удалением или восстановлением роли;
- проверять предлагаемые изменения через policy-as-code и обычный peer review;
- настроить централизованные audit logs и уведомления о чувствительных действиях;
- протестировать аварийный доступ и откат до разрешения операций с deny-политиками.
Командам банков, финтеха, телеком-операторов и государственных систем стоит дополнительно согласовать хранение журналов, расположение данных и допустимые OAuth-клиенты с внутренними требованиями безопасности.
Model Armor и новые риски журналирования
Google Cloud позволяет направлять запросы и ответы управляемых MCP-серверов через Model Armor. Политики могут фильтровать опасный контент, вредоносные URL и другие риски. IAM-политики также позволяют ограничивать MCP по субъекту, имени сервиса, имени инструмента, признаку read-only и OAuth client ID.
Однако у защиты есть важные оговорки. При включённом журналировании Model Armor может сохранять полный payload, включая чувствительные данные из запроса или ответа. Кроме того, если нужная юрисдикция не поддерживается, маршрутизация через Model Armor может повлиять на требования к резидентности данных. Эти параметры нужно проверять до передачи агенту сведений о реальной инфраструктуре.
Prompt injection также остаётся актуальной угрозой, особенно если агент получает инструкции из репозиториев, тикетов или внешних документов. Политика должна ограничивать не только пользователя, но и конкретные инструменты, которые разрешено вызывать после обработки недоверенного контента.
Что меняется для облачных операций
IAM MCP превращает работу с ролями и deny-политиками в инструмент, доступный AI-клиенту через единый протокол. Это может ускорить инвентаризацию, подготовку изменений и объяснение сложных политик. Но административная автоматизация отличается от генерации кода: неверный ответ способен немедленно изменить границу доступа к данным и сервисам.
Оптимальная роль агента на старте — аналитик и автор предложения. Он собирает состояние, выявляет расхождения и готовит минимальный патч политики, а человек либо контролируемый CI/CD-конвейер проверяет и применяет изменение. Полностью автономное управление IAM оправдано только после собственных тестов, ограниченного набора инструментов и отработанного восстановления.
Вывод
Статус GA делает IAM MCP Server пригодным для планового корпоративного пилота, но не отменяет осторожность. OAuth, отдельная идентичность, минимальные роли, ограничения на уровне инструментов и аудит должны быть частью архитектуры с первого дня.
Для команд Узбекистана практический выигрыш — единый управляемый интерфейс между AI-агентом и IAM. Без строгой модели доступа тот же интерфейс становится новым привилегированным каналом, поэтому начинать следует с чтения, тестового проекта и обязательного человеческого контроля.
