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_URLal proprio endpoint invia l’inferenza altrove interamente; la nostra stessa nota ingegneristica lo dichiara chiaramente: “a customANTHROPIC_BASE_URLbypasses 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:
- È 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.
- L’elusione è essa stessa un finding. Un
ANTHROPIC_BASE_URLnon 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
| Canale | Cosa fa | Tocca l’inferenza? | La credenziale |
|---|---|---|---|
| Osservare | Utilizzo, costo, attività degli strumenti → mappa di accesso + postura; Analytics/Compliance di Codex → ledger | No | Nessuna — solo telemetria, contenuto redatto per default |
| Managed settings + hook | PEP PreToolUse deny-closed su Claude Code, non sovrascrivibile tramite settings | No | Quella dell’agente stesso; non la vediamo mai |
| Gateway (solo API key) | Pipeline governata per chiamanti SDK/curl diretti tramite ANTHROPIC_BASE_URL | Sì | API key / bearer — mai OAuth di abbonamento |
| Codex managed-config | Requisiti applicati dall’admin (approval/sandbox/MCP) + acquisizione dell’evidenza | No | Quella dell’organizzazione; configurazione, non intercettazione |
Correlati
- Dove si colloca Olivares rispetto al tuo gateway / Guardrails — perché nulla di questo compete con il tuo AI gateway.
- Olivares AI vs WitnessAI — il confronto diretto sulla governance degli agenti negli IDE.