Claude Apps Gateway: SSO and Spend Caps for Claude Code on AWS

If you run a dev team of any size, you know how this goes. Claude Code rolls out. Developers add their API keys to .bash_profile. Usage explodes. Finance asks how much you spent last month. Someone leaves. Nobody is sure if their credential is still active somewhere. On June 29, Anthropic shipped a direct answer: the Claude Apps Gateway, a self-hosted control plane that replaces scattered API credentials with corporate SSO and real spend controls.

What It Actually Does

The gateway sits between your developers’ Claude Code clients and your model provider—Amazon Bedrock, Google Cloud, Microsoft Foundry, or the Anthropic API directly. Developers sign in with your corporate identity provider (Okta, Google Workspace, Microsoft Entra ID, or any OIDC-compliant IdP) instead of holding cloud credentials. The gateway holds the upstream credential and issues short-lived tokens. When someone leaves, deprovision them in the IdP. Their gateway access expires within the session TTL—one hour by default. No API key hunting required.

It ships inside the same claude binary your team already uses. Run it with claude gateway --config gateway.yaml on a Linux host backed by PostgreSQL 14+.

Getting It Running

The setup is five steps: register an OIDC application in your IdP, provision a Postgres database, write a gateway.yaml, deploy with Docker Compose (or Kubernetes/Cloud Run for production), and verify sign-in. The minimal config covers most setups:

listen:
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}
  ttl_hours: 1

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {}

auto_include_builtin_models: true

One requirement worth noting: the gateway must resolve only to a private IP address. Claude Code rejects public IPs at /login as a security control—a gateway that can push managed settings to developer machines cannot be reachable from the public internet.

Push these two settings to developer machines via MDM and they connect automatically on next boot:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}

Spend Controls That Actually Work

The gateway’s spend limits are its most immediately useful feature for most teams. Set caps at the organization, group, or individual level through an admin API—and the gateway enforces them live on every inference request. A developer who hits their cap gets a 429 until the period resets or an admin raises the limit.

# $500/month org-wide default
curl -X POST https://claude-gateway.internal.example.com/v1/organizations/spend_limits \
  -H "x-api-key: $ADMIN_KEY" \
  -d '{"scope": {"type": "organization"}, "amount": "50000", "period": "monthly"}'

# $100/day cap for contractors
curl -X POST https://claude-gateway.internal.example.com/v1/organizations/spend_limits \
  -H "x-api-key: $ADMIN_KEY" \
  -d '{"scope": {"type": "rbac_group", "rbac_group_id": "contractors"}, "amount": "10000", "period": "daily"}'

The spend API mirrors Anthropic’s public Admin API contract, so existing tooling targeting that API works by swapping the base URL. One caveat: these limits are circuit breakers, not billing sources of truth. Reconcile actual spend against your Bedrock or GCP invoices—the gateway estimates from token counts at list price.

What You Give Up

A few features do not work through the gateway, and it is worth knowing them before you start the migration:

• Web search: Disabled. The CLI cannot verify which upstream supports it, so it turns web search off for all gateway sessions.
• 1-hour prompt cache TTL: Unavailable. You get the standard 5-minute TTL. Not every upstream the gateway routes to supports the extended TTL, so it is omitted.
• CI service tokens: Not supported. The gateway requires the browser device flow. There is no machine credential path. CI jobs must authenticate directly against your cloud provider. This is the most significant limitation for teams hoping to centralize everything.
• Admin UI: None. Configuration is YAML only—redeploy to change settings.
• SAML or LDAP: Not supported. OIDC-compliant providers only.

Gateway or Claude Enterprise?

Before you start deploying, check if you actually need the gateway. If your organization does not have a data-residency requirement that forces inference through Bedrock or GCP, Claude Enterprise (via the claude.ai admin console) is probably the better choice. You get SCIM provisioning, Claude Code on web and mobile, and simpler setup—no self-hosted container to run.

The gateway is specifically for organizations where inference traffic must stay in their cloud environment. If that is you, it is the right call. If it is not, Claude Enterprise gives you most of the same governance features with significantly less operational overhead.

The Part It Does Not Solve

Mitch Ashley at The Futurum Group put it plainly: "This makes one coding tool manageable at scale. It does not govern what agents do." The gateway solves credential sprawl and spend visibility. It does not tell you what an agent running in Auto mode actually did with the production credentials it was handed. As Claude Code increasingly operates autonomously—running bash commands, modifying files, calling external APIs—the gap between access governance and behavioral governance is where the next set of hard problems lives.

For now, the gateway is a clean solution to a real problem. If you are running Claude Code across a team of more than a dozen developers on Bedrock or GCP, it is worth an afternoon to deploy. The official announcement and full documentation are the right starting points. AWS teams should also check the AWS blog post; GCP teams the Google Cloud announcement. The spend limits documentation is worth bookmarking before your first deployment.