Autenticare
Agentic Engineering · · 8 min

Cloud Workstations + GeminiClaw: a secure environment for building AI agents in production

A local environment can't guarantee reproducibility or security when an agent is hitting real corporate data. See how engineering teams use Cloud Workstations Gateway + GeminiClaw to develop agents with zero-trust isolation — no credentials on the laptop.

Fabiano Brito

Fabiano Brito

CEO & Founder

Cloud Workstations + GeminiClaw: a secure environment for building AI agents in production
TL;DR Local environments break the moment an agent needs real corporate data: credentials on laptops, flaky VPNs, three-day onboarding. Cloud Workstations solves the environment; GeminiClaw runs the agent loop inside it — everything in the VPC, no credential leakage, with IAP + BeyondCorp enforced at the gateway.

Developing an AI agent locally works fine until the moment it needs to hit a production database, a corporate ERP, or a data warehouse with sensitive data. At that point, the local setup reveals three problems with no clean solution: credentials have to leave the vault and land on the laptop, the developer's environment never matches production, and onboarding a new team member takes days of painful setup.

This post shows how AI engineering teams solve all three at once using Google Cloud Workstations as a standardized environment and GeminiClaw as the agent runtime — both running inside the corporate VPC, behind a managed gateway with native zero-trust.


The problem: why local environments don't scale for enterprise agents

An AI agent is fundamentally different from a CRUD API. It executes chained calls across multiple systems, maintains context between steps, makes decisions based on live data, and can — if there's a bug — do destructive things in real systems. That execution profile demands guarantees a laptop simply cannot provide.

Local environment — real problems
  • Service credentials saved in ~/.env or hardcoded in tests
  • Unstable VPN drops the agent mid-task after 40 minutes of work
  • Python/Node/SDK versions diverge between developers and production
  • Onboarding takes 2–3 days of setup; new hire tests in a different environment
  • Agent execution logs stay on the laptop — no centralized audit trail
Cloud Workstations + GeminiClaw — what changes
  • Workstation accesses secrets via Workload Identity — no credential files on disk
  • GeminiClaw runs inside the VPC: direct access to BigQuery, AlloyDB, internal APIs
  • Standardized image: same runtime in dev and production
  • New developer productive in under 1 hour (start workstation, authenticate with Google)
  • Agent loop logs centralize in Cloud Logging with auditable structure

How the Cloud Workstations Gateway works

Cloud Workstations provisions managed development VMs on Google Cloud, each with a full IDE environment (VS Code Server, JetBrains Gateway, terminal). The critical component for enterprise teams is the managed gateway: a controller that routes access traffic to the workstation without exposing the VM directly to the internet.

1
IAP + BeyondCorp on workstation access

Developers access the workstation via Identity-Aware Proxy. BeyondCorp verifies user identity and device posture before granting access. No VPN. No static IP allowlisted in the firewall.

2
Private Gateway — the VM has no public IP

With private gateway mode, the workstation VM lives exclusively in the internal VPC. The only access path is through the controlled gateway — ideal for environments with VPC Service Controls enabled.

3
CMEK — customer-managed encryption keys

The workstation disk and data in transit can be encrypted with CMEK in Cloud KMS. For regulated sectors (financial, healthcare, legal), this simplifies compliance with data sovereignty requirements.

4
Workload Identity — no credential files

The workstation inherits a Service Account via Workload Identity Federation. GeminiClaw uses Application Default Credentials automatically — no JSON key file needs to exist on the VM disk.

⚠️ Common pitfall Teams that enable Cloud Workstations but keep service credentials as exported JSON files lose 80% of the security benefit. The correct pattern is Workload Identity + Application Default Credentials: the workstation authenticates by identity, not by key.

GeminiClaw inside the workstation: the agent loop in the VPC

GeminiClaw is a local-first multi-agent orchestrator: it runs as a process in whatever environment it's installed in, without relying on a third-party central cloud for the execution loop. This makes Cloud Workstations the natural home for it in enterprise scenarios.

When GeminiClaw runs inside a Cloud Workstation in the corporate VPC, the agent loop gains direct access to all internal systems without needing an external tunnel:

Dev (browser) → IAP/BeyondCorp → Cloud Workstations Gateway

                              VM in VPC (GeminiClaw running)

                    BigQuery · AlloyDB · Internal APIs · Secret Manager

The agent under development doesn't need data mocks or a separate staging environment to test real integrations. It accesses development/staging systems directly, with the same credentials and permissions it will have in production — controlled via IAM, not local files.


Use cases: where this combination makes a real difference

🏦 Financial agents with sensitive data

Teams at fintechs and banks building credit analysis, KYC, and AML agents. The workstation accesses BigQuery with real staging data; CMEK ensures regulatory compliance; VPC Service Controls block exfiltration. The GeminiClaw agent is tested against real data — without copying a CSV to a laptop.

🌍 Distributed and remote teams

Engineers in São Paulo, Lisbon, and Buenos Aires all access the same reference workstation via BeyondCorp. No environment drift across timezones. GeminiClaw state (sessions, agent memory, logs) lives in the VM — it doesn't vanish when the developer closes their laptop.

⚡ Developer onboarding in hours, not days

A new engineer receives IAM + IAP access and starts the workstation. GeminiClaw and all dependencies are baked into the custom image. In under an hour they're debugging their first agent — without installing Docker, configuring VPN, or requesting service keys.

🏥 Agents in healthcare and regulated data

Projects handling electronic health records or patient data. The workstation never persists data on the developer's laptop. CMEK with customer-managed keys satisfies LGPD and HIPAA requirements. The GeminiClaw agent processes and returns — nothing leaves the VPC.


What each security layer guarantees

Layer What it protects Relevant for
IAP + BeyondCorp Access to the development environment Every team; eliminates VPN
Private Gateway VM with no public IP — no external attack surface Regulated, financial, healthcare
Workload Identity Zero credential files on the workstation disk Every team using GCP services
CMEK Disk and data encryption with customer-owned key LGPD, HIPAA, PCI-DSS, Bacen
VPC Service Controls Blocks exfiltration even with a compromised credential Highly sensitive data (PII, PHI)
The developer's laptop never touches the data. The agent runs where the data already lives — and only those with verified identity can get there.

Autenticare — Google Cloud Partner

Want to set up this environment for your team?

Autenticare implements Cloud Workstations + GeminiClaw with all security layers configured for your sector's requirements. We include a custom image, IAP policy, VPC Service Controls, and team training — delivered in a 2-week cycle.


Also read