Google Cloud Remote MCP: gcloud как инструмент агента
30 сентября 2026 года Google Cloud вывела в preview удалённый MCP-сервер для gcloud CLI: агент шлёт естественный запрос, сервер исполняет команды в изолированной песочнице под вашей IAM-ролью. Это образцовый кейс главной дилеммы remote MCP: мощь против blast radius. Разбираем устройство, запреты, права и практику — на примере, который переносится на любой удалённый сервер.
Срез на дату публикации: тарифы и каталог меняются — пересчитайте по методике статьи на свежих данных.
Короткий ответ
Удалённый MCP превращает gcloud в инструмент агента: один endpoint, OAuth с ролями, запрещённые команды, audit log каждого вызова. Начинайте с чтения и узких ролей.
Устройство: один endpoint, один инструмент
Схема: клиент агента подключается к endpoint сервера по HTTP с OAuth-аутентификацией, дальше всё сводится к одному инструменту выполнения команд с обязательным параметром проекта. Агент генерирует команду, сервер исполняет, возвращает вывод. Локальная установка CLI агенту больше не нужна — важно для веб-платформ, где окружение не контролируется.
Ключевая деталь — чья идентичность действует: вызывающего (ваша, агента, сервис-аккаунта), и именно под неё проверяются права на каждую команду. Проект для биллинга и квот задаётся явно и отдельно от проекта, над которым работает команда, — путаница этих двух сущностей ломает и биллинг, и доступ.
- один endpoint, OAuth, один инструмент
- действует идентичность вызывающего
- проект биллинга отдельно от рабочего
- локальный CLI агенту не нужен
Запреты и least privilege
Сервер заранее запрещает группы команд: управление доступом, конфиги, инициализация, биллинг, установка компонентов — всё, чем агент может выстрелить себе в ногу или расширить свои права. Остальное решается ролями: минимально необходимая роль на агента, а не владелец проекта «чтобы точно завелось».
Отдельный класс правил — формат и безопасность выполнения: флаги только через знак равенства, обязательный проект в команде, лимит на чтение логов, асинхронность для долгих операций (создание VM синхронно — это таймаут агента, а не «подождать»). Длинные операции — только асинхронно, иначе агент умрёт раньше результата.
| Класс | Пример | Правило |
|---|---|---|
| Доступы и конфиги | Управление ролями, инициализация | Запрещены сервером |
| Биллинг и установка | Оплата, компоненты | Запрещены сервером |
| Чтение состояния | Список инстансов, логи с лимитом | Разрешено, узкая роль |
| Изменения | Создание сетей и VM | Роль + подтверждение + --async |
- доступы и биллинг — запрещены заранее
- роль минимальная, не владелец
- флаги через =, проект всегда явно
- долгое — только асинхронно
Практика: пилот за вечер
Пилот: включите API исполнения, выдайте роль исполнителя MCP на тестовый проект, подключите клиент, попросите агента списком инстансов и чтением ошибок из логов с лимитом. Проверьте три вещи: запрещённая команда отклоняется, чужой проект недоступен, каждый вызов виден в audit log. Только потом — запись.
В проде: системный промпт агента с явным указанием правильного проекта (агент не должен его угадывать), мониторинг успешности, ошибок прав и нарушений политик, журнал вызовов в вашу observability. Следите за выходом из preview: тарифы, лимиты и набор команд изменятся, сегодняшние договорённости протухнут вместе с ним.
- пилот: чтение, запреты, чужой проект, журнал
- проект — явно в промпте, не на угадывание
- мониторинг прав и нарушений
- preview кончится — условия изменятся
Источники и связанные страницы
Следующий шаг
Открыть эту статью в Markdown·Поделиться в Telegram
Следующий материалGoogle Cloud Data Agent Kit: данные для coding-агентов