Self-hosted governance next to the Claude apps gateway: a co-deployment guide

Anthropic shipped the Claude apps gateway in late June 2026. It is a self-hosted service bundled inside the claude binary (v2.1.195+). You run it with claude gateway --config gateway.yaml, back it with PostgreSQL, and it puts OIDC sign-in in front of your Claude Code fleet: corporate IdP sessions instead of locally managed API keys. That is a real step forward. For teams that run Claude Code against Bedrock, Vertex, Foundry, or the Anthropic API directly, the gateway centralizes identity, model access, and spend controls behind a single config file.

This post is about what happens next. Your AI estate is almost certainly more than Claude. You probably run MCP servers from multiple vendors. You may have OpenAI or Gemini workloads, self-hosted inference through vLLM or Ollama, CI pipelines that never see a browser, and agent frameworks that delegate across providers. The apps gateway is Claude-only and OIDC-only. That is a scope decision, not a defect — but it means the governance question is only partially answered.

The co-deployment model described here puts a self-hosted governance platform alongside the gateway, reading from both the gateway’s telemetry and the rest of your agent infrastructure. Complementary, not competitive: the gateway handles authentication, the platform handles governance.

What the apps gateway does well

The gateway solves a specific, important problem: giving Claude Code a proper identity layer. Before it existed, every developer carried an API key or used a shared credential, and there was no standardized way to enforce model access, spend ceilings, or managed settings at the organizational level.

With the gateway in place:

• Developers authenticate through your OIDC identity provider (one issuer per gateway instance).
• IdP groups map to model allowlists and managed-settings policies in gateway.yaml.
• Spend limits are enforced per user, per group, or per organization, with a spend-limits Admin API.
• Telemetry is fanned out over OTLP/HTTP, stamped with user.id, user.email, and user.groups.
• Audit events (11 types: config.load, session.mint, auth.denied, inference, etc.) are emitted as single-line JSON on stderr.

This is well-designed infrastructure for its stated scope. Anthropic publishes the gateway protocol and invites third-party implementations, which is an unusually open posture for a model provider.

What it does not cover

Anthropic documents the following scope decisions clearly. These are not defects — they define where a co-deployment boundary belongs:

• OIDC only. No SAML, no LDAP. If your IdP uses SAML, you need an OIDC bridge in front of the gateway.
• Single issuer. One OIDC provider per gateway instance. Multi-tenant deployments need separate instances.
• Claude only. The model catalog is Claude models. OpenAI, Gemini, local inference, and other providers are outside the gateway’s scope.
• No service-token flow. Unattended CI/CD pipelines have no documented non-interactive authentication path through the gateway.
• No admin UI. Configuration is the YAML file; changes require a redeploy.
• No Helm chart. The gateway runs as a standard deployment, but there is no packaged chart.

Beyond these documented limits, there are governance-layer concerns the gateway was not designed to address:

• MCP server inventory and posture. Which MCP servers are deployed, what tools they expose, and whether their declared capabilities match their observed behavior — none of this is the gateway’s job.
• Cross-provider policy enforcement. A policy that says “production databases are read-only for all agents” needs to apply across Claude, OpenAI, and self-hosted models. The gateway governs Claude model access; it does not govern the resources those models touch, or what other models do.
• Session-level access mapping. Building the graph of which agent session reached which database, object store, or API endpoint — and whether that access was read or read/write — requires correlating telemetry, hooks, and infrastructure signals. The gateway relays OTLP verbatim; it does not analyze what the telemetry describes.
• Tamper-evident audit. The gateway emits JSON audit events on stderr. Those events need to land in a hash-chained, append-only ledger if they are going to support compliance evidence packs.

The co-deployment model

The architecture is deliberately simple: the gateway and the governance platform run side by side in your infrastructure, each doing what it is good at.

  Developer workstations                   Your infrastructure
  ┌─────────────────────┐
  │ Claude Code          │
  │ (v2.1.195+)         │
  └──────┬──────────────┘
         │
         │ OIDC device flow
         │ /v1/messages
         ▼
  ┌──────────────────────────────┐      ┌────────────────────────────────┐
  │ Claude apps gateway          │      │ Olivares AI (self-hosted)      │
  │                              │      │                                │
  │ • OIDC auth (1 issuer)       │      │ • OTLP receiver (gRPC + HTTP)  │
  │ • Model allowlists           │  ──▶ │ • Claude hooks correlation     │
  │ • Spend limits               │ OTLP │ • gateway.yaml posture         │
  │ • Managed settings           │      │ • Audit event ingest           │
  │ • OTLP fan-out               │      │ • Multi-provider governance    │
  │ • JSON audit on stderr       │  ──▶ │ • MCP server inventory         │
  │                              │ logs │ • Access-edge graph (R/RW)     │
  │ Claude models only.          │      │ • Hash-chained audit ledger    │
  │ OIDC only.                   │      │                                │
  └──────────────────────────────┘      │ ALL providers, ALL surfaces.   │
                                        └────────────────────────────────┘
                                                     ▲
         Other agent traffic ────────────────────────┘
         (OpenAI, Gemini, vLLM, Ollama, MCP servers, CI pipelines)

Two data flows connect the gateway to the platform:

OTLP fan-out. The gateway’s telemetry.forward_to configuration already supports OTLP/HTTP destinations. Point one of those at the Olivares OTLP receiver. The session.id attribute correlates gateway-relayed telemetry with session-runtime records from the Claude connector’s own hooks receiver. Identity attributes (user.id, user.email, user.groups) added by the gateway ride the operator attribute allowlist and become attribution labels on session edges and cost samples — no new receiver code is needed.

Audit event ingest. The claude-apps-gateway connector reads the gateway’s JSON audit events. The 11 documented event types (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) are mapped to SDK observations: security-relevant denials become findings, inference events become access edges, session mints become identity observations, and operational events become metric counters. PII in the raw events is SHA-256 hashed before it enters any observation; emails and identifiers are pseudonymous.

The claude-apps-gateway connector also inventories gateway.yaml itself: OIDC issuer, IdP-group-to-model mappings, upstream providers, OTLP destinations, and spend-admin posture. This inventory is structural metadata — topology, not credentials.

Posture findings from the gateway config

The connector raises a family of posture findings derived from the gateway configuration. These are the things a governance operator needs to know about a gateway deployment:

These findings appear in the same posture view as findings from every other connector. The MCP connector might report an unsandboxed tool. The Bedrock connector might flag a guardrail gap. The gateway connector reports that a policy catch-all is missing. One surface, one view.

What this looks like in configuration

The Claude connector runs an OTLP receiver on the standard OpenTelemetry ports and a hooks endpoint for Claude Code’s PreToolUse/PostToolUse hooks. Alongside it, the apps-gateway connector reads the gateway’s config and audit stream. Both connectors ship under Apache-2.0 and import only from the SDK, never from the engine core.

# olivares.yaml (abbreviated)
connectors:
  - name: olivares.claude
    config:
      grpc_addr: "127.0.0.1:4317"
      http_addr: "127.0.0.1:4318"
      hook_path: "/hooks"
      enforcement: |
        {"rules":[
          {"tool":"Bash","decision":"ask","reason":"shell access requires confirmation"},
          {"resource_kind":"file","mode":"write","decision":"ask"}
        ]}
      gateway: "direct"
      semconv_opt_in: "gen_ai_latest_experimental"

  - name: olivares.claude-apps-gateway
    config:
      config_path: "/etc/claude-gateway/gateway.yaml"
      audit_log_path: "/var/log/claude-gateway/audit.jsonl"

The gateway field on the Claude connector tags every cost sample with the deployment surface (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), so FinOps can slice spend by provider path. The semconv_opt_in field enables the vendor-neutral GenAI ingest profile (pinned to OpenTelemetry semconv v1.41.1), which means OpenAI, Gemini, or any OTel-instrumented agent feeds the same access-map and cost pipeline — not just Claude Code.

Honest positioning

There are things worth being direct about.

This is not a gateway replacement. The Olivares inference proxy implements a subset of Anthropic’s published gateway protocol (OAuth discovery, RFC 8628 device authorization, managed-settings delivery, and the spend-limits admin surface — views, writes and per-seat enforcement, with its divergences from the wire protocol documented). It is useful when that subset is sufficient. It is not a full replacement for the gateway’s browser OIDC flow, and its group spend semantics deliberately differ (most-restrictive-wins rather than the gateway’s merge rules). If the Anthropic gateway meets your auth requirements, run it.

The connector is read-only. The claude-apps-gateway connector observes the gateway’s configuration and audit output. It does not modify gateway.yaml, does not inject policies, and does not intercept the /v1/messages path. It is visibility, not control.

Olivares AI is pre-release. The product is not certified under SOC 2, ISO/IEC 27001, the EU AI Act, or any other framework, and no audit is in progress. It is designed toward the control objectives those frameworks examine so it is ready to be audited when the time comes.

The value is in the combination. A team that only runs Claude Code against one provider, with one IdP, and no MCP servers from other vendors, may find the gateway alone sufficient. The co-deployment earns its place when the estate is heterogeneous: multiple providers, MCP servers from multiple vendors, self-hosted models, CI pipelines, compliance requirements that span the full agent surface. That is where “Claude auth” and “estate governance” are genuinely different problems.

FAQ

Does Olivares AI replace the Claude apps gateway?

No. The doctrine is “and, not or.” The Anthropic gateway owns the Claude Code auth session, model-access routing, and upstream selection. Olivares AI makes that deployment a governed surface inside a broader control plane that also covers non-Claude providers, MCP servers, self-hosted models, and the rest of your agent estate. If you already run the gateway, keep it.

Can I run Olivares AI without the Claude apps gateway?

Yes. The claude-apps-gateway connector is optional. The core Claude connector (connectors/claude) ingests OTLP telemetry and hooks directly from Claude Code sessions, with or without a gateway in front. If you do not use the Anthropic gateway, you lose its OIDC session auth path but you retain full governance: session inventory, access-edge mapping, cost attribution, hook enforcement, MCP posture, and the multi-provider view.

For the deployment topology in detail, see /architecture. For MCP server governance across vendors, see /product/mcp. For the full product surface, see /product.