Vai al contenuto

Compare

Governance di Claude Code e Codex autenticati tramite abbonamento

L'agente più difficile da governare si autentica con un abbonamento personale o aziendale. La soluzione allettante — intermediare l'abbonamento — è qualcosa che non costruiremo. Ecco come governiamo senza intermediare.

L’agente più difficile da governare è quello a cui uno sviluppatore ha effettuato l’accesso con un abbonamento personale o aziendale: Claude Code con Pro/Max, o Codex con ChatGPT. Viene eseguito su un laptop, si autentica con una credenziale OAuth, ed è esattamente la superficie che un guardrail di un cloud provider nel percorso di inferenza non vede mai (si veda il confronto con i gateway). La “soluzione” allettante — interporre un servizio che detenga l’abbonamento e instradi il suo traffico — è qualcosa che Olivares AI non costruirà, perché i fornitori di modelli lo proibiscono e perché renderebbe il nostro control plane un singolo punto di compromissione delle credenziali.

Questa pagina è il resoconto onesto di come governiamo questi agenti senza mai intermediare l’abbonamento: cosa osserviamo, dove applichiamo le policy e l’unico percorso ristretto in cui un gateway è appropriato (e non è mai quello dell’abbonamento).

La linea rossa: non instraderemo mai il tuo abbonamento. Olivares AI non detiene, non proxifica e non instrada mai una credenziale di abbonamento di terzi. La policy stessa di Anthropic stabilisce: “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, consultato il 21-06-2026 — la proibizione nomina i tre piani consumer Free, Pro, Max). I termini di OpenAI funzionano allo stesso modo per un accesso consumer di ChatGPT/Codex. La nostra postura è più rigorosa della linea stessa: non instraderemo alcun OAuth di abbonamento, di alcun piano. La governance avviene attorno all’agente, mai all’interno della sua credenziale.

Perché intermediare l’abbonamento è fuori discussione

Vale la pena essere precisi sulla regola, perché il consulente legale di un acquirente la verificherà. La policy di Anthropic traccia due elenchi che non devono essere confusi:

  • Chi può utilizzare OAuth — cinque piani: “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.”
  • Cosa non può fare un soggetto terzo — instradare per conto degli utenti: “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.”

La proibizione nomina esplicitamente i piani consumer (Free, Pro, Max). La pagina non concede, viceversa, a nessuno il permesso di instradare le postazioni Team o Enterprise — tace al riguardo, e non interpretiamo il silenzio come una licenza. Per gli sviluppatori che costruiscono strumenti, la guida stessa di Anthropic orienta lontano dall’OAuth di abbonamento in toto: “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.” (source; suddivisione per tipo di piano: Team/Enterprise/API sotto Commercial Terms, Free/Pro/Max sotto Consumer Terms.)

Il nostro connettore Codex codifica la medesima disciplina nel codice, per progettazione: la credenziale di automazione è una API key di OpenAI o un workspace access token, mai un abbonamento personale di ChatGPT — “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). Pertanto la linea rossa non è una promessa di marketing aggiunta successivamente; è la forma del prodotto.

Tre meccanismi, nessuno dei quali l’abbonamento

Governiamo un agente autenticato tramite abbonamento attraverso tre canali indipendenti. I primi due non toccano mai l’inferenza; il terzo la tocca solo per il traffico che si autentica con una API key, mai con un abbonamento.

1. Osservare — telemetria, utilizzo e postura

Claude Code emette OpenTelemetry, e un amministratore può attivarlo per l’intera flotta dal tier gestito: “Administrators can configure OpenTelemetry settings for all users through the managed settings file” (Claude Code monitoring). Acquisiamo quel segnale gen-ai — sessioni, token, costo, attività degli strumenti — e lo trasformiamo nella mappa di accesso e nei finding di postura. È fondamentale che questo sia minimal-data per costruzione anche dal lato di Claude Code: il contenuto dei prompt è “redacted by default” e i dettagli degli strumenti, il contenuto degli strumenti e i body API grezzi sono ciascuno “(default: disabled)” (stessa fonte). Consumiamo utilizzo e metadati, non conversazioni.

Per Codex, lo stesso canale di osservazione è l’acquisizione da parte del connettore delle API di Analytics e Compliance/Audit — utilizzo, adozione e record di audit immutabili trasformati in campioni di costo ed evidenza a prova di manomissione, senza mai includere “never prompt/diff content or key values” (connectors/codex/codex.go).

2. Managed settings + hook — il PEP in-process

L’osservazione non è enforcement. Il canale di enforcement per Claude Code sono i suoi managed settings al tier della policy del sistema operativo, che includono un hook PreToolUse non sovrascrivibile che richiama il punto decisionale di Olivares prima dell’esecuzione di ogni strumento. Anthropic documenta la proprietà su cui ci basiamo: “Environment variables defined in the managed settings file have high precedence and cannot be overridden by users”, e i managed settings “can be distributed via MDM” (monitoring).

Olivares genera quel file (olivares agent managed-settings) con allowManagedHooksOnly affinché l’hook proprio di uno sviluppatore non possa mai precedere né eludere quello governato, e l’endpoint per sessione e il bearer vengono iniettati all’avvio — non scritti nel file statico. La decisione in sé è deny-closed a ogni confine: una chiamata a strumento è consentita solo quando un’identità sicura viene risolta, la disposizione della policy non è deny, il motore di policy in tempo reale non lo vieta, e — per un ask — un’approvazione umana è vincolata all’hash esatto del piano. Un emergency stop (kill switch) prevale su tutto, inclusa una concessione attiva di break-glass.

Questo è il meccanismo che la pagina Claude Code hooks PEP documenta operativamente, ed è ciò che ci consente di governare l’agente di sviluppo locale, non soltanto osservarlo.

3. Gateway per API key — mai per OAuth

Esiste esattamente un percorso in cui Olivares si colloca nella linea della richiesta di inferenza, e sussiste solo per i chiamanti che non utilizzano il canale managed settings di Claude Code: traffico SDK diretto o curl autenticato con una API key (o un equivalente Bedrock/Vertex). Claude Code instrada tali richieste con ANTHROPIC_BASE_URL“To route requests through a custom API endpoint, set the ANTHROPIC_BASE_URL environment variable instead” — e autentica un gateway con un bearer tramite ANTHROPIC_AUTH_TOKEN, “when routing through an LLM gateway or proxy that authenticates with bearer tokens rather than Anthropic API keys” (Claude Code IAM). Indirizzato al proxy di inferenza inline di Olivares, quel traffico riceve una pipeline governata — residenza, accesso ai modelli, finestra di contesto, DLP, budget, registrazione — prima di essere inoltrato.

Il confine è assoluto: questo percorso trasporta traffico API key / bearer, mai la credenziale OAuth di un abbonamento. È la giuntura di enforcement per i chiamanti SDK/curl che i managed settings non possono raggiungere, e nulla di più.

Il riquadro dell’onestà: verified-deployed, non inviolabile

Enforcement che possiamo dimostrare essere implementato, non enforcement che non possa essere eluso. Il PEP managed settings + hook è deny-closed e non sovrascrivibile dall’utente tramite settings — ma non è magia. Uno sviluppatore che indirizza ANTHROPIC_BASE_URL al proprio endpoint invia l’inferenza altrove interamente; la nostra stessa nota ingegneristica lo dichiara chiaramente: “a custom ANTHROPIC_BASE_URL bypasses server-managed-settings entirely” (modules/inferenceproxy/doc.go). Pertanto non affermiamo mai che il PEP sia impossibile da eludere. Affermiamo invece due cose che possiamo sostenere:

  1. È verified-deployed. Olivares attesta che i managed settings e l’hook PEP sono effettivamente presenti sull’host — un host non approvvigionato viene eseguito senza governance ma osservato, e ciò è visibile, non nascosto.
  2. L’elusione è essa stessa un finding. Un ANTHROPIC_BASE_URL non predefinito su un host emerge come finding di postura, e un ambiente gestito che fissa un base URL divergente dal gateway autorizzato di Olivares genera un finding di drift (connectors/claude-config, connectors/managedsettings). L’evasione non resta silente; si illumina.

“Verified-deployed, evasion-as-finding” è la narrativa onesta di enforcement per qualsiasi agente che opera su una macchina controllata dallo sviluppatore. Non vi venderemo “inviolabile”.

L’asimmetria di Codex, esposta con onestà

Claude Code e Codex non sono simmetrici, e la differenza è rilevante. Per Codex autenticato tramite ChatGPT non esiste un equivalente documentato di ANTHROPIC_BASE_URL — la pagina di managed configuration di OpenAI non documenta alcun setting né variabile d’ambiente per instradare l’inferenza attraverso un base URL personalizzato o un gateway (verificato tramite fetch, 21-06-2026; un’assenza su quella pagina, non una prova che non esista altrove). Pertanto non governiamo Codex intercettando la sua inferenza.

Lo governiamo invece dove OpenAI effettivamente fornisce agli amministratori controlli applicabili. La managed configuration di Codex consente a un’azienda di impostare “Requirements: admin-enforced constraints that users can’t override” che “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)” (stessa fonte). Olivares redige e attesta tali requisiti (connectors/codex-managed-config) — approval policy, sandbox mode, la allowlist MCP, telemetria redatta (log_user_prompt = false) — e acquisisce l’evidenza di Analytics e Compliance di Codex. Governance attraverso configurazione ed evidenza, non attraverso un man-in-the-middle sulla chiamata al modello.

In una tabella

CanaleCosa faTocca l’inferenza?La credenziale
OsservareUtilizzo, costo, attività degli strumenti → mappa di accesso + postura; Analytics/Compliance di Codex → ledgerNoNessuna — solo telemetria, contenuto redatto per default
Managed settings + hookPEP PreToolUse deny-closed su Claude Code, non sovrascrivibile tramite settingsNoQuella dell’agente stesso; non la vediamo mai
Gateway (solo API key)Pipeline governata per chiamanti SDK/curl diretti tramite ANTHROPIC_BASE_URLAPI key / bearer — mai OAuth di abbonamento
Codex managed-configRequisiti applicati dall’admin (approval/sandbox/MCP) + acquisizione dell’evidenzaNoQuella dell’organizzazione; configurazione, non intercettazione

Correlati

Chiedi a Claude

Domande

Olivares instrada il mio abbonamento Claude Pro/Max?

Mai. La policy di Anthropic proibisce l'instradamento da parte di terzi attraverso credenziali Free, Pro o Max. La nostra postura è più rigorosa: non instraderemo alcun OAuth di abbonamento di alcun piano.

E per quanto riguarda Claude Team o Enterprise?

La proibizione nomina Free, Pro, Max. La pagina di Anthropic tace sull'instradamento di Team/Enterprise. Non interpretiamo il silenzio come una licenza — pertanto non instraderemo nessuno di essi.