Anthropic hat das Claude Apps Gateway Ende Juni 2026 ausgeliefert. Es handelt sich um einen selbst gehosteten Dienst, der in der Binärdatei claude (v2.1.195+) gebündelt ist. Sie führen es mit claude gateway --config gateway.yaml aus, unterstützen es mit PostgreSQL und es stellt die OIDC-Anmeldung vor Ihre Claude Code-Flotte: Unternehmens-IdP-Sitzungen anstelle lokal verwalteter API-Schlüssel. Das ist ein echter Fortschritt. Für Teams, die Claude Code direkt gegen Bedrock, Vertex, Foundry oder die Anthropic-API ausführen, zentralisiert das Gateway Identität, Modellzugriff und Ausgabenkontrollen hinter einer einzigen Konfigurationsdatei.
In diesem Beitrag geht es darum, was als nächstes passiert. Ihr KI-Nachlass ist mit ziemlicher Sicherheit mehr als Claude. Sie betreiben wahrscheinlich MCP-Server verschiedener Anbieter. Möglicherweise verfügen Sie über OpenAI- oder Gemini-Workloads, selbstgehostete Rückschlüsse über vLLM oder Ollama, CI-Pipelines, die nie einen Browser sehen, und Agent-Frameworks, die anbieterübergreifend delegieren. Das Apps-Gateway ist nur für Claude und nur für OIDC verfügbar. Das ist eine Entscheidung über den Umfang und kein Mangel – aber es bedeutet, dass die Governance-Frage nur teilweise beantwortet ist.
Das hier beschriebene Co-Deployment-Modell stellt neben dem Gateway eine selbstgehostete Governance-Plattform bereit, die sowohl die Telemetriedaten des Gateways als auch den Rest Ihrer Agenteninfrastruktur ausliest. Komplementär, nicht konkurrenzfähig: Das Gateway übernimmt die Authentifizierung, die Plattform übernimmt die Governance.
Was das Apps-Gateway gut macht
Das Gateway löst ein spezifisches, wichtiges Problem: Es gibt Claude Code eine richtige Identitätsschicht. Bevor es existierte, verfügte jeder Entwickler über einen API-Schlüssel oder verwendete gemeinsame Anmeldeinformationen, und es gab keine standardisierte Möglichkeit, den Modellzugriff, Ausgabenobergrenzen oder verwaltete Einstellungen auf Organisationsebene durchzusetzen.
Wenn das Gateway vorhanden ist:
- Entwickler authentifizieren sich über Ihren OIDC-Identitätsanbieter (ein Aussteller pro Gateway-Instanz).
- IdP-Gruppen werden Modellzulassungslisten und Richtlinien für verwaltete Einstellungen in
gateway.yamlzugeordnet. - Ausgabenlimits werden pro Benutzer, pro Gruppe oder pro Organisation mit einer Admin-API für Ausgabenlimits durchgesetzt.
- Die Telemetrie wird über OTLP/HTTP verteilt und ist mit
user.id,user.emailunduser.groupsgekennzeichnet. - Prüfereignisse (11 Typen:
config.load,session.mint,auth.denied,inferenceusw.) werden als einzeiliges JSON auf stderr ausgegeben.
Dies ist eine gut konzipierte Infrastruktur für den angegebenen Umfang. Anthropic veröffentlicht das Gateway-Protokoll und lädt Implementierungen von Drittanbietern ein, was für einen Modellanbieter eine ungewöhnlich offene Haltung darstellt.
Was es nicht abdeckt
Anthropic dokumentiert die folgenden Scope-Entscheidungen übersichtlich. Hierbei handelt es sich nicht um Mängel – sie definieren, wo eine Co-Deployment-Grenze hingehört:
- Nur OIDC. Kein SAML, kein LDAP. Wenn Ihr IdP SAML verwendet, benötigen Sie eine OIDC-Bridge vor dem Gateway.
- Einzelner Aussteller. Ein OIDC-Anbieter pro Gateway-Instanz. Für mehrinstanzenfähige Bereitstellungen sind separate Instanzen erforderlich.
- Nur Claude. Der Modellkatalog umfasst Claude-Modelle. OpenAI, Gemini, lokale Inferenz und andere Anbieter liegen außerhalb des Geltungsbereichs des Gateways.
- Kein Service-Token-Fluss. Unbeaufsichtigte CI/CD-Pipelines haben keinen dokumentierten nicht interaktiven Authentifizierungspfad durch das Gateway.
- Keine Admin-Benutzeroberfläche. Die Konfiguration erfolgt über die YAML-Datei. Änderungen erfordern eine erneute Bereitstellung.
- Kein Helm-Diagramm. Das Gateway wird als Standardbereitstellung ausgeführt, es gibt jedoch kein gepacktes Diagramm.
Über diese dokumentierten Grenzen hinaus gibt es Bedenken auf Governance-Ebene, für deren Behebung das Gateway nicht konzipiert wurde:
- MCP-Serverinventur und -Status. Welche MCP-Server bereitgestellt werden, welche Tools sie bereitstellen und ob ihre deklarierten Fähigkeiten mit ihrem beobachteten Verhalten übereinstimmen – nichts davon ist die Aufgabe des Gateways.
- Anbieterübergreifende Richtliniendurchsetzung. Eine Richtlinie, die besagt „Produktionsdatenbanken sind für alle Agenten schreibgeschützt“, muss für Claude-, OpenAI- und selbstgehostete Modelle gelten. Das Gateway regelt den Zugriff auf das Claude-Modell. Es regelt nicht die Ressourcen, die diese Modelle berühren, oder was andere Modelle tun.
- Zugriffszuordnung auf Sitzungsebene. Die Erstellung des Diagramms darüber, welche Agentensitzung welche Datenbank, welchen Objektspeicher oder welchen API-Endpunkt erreicht hat – und ob dieser Zugriff gelesen oder read/write war – erfordert die Korrelation von Telemetrie, Hooks und Infrastruktursignalen. Das Gateway leitet OTLP wörtlich weiter; Es wird nicht analysiert, was die Telemetrie beschreibt.
- Manipulationssichere Prüfung. Das Gateway gibt JSON-Prüfereignisse auf stderr aus. Diese Ereignisse müssen in einem Hash-verketteten, nur anhängbaren Ledger landen, wenn sie Compliance-Beweispakete unterstützen sollen.
Das Co-Deployment-Modell
Die Architektur ist bewusst einfach gehalten: Das Gateway und die Governance-Plattform laufen in Ihrer Infrastruktur nebeneinander und tun jeweils das, was sie können.
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)Zwei Datenflüsse verbinden das Gateway mit der Plattform:
OTLP Fan-Out. Die telemetry.forward_to-Konfiguration des Gateways unterstützt bereits OTLP/HTTP-Ziele. Richten Sie einen davon auf den Olivares OTLP-Empfänger. Das session.id-Attribut korreliert die vom Gateway weitergeleitete Telemetrie mit Sitzungslaufzeitdatensätzen vom eigenen Hooks-Empfänger des Claude-Connectors. Vom Gateway hinzugefügte Identitätsattribute (user.id, user.email, user.groups) folgen der Zulassungsliste für Operatorattribute und werden zu Zuordnungsbezeichnungen an Sitzungskanten und Kostenbeispielen – es ist kein neuer Empfängercode erforderlich.
Aufnahme von Prüfereignissen. Der Connector claude-apps-gateway liest die JSON-Prüfereignisse des Gateways. Die 11 dokumentierten Ereignistypen (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) werden SDK-Beobachtungen zugeordnet: Sicherheitsrelevante Ablehnungen werden zu Erkenntnissen, Inferenzereignisse werden zu Zugriffskanten, Sitzungsmints werden zu Identitätsbeobachtungen und Betriebsereignisse werden zu Metrikzählern. PII in den Rohereignissen werden SHA-256 gehasht, bevor sie in eine Beobachtung eingehen; E-Mails und Identifikatoren sind pseudonym.
Der claude-apps-gateway-Connector inventarisiert auch gateway.yaml selbst: OIDC-Aussteller, IdP-Gruppen-zu-Modell-Zuordnungen, Upstream-Anbieter, OTLP-Ziele und Ausgabenadministratorstatus. Bei diesem Inventar handelt es sich um strukturelle Metadaten – Topologie, nicht um Anmeldeinformationen.
Statusergebnisse aus der Gateway-Konfiguration
Der Connector generiert eine Reihe von Haltungsergebnissen, die aus der Gateway-Konfiguration abgeleitet werden. Dies sind die Dinge, die ein Governance-Betreiber über eine Gateway-Bereitstellung wissen muss:
| Finden | Schweregrad | Was es fängt |
|---|---|---|
| Kein OTLP-Ziel konfiguriert | Mittel | Telemetrie wird nicht weitergeleitet; Die Flotte ist für die Überwachung unsichtbar |
| Keine Pauschalpolitik | Hoch | Benutzer, die keiner IdP-Gruppe entsprechen, erhalten jedes Modell und keine verwalteten Einstellungen |
| Keine Ausgabenlimits | Mittel | Die Spend-Admin-API und die Durchsetzung sind nicht konfiguriert |
| Geheime Literale in YAML | Hoch | client_secret, jwt_secret oder Datenbankkennwörter, die als Literale anstelle von ${VAR}- oder ${file:...}-Referenzen geschrieben werden |
| Lange Sitzungs-TTL (>12 Stunden) | Mittel | Deprovisionierungslatenz: Die Sitzung eines widerrufenen Benutzers bleibt gültig |
| PKCE deaktiviert | Niedrig | Der OIDC-Flow verwendet keinen Proof Key für den Codeaustausch |
| Empfindliche Telemetriesignale | Niedrig | logs: true oder traces: true auf einem Ziel – diese können vollständige Bash-Befehle und Dateipfade übertragen |
Diese Ergebnisse werden in derselben Haltungsansicht angezeigt wie die Ergebnisse aller anderen Konnektoren. Der MCP-Connector meldet möglicherweise ein Tool ohne Sandbox. Der Bedrock-Stecker weist möglicherweise auf eine Leitplankenlücke hin. Der Gateway-Connector meldet, dass ein Policy Catch-All fehlt. Eine Oberfläche, eine Ansicht.
Wie das in der Konfiguration aussieht
Der Claude-Connector führt einen OTLP-Empfänger auf den Standard-OpenTelemetry-Ports und einen Hooks-Endpunkt für die PreToolUse/PostToolUse-Hooks von Claude Code aus. Daneben liest der Apps-Gateway-Connector den Konfigurations- und Audit-Stream des Gateways. Beide Konnektoren werden unter Apache-2.0 ausgeliefert und nur vom SDK importiert, niemals vom Engine-Kern.
# olivares.yaml (abgekürzt)
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"Das Feld gateway im Claude-Connector markiert jede Kostenprobe mit der Bereitstellungsoberfläche (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), sodass FinOps die Ausgaben nach Anbieterpfad aufteilen kann. Das Feld semconv_opt_in ermöglicht das herstellerneutrale GenAI-Ingest-Profil (angeheftet an OpenTelemetry semconv v1.41.1), was bedeutet, dass OpenAI, Gemini oder jeder OTel-instrumentierte Agent dieselbe Access Map und Kostenpipeline speist – nicht nur Claude Code.
Ehrliche Positionierung
Es gibt Dinge, die es wert sind, direkt angesprochen zu werden.
Dies ist kein Gateway-Ersatz. Der Olivares-Inferenz-Proxy implementiert eine Teilmenge des veröffentlichten Gateway-Protokolls von Anthropic (OAuth-Erkennung, RFC 8628-Geräteautorisierung, Bereitstellung verwalteter Einstellungen und die Verwaltungsoberfläche für Ausgabenlimits – Ansichten, Schreibvorgänge und Durchsetzung pro Arbeitsplatz, wobei die Abweichungen vom Wire-Protokoll dokumentiert sind). Dies ist nützlich, wenn diese Teilmenge ausreichend ist. Es ist kein vollständiger Ersatz für den Browser-Fluss OIDC des Gateways, und seine Gruppenausgabensemantik unterscheidet sich bewusst (most-restrictive-wins statt der Zusammenführungsregeln des Gateways). Wenn das Anthropic-Gateway Ihre Authentifizierungsanforderungen erfüllt, führen Sie es aus.
Der Connector ist schreibgeschützt. Der Connector claude-apps-gateway überwacht die Konfiguration und Prüfausgabe des Gateways. gateway.yaml wird nicht geändert, es werden keine Richtlinien eingefügt und der /v1/messages-Pfad wird nicht abgefangen. Es geht um Sichtbarkeit, nicht um Kontrolle.
Bei Olivares AI handelt es sich um eine Vorabversion. Das Produkt ist nicht nach SOC 2, ISO/IEC 27001, dem EU-KI-Gesetz oder einem anderen Rahmenwerk zertifiziert und es wird kein Audit durchgeführt. Es ist auf die Kontrollziele ausgerichtet, die in diesen Rahmenwerken untersucht werden, sodass es zu gegebener Zeit geprüft werden kann.
Der Wert liegt in der Kombination. Ein Team, das Claude Code nur gegen einen Anbieter, mit einem IdP und keine MCP-Server anderer Anbieter ausführt, kann das Gateway allein als ausreichend erachten. Die gemeinsame Bereitstellung verdient ihren Platz, wenn der Bestand heterogen ist: mehrere Anbieter, MCP-Server von mehreren Anbietern, selbst gehostete Modelle, CI-Pipelines, Compliance-Anforderungen, die sich über die gesamte Agentenoberfläche erstrecken. Hier sind „Claude Auth“ und „Estate Governance“ wirklich unterschiedliche Probleme.
FAQ
Ersetzt Olivares AI das Claude-Apps-Gateway?
Nein. Die Lehre lautet „und, nicht oder“. Das Anthropic-Gateway besitzt die Claude Code-Authentifizierungssitzung, das Modellzugriffsrouting und die Upstream-Auswahl. Olivares AI macht diese Bereitstellung zu einer kontrollierten Oberfläche innerhalb einer breiteren Kontrollebene, die auch Nicht-Claude-Anbieter, MCP-Server, selbstgehostete Modelle und den Rest Ihres Agentenbestands abdeckt. Wenn Sie das Gateway bereits ausführen, behalten Sie es bei.
Kann ich Olivares AI ohne das Claude Apps Gateway ausführen?
Ja. Der claude-apps-gateway-Stecker ist optional. Der Claude-Kern-Connector (connectors/claude) nimmt OTLP-Telemetrie auf und verbindet sich direkt mit Claude Code-Sitzungen, mit oder ohne vorgeschaltetes Gateway. Wenn Sie das Anthropic-Gateway nicht verwenden, verlieren Sie seinen OIDC-Sitzungsauthentifizierungspfad, behalten aber die vollständige Governance: Sitzungsinventar, Zugriffskantenzuordnung, Kostenzuordnung, Hook-Durchsetzung, MCP-Status und die Multi-Provider-Ansicht.
Einzelheiten zur Bereitstellungstopologie finden Sie unter /architecture. Informationen zur MCP-Server-Governance verschiedener Anbieter finden Sie unter /product/mcp. Die vollständige Produktoberfläche finden Sie unter /product.