Zum Inhalt springen

So funktioniert es

Governance von subskriptionsauthentifizierten Claude Code und Codex

Der am schwierigsten zu regierende Agent authentifiziert sich mit einer persönlichen oder Unternehmenssubskription. Die verlockende Lösung — die Subskription als Proxy durchzuleiten — ist etwas, das wir nicht bauen werden. So regieren wir, ohne zu vermitteln.

Der am schwierigsten zu regierende Agent ist derjenige, bei dem sich ein Entwickler mit einer persönlichen oder Unternehmens-Subskription angemeldet hat: Claude Code mit Pro/Max, oder Codex mit ChatGPT. Er läuft auf einem Laptop, authentifiziert sich mit einer OAuth-Credential und ist genau die Angriffsfläche, die ein Cloud-Provider-Guardrail im Inferenzpfad nie sieht (siehe den Gateway-Vergleich). Die verlockende „Lösung” — einen Service davorzusetzen, der die Subskription hält und den Verkehr routet — ist etwas, das Olivares AI nicht bauen wird, weil die Modellanbieter es verbieten und weil es unser Control Plane zu einem Single Point of Credential Compromise machen würde.

Diese Seite ist die ehrliche Darstellung, wie wir diese Agenten regieren, ohne jemals die Subskription zu vermitteln: was wir beobachten, wo wir Policy durchsetzen, und den einen schmalen Pfad, auf dem ein Gateway angemessen ist (und dieser ist nie der der Subskription).

Die rote Linie: Wir routen nie Ihre Subskription. Olivares AI hält, proxifiziert oder routet niemals eine Drittanbieter-Subskriptions- Credential. Die eigene Richtlinie von Anthropic besagt: “Anthropic does not permit third-party developers to offer Claude.ai login or to route requests through Free, Pro, or Max plan credentials on behalf of their users” (Claude Code legal & compliance, abgerufen am 21.06.2026 — das Verbot benennt die drei Verbraucherpläne Free, Pro, Max). Die Nutzungsbedingungen von OpenAI funktionieren genauso für ein ChatGPT-/Codex-Verbraucher-Login. Unsere Haltung ist strenger als die Linie selbst: Wir routen kein Subskriptions-OAuth, keines Plans. Governance geschieht um den Agenten herum, nie innerhalb seiner Credential.

Warum das Vermitteln der Subskription ausgeschlossen ist

Es lohnt sich, bei der Regel präzise zu sein, weil die Rechtsabteilung eines Käufers sie prüfen wird. Die Richtlinie von Anthropic zieht zwei Listen, die nicht vermischt werden dürfen:

  • Wer OAuth überhaupt nutzen darf — fünf Pläne: “OAuth authentication is intended exclusively for purchasers of Claude Free, Pro, Max, Team, and Enterprise subscription plans and is designed to support ordinary use of Claude Code and other native Anthropic applications.”
  • Was ein Drittanbieter nicht tun darf — im Auftrag von Nutzern routen: “Anthropic does not permit third-party developers to offer Claude.ai login or to route requests through Free, Pro, or Max plan credentials on behalf of their users.”

Das Verbot benennt explizit die Verbraucher-Pläne (Free, Pro, Max). Die Seite erteilt umgekehrt niemandem die Erlaubnis, Team- oder Enterprise-Plätze zu routen — sie schweigt dazu, und wir interpretieren Schweigen nicht als Erlaubnis. Für Entwickler, die Tooling bauen, weist die eigene Anleitung von Anthropic grundsätzlich von Subskriptions-OAuth weg: “Developers building products or services that interact with Claude’s capabilities, including those using the Agent SDK, should use API key authentication through Claude Console or a supported cloud provider.” (Quelle; Aufteilung nach Plantyp: Team/Enterprise/API unter Commercial Terms, Free/Pro/Max unter Consumer Terms.)

Unser Codex-Konnektor kodiert dieselbe Disziplin im Code, by Design: Die Automatisierungs-Credential ist ein OpenAI-API-Key oder ein Workspace-Access-Token, nie eine persönliche ChatGPT-Subskription — “proxying it for third-party/programmatic use violates OpenAI’s terms exactly as a consumer Claude subscription does for Anthropic. There is no subscription config field by design” (connectors/codex/codex.go). Die rote Linie ist also kein nachträglich aufgesetztes Marketing-Versprechen; sie ist die Form des Produkts.

Drei Mechanismen, keiner davon die Subskription

Wir regieren einen subskriptionsauthentifizierten Agenten über drei unabhängige Kanäle. Die ersten beiden berühren die Inferenz überhaupt nicht; der dritte berührt sie nur für Verkehr, der sich mit einem API-Key authentifiziert, nie mit einer Subskription.

1. Beobachten — Telemetrie, Nutzung und Posture

Claude Code emittiert OpenTelemetry, und ein Administrator kann es für die gesamte Flotte vom verwalteten Tier aus aktivieren: “Administrators can configure OpenTelemetry settings for all users through the managed settings file” (Claude Code monitoring). Wir ingestieren dieses Gen-AI-Signal — Sitzungen, Tokens, Kosten, Tool-Aktivitäten — und wandeln es in die Access Map und Posture-Findings um. Entscheidend ist, dass dies Minimal-Data by Construction auch auf Claude Codes Seite ist: Prompt-Inhalte sind “redacted by default”, und Tool-Details, Tool-Inhalte und rohe API-Bodies sind jeweils “(default: disabled)” (gleiche Quelle). Wir konsumieren Nutzungs- und Metadaten, keine Konversationen.

Für Codex ist derselbe Beobachtungskanal die Ingestion des Konnektors aus den Analytics- und Compliance-/Audit-APIs — Nutzung, Adoption und unveränderliche Audit-Datensätze, umgewandelt in Kostenproben und manipulationssichere Evidenz, mit dem Grundsatz “never prompt/diff content or key values” (connectors/codex/codex.go).

2. Managed Settings + Hooks — der In-Process-PEP

Beobachtung ist kein Enforcement. Der Enforcement-Kanal für Claude Code sind dessen Managed Settings auf der Betriebssystem-Policy-Ebene, die einen nicht überschreibbaren PreToolUse-Hook enthalten, der vor jeder Tool-Ausführung den Olivares-Entscheidungspunkt aufruft. Anthropic dokumentiert die Eigenschaft, auf die wir uns stützen: “Environment variables defined in the managed settings file have high precedence and cannot be overridden by users”, und Managed Settings “can be distributed via MDM” (monitoring).

Olivares generiert diese Datei (olivares agent managed-settings) mit allowManagedHooksOnly, sodass ein eigener Hook des Entwicklers den governierten nie vorausgehen oder unterlaufen kann, und der sitzungsspezifische Endpoint und Bearer werden beim Start injiziert — nicht in die statische Datei geschrieben. Die Entscheidung selbst ist deny-closed an jedem Rand: Ein Tool-Call wird nur zugelassen, wenn eine feste Identität aufgelöst wird, die Policy-Disposition nicht deny ist, die Live-Policy-Engine es nicht verbietet und — bei einem ask — eine menschliche Genehmigung an den exakten Plan-Hash gebunden ist. Ein Emergency Stop (Kill Switch) überstimmt alles, einschließlich einer aktiven Break-Glass-Gewährung.

Das ist der Mechanismus, den die Seite Claude Code Hooks PEP operativ dokumentiert, und es ist das, was uns in die Lage versetzt, den lokalen Entwicklungsagenten zu regieren, nicht nur zu beobachten.

3. Gateway für API-Key — nie für OAuth

Es gibt genau einen Pfad, auf dem sich Olivares in der Inferenz-Anfragelinie befindet, und er existiert nur für Aufrufer, die den Managed-Settings-Kanal von Claude Code nicht nutzen: direkter SDK- oder curl-Verkehr, authentifiziert mit einem API-Key (oder einem Bedrock-/Vertex-Äquivalent). Claude Code routet solche Anfragen mit ANTHROPIC_BASE_URL“To route requests through a custom API endpoint, set the ANTHROPIC_BASE_URL environment variable instead” — und authentifiziert ein Gateway mit einem Bearer über ANTHROPIC_AUTH_TOKEN, “when routing through an LLM gateway or proxy that authenticates with bearer tokens rather than Anthropic API keys” (Claude Code IAM). Auf den Olivares-Inline-Inferenz-Proxy gerichtet, erhält dieser Verkehr eine governierte Pipeline — Residency, Modellzugriff, Context-Window, DLP, Budget, Aufzeichnung — bevor er weitergeleitet wird.

Die Grenze ist absolut: Dieser Pfad transportiert API-Key-/Bearer-Verkehr, niemals die OAuth-Credential einer Subskription. Er ist die Enforcement-Naht für die SDK-/curl-Aufrufer, die Managed Settings nicht erreichen können, und nichts weiter.

Die Ehrlichkeitsbox: verified-deployed, nicht unumgehbar

Enforcement, das wir als deployed nachweisen können, nicht Enforcement, das nicht umgangen werden kann. Der Managed-Settings-+-Hook-PEP ist deny-closed und nicht durch den Benutzer über Settings überschreibbar — aber er ist keine Magie. Ein Entwickler, der ANTHROPIC_BASE_URL auf seinen eigenen Endpoint richtet, sendet die Inferenz woanders hin; unsere eigene Engineering-Notiz sagt es klar: “a custom ANTHROPIC_BASE_URL bypasses server-managed-settings entirely” (modules/inferenceproxy/doc.go). Wir behaupten also nie, dass der PEP unmöglich zu umgehen ist. Stattdessen behaupten wir zwei Dinge, die wir belegen können:

  1. Er ist verified-deployed. Olivares attestiert, dass die Managed Settings und der PEP-Hook tatsächlich auf dem Host vorhanden sind — ein nicht provisionierter Host läuft ungoverned-aber-beobachtet, und das ist sichtbar, nicht versteckt.
  2. Die Umgehung ist selbst ein Finding. Eine nicht standardmäßige ANTHROPIC_BASE_URL auf einem Host erscheint als Posture-Finding, und eine verwaltete Umgebung, die eine Base-URL fixiert, die vom autorisierten Olivares-Gateway abweicht, erzeugt ein Drift-Finding (connectors/claude-config, connectors/managedsettings). Die Umgehung wird nicht still; sie leuchtet auf.

„Verified-deployed, evasion-as-finding” ist die ehrliche Enforcement-Narrative für jeden Agenten, der auf einer Maschine läuft, die der Entwickler kontrolliert. Wir werden Ihnen nicht „unumgehbar” verkaufen.

Die Codex-Asymmetrie, ehrlich dargestellt

Claude Code und Codex sind nicht symmetrisch, und der Unterschied ist relevant. Für Codex, authentifiziert über ChatGPT, gibt es kein dokumentiertes Äquivalent zu ANTHROPIC_BASE_URL — die Managed-Configuration-Seite von OpenAI dokumentiert kein Setting und keine Umgebungsvariable, um die Inferenz über eine benutzerdefinierte Base-URL oder ein Gateway zu routen (per Fetch verifiziert am 21.06.2026; ein Fehlen auf dieser Seite, kein Beweis, dass es anderswo nicht existiert). Wir regieren Codex also nicht durch Abfangen seiner Inferenz.

Stattdessen regieren wir dort, wo OpenAI Administratoren tatsächlich durchsetzbare Kontrollen gibt. Die Managed Configuration von Codex ermöglicht es einem Unternehmen, “Requirements: admin-enforced constraints that users can’t override” zu setzen, die “constrain security-sensitive settings (approval policy, approvers reviewer, automatic review policy, sandbox mode, permission profiles, web search mode, managed hooks, and optionally which MCP servers users can enable)” (gleiche Quelle). Olivares verfasst und attestiert diese Anforderungen (connectors/codex-managed-config) — Approval Policy, Sandbox Mode, die MCP-Allowlist, redaktierte Telemetrie (log_user_prompt = false) — und ingestiert die Analytics- und Compliance-Evidenz von Codex. Governance durch Konfiguration und Evidenz, nicht durch einen Man-in-the-Middle beim Modellaufruf.

In einer Tabelle

KanalWas er tutBerührt er die Inferenz?Die Credential
BeobachtenNutzung, Kosten, Tool-Aktivitäten → Access Map + Posture; Codex Analytics/Compliance → LedgerNeinKeine — nur Telemetrie, Inhalt standardmäßig redaktiert
Managed Settings + HooksDeny-closed PreToolUse-PEP auf Claude Code, nicht überschreibbar über SettingsNeinDie des Agenten selbst; wir sehen sie nie
Gateway (nur API-Key)Governierte Pipeline für direkte SDK-/curl-Aufrufer über ANTHROPIC_BASE_URLJaAPI-Key / Bearer — nie Subskriptions-OAuth
Codex Managed-ConfigVom Admin durchgesetzte Anforderungen (Approval/Sandbox/MCP) + Evidenz-IngestionNeinDie der Organisation; Konfiguration, keine Interception

Verwandt

Claude fragen

Fragen

Routet Olivares meine Claude Pro/Max-Subskription?

Niemals. Die Richtlinie von Anthropic verbietet Drittanbieter-Routing über Free-, Pro- oder Max-Credentials. Unsere Haltung ist strenger: Wir routen kein Subskriptions-OAuth irgendeines Plans.

Was ist mit Claude Team oder Enterprise?

Das Verbot benennt Free, Pro, Max. Die Seite von Anthropic schweigt zum Routing von Team/Enterprise. Wir interpretieren Schweigen nicht als Erlaubnis — also routen wir keinen.