Anthropic ha distribuito il gateway delle app Claude alla fine di giugno 2026. Si tratta di un servizio self-hosted incluso nel file binario claude (v2.1.195+). Lo esegui con claude gateway --config gateway.yaml, lo supporti con PostgreSQL e mette l’accesso OIDC davanti alla tua flotta Claude Code: sessioni IdP aziendali invece di chiavi API gestite localmente. Questo è un vero passo avanti. Per i team che eseguono Claude Code con Bedrock, Vertex, Foundry o direttamente con l’API Anthropic, il gateway centralizza identità, accesso al modello e controlli di spesa dietro un singolo file di configurazione.
Questo post riguarda ciò che accadrà dopo. Il tuo patrimonio di intelligenza artificiale è quasi certamente superiore a quello di Claude. Probabilmente esegui server MCP di più fornitori. Potresti avere carichi di lavoro OpenAI o Gemini, inferenza self-hosted tramite vLLM o Ollama, pipeline CI che non vedono mai un browser e framework di agenti che delegano tra provider. Il gateway delle app è solo Claude e solo OIDC. Questa è una decisione sull’ambito, non un difetto, ma significa che la questione della governance ha solo una risposta partially.
Il modello di co-distribuzione qui descritto affianca al gateway una piattaforma di governance self-hosted, che legge sia i dati di telemetria del gateway che il resto dell’infrastruttura dell’agente. Complementari, non competitivi: il gateway gestisce l’autenticazione, la piattaforma gestisce la governance.
Cosa fa bene il gateway app
Il gateway risolve un problema specifico e importante: fornire a Claude Code un livello di identità adeguato. Prima che esistesse, ogni sviluppatore portava una chiave API o utilizzava credenziali condivise e non esisteva un modo standardizzato per imporre l’accesso ai modelli, i limiti di spesa o le impostazioni gestite a livello organizzativo.
Con il gateway in posizione:
- Gli sviluppatori eseguono l’autenticazione tramite il provider di identità OIDC (un emittente per istanza del gateway).
- I gruppi IdP vengono mappati per modellare le liste consentite e i criteri delle impostazioni gestite in
gateway.yaml. - I limiti di spesa vengono applicati per utente, per gruppo o per organizzazione, con un’API di amministrazione dei limiti di spesa.
- La telemetria è distribuita su OTLP/HTTP, contrassegnata con
user.id,user.emaileuser.groups. - Gli eventi di controllo (11 tipi:
config.load,session.mint,auth.denied,inferencee così via) vengono emessi come JSON a riga singola su stderr.
Si tratta di un’infrastruttura ben progettata per l’ambito dichiarato. Anthropic pubblica il protocollo gateway e invita implementazioni di terze parti, che è un atteggiamento insolitamente aperto per un fornitore di modelli.
Cosa non copre
Anthropic documenta chiaramente le seguenti decisioni sull’ambito. Questi non sono difetti: definiscono il luogo in cui appartiene un confine di co-distribuzione:
- Solo OIDC. Nessun SAML, nessun LDAP. Se il tuo IdP utilizza SAML, è necessario un bridge OIDC davanti al gateway.
- Singolo emittente. Un provider OIDC per istanza del gateway. Le distribuzioni multi-tenant richiedono istanze separate.
- Solo Claude. Il catalogo dei modelli riguarda i modelli Claude. OpenAI, Gemini, inferenza locale e altri provider non rientrano nell’ambito del gateway.
- Nessun flusso di token di servizio. Le pipeline CI/CD non presidiate non hanno un percorso di autenticazione non interattivo documentato attraverso il gateway.
- Nessuna interfaccia utente di amministrazione. La configurazione è il file YAML; le modifiche richiedono una ridistribuzione.
- Nessun grafico Helm. Il gateway viene eseguito come distribuzione standard, ma non è disponibile un grafico in pacchetto.
Oltre a questi limiti documentati, esistono problemi a livello di governance per cui il gateway non è stato progettato:
- Inventario e comportamento dei server MCP. Quali server MCP vengono distribuiti, quali strumenti espongono e se le loro capacità dichiarate corrispondono al comportamento osservato: niente di tutto questo è compito del gateway.
- Applicazione di policy tra provider. Una policy che dice che “i database di produzione sono di sola lettura per tutti gli agenti” deve essere applicata ai modelli Claude, OpenAI e self-hosted. Il gateway governa l’accesso al modello Claude; non governa le risorse toccate da questi modelli o cosa fanno gli altri modelli.
- Mappatura degli accessi a livello di sessione. Per creare il grafico di quale sessione dell’agente ha raggiunto quale database, archivio oggetti o endpoint API e se l’accesso è stato letto o letto/write, è necessario correlare telemetria, hook e segnali dell’infrastruttura. Il gateway trasmette OTLP alla lettera; non analizza ciò che descrive la telemetria.
- Controllo antimanomissione. Il gateway emette eventi di controllo JSON su stderr. Tali eventi devono finire in un registro concatenato con hash e di sola aggiunta se intendono supportare i pacchetti di prove di conformità.
Il modello di co-implementazione
L’architettura è volutamente semplice: il gateway e la piattaforma di governance funzionano fianco a fianco nella tua infrastruttura, ciascuno facendo ciò in cui è più bravo.
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)Due flussi di dati collegano il gateway alla piattaforma:
OTLP fan-out. La configurazione telemetry.forward_to del gateway supporta già le destinazioni OTLP/HTTP. Punta uno di questi verso il ricevitore Olivares OTLP. L’attributo session.id mette in correlazione la telemetria trasmessa dal gateway con i record di runtime della sessione dal ricevitore hook del connettore Claude. Gli attributi di identità (user.id, user.email, user.groups) aggiunti dal gateway vengono inseriti nella lista consentita degli attributi dell’operatore e diventano etichette di attribuzione sui bordi della sessione e sugli esempi di costo: non è necessario un nuovo codice destinatario.
Inserimento eventi di controllo. Il connettore claude-apps-gateway legge gli eventi di controllo JSON del gateway. Gli 11 tipi di eventi documentati (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) sono mappati alle osservazioni dell’SDK: i rifiuti rilevanti per la sicurezza diventano risultati, gli eventi di inferenza diventano bordi di accesso, i coni di sessione diventano osservazioni di identità e gli eventi operativi diventano contatori metrici. Le PII negli eventi grezzi hanno l’hashing SHA-256 prima di entrare in qualsiasi osservazione; le e-mail e gli identificatori sono pseudonimi.
Il connettore claude-apps-gateway esegue anche l’inventario dello stesso gateway.yaml: emittente OIDC, mappature gruppo IdP-modello, fornitori upstream, destinazioni OTLP e comportamento di amministrazione della spesa. Questo inventario è costituito da metadati strutturali: topologia, non credenziali.
Risultati della postura dalla configurazione del gateway
Il connettore genera una famiglia di risultati sulla postura derivati dalla configurazione del gateway. Queste sono le cose che un operatore di governance deve sapere sulla distribuzione del gateway:
| Trovare | Gravità | Cosa cattura |
|---|---|---|
| Nessuna destinazione OTLP configurata | Medio | La telemetria non viene inoltrata; la flotta è invisibile al monitoraggio |
| Nessuna politica onnicomprensiva | Alto | Gli utenti che non corrispondono a nessun gruppo IdP ricevono tutti i modelli e nessuna impostazione gestita |
| Nessun limite di spesa | Medio | L’API di amministrazione della spesa e l’applicazione non sono configurate |
| Letterali segreti in YAML | Alto | client_secret, jwt_secret o password del database scritte come valori letterali invece dei riferimenti ${VAR} o ${file:...} |
| TTL a sessione lunga (>12h) | Medio | Latenza di deprovisioning: la sessione di un utente revocato rimane valida |
| PKCE disabilitato | Basso | Il flusso OIDC non utilizza la chiave di prova per lo scambio di codice |
| Segnali telemetrici sensibili | Basso | logs: true o traces: true su una destinazione: possono trasportare comandi bash completi e percorsi di file |
Questi risultati appaiono nella stessa visualizzazione della postura dei risultati di ogni altro connettore. Il connettore MCP potrebbe segnalare uno strumento senza sandbox. Il connettore Bedrock potrebbe contrassegnare un guardrail gap. Il connettore gateway segnala che manca una policy generale. Una superficie, una vista.
Come appare nella configurazione
Il connettore Claude esegue un ricevitore OTLP sulle porte OpenTelemetry standard e un endpoint hook per gli hook PreToolUse/PostToolUse di Claude Code. Accanto a esso, il connettore apps-gateway legge il flusso di configurazione e controllo del gateway. Entrambi i connettori vengono forniti con Apache-2.0 e importati solo dall’SDK, mai dal core del motore.
# olivares.yaml (abbreviato)
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"Il campo gateway sul connettore Claude contrassegna ogni campione di costo con la superficie di distribuzione (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), in modo che FinOps possa suddividere la spesa in base al percorso del fornitore. Il campo semconv_opt_in abilita il profilo di acquisizione GenAI indipendente dal fornitore (aggiunto a OpenTelemetry semconv v1.41.1), il che significa che OpenAI, Gemini o qualsiasi agente dotato di strumenti OTel alimenta la stessa mappa di accesso e la stessa pipeline dei costi, non solo Claude Code.
Posizionamento onesto
Ci sono cose su cui vale la pena essere diretti.
Non si tratta di una sostituzione del gateway. Il proxy di inferenza Olivares implementa un sottoinsieme del protocollo gateway pubblicato di Anthropic (rilevamento OAuth, autorizzazione del dispositivo RFC 8628, distribuzione delle impostazioni gestite e superficie amministrativa dei limiti di spesa: visualizzazioni, scritture e applicazione per postazione, con le relative divergenze dal protocollo wire documentate). È utile quando quel sottoinsieme è sufficiente. Non sostituisce completamente il flusso OIDC del browser del gateway e la semantica di spesa del gruppo differisce deliberatamente (prevale il criterio più restrittivo anziché le regole di unione del gateway). Se il gateway Anthropic soddisfa i tuoi requisiti di autenticazione, eseguilo.
Il connettore è di sola lettura. Il connettore claude-apps-gateway osserva la configurazione del gateway e l’output di controllo. Non modifica gateway.yaml, non inserisce policy e non intercetta il percorso /v1/messages. È visibilità, non controllo.
Olivares AI è una versione pre-release. Il prodotto non è certificato ai sensi di SOC 2, ISO/IEC 27001, EU AI Act o qualsiasi altro quadro normativo e non è in corso alcun controllo. È progettato in base agli obiettivi di controllo esaminati da tali quadri, quindi è pronto per essere sottoposto a verifica quando sarà il momento.
Il valore è nella combinazione. Un team che esegue Claude Code solo con un provider, con un IdP e nessun server MCP di altri fornitori, potrebbe ritenere sufficiente il gateway da solo. La co-distribuzione guadagna il suo posto quando il patrimonio è eterogeneo: più fornitori, server MCP di più fornitori, modelli self-hosted, pipeline CI, requisiti di conformità che abbracciano l’intera superficie dell’agente. È qui che “Claude auth” e “governance patrimoniale” sono problemi veramente diversi.
Domande frequenti
Olivares AI sostituisce il gateway delle app Claude?
No. La dottrina è “e, non o”. Il gateway Anthropic possiede la sessione di autenticazione Claude Code, il routing di accesso al modello e la selezione upstream. Olivares AI rende tale distribuzione una superficie governata all’interno di un piano di controllo più ampio che copre anche provider non Claude, server MCP, modelli self-hosted e il resto del patrimonio degli agenti. Se esegui già il gateway, mantienilo.
Posso eseguire Olivares AI senza il gateway delle app Claude?
Sì. Il connettore claude-apps-gateway è opzionale. Il connettore Claude principale (connectors/claude) acquisisce la telemetria OTLP e si aggancia direttamente dalle sessioni Claude Code, con o senza gateway anteriore. Se non utilizzi il gateway Anthropic, perdi il percorso di autenticazione della sessione OIDC ma mantieni la governance completa: inventario delle sessioni, mappatura dei bordi di accesso, attribuzione dei costi, applicazione degli hook, postura MCP e visualizzazione multi-provider.
Per la topologia di distribuzione in dettaglio, vedere /architecture. Per la governance del server MCP tra i fornitori, vedere /product/mcp. Per la superficie completa del prodotto, vedere /product.