Cloud Workstations + GeminiClaw: ambiente seguro para desenvolver agentes em produção
Ambiente local não garante reprodutibilidade nem segurança quando o agente acessa dados corporativos reais. Veja como times de engenharia usam Cloud Workstations Gateway + GeminiClaw para desenvolver agentes com isolamento zero-trust, sem credencial no laptop.
Fabiano Brito
CEO & Founder
Desenvolver um agente de IA em modo local funciona até o momento em que ele precisa acessar um banco de dados de produção, um ERP corporativo ou um data warehouse com dados sensíveis. Nesse ponto, o setup local expõe três problemas que não têm solução elegante: credenciais precisam sair do cofre e entrar no laptop, o ambiente do desenvolvedor nunca é idêntico ao de produção, e qualquer novo membro do time leva dias para replicar o setup.
Este post mostra como times de engenharia de IA resolvem esses três problemas de uma vez usando Google Cloud Workstations como ambiente padronizado e o GeminiClaw como runtime de agentes — ambos rodando dentro da VPC corporativa, atrás de um gateway gerenciado com zero-trust nativo.
O problema: por que ambiente local não escala para agentes corporativos
Um agente de IA é diferente de uma API CRUD. Ele executa chamadas encadeadas a múltiplos sistemas, mantém contexto entre passos, toma decisões baseadas em dados ao vivo e pode — em caso de bug — fazer coisas destrutivas em sistemas reais. Esse perfil de execução exige garantias que o laptop do desenvolvedor não dá.
- ✗Credenciais de serviço salvas em
~/.envou hardcoded nos testes - ✗VPN instável faz o agente perder conexão no meio de uma task de 40 min
- ✗Versão de Python/Node/SDK diverge entre devs e produção
- ✗Onboarding leva 2–3 dias de setup; novo dev testa em ambiente diferente
- ✗Logs de execução do agente ficam no laptop — sem auditoria centralizada
- ✓Workstation acessa secrets via Workload Identity — sem credencial em texto no disco
- ✓GeminiClaw roda dentro da VPC: acesso direto a BigQuery, AlloyDB, APIs internas
- ✓Imagem padronizada: mesmo runtime em dev e produção
- ✓Novo dev operacional em menos de 1h (boot da workstation, autenticar com Google)
- ✓Logs do loop de agentes centralizam no Cloud Logging com estrutura auditável
Como o Cloud Workstations Gateway funciona
O Cloud Workstations provisiona VMs de desenvolvimento gerenciadas pelo Google Cloud, cada uma com um ambiente de IDE completo (VS Code Server, JetBrains Gateway, terminal). O componente crítico para times corporativos é o gateway gerenciado: um controlador que roteia o tráfego de acesso à workstation sem expor a VM diretamente à internet.
O dev acessa a workstation via Identity-Aware Proxy. O BeyondCorp verifica identidade do usuário e postura do dispositivo antes de autorizar. Sem VPN. Sem IP estático liberado no firewall.
Com o modo private gateway, a VM da workstation vive exclusivamente na VPC interna. O único caminho de acesso é via gateway controlado — ideal para ambientes com VPC Service Controls habilitado.
Disco da workstation e dados em trânsito podem ser encriptados com CMEK no Cloud KMS. Para setores regulados (financeiro, saúde, jurídico), isso simplifica o atendimento a requisitos de soberania de dados.
A workstation herda uma Service Account via Workload Identity Federation. O GeminiClaw usa Application Default Credentials automaticamente — nenhum arquivo de chave JSON precisa existir no disco da VM.
GeminiClaw dentro da workstation: o loop de agentes na VPC
O GeminiClaw é um orquestrador multi-agente local-first: ele roda como processo no ambiente onde é instalado, sem depender de cloud central de terceiros para o loop de execução. Isso torna o Cloud Workstations o ambiente natural para ele em cenários corporativos.
Quando o GeminiClaw roda dentro de uma Cloud Workstation na VPC corporativa, o loop de agentes ganha acesso direto a todos os sistemas internos sem precisar de túnel externo:
Dev (navegador) → IAP/BeyondCorp → Cloud Workstations Gateway
↓
VM na VPC (GeminiClaw rodando)
↓
BigQuery · AlloyDB · APIs internas · Secret ManagerO agente em desenvolvimento não precisa de mock de dados nem de ambiente de staging separado para testar integrações reais. Ele acessa os sistemas de desenvolvimento/homologação diretamente, com as mesmas credenciais e permissões que terá em produção — controladas via IAM, não via arquivo local.
Casos de uso: onde essa combinação faz diferença
Times de fintech e bancos desenvolvendo agentes de análise de crédito, KYC e AML. A workstation acessa BigQuery com dados reais de homologação; CMEK garante conformidade com Bacen; VPC Service Controls bloqueia exfiltração. O agente GeminiClaw é testado contra dados reais — sem copiar CSV para o laptop.
Engenheiro em São Paulo, Lisboa e Buenos Aires acessam a mesma workstation de referência via BeyondCorp. Sem disparidade de ambiente entre timezones. O estado do GeminiClaw (sessões, memória de agentes, logs) fica na VM — não se perde quando o dev fecha o laptop.
Novo engenheiro recebe acesso IAM + IAP e inicia a workstation. O GeminiClaw e todas as dependências estão na imagem customizada. Em menos de 1h está debugando o primeiro agente — sem instalar Docker, configurar VPN ou pedir chaves de serviço.
Projetos com dados de prontuário eletrônico ou informações de pacientes. A workstation nunca persiste dados no laptop do dev. CMEK com chave gerenciada pelo cliente satisfaz exigências de LGPD e HIPAA. O agente GeminiClaw processa e retorna — nada sai da VPC.
Como montar o ambiente: checklist prático
Provisionar o cluster em modo private (sem IP público) dentro da VPC de desenvolvimento. Habilitar Cloud NAT para saída controlada. Anotar o endpoint do gateway para configurar IAP.
Criar Access Level que exige dispositivo gerenciado (ou Chrome verificado) + identidade corporativa. Vincular ao túnel IAP do gateway da workstation.
A partir da imagem base do Cloud Workstations, adicionar Node.js, GeminiClaw e dependências do projeto. Publicar no Artifact Registry privado. A Workstation Configuration aponta para essa imagem.
A Service Account da workstation recebe apenas as permissões que o agente precisa (BigQuery Data Viewer, Secret Manager Accessor, etc.). O GeminiClaw usa ADC automaticamente — sem GOOGLE_APPLICATION_CREDENTIALS setado.
Criar um Service Perimeter que inclua a VPC da workstation e os serviços GCP acessados pelo agente (BigQuery, Cloud Storage, Secret Manager). Qualquer tentativa de acesso fora do perímetro é bloqueada — mesmo com credencial válida.
O laptop do dev nunca toca os dados. O agente executa onde os dados já estão — e só quem tem identidade verificada chega até lá.
O que cada camada de segurança garante
| Camada | O que protege | Relevante para |
|---|---|---|
| IAP + BeyondCorp | Acesso ao ambiente de desenvolvimento | Todo time; elimina VPN |
| Private Gateway | VM sem IP público — sem superfície de ataque externa | Regulados, financeiro, saúde |
| Workload Identity | Zero credential files no disco da workstation | Todo time que usa serviços GCP |
| CMEK | Encriptação do disco e dados com chave do cliente | LGPD, HIPAA, PCI-DSS, Bacen |
| VPC Service Controls | Bloqueia exfiltração mesmo com credencial comprometida | Dados altamente sensíveis (PII, PHI) |
Quer montar esse ambiente no seu time?
A Autenticare implementa Cloud Workstations + GeminiClaw com todas as camadas de segurança configuradas para o contexto do seu setor. Incluímos imagem customizada, IAP policy, VPC Service Controls e treinamento do time — tudo em ciclo de 2 semanas.