Sudipta Deb
Founder of Technical Potpourri, Co-Founder of Shrey Tech, Enterprise Cloud Architect
Managing Claude Code across your organization shouldn't require per-developer cloud credentials, manual laptop configuration, and custom tooling just to track who spent what. Yet until now, that's exactly what enterprises faced.
Individual developers could point CLAUDE_CODE_USE_VERTEX=1 at their Google Cloud project with a simple roles/aiplatform.user grant. But rolling out to a team meant:
- Identity debt: Managing per-developer credentials, service account keys, and API tokens on every machine
- Configuration chaos: Pushing
managed-settings.jsonacross dozens of laptops via MDM, praying they stay in sync - Cost blindness: No visibility into per-user spending or ability to enforce spend caps
- Offboarding risk: Manually revoking access across multiple developers' machines when someone leaves
The Claude apps gateway solves all of this by inserting a single, stateless control plane between your developers and Google Cloud—letting you govern identity, policy, telemetry, and cost from one place.
What Is the Claude Apps Gateway?
The Claude apps gateway is a self-hosted service, shipped with the same claude binary, that sits directly between your local Claude Code clients and Google Cloud. It's a containerized application that you deploy once (typically on Cloud Run) and point all your developers through.
Think of it as an enterprise reverse proxy for AI inference. It handles:
- Identity & SSO — OIDC integration with Google Workspace, Entra ID, Okta, or any standards-compliant provider
- Policy enforcement — Role-based access control (RBAC) applied server-side on every request
- Usage telemetry — Per-user attribution sent to your observability stack via OTLP
- Spend management — Daily, weekly, and monthly token limits per user, group, or org
- Credential routing — Gateway holds the upstream credential (no secrets on dev machines)
5 Practical Use Cases
1. Google Workspace SSO + Zero Secrets on Laptops
Configure the gateway to authenticate developers against your Google Workspace OIDC provider. Developers sign in once with their work email; the gateway issues a short-lived session. No API keys, service account files, or ANTHROPIC_VERTEX_PROJECT_ID environment variables ever touch their laptop.
oidc:
issuer: https://accounts.google.com
client_id: your-oauth-app-id.apps.googleusercontent.com
allowed_email_domains: [yourcompany.com]Benefit: Onboarding is adding a user to an IdP group. Offboarding is removing them—next session refresh fails, and that developer's access is instantly revoked.
2. Role-Based Model Access
Define RBAC policies in gateway.yaml once. Different teams get different Claude models and tool permissions, enforced server-side on every /v1/messages request.
policies:
- match:
groups: [engineering]
availableModels:
- claude-opus-4-6
- claude-sonnet-4-6
- match:
groups: [design]
availableModels:
- claude-sonnet-4-6Any changes to policies are reflected across your entire developer fleet within the hour—no client updates required.
3. Per-Developer Cost Attribution & Spend Caps
Every inference request stamps a usage metric carrying the verified email and group claims from the session JWT. The gateway relays this over OTLP (OpenTelemetry Protocol) to your observability collector—Cloud Monitoring, Datadog, Grafana, or whatever you use.
Set spend limits via the admin API:
curl -X POST https://your-gateway.internal/api/spend-limits \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-d '{
"user": "alice@company.com",
"daily_limit_usd": 50,
"monthly_limit_usd": 1000
}'When a user hits the cap, the gateway returns HTTP 429 (Too Many Requests). Costs are metered at list price, not discounted rates, so treat them as a runaway-usage guardrail.
4. Secure Cloud Run Deployment with VPC Isolation
Deploy the gateway as a stateless Cloud Run service with internal ingress only. Developers connect over your corporate network (VPN, Interconnect, or private GCP network), never over the internet.
gcloud run deploy claude-gateway \
--service-account=claude-gateway@${PROJECT_ID}.iam.gserviceaccount.com \
--set-secrets=/etc/claude/gateway.yaml=gateway-config:latest \
--ingress=internalThe gateway authenticates to Agent Platform using the Cloud Run service account's Workload Identity—no service account keys needed.
5. Multi-Region Failover & Global Routing
Configure the gateway to route through multiple upstreams with automatic failover. If us-east5 Agent Platform hits quota or returns 5xx/429, traffic automatically fails over to your next configured region.
upstreams:
- provider: vertex
region: us-east5
project_id: my-project
- provider: vertex
region: us-west1
project_id: my-projectInference stays in your GCP project; quota, DPA compliance, and billing all remain unchanged.
Deployment in 4 Steps
Step 1: GCP Foundation
- Enable Agent Platform, Cloud SQL, and Secret Manager APIs
- Create a
claude-gatewayservice account withroles/aiplatform.user - Provision a small Cloud SQL Postgres instance for state
- Register an OAuth 2.0 Web application client in Google Cloud Console for OIDC
Step 2: Configure the Gateway
Write gateway.yaml pointing to your OIDC issuer, Postgres database, and Agent Platform:
listen:
port: 8080
public_url: https://claude-gateway.example.internal
oidc:
issuer: https://accounts.google.com
client_id: your-client-id.apps.googleusercontent.com
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [yourcompany.com]
upstreams:
- provider: vertex
region: us-east5
project_id: your-project
auth: {} # Uses Cloud Run service account (no keys)Store this config, the OIDC secret, Postgres URL, and JWT signing key in Secret Manager.
Step 3: Deploy to Cloud Run
gcloud run deploy claude-gateway \
--service-account=claude-gateway@${PROJECT_ID}.iam.gserviceaccount.com \
--set-secrets=/etc/claude/gateway.yaml=gateway-config:latest \
--ingress=internalStep 4: Onboard Developers
Push managed-settings.json to developer machines via MDM (or manually for trials):
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.example.internal"
}On next Claude Code startup, developers authenticate to Google Workspace, confirm a device code in their browser, and they're online.
Why This Matters for Technical Architects
For Claude and Google Cloud architects:
- Centralized governance: One
gateway.yamlfile replaces dozens of per-developer configs - Compliance-ready: Per-user attribution, audit logs, and spend limits satisfy enterprise security reviews
- Operational simplicity: Stateless deployment scales horizontally on Cloud Run; no agents or sidecars to manage
- Data residency: Inference never leaves your GCP project—Agent Platform, quota, and DPA coverage all intact
For platform engineers rolling out AI to teams:
- Self-service identity: Developers onboard themselves through OIDC; no manual credential provisioning
- Cost control: Set spend caps per user or team, metered in real-time against Cloud SQL ledger
- Policy as code: Update RBAC, model lists, and tool permissions without touching developer machines
- Observability built-in: Every token request carries user email and group claims for billing, auditing, and alerts
Next Steps
- Review the full docs: The complete
gateway.yamlreference, GCP setup guide, and GKE deployment instructions are in the Claude apps gateway documentation. - Start small: Spin up a test gateway on Cloud Run, onboard 2–3 engineers, validate the flow, then scale to your team.
- Integrate telemetry: Wire OTLP output to your existing monitoring stack (Cloud Monitoring, Datadog, Grafana) for per-user dashboards and alerts.
- Enforce policy: Once you see usage patterns, lock down model access by group, set spend limits, and iterate based on feedback.
The gateway is available now in the Claude binary. Happy building!
Resources
Disclaimer
This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.
0 Comments