Gateway di app Claude per Amazon Bedrock, Claude Platform su AWS, Google Cloud e Microsoft Foundry

Esegui Claude Code attraverso Amazon Bedrock, Claude Platform su AWS, Google Cloud o Microsoft Foundry dietro un gateway auto-ospitato con accesso SSO, accesso ai modelli per gruppo e telemetria OTLP.

Claude apps gateway è un servizio auto-ospitato che si posiziona tra i client Claude Code dei tuoi sviluppatori e il tuo provider di modelli. Gli sviluppatori accedono con il tuo provider di identità aziendale (IdP) invece di detenere chiavi API o credenziali cloud. Il gateway contiene la credenziale upstream, applica l'accesso ai modelli e le impostazioni gestite per gruppo IdP, e trasmette la telemetria di utilizzo al tuo stack di osservabilità.

È incluso nel binario claude, quindi lo stesso eseguibile che esegue Claude Code su un laptop esegue il server gateway con claude gateway --config gateway.yaml.

Questa pagina copre:

• Perché Claude apps gateway, cosa aggiunge rispetto all'esecuzione della tua, e quando qualcos'altro si adatta meglio
• Una guida rapida con prerequisiti che porta un gateway da zero a uno sviluppatore connesso
• Connessione degli sviluppatori, inclusa l'impostazione dell'URL del gateway attraverso le impostazioni gestite
• Disponibilità e limitazioni che coprono quali funzionalità di Claude Code funzionano attraverso il gateway e cosa supporta il server

Le pagine complementari approfondiscono. Il riferimento di configurazione copre ogni opzione nel file YAML che la guida rapida scrive, e la guida di distribuzione copre la configurazione per IdP, la distribuzione su Kubernetes e Cloud Run, e le operazioni.

Perché Claude apps gateway

La panoramica del gateway copre cosa fa un gateway e perché ne eseguiresti uno. Claude apps gateway è il gateway di Anthropic, integrato nel binario claude e testato insieme a ogni rilascio di Claude Code, quindi inoltra le intestazioni e i campi di richiesta che Claude Code invia senza che gli operatori mantengano un elenco di autorizzazioni separato. Una volta distribuito, ti offre:

• Credenziali: la chiave API upstream o la credenziale cloud vive solo nella tua infrastruttura. Gli sviluppatori si autenticano con SSO aziendale e ricevono token bearer di breve durata, quindi l'offboarding avviene nel tuo IdP. Deprovision un utente e il suo accesso al gateway scade entro la durata della sessione, un'ora per impostazione predefinita.
• Controllo di accesso: i tuoi gruppi IdP si mappano agli elenchi di modelli consentiti e alle politiche di impostazioni gestite. Il gateway applica l'accesso ai modelli lato server, rifiutando le richieste per modelli non concessi, e seleziona la politica di impostazioni gestite di ogni gruppo, che il CLI applica al livello di impostazioni gestite. Diversi team ottengono diversi modelli, strumenti e autorizzazioni, e uno sviluppatore non può ignorare ciò che la sua politica blocca.
• Consegna delle impostazioni: il gateway consegna le impostazioni gestite ai client connessi stesso, prendendo il posto delle impostazioni gestite dal server dalla console amministratore di claude.ai.
• Telemetria: ogni destinazione configurata riceve metriche OpenTelemetry Protocol (OTLP) con conteggi di token, modello, identità dell'utente e latenza per impostazione predefinita, con log e tracce come opt-in per destinazione.
• Instradamento upstream: i client parlano l'API Anthropic Messages al gateway, e il gateway traduce per ogni upstream, sia Bedrock, Claude Platform su AWS, Agent Platform di Google Cloud, Foundry o l'API Anthropic, con failover tra loro. Puoi cambiare regioni, provider o ordine di failover senza che gli sviluppatori se ne accorgano o riconfigurino.

Per quali funzionalità di Claude Code funzionano attraverso il gateway e cosa supporta il server stesso, vedi Disponibilità e limitazioni di seguito. Per decisioni come costo, bypass, esecuzione di più gateway e piattaforme serverless, vedi la guida di distribuzione.

Altre implementazioni di gateway

Se esegui già un gateway LLM o un gateway API che soddisfa le tue esigenze, continua a usarlo; Altri gateway LLM copre la configurazione di Claude Code rispetto ad esso.

La guida di compatibilità del gateway documenta cosa Claude Code si aspetta da qualsiasi gateway: gli endpoint che chiama, le intestazioni e i campi del corpo da inoltrare, e cosa smette di funzionare quando vengono rimossi. Un gateway di app Claude in esecuzione serve anche il suo proprio riferimento di protocollo su GET /protocol, che descrive gli endpoint che espone ai client Claude Code: accesso SSO, inferenza, consegna di impostazioni gestite, scoperta di modelli e telemetria. Recuperalo con curl https://claude-gateway.internal.example.com/protocol da qualsiasi gateway distribuito, come quello che la guida rapida di seguito produce.

I cambiamenti di rottura del protocollo vengono annunciati in anticipo, ma la compatibilità all'indietro indefinita non è garantita.

Guida rapida

Questa guida rapida percorre il percorso minimo: registra un client OAuth nel tuo IdP, scrivi un gateway.yaml, esegui il gateway insieme a Postgres con Docker Compose, e verifica l'accesso end-to-end. Utilizza un upstream Amazon Bedrock; Claude Platform su AWS, Agent Platform di Google Cloud, Microsoft Foundry e l'API Anthropic sono ugualmente supportati scambiando il blocco upstreams come mostrato nel riferimento di configurazione. Alla fine hai un gateway a cui uno sviluppatore può /login.

Prerequisiti

Avere questi in atto prima di iniziare:

Passaggi

listen:
host: 0.0.0.0
port: 8080
# Obbligatorio a meno che l'host non sia un indirizzo loopback. Utilizzato per l'IdP
# redirect_uri e il documento di discovery.
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # deve servire /.well-known/openid-configuration
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # rifiuta id_tokens al di fuori della tua organizzazione
userinfo_fallback: true                  # per IdP il cui id_token omette email/groups; innocuo altrimenti

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # limita anche la latenza di revoca su deprovision IdP

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # aggiungi ?sslmode=require per Postgres gestito

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # vuoto: catena di credenziali predefinita AWS
# (IRSA, ruolo attività EC2/ECS, variabili env, ~/.aws)

# I modelli vengono tradotti per upstream automaticamente. Il catalogo integrato
# mappa claude-opus-4-8 a us.anthropic.claude-opus-4-8 e così via per ogni
# modello Claude supportato da Bedrock. Imposta false e aggiungi un elenco `models:` per
# esporre solo modelli specifici.
auto_include_builtin_models: true

services:
gateway:
image: registry.example.com/claude-gateway:2.1.198
ports: ["8080:8080"]
volumes: ["./gateway.yaml:/etc/claude/gateway.yaml:ro"]
environment:
OIDC_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
GATEWAY_JWT_SECRET: ${GATEWAY_JWT_SECRET}
GATEWAY_POSTGRES_URL: postgres://gw:pw@postgres/gateway
# Credenziali AWS: in produzione, ometti questi e usa un ruolo
# di istanza. Per il test locale di Compose, passa i tuoi:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_SESSION_TOKEN: ${AWS_SESSION_TOKEN}
depends_on:
postgres:
condition: service_healthy
postgres:
image: postgres:16-alpine
environment: { POSTGRES_USER: gw, POSTGRES_PASSWORD: pw, POSTGRES_DB: gateway }
healthcheck:
test: ["CMD-SHELL", "pg_isready -U gw"]
interval: 5s
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes: { pgdata: }

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info waiting for migration lock (another replica may be migrating; check pg_locks for key 6775156 if this persists)
[gateway] 2026-06-10T17:03:21.408Z info migration 1 applied
…
[gateway] 2026-06-10T17:03:21.431Z info migration 6 applied
[gateway] 2026-06-10T17:03:21.512Z info claude gateway listening on http://0.0.0.0:8080

curl -s https://claude-gateway.internal.example.com/.well-known/oauth-authorization-server | jq

{
"issuer": "https://claude-gateway.internal.example.com",
"device_authorization_endpoint": "…/oauth/device_authorization",
"token_endpoint": "…/oauth/token",
"grant_types_supported": ["urn:ietf:params:oauth:grant-type:device_code", "refresh_token"]
}

curl -s -X POST https://claude-gateway.internal.example.com/oauth/device_authorization | jq

{
"device_code": "…",
"user_code": "WDJB-MJHT",
"verification_uri": "https://claude-gateway.internal.example.com/device",
"verification_uri_complete": "https://claude-gateway.internal.example.com/device?user_code=WDJB-MJHT",
"expires_in": 600,
"interval": 5
}

Connetti gli sviluppatori

Gli sviluppatori si connettono dai loro laptop con un accesso al browser, utilizzando il loro account di lavoro aziendale. Non hanno bisogno di un account claude.ai, una chiave API o un abbonamento, perché le richieste al modello passano attraverso il gateway utilizzando la credenziale upstream dell'organizzazione. La connessione è guidata dalle impostazioni gestite lato client che spingere tramite MDM, quindi non c'è configurazione manuale sul lato dello sviluppatore; questa sezione copre cosa configura l'amministratore.

Il CLI impronta digitale il certificato foglia TLS del gateway al primo collegamento e lo blocca per nome host. Controlla di nuovo quel pin durante l'accesso, sui refresh di sessione silenziosi e sui recuperi di impostazioni gestite, mentre le richieste di inferenza utilizzano la convalida TLS standard senza il pin. Le richieste instradate attraverso un proxy HTTPS saltano il controllo del pin, quindi aggiungere l'host del gateway a NO_PROXY per mantenerle dirette.

Pubblica l'impronta digitale SHA-256 prevista insieme all'URL del gateway in modo che gli sviluppatori abbiano qualcosa da confrontare. Il prompt /login mostra i primi 16 caratteri dell'impronta digitale come esadecimale minuscolo senza due punti. Per stampare l'impronta digitale completa in quella forma dal file del certificato, eseguire:

openssl x509 -noout -fingerprint -sha256 -in cert.pem | cut -d= -f2 | tr -d : | tr 'A-F' 'a-f'

Quando il certificato ruota, ogni sviluppatore vede di nuovo il prompt di fiducia, quindi tratta le rotazioni come un evento pianificato e ripubblica l'impronta digitale. Se la politica del gateway include impostazioni che necessitano di approvazione, lo sviluppatore vede anche di nuovo quel dialogo di approvazione dopo aver accettato il nuovo certificato, perché Claude Code memoria di approvazione delle chiavi al certificato bloccato.

Una volta che lo sviluppatore accede, il selettore di modelli mostra i modelli nell'elenco di autorizzazione availableModels dello sviluppatore. Le impostazioni gestite si applicano all'avvio e si aggiornano ogni ora, e la telemetria si instrada al tuo raccoglitore.

Le sessioni si aggiornano silenziosamente prima della scadenza di ttl_hours. Quando un aggiornamento non riesce dopo il deprovision IdP, Claude Code richiede allo sviluppatore di accedere di nuovo.

Imposta l'URL del gateway

Tre chiavi vanno nel file di impostazioni gestite per OS che distribuisci tramite MDM o direttamente su disco. forceLoginMethod e forceLoginGatewayUrl aprono /login direttamente sulla schermata Cloud gateway con l'URL compilato, e parentSettingsBehavior: "merge" consente a Claude Desktop di consegnare l'elenco di autorizzazione di uscita del gateway alle sessioni di Claude Code che avvia, spiegato in Consegna la politica alle sessioni di Claude Desktop:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge"
}

Lo sviluppatore preme Invio per connettersi. Il prompt dell'impronta digitale TLS del primo collegamento appare ancora. Una volta che il file è su una macchina, uno sviluppatore che non ha completato l'accesso al gateway vede uno dei messaggi descritti in La politica dell'amministratore richiede un accesso al Cloud gateway. Gli sviluppatori che selezionano un provider cloud attraverso una variabile di ambiente come CLAUDE_CODE_USE_BEDROCK non hanno bisogno dell'accesso al gateway.

Uno sviluppatore non può configurare questo manualmente. Il selettore di accesso non ha opzione gateway e forceLoginGatewayUrl viene ignorato nei file di impostazioni personali di uno sviluppatore. forceLoginMethod da solo, senza un URL, lascia lo sviluppatore con un messaggio "Contatta il tuo amministratore IT". Le chiavi di accesso appartengono al file che spingere alle macchine, non al blocco managed.policies[].cli del gateway, che raggiunge solo i client già connessi.

Consegna la politica alle sessioni di Claude Desktop

Claude Desktop esegue le sue schede Cowork e Code, più la scheda Chat quando la abiliti, su sessioni di Claude Code incorporate e invia le loro richieste di modello attraverso il gateway. Passa la politica a ciascuna di quelle sessioni, costruita dalla configurazione che il gateway serve a /user/bootstrap: l'elenco di autorizzazione dei modelli, gli strumenti disabilitati e l'elenco di autorizzazione di uscita derivato dal blocco cli della politica corrispondente, più l'overlay desktop.

Altre chiavi cli, come hooks, env e regole di autorizzazione con ambito come Bash(npm *), raggiungono solo i client che accedono tramite /login. Claude Desktop legge l'URL del gateway dalla sua propria configurazione gestita e accede con il suo proprio flusso, separato dalle chiavi forceLoginMethod e forceLoginGatewayUrl in Imposta l'URL del gateway.

Le impostazioni passate da un processo di avvio sono impostazioni padre. Claude Code ignora le impostazioni padre su qualsiasi macchina che ha una fonte gestita distribuita dall'amministratore, a meno che la fonte che consegna la politica non imposti parentSettingsBehavior: "merge".

Quali macchine hanno bisogno dell'opt-in

Le macchine che eseguono solo Claude Desktop ne hanno bisogno. Claude Desktop applica l'elenco di modelli e l'elenco di strumenti disabilitati alle sessioni incorporate stesso, ma l'elenco di autorizzazione di uscita le raggiunge solo come impostazioni padre, sotto forma di regole di dominio WebFetch e regole di rete sandbox. Senza l'opt-in, quelle sessioni vengono eseguite senza la restrizione di uscita e nulla ti avverte. Il gateway rifiuta comunque le richieste di inferenza per i modelli che la politica non concede.

Le macchine in cui gli sviluppatori accedono tramite /login non ne hanno bisogno; ogni sessione di Claude Code recupera la sua politica dal gateway.

Le flotte il cui policyHelper fornisce impostazioni gestite non possono usarlo: Claude Code non unisce mai le impostazioni padre su quelle flotte, perché legge le impostazioni gestite solo dall'output dell'helper.

Imposta l'opt-in

Distribuisci lo snippet di impostazioni gestite da Imposta l'URL del gateway, specchialo su qualsiasi fonte lato client che supera il file, quindi verifica.

Limita le impostazioni padre

Una volta che distribuisci parentSettingsBehavior: "merge", qualsiasi processo host che avvia Claude Code può fornire impostazioni padre, non solo Claude Desktop ma anche un'applicazione Agent SDK o un'estensione IDE.

Claude Code filtra le impostazioni padre rispetto a un elenco di autorizzazione di chiavi restrittive, ma alcune chiavi consentite possono concedere accesso piuttosto che limitarlo. A meno che non imposti i blocchi allowManaged*Only, le regole di autorizzazione di autorizzazione e gli elenchi di autorizzazione sandbox forniti dall'host si applicano comunque. Le regole di negazione e richiesta della tua politica rimangono in vigore comunque; vengono valutate prima di qualsiasi regola di autorizzazione.

Claude Code inoltra le voci sandbox.credentials fornite dal padre in forma spogliata:

• Voci deny: inoltrate con solo il loro path o name e la modalità.
• Voci di file con mode: mask: inoltrate solo sentinel, come una maschera di file intero il cui injectHosts è l'elenco vuoto, quindi il proxy non sostituisce mai il valore reale per una voce fornita dal padre su nessuna piattaforma. Tutti i campi di mascheramento strutturato vengono eliminati anche, quindi un modello di estrazione fornito dal padre non può spostare una maschera più ristretta che un'altra fonte imposta per lo stesso percorso.
• Voci envVars con mode: mask: non inoltrate. deny è l'unica restrizione che il canale padre può esprimere attraverso le voci envVars.
• awsPairs e sigv4: inoltrate solo restrizione. Da sigv4, vengono mantenuti solo i valori deny e un padre che definisce un blocco sigv4 affatto blocca tutti e tre i moduli di richiesta, streaming, presigned e sigv4a, a deny. Una coppia awsPairs non viene mai inoltrata in una forma che può ri-firmare; una coppia che nomina una delle variabili AWS convenzionali viene sostituita da una voce inerte che mantiene l'accoppiamento automatico di AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN soppresso.

Distribuisci i blocchi

Per mantenere le impostazioni padre il più vicino possibile a solo restrizione come il filtro supporta, aggiungi tutti e cinque i blocchi allowManaged*Only e gli elenchi di autorizzazione che governano, alle stesse fonti come l'opt-in di unione:

{
  "forceLoginMethod": "gateway",
  "forceLoginGatewayUrl": "https://claude-gateway.internal.example.com",
  "parentSettingsBehavior": "merge",
  "allowManagedPermissionRulesOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedHooksOnly": true,
  "allowedMcpServers": [{ "serverUrl": "https://mcp.internal.example.com/*" }],
  "sandbox": {
    "network": {
      "allowManagedDomainsOnly": true,
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "filesystem": {
      "allowManagedReadPathsOnly": true,
      "denyRead": ["~/"],
      "allowRead": ["~/projects"]
    }
  }
}

Una politica del sistema operativo, come una politica del registro HKLM o un plist di preferenze gestite, supera questo file, quindi consegna l'intero snippet attraverso di esso invece del file. Le impostazioni gestite remote del gateway superano le fonti della politica del sistema operativo e del file ma raggiungono solo i client connessi. Specchia i blocchi, gli elenchi di autorizzazione e l'opt-in di unione nel blocco cli della politica e mantieni questo file distribuito, perché le macchine che non si connettono mai, incluse quelle che eseguono solo Claude Desktop, ottengono la loro politica dal file solo.

Comportamento del blocco tra le fonti

Impostare un blocco non limita gli altri; ogni chiave è documentata nel riferimento delle impostazioni. Da una fonte amministrativa sotto il vincitore, i due blocchi sandbox si applicano comunque e allowManagedPermissionRulesOnly blocca comunque le regole di autorizzazione fornite dal padre e additionalDirectories. I blocchi hooks e server MCP e l'effetto di allowManagedPermissionRulesOnly sulle regole personali dello sviluppatore hanno bisogno della fonte vincente per impostazione predefinita; secondo l'opt-in di unione managedSourcesBehavior in come Claude Code combina le fonti gestite, Claude Code applica il valore più rigoroso che qualsiasi fonte imposta per ogni blocco. Sulle flotte policyHelper, i blocchi vengono letti solo dall'output dell'helper.

Ogni blocco fa sì che Claude Code ignori le voci personali dello sviluppatore per quella impostazione, quindi includi gli elenchi di autorizzazione della tua organizzazione accanto ai blocchi. Bloccare i domini di rete con un elenco di dominio gestito vuoto blocca tutto il traffico in uscita in sandbox e bloccare i server MCP senza allowedMcpServers gestito o fornito dal padre carica ogni server che deniedMcpServers non blocca. Le voci allowRead solo ri-consentono i percorsi all'interno delle regioni denyRead, quindi abbinale a un denyRead gestito.

Impostazioni che i blocchi non coprono

Quattro impostazioni fornite dal padre passano il filtro anche con tutti e cinque i blocchi impostati. Secondo l'impostazione predefinita first-wins, il valore amministrativo che blocca quello del padre è quello nella fonte amministrativa con priorità più alta. Secondo l'opt-in di unione managedSourcesBehavior, come Claude Code combina le fonti gestite dice quale valore della fonte si applica invece.

• forceLoginOrgUUID: Claude Code onora un valore fornito dal padre quando la fonte amministrativa con priorità più alta non imposta un UUID org. L'accesso al gateway non controlla questa chiave, quindi importa solo per le flotte che utilizzano anche accessi Anthropic di prima parte. Un UUID org nella fonte amministrativa con priorità più alta blocca il valore del padre ed è quello che Claude Code applica, quindi imposta forceLoginOrgUUID lì.
• allowedMcpServers: Claude Code onora un elenco di autorizzazione fornito dal padre quando la fonte amministrativa con priorità più alta non ne imposta uno e allowManagedMcpServersOnly non lo blocca, perché il blocco applica qualunque elenco vinca come valore gestito, incluso un elenco fornito dal padre quando la fonte amministrativa con priorità più alta non ne imposta uno. Un elenco nella fonte amministrativa con priorità più alta blocca quello del padre ed è l'elenco che Claude Code applica, quindi imposta allowedMcpServers lì, accanto al blocco. Prima della v2.1.223, un valore per una delle due chiavi in qualsiasi fonte amministrativa bloccava quello del padre.
• availableModels: Claude Code onora un elenco di modelli fornito dal padre quando la fonte gestita vincente non ne imposta uno. Se la tua flotta limita i modelli, imposta availableModels nella fonte vincente.
• strictPluginOnlyCustomization: questa chiave passa il filtro indipendentemente da qualsiasi blocco e fa sì che Claude Code ignori la personalizzazione personale dello sviluppatore, inclusi gli hooks protettivi. Nessun blocco lo blocca.

Connetti Claude Desktop

Claude Desktop si connette allo stesso gateway attraverso una chiave MDM diversa: imposta bootstrapUrl nella configurazione gestita di Claude Desktop a <listen.public_url>/user/bootstrap e opt-in della politica dell'utente con una chiave desktop. L'overlay di Claude Desktop copre entrambe le metà. Richiede Claude Code v2.1.203 o successivo sul server del gateway.

Claude Desktop firma lo sviluppatore attraverso il provider di identità del gateway con lo stesso passaggio SSO del browser, quindi recupera la sua configurazione dal gateway invece che da Anthropic. L'accesso ai modelli e la politica seguono le stesse regole per gruppo come il CLI. Uno sviluppatore che utilizza sia il CLI che Claude Desktop accede a ciascuno separatamente; la sessione del gateway non è condivisa tra loro.

Una volta connesso, Claude Desktop invia richieste di modello da ogni scheda abilitata attraverso il gateway. Mostra le schede Cowork e Code per impostazione predefinita. Per attivare anche la scheda Chat, imposta chatTabEnabled a true nella configurazione gestita di Claude Desktop o nel blocco desktop della politica su un gateway che esegue Claude Code v2.1.227 o successivo.

Pipeline CI e macchine remote

Non c'è flusso di token di servizio per pipeline non presenziate. L'accesso al gateway esegue sempre il flusso del dispositivo del browser, quindi un lavoro CI senza uno sviluppatore per approvare l'accesso non può autenticarsi; configura quelli direttamente contro il tuo provider.

Una volta che uno sviluppatore ha effettuato l'accesso, ogni sessione di Claude Code su quella macchina utilizza la sessione del gateway, incluse le esecuzioni non interattive claude -p e le sessioni avviate da Agent SDK. Claude Code applica la politica del gateway a ciascuna di esse.

Il flusso del dispositivo separa il CLI di polling dal browser di approvazione, quindi una scatola di sviluppo remoto senza display funziona ancora: lo sviluppatore esegue /login su SSH sulla macchina remota e apre il link di verifica nel browser sul suo laptop.

Cosa viene applicato agli sviluppatori

Queste garanzie si applicano a ogni sessione connessa tramite /login. Le sessioni incorporate che Claude Desktop avvia ottengono la loro politica come descritto in Consegna la politica alle sessioni di Claude Desktop e il punto di telemetria dice dove vanno le loro esportazioni.

• Accesso ai modelli: le richieste per modelli che la politica non concede restituiscono 400 e il selettore /model viene filtrato all'elenco di autorizzazione availableModels della politica. Imposta enforceAvailableModels: true nella politica in modo che l'opzione Predefinita si risolva in un modello all'interno di availableModels invece che al valore predefinito integrato di Claude Code; senza di esso, Predefinita rimane selezionabile e viene rifiutata al momento della richiesta se quel modello non è concesso.
• Destinazione telemetria: nelle sessioni connesse tramite /login, il CLI invia le sue esportazioni OTLP/HTTP al gateway piuttosto che a un OTEL_EXPORTER_OTLP_ENDPOINT impostato localmente, a meno che una politica non nomini il tuo raccoglitore come endpoint. Il gateway inoltra le esportazioni che riceve alle destinazioni in telemetry.forward_to.
  • Nelle sessioni incorporate che Claude Desktop avvia, il CLI invia le sue esportazioni all'OTEL_EXPORTER_OTLP_ENDPOINT configurato. Il CLI allega il token di sessione del gateway a quelle esportazioni solo quando quell'endpoint punta al gateway stesso.
  • Senza una destinazione configurata per un segnale, il gateway lo accetta e lo scarta.
  • Se raccogli già la telemetria di Claude Code direttamente, aggiungi il tuo raccoglitore come destinazione forward_to o nominalo in una politica per saltare il relay.
• Credenziali: il token del gateway è l'unica credenziale della sessione. Profili Anthropic e qualsiasi accesso precedente a claude.ai vengono ignorati mentre connesso, quindi gli sviluppatori non hanno bisogno di disconnettersi da claude.ai per primo. Per una credenziale ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN o apiKeyHelper configurata, vedi La politica dell'amministratore richiede un accesso al Cloud gateway.
• Impostazioni gestite: le chiavi bloccate non possono essere ignorate localmente. Il CLI applica la politica all'avvio e applica le modifiche su ogni sondaggio orario, a parte le modifiche che si applicano solo al prossimo avvio.
• Avvio con il gateway irraggiungibile: le sessioni connesse escono all'avvio con un errore dopo circa 10 secondi piuttosto che iniziare senza le loro impostazioni.
• Avvio dopo che il gateway termina la sessione: vedi Applica fail-closed startup per i lanci che si aprono disconnessi dal gateway e quelli che escono quando il gateway risponde con un 401.
• Deprovision: una sessione il cui utente è disabilitato nell'IdP scade entro ttl_hours quando il prossimo aggiornamento fallisce.

Cosa può vedere l'organizzazione

La telemetria di utilizzo porta l'identità dello sviluppatore, i conteggi di token, il modello e la latenza al raccoglitore dell'organizzazione. Il gateway non registra o archivia il contenuto del prompt o del completamento. Se viene raccolta una telemetria più ricca come log e tracce, che può includere comandi e percorsi di file, è la scelta per destinazione dell'organizzazione.

Disponibilità e limitazioni

La tabella copre quali funzionalità di Claude Code funzionano quando gli sviluppatori si connettono attraverso il gateway e cosa supporta il server gateway stesso. Dove qualcosa non è supportato, la colonna Note fornisce l'alternativa.

Il gateway consegna i valori anthropic-beta che il CLI invia a ogni upstream, quindi gli operatori non mantengono un elenco di autorizzazioni beta. Per Amazon Bedrock, che ignora l'intestazione, il gateway sposta i valori nel campo anthropic_beta del corpo della richiesta; gli altri upstream ricevono l'intestazione come inviata.

Passaggi successivi

La guida rapida ti lascia con una configurazione minima in esecuzione sotto Docker Compose. Per andare oltre:

• Espandi gateway.yaml oltre la configurazione minima, ad esempio per aggiungere RBAC per gruppo, failover multi-upstream o destinazioni di telemetria. Il riferimento di configurazione copre ogni opzione.
• Passa da Compose a una distribuzione di produzione su Kubernetes o Cloud Run, configura correttamente il tuo IdP e rivedi il modello di sicurezza. La guida di distribuzione e operazioni copre la configurazione per IdP, i requisiti dell'immagine container, i probe di salute e la risoluzione dei problemi.
• Metti limiti di spesa su singoli sviluppatori o gruppi in modo che un carico di lavoro incontrollato non possa consumare il tuo intero impegno. Limiti di spesa copre l'API amministratore e come funziona l'applicazione.
• Per un esempio completo su AWS, con ECS Fargate o EKS, Amazon RDS e Secrets Manager, vedi Distribuisci su AWS.
• Per un esempio completo su Google Cloud, con Cloud Run, Cloud SQL e Secret Manager, vedi Distribuisci su Google Cloud.