37  Introducing the Claude Apps Gateway for Bedrock and Google Cloud

37.1 Overview

On June 29, 2026, Anthropic introduced the Claude Apps Gateway — a self-hosted control plane for Claude Code that gave organizations centralized management of their agentic coding infrastructure without surrendering control of their data or authentication to a third party. The Gateway was a single stateless container backed by PostgreSQL, deployable in any environment, and capable of routing Claude Code traffic to the Claude API, Amazon Bedrock, or Google Cloud with intelligent failover.

The problem the Gateway solved was specific and acute. As Claude Code adoption exploded inside enterprises — with hundreds or thousands of developers running agentic coding sessions — IT and security teams faced a management challenge. Each developer’s machine was making API calls, potentially holding credentials, and generating cost. Without a central control plane, administrators had no way to enforce policy, attribute costs, or ensure that traffic routed through approved endpoints.

The Claude Apps Gateway addressed this with an elegant architecture: a lightweight, stateless intermediary that sat between Claude Code clients and the inference endpoints, enforcing policy, managing authentication, and providing visibility — all without requiring organizations to send their data to Anthropic unless they explicitly chose to.

37.2 What the Gateway Is

The Claude Apps Gateway was, at its core, a self-hosted control plane. It was not an inference engine — it did not run models. Instead, it managed the flow of requests from Claude Code clients to whatever inference backend the organization chose.

37.2.1 Architecture

┌──────────────────────────────────────────────────────────┐
│                    Developer Machines                      │
│                                                           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐ │
│  │Claude    │  │Claude    │  │Claude    │  │Claude    │ │
│  │Code      │  │Code      │  │Code      │  │Code      │ │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘ │
│       │             │             │             │        │
└───────┼─────────────┼─────────────┼─────────────┼────────┘
        │             │             │             │
        ▼             ▼             ▼             ▼
┌──────────────────────────────────────────────────────────┐
│              Claude Apps Gateway (Self-Hosted)            │
│                                                           │
│  ┌──────────────────────────────────────────────────────┐│
│  │  Stateless Container                                  ││
│  │  • OIDC SSO        • Policy Enforcement              ││
│  │  • Role-Based Access • Cost Attribution              ││
│  │  • Spend Caps      • Telemetry (OTLP)               ││
│  └───────────────────────┬──────────────────────────────┘│
│                          │                                │
│              ┌───────────┼───────────┐                   │
│              ▼           ▼           ▼                   │
│         ┌────────┐  ┌────────┐  ┌────────┐              │
│         │PostgreSQL│  │Routing │  │Failover│              │
│         │(State)  │  │Logic   │  │Engine  │              │
│         └────────┘  └────────┘  └────────┘              │
└──────────────────────────────────────────────────────────┘
                 │             │             │
                 ▼             ▼             ▼
          ┌──────────┐  ┌──────────┐  ┌──────────┐
          │Claude API│  │ Bedrock  │  │Google    │
          │          │  │          │  │Cloud     │
          └──────────┘  └──────────┘  └──────────┘

The Gateway consisted of:

  • A single stateless container: The application logic ran in a stateless container that could be deployed anywhere — on-premises, in a private VPC, or in any cloud.
  • A PostgreSQL database: All state — user sessions, policy configurations, cost attribution data — was stored in a standard PostgreSQL database that the organization controlled.

This separation of stateless compute and stateful storage meant the Gateway could be scaled horizontally (run multiple container instances behind a load balancer) while maintaining a single source of truth in PostgreSQL.

37.3 Key Features

37.3.1 OIDC Single Sign-On

The Gateway integrated with any OIDC-compliant identity provider, providing SSO authentication for Claude Code users. Rather than each developer managing their own API credentials, authentication flowed through the corporate identity provider.

# Gateway OIDC configuration
auth:
  oidc:
    issuer: https://login.contoso.com
    client_id: claude-apps-gateway
    client_secret: ${OIDC_CLIENT_SECRET}
    scopes:
      - openid
      - profile
      - groups

This ensured that:

  • Access was governed by existing identity policies (MFA, conditional access, device compliance).
  • Departed employees lost access immediately upon deprovisioning.
  • Audit trails tied Claude Code activity to authenticated identities.

37.3.2 Centrally Enforced Policy

The Gateway allowed administrators to define policies that were enforced at the control-plane level, not on individual developer machines. This was a significant security improvement over distributing configuration files to each machine.

Policies could control:

  • Which models were allowed.
  • Maximum token limits per session.
  • Allowed and blocked file paths.
  • Tool use permissions.
  • Rate limits per user or group.
Note

The key insight behind centrally enforced policy was that client-side configuration is inherently insecure — a developer can always modify or bypass settings on their own machine. By enforcing policy at the Gateway level, the guarantee was cryptographic: requests that didn’t comply with policy were rejected before they ever reached an inference endpoint.

37.3.3 Role-Based Access Control

The Gateway supported role-based access control (RBAC), allowing administrators to define fine-grained permissions for different user populations:

Role Permissions Typical Users
Admin Full configuration, analytics, policy management IT administrators
Group Lead View group analytics, set group policies Engineering managers
Developer Use Claude Code, view own analytics All developers
Auditor Read-only access to logs and analytics Security/compliance

37.3.4 Per-User Cost Attribution

Every API call routed through the Gateway was attributed to the authenticated user, enabling precise cost tracking and chargeback:

{
  "user": "alice@contoso.com",
  "group": "payments-team",
  "model": "claude-sonnet-4-6",
  "input_tokens": 125000,
  "output_tokens": 8000,
  "cost_usd": 0.54,
  "timestamp": "2026-06-29T14:30:00Z",
  "session_id": "sess_abc123"
}

This data was stored in PostgreSQL and could be queried through the Gateway’s analytics interface or exported via API to FinOps tools.

37.4 No Long-Lived Secrets on Machines

One of the Gateway’s most important security features was the elimination of long-lived secrets on developer machines. In a traditional setup, each developer’s machine held an API key — a static credential that could be stolen, leaked, or misused.

With the Gateway, developer machines held no API keys at all. Instead:

  1. The developer authenticated to the Gateway using SSO (short-lived OIDC tokens).
  2. The Gateway held the backend credentials (Bedrock or Google Cloud credentials).
  3. The Gateway injected authentication into each request before forwarding it to the backend.

This meant that even if a developer’s laptop was compromised, the attacker gained no credentials that could be used to call Claude APIs directly. The most they could do was impersonate the developer through the Gateway — which would be visible in audit logs and subject to policy enforcement.

Tip

For organizations with strict security requirements (e.g., those subject to SOC 2, FedRAMP, or similar frameworks), the elimination of long-lived secrets on endpoints was often the single most compelling reason to deploy the Gateway. It transformed API key management from a per-device problem to a centralized, controlled process.

37.5 Managed Settings Distributed at Sign-In

The Gateway distributed managed settings to Claude Code clients at sign-in time. This meant that when a developer launched Claude Code and authenticated through SSO, the Gateway pushed down the current configuration:

{
  "managed_settings": {
    "model": {
      "default": "claude-sonnet-4-6",
      "allowed": ["claude-sonnet-4-6", "claude-haiku-4-5"]
    },
    "limits": {
      "max_tokens_per_session": 2000000,
      "max_sessions_per_day": 50
    },
    "tools": {
      "bash": { "allowed": true },
      "file_write": { "allowed_paths": ["/home/*/projects/*"] }
    },
    "policy_version": "2026-06-29-v3"
  }
}

These settings were enforced by Claude Code itself AND by the Gateway, providing defense in depth. If a developer modified local settings to bypass restrictions, the Gateway would still reject non-compliant requests.

37.6 Telemetry via OTLP

The Gateway emitted telemetry using the OpenTelemetry Protocol (OTLP), the industry standard for observability data. This meant Gateway telemetry could be ingested by any OTLP-compatible observability platform:

Platform Integration
Datadog Native OTLP ingestion
Honeycomb Native OTLP ingestion
Grafana Cloud Native OTLP ingestion
New Relic Native OTLP ingestion
Jaeger Distributed tracing 
# Gateway OTLP telemetry configuration
telemetry:
  otlp:
    endpoint: https://otlp.contoso.com:4317
    headers:
      authorization: "Bearer ${OTLP_TOKEN}"
    metrics:
      enabled: true
      interval: 60s
    traces:
      enabled: true
      sampling_rate: 0.1
    logs:
      enabled: true

This provided end-to-end visibility into Claude Code usage: which users were active, what models they were using, how long sessions lasted, error rates, and latency — all correlatable with other application and infrastructure telemetry.

37.7 Multi-Backend Routing with Failover

The Gateway could route requests to multiple inference backends with intelligent failover:

# Gateway routing configuration
routing:
  primary:
    provider: bedrock
    region: us-east-1
    model_mapping:
      claude-sonnet-4-6: anthropic.claude-sonnet-4-6
  failover:
    - provider: google_cloud
      region: us-central1
      trigger:
        error_rate: 0.05
        latency_p99: 5000
    - provider: claude_api
      trigger:
        primary_down: true

The failover logic monitored backend health and automatically rerouted traffic if:

  • The primary backend returned errors above a threshold.
  • Latency exceeded acceptable bounds.
  • The primary backend was completely unavailable.

This provided resilience that individual API connections could not. If Bedrock had an outage, Claude Code sessions would transparently failover to Google Cloud or the Claude API without developers even noticing.

37.8 Spend Caps

The Gateway implemented multi-granularity spend caps — budget limits that could be set at the organization, group, or individual user level, across daily, weekly, or monthly time windows:

Granularity Time Window Example Use Case
Organization Monthly Total budget cap
Organization Daily Prevent runaway spend
Group Weekly Team budget allocation
Group Monthly Department chargeback
User Daily Individual fair-use limit
User Monthly Per-developer budget

When a spend cap was approached, the Gateway could:

  • Warn: Notify the user and admin.
  • Throttle: Reduce the rate of allowed requests.
  • Block: Reject requests entirely until the next period.

37.9 Data Privacy: Nothing Goes to Anthropic Unless Configured

A critical design principle of the Gateway was that it did not send data to Anthropic unless explicitly configured to route to the Claude API.

If an organization configured the Gateway to route to Bedrock or Google Cloud, no data flowed to Anthropic at all — not usage data, not conversation content, not telemetry. The Gateway was entirely under the organization’s control, and Anthropic had no visibility into its operation.

This was a significant differentiator for organizations with strict data privacy requirements. They could use Claude Code — Anthropic’s product — while ensuring that Anthropic itself had zero access to their data.

Note

The data privacy guarantee was architectural, not policy-based. The Gateway was open source (or source-available), allowing organizations to audit the code and verify that no data was exfiltrated. This verifiability was essential for high-trust environments.

37.10 Deployment Example

A typical deployment of the Claude Apps Gateway looked like this:

# Deploy the Gateway as a container
docker run -d \
  --name claude-gateway \
  -p 8443:8443 \
  -e DATABASE_URL=postgresql://gateway:password@db.internal:5432/gateway \
  -e OIDC_ISSUER=https://login.contoso.com \
  -e OIDC_CLIENT_ID=claude-gateway \
  -e OIDC_CLIENT_SECRET=${OIDC_SECRET} \
  -e BEDROCK_REGION=us-east-1 \
  -v /etc/gateway/policies.yaml:/etc/gateway/policies.yaml \
  ghcr.io/anthropic/claude-apps-gateway:latest

# Configure Claude Code clients to use the Gateway
claude config set gateway.url https://gateway.contoso.com:8443
claude config set gateway.auth sso

37.11 Key Takeaways

  • Self-hosted control plane for Claude Code. The Gateway is a single stateless container + PostgreSQL that centralizes management of Claude Code infrastructure.
  • OIDC SSO eliminates per-machine API keys. Authentication flows through the corporate identity provider, with no long-lived secrets stored on developer machines.
  • Policy is enforced centrally, not client-side. The Gateway rejects non-compliant requests before they reach inference endpoints — a cryptographic guarantee, not a client-side suggestion.
  • Per-user cost attribution enables chargeback. Every API call is attributed to the authenticated user and group, stored in PostgreSQL, and exportable to FinOps tools.
  • Managed settings are pushed at sign-in. Current configuration is distributed to clients when they authenticate, ensuring policy compliance without manual distribution.
  • OTLP telemetry integrates with existing observability stacks. Datadog, Honeycomb, Grafana Cloud, and any OTLP-compatible platform can ingest Gateway metrics, traces, and logs.
  • Multi-backend routing with failover provides resilience. Route to Claude API, Bedrock, or Google Cloud with automatic failover on errors, latency, or outages.
  • Spend caps at multiple granularities. Daily/weekly/monthly limits at org/group/user levels, with warn/throttle/block actions.
  • Nothing goes to Anthropic unless you route to the Claude API. When configured for Bedrock or Google Cloud, the Gateway sends zero data to Anthropic — an architectural, auditable guarantee.
  • The Gateway is the right choice for organizations that need centralized control of Claude Code at scale without surrendering data governance to a third party.