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.

[!NOTE]

Il gateway di app Claude è progettato per le organizzazioni che devono — o preferiscono — instradare l'inferenza attraverso il proprio provider cloud, ad esempio per soddisfare i requisiti di residenza dei dati. Se non hai questo requisito e desideri accesso ad altre funzionalità come il provisioning SCIM o Claude Code su web e mobile, Claude Enterprise potrebbe essere una scelta migliore. Consulta la pagina di disponibilità delle funzionalità per un confronto completo di tutti i metodi di distribuzione.

Claude Code usa un solo accesso alla volta: un accesso tramite gateway sostituisce un login a Claude for Teams o Enterprise. Le sessioni tramite gateway non recuperano le impostazioni gestite dal server che configuri nella console di amministrazione di claude.ai, quindi forniscile dal blocco managed del gateway. Lascia forceLoginMethod e forceLoginOrgUUID fuori da quel blocco, altrimenti alcune sessioni con accesso effettuato terminano all'avvio. Consulta Disponibilità e limitazioni per sapere cosa perdono le sessioni tramite gateway.

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 i valori anthropic-beta e i campi di richiesta che Claude Code invia senza che gli operatori mantengano un'allowlist separata. Una volta fatto il deploy, 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 ad allowlist di modelli, politiche di impostazioni gestite e upstream. 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 permessi, e uno sviluppatore non può sovrascrivere 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.

[!NOTE]

Il piano dati del gateway stesso non invia nulla all'infrastruttura Anthropic a meno che l'API Anthropic non sia un upstream configurato. Controlli dove vanno la telemetria, i log di audit, le impostazioni gestite e l'identità IdP dei tuoi sviluppatori, e il gateway non li invia ad Anthropic. Per il traffico rimanente che il processo CLI può inviare e come chiuderlo, vedi Compliance posture.

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.

[!NOTE]

Un token di accesso al gateway identifica lo sviluppatore che ha approvato l'accesso, non il programma che lo usa. Claude Code accede senza un proprio client ID o secret, quindi un gateway non ha modo di verificare quale programma sta effettuando l'accesso. Qualsiasi client può impostare User-Agent e altri campi di richiesta, quindi usali per l'instradamento o per le metriche, non come prova che una richiesta provenga da Claude Code.

Guida rapida

Questa guida rapida percorre il cammino 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. Usa un upstream Amazon Bedrock; Claude Platform on AWS, Google Cloud's Agent Platform, Microsoft Foundry e l'API Anthropic sono ugualmente supportati sostituendo il blocco upstreams come mostrato nel riferimento di configurazione. Alla fine avrai un gateway a cui uno sviluppatore può accedere con /login.

[!NOTE]

Esegui il deploy sulla tua rete privata. Claude Code si connette solo a un gateway il cui indirizzo è privato. Si tratta di una protezione di sicurezza, perché un gateway attendibile può inviare impostazioni che eseguono comandi sulle macchine degli sviluppatori. Metti il gateway dietro un load balancer interno o una VPN e assegnagli un hostname che si risolva solo in IP privati. Se la tua rete interna è numerata con spazio IPv4 pubblico di proprietà della tua organizzazione, consulta Consentire un gateway su spazio di indirizzi pubblici di tua proprietà.

Prerequisiti

Prima di iniziare, assicurati di avere quanto segue:

Passaggi

1. Registra un client OAuth nel tuo IdP

Decidi prima l'hostname del gateway, perché l'URI di reindirizzamento deve corrispondere. Crea una nuova applicazione web OIDC e imposta l'URI di reindirizzamento su https://claude-gateway.<your-domain>/oauth/callback, dove l'host è lo stesso valore che imposti come listen.public_url nel passaggio 3. Annota client_id e client_secret. Le istruzioni per ciascun IdP si trovano in Configurazione del provider di identità.

2. Prepara un database PostgreSQL

Usa PostgreSQL 11 o successivo. Il tier gestito più piccolo è sufficiente. Il gateway esegue le proprie migrazioni dello schema all'avvio, quindi il ruolo del database necessita dei permessi per creare e modificare tabelle; consulta store.

3. Scrivi gateway.yaml

I segreti vengono letti tramite l'espansione ${ENV_VAR}, così il file stesso può stare nel controllo di versione. Usa un hostname public_url che si risolva in un IP privato sulla tua rete, perché /login rifiuta gli indirizzi pubblici. La configurazione minima ha cinque sezioni e ogni altro campo ha un valore predefinito:

listen:
  host: 0.0.0.0
  port: 8080
  # Required unless host is a loopback address. Used for the IdP
  # redirect_uri and the discovery document.
  public_url: https://claude-gateway.internal.example.com

oidc:
  issuer: https://login.example.com        # must serve /.well-known/openid-configuration
  client_id: 0oa1example2
  client_secret: ${OIDC_CLIENT_SECRET}
  allowed_email_domains: [example.com]        # reject id_tokens outside your org
  userinfo_fallback: true                  # for IdPs whose id_token omits email/groups; harmless otherwise

session:
  jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
  ttl_hours: 1                             # also bounds revocation latency on IdP deprovision

store:
  postgres_url: ${GATEWAY_POSTGRES_URL}    # add ?sslmode=require for managed Postgres

upstreams:
  - provider: bedrock
    region: us-east-1
    auth: {} # empty: AWS default credential chain
# (IRSA, EC2/ECS task role, env vars, ~/.aws)

# Models are translated per upstream automatically. The built-in catalog
# maps claude-opus-4-8 to us.anthropic.claude-opus-4-8 and so on for every
# Bedrock-supported Claude model. Set false and add a `models:` list to
# expose only specific models.
auto_include_builtin_models: true

Questa configurazione è sufficiente per un ciclo di accesso funzionante con il catalogo di modelli Amazon Bedrock predefinito. Una volta in esecuzione, aggiungi RBAC per gruppo e impostazioni gestite tramite managed.policies, la distribuzione della telemetria tramite telemetry e il failover multi-upstream, gli ARN di provisioned throughput o le regioni non statunitensi tramite models.

[!NOTE]

L'upstream Amazon Bedrock necessita di un principal AWS con bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream sia sugli ARN inference-profile/us.anthropic.* sia sugli ARN sottostanti foundation-model/anthropic.*. Richiede inoltre che il modulo una tantum di Anthropic sul caso d'uso sia stato inviato per l'account dal Model catalog della console Bedrock.

Fornisci la credenziale con IRSA su EKS, un task role ECS o un instance profile EC2 anziché con chiavi statiche. Il riferimento upstreams contiene tutti i dettagli IAM, la matrice delle credenziali cross-cloud e i blocchi auth per gli altri provider.

4. Eseguilo

Crea un'immagine container attorno al binario claude che soddisfi i requisiti dell'immagine, quindi eseguila insieme a Postgres. Il file Compose fa riferimento all'immagine come registry.example.com/claude-gateway:2.1.198; sostituisci il tuo registry e il tuo tag dell'immagine:

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
      # AWS credentials: in production, omit these and use an instance
      # role. For local Compose testing, pass through your own:
      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: }

Il gateway è un singolo binario Linux che legge la configurazione, si connette a Postgres e applica le migrazioni dello schema, esegue la discovery OIDC verso il tuo IdP, crea i client upstream e inizia ad ascoltare.

L'avvio è fail-closed per la configurazione, la connessione a Postgres, la discovery OIDC e la creazione dei client upstream. Se uno di questi elementi non è raggiungibile o è configurato in modo errato, il gateway termina con un errore anziché servire traffico in uno stato degradato.

Un avvio riuscito non convalida il percorso di inferenza, perché le credenziali di istanza di Amazon Bedrock e di Google Cloud's Agent Platform vengono risolte alla prima richiesta, non all'avvio.

Controlla stderr per la sequenza di avvio. Le righe di log usano il formato [gateway] <timestamp> <level> <message>, gli eventi di audit sono JSON su una singola riga con un campo evt e un banner di avvio, omesso qui sotto, viene stampato tra le righe di migrazione e quella di ascolto. Un database nuovo stampa una riga migration N applied per ciascuna migrazione dello schema; un database già migrato non ne stampa nessuna. Dovresti vedere, in ordine:

{"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

Il gateway registra anche un avviso che access_control.allow_cidrs è vuoto. In questo caso è previsto, perché nulla limita gli indirizzi client serviti dal gateway finché non imposti una allow list. Il riferimento access_control indica gli intervalli consigliati.

Se l'avvio termina prima della riga claude gateway listening on, l'ultima riga di stderr indica il problema:

• un Postgres non raggiungibile
• un ruolo Postgres senza permesso DDL
• un documento di discovery OIDC non raggiungibile o non valido
• una violazione dello schema di configurazione con il percorso del campo problematico

Correggilo e riavvia.

Se hai già un ingress che termina TLS, salta Compose ed esegui direttamente il binario con claude gateway --config gateway.yaml. Imposta public_url sull'origine dell'ingress e associa listen a un indirizzo di loopback o interno al cluster.

5. Verifica la superficie di autenticazione

Tre controlli confermano che il gateway è in grado di autenticare un utente reale prima di condividerlo con uno sviluppatore.

Gli esempi usano l'URL pubblico del gateway; per la configurazione Compose locale senza ingress, sostituisci http://localhost:8080 nei primi due controlli. Il terzo controllo apre verification_uri_complete, che è costruito a partire da public_url, quindi per Compose locale imposta public_url: http://localhost:8080 in gateway.yaml e aggiungi http://localhost:8080/oauth/callback come secondo URI di reindirizzamento sul client OAuth del passaggio 1, perché il gateway costruisce il redirect_uri dell'IdP a partire da public_url. Il link di verifica si apre quindi nel tuo browser locale.

In Windows PowerShell, esegui curl.exe; il semplice curl è un alias di Invoke-WebRequest e rifiuta questi flag.

Per prima cosa, recupera il documento di discovery, che conferma che il gateway è attivo, la configurazione è valida e tutti i controlli di avvio sono stati superati:

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"]
}

La risposta include campi aggiuntivi, come response_types_supported e scopes_supported.

In secondo luogo, richiedi un'autorizzazione del dispositivo, che conferma che il flusso di accesso del dispositivo funziona e che Postgres è raggiungibile e scrivibile:

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
}

In terzo luogo, verifica la parte del browser aprendo verification_uri_complete in un browser e confermando il codice. Dovresti essere reindirizzato alla pagina di accesso del tuo IdP e, dopo l'accesso, tornare al gateway con una conferma di accesso avvenuto.

Usa il primo controllo non superato per individuare il problema:

• Il primo controllo fallisce: l'avvio non è stato completato; controlla stderr
• Il secondo controllo fallisce: Postgres non è raggiungibile dal gateway o il ruolo non può scrivere; controlla la stringa di connessione e i grant
• Il terzo controllo non raggiunge l'IdP: verifica che l'URI di reindirizzamento dell'IdP corrisponda esattamente a https://<gateway>/oauth/callback
• Il terzo controllo raggiunge l'IdP ma torna indietro con un errore: leggi il log di audit del gateway, che registra ogni rifiuto di autenticazione con il motivo, ad esempio email domain not allowed

6. Fai accedere uno sviluppatore

Quest'ultimo passaggio avviene sulla macchina di uno sviluppatore, non sul server. Imposta forceLoginMethod su "gateway", forceLoginGatewayUrl sul public_url del tuo gateway e parentSettingsBehavior su "merge" nel file delle impostazioni gestite di quella macchina, quindi esegui /login, premi Enter nella schermata Cloud gateway e completa l'accesso nel browser. La sezione Impostare l'URL del gateway più avanti descrive le tre chiavi e come distribuirle a ogni macchina degli sviluppatori.

Connettere gli sviluppatori

Gli sviluppatori si connettono dai propri laptop con un unico accesso tramite browser, usando il proprio account aziendale. Non hanno bisogno di un account claude.ai, di una chiave API o di un abbonamento, perché le richieste al modello passano attraverso il gateway usando la credenziale upstream dell'organizzazione. La connessione è guidata dalle impostazioni gestite lato client che distribuisci tramite MDM, e questa sezione descrive ciò che configura l'amministratore.

La CLI calcola l'impronta del certificato TLS foglia del gateway alla prima connessione e la fissa per nome host. Controlla di nuovo questa impronta fissata durante l'accesso, nei rinnovi silenziosi della sessione e nel recupero delle impostazioni gestite, mentre le richieste di inferenza usano la normale convalida TLS senza l'impronta fissata. Le richieste instradate tramite un proxy HTTPS saltano il controllo dell'impronta, quindi aggiungi l'host del gateway a NO_PROXY per mantenerle dirette.

Pubblica l'impronta SHA-256 prevista insieme all'URL del gateway, in modo che gli sviluppatori abbiano un riferimento con cui confrontarla. Il prompt di /login mostra i primi 16 caratteri dell'impronta in esadecimale minuscolo senza due punti. Per stampare l'impronta completa in quella forma dal file del certificato, esegui:

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

Quando il certificato viene ruotato, ogni sviluppatore vede di nuovo la richiesta di attendibilità, quindi tratta le rotazioni come un evento pianificato e ripubblica l'impronta. Se la policy del tuo gateway include impostazioni che richiedono approvazione, dopo aver accettato il nuovo certificato lo sviluppatore vede di nuovo anche quella finestra di approvazione, perché Claude Code associa la memoria delle approvazioni al certificato fissato.

Un gateway può restituire il campo facoltativo email nella sua risposta del token per indicare l'account usato per un accesso. In tal caso, lo sviluppatore conferma l'account prima che Claude Code salvi la credenziale. Dopo un accesso confermato, /status mostra l'account.

La conferma richiede Claude Code v2.1.275 o successivo sulla macchina dello sviluppatore; un client con una versione precedente ignora il campo. Il server gateway incluso nel binario claude non restituisce il campo, quindi i suoi accessi si completano senza la conferma.

Una volta che lo sviluppatore ha effettuato l'accesso, il selettore dei modelli mostra i modelli presenti nella sua allowlist availableModels. Le impostazioni gestite si applicano all'avvio e si aggiornano ogni ora, e la telemetria viene instradata al tuo collector.

Le sessioni si rinnovano silenziosamente prima della scadenza di ttl_hours. Quando un rinnovo fallisce dopo il deprovisioning nell'IdP, Claude Code chiede allo sviluppatore di accedere di nuovo.

Impostare l'URL del gateway

Tre chiavi vanno nel file di impostazioni gestite specifico per sistema operativo che distribuisci tramite MDM o direttamente su disco. Per una macchina senza impostazioni gestite, consulta invece Impostare l'URL del gateway nelle impostazioni utente. forceLoginMethod e forceLoginGatewayUrl aprono /login direttamente sulla schermata Cloud gateway con l'URL già compilato, e parentSettingsBehavior: "merge" consente a Claude Desktop di fornire l'allowlist di uscita del gateway alle sessioni di Claude Code che avvia, come spiegato in Fornire la policy alle sessioni di Claude Desktop:

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

Lo sviluppatore preme Enter per connettersi. La richiesta dell'impronta TLS alla prima connessione compare comunque. Una volta che il file si trova su una macchina, uno sviluppatore che non ha completato l'accesso al gateway vede uno dei messaggi descritti in Administrator policy requires a Cloud gateway sign-in. Gli sviluppatori che selezionano un provider cloud tramite una variabile d'ambiente come CLAUDE_CODE_USE_BEDROCK non hanno bisogno dell'accesso al gateway.

Il selettore di accesso non ha un'opzione gateway e, nelle impostazioni gestite, forceLoginMethod da solo, senza un URL, lascia lo sviluppatore davanti a un messaggio "Contact your IT administrator". Le chiavi di accesso vanno nel file che distribuisci alle macchine, non nel blocco managed.policies[].cli del gateway, che raggiunge solo i client già connessi.

Impostare l'URL del gateway nelle impostazioni utente

Sulle macchine senza impostazioni gestite, fai aggiungere a ogni sviluppatore forceLoginMethod e forceLoginGatewayUrl al proprio file di impostazioni utente, ~/.claude/settings.json. Questo richiede Claude Code v2.1.295 o successivo sulla macchina dello sviluppatore. Questo esempio indica un gateway su claude-gateway.internal.example.com:

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

Quando lo sviluppatore esegue /login nel prompt di Claude Code, la schermata Cloud gateway si apre su quell'indirizzo e lo sviluppatore preme Enter per connettersi. La richiesta dell'impronta TLS alla prima connessione compare comunque. Alle chiavi impostate in questo modo si applicano questi limiti:

• Solo impostazioni utente: Claude Code legge le due chiavi da ~/.claude/settings.json, non dal .claude/settings.json o dal .claude/settings.local.json di un progetto.
• Le impostazioni gestite le disattivano: una volta che le impostazioni di un amministratore raggiungono la macchina tramite un file di impostazioni gestite, un plist macOS o una policy HKLM di Windows, oppure un policy helper, Claude Code ignora un gateway indicato nelle impostazioni utente.

Consentire un gateway su uno spazio di indirizzi pubblico di tua proprietà

Alcune organizzazioni numerano la propria rete interna a partire da un blocco IPv4 pubblico di loro proprietà, come lo spazio di indirizzi di un operatore o un /8 storico, quindi il loro gateway non ha un indirizzo privato. Elenca questi blocchi nell'impostazione gestita gatewayInternalNetworks. /login accetta quindi un gateway all'interno di un blocco elencato quando la macchina dello sviluppatore si connette a esso da un indirizzo all'interno dello stesso blocco. Questo richiede Claude Code v2.1.268 o successivo sulla macchina dello sviluppatore; le versioni precedenti ignorano la chiave e applicano la regola degli indirizzi privati.

[!WARNING]

gatewayInternalNetworks è pensato per le reti interne che risultano numerate a partire da uno spazio di indirizzi pubblico. Non rende sicuro esporre un gateway su internet: un gateway attendibile può distribuire impostazioni che eseguono comandi sulle macchine degli sviluppatori.

Mantieni il gateway irraggiungibile dall'esterno della tua rete con le regole del firewall o del load balancer. Imposta access_control.allow_cidrs del gateway sugli stessi blocchi che dichiari qui, in modo che il gateway stesso rifiuti i client provenienti da qualsiasi altro luogo. Dietro un load balancer o un ingress, imposta anche listen.trusted_proxies su quel front end, perché altrimenti il gateway confronta allow_cidrs con l'indirizzo del front end anziché con quello dello sviluppatore.

Aggiungi la chiave alla stessa origine di impostazioni gestite delle chiavi di accesso: il file di impostazioni gestite, il profilo MDM o la policy del registro. Claude Code la ignora nelle impostazioni utente, di progetto e gestite dal server.

Questo esempio dichiara un blocco. Sostituisci 203.0.113.0/24 con il tuo blocco. Si tratta di un intervallo di documentazione, e Claude Code li rifiuta.

{
  "gatewayInternalNetworks": ["203.0.113.0/24"]
}

Claude Code convalida l'elenco in /login prima di contattare qualsiasi gateway:

• Ogni voce è un blocco IPv4 scritto come primo indirizzo e un prefisso da /8 a /32.
• L'elenco contiene al massimo quattro blocchi, e nessuno si sovrappone a un altro.
• Nessun blocco si sovrappone allo spazio di indirizzi privato: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 e 100.64.0.0/10. /login accetta già un gateway lì senza questa chiave.
• Nessun blocco si sovrappone a uno spazio che non è mai la rete di un'organizzazione: 198.18.0.0/15 e 192.0.0.0/24, che i client VPN e NAT64 usano come indirizzi locali; gli intervalli di documentazione 192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24; e gli intervalli riservati 0.0.0.0/8, 192.88.99.0/24 e multicast 224.0.0.0/4. Puoi dichiarare blocchi all'interno di 240.0.0.0/4, che alcune reti di grandi dimensioni usano come spazio unicast interno.

I blocchi di managed-settings.json e dei relativi file drop-in managed-settings.d/ si combinano in un unico elenco, e questi limiti si applicano all'elenco combinato. Per restringere un blocco, sostituisci la sua voce anziché aggiungerne una seconda sovrapposta in un drop-in; /login rifiuta la sovrapposizione.

Se una voce viola una regola, o il valore non è un elenco di stringhe, Claude Code rifiuta ogni nuovo accesso al gateway su quella macchina e indica il problema nel messaggio. Anche l'accesso a un gateway su un indirizzo privato fallisce, mentre gli accessi esistenti continuano a funzionare. Prova il valore su una macchina prima di distribuirlo. Claude Code elenca inoltre un valore di tipo errato tra le impostazioni gestite non valide che segnala.

Con un elenco valido, /login applica tre controlli a un gateway il cui indirizzo si trova all'interno di un blocco elencato:

• Ogni indirizzo a cui si risolve il nome host del gateway si trova all'interno di quell'unico blocco. Claude Code rifiuta un nome che ha anche record al di fuori di esso, compresi gli indirizzi privati e IPv6.
• La macchina dello sviluppatore si connette dall'interno dello stesso blocco. Claude Code rifiuta una macchina dietro NAT, all'interno di un container o di WSL2, o su una VPN il cui pool di indirizzi si trova al di fuori del blocco, e indica l'indirizzo da cui la macchina si è connessa.
• La connessione è diretta. Se HTTPS_PROXY si applica all'host del gateway, /login rifiuta e indica la voce NO_PROXY da aggiungere.

Quando tutti e tre i controlli hanno esito positivo, la richiesta di attendibilità aggiunge una riga che indica l'indirizzo della macchina, l'indirizzo del gateway e il blocco dichiarato che li contiene entrambi.

La chiave non cambia nulla per gli altri gateway: l'accesso a uno su un indirizzo privato funziona come prima, e l'accesso a uno su un indirizzo pubblico al di fuori di tutti i blocchi elencati viene rifiutato come prima.

Un blocco dichiarato restringe chi può accedere ma non dimostra dove si trova una macchina, quindi dichiara solo lo spazio di indirizzi controllato dalla tua organizzazione. Un blocco condiviso con altri tenant, come l'intervallo pubblico di un provider cloud, consente a chiunque vi si trovi di superare lo stesso controllo.

Fornire la policy alle sessioni di Claude Desktop

Claude Desktop esegue le sue schede su sessioni Claude Code incorporate e invia le loro richieste al modello tramite il gateway. Passa una policy a ciascuna di queste sessioni, costruita a partire dalla configurazione che il gateway gli fornisce su /user/bootstrap. Questa configurazione contiene l'allowlist dei modelli, gli strumenti disabilitati e l'allowlist del traffico in uscita derivati dal blocco cli o code della policy corrispondente, più l'overlay desktop.

Le altre chiavi del blocco, come gli hook, env e le regole di permesso con ambito come Bash(npm *), raggiungono i client che accedono tramite /login. Sotto code, raggiungono anche la sessione della scheda Code quando sono soddisfatte le condizioni per la scheda Code. Non raggiungono le sessioni Cowork o Chat. Claude Desktop legge l'URL del gateway dalla propria configurazione gestita e accede con il proprio flusso, separato dalle chiavi forceLoginMethod e forceLoginGatewayUrl descritte in Impostare 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 un'origine gestita distribuita da un amministratore, a meno che l'origine che fornisce la policy non imposti parentSettingsBehavior: "merge".

Quali macchine richiedono l'opt-in

Le macchine che eseguono solo Claude Desktop ne hanno bisogno. Claude Desktop applica direttamente l'elenco dei modelli e l'elenco degli strumenti disabilitati alle sessioni incorporate, ma l'allowlist di uscita le raggiunge solo come impostazioni padre, sotto forma di regole di dominio WebFetch e regole di rete della sandbox. Senza l'opt-in, queste sessioni vengono eseguite senza la restrizione in uscita, e nulla te lo segnala. Il gateway rifiuta comunque le richieste di inferenza per i modelli che la policy non concede.

Anche un'allowlist di marketplace di plugin raggiunge le sessioni incorporate solo come impostazioni padre. Quando disattivi i marketplace di plugin aggiunti dagli utenti nella configurazione gestita di Claude Desktop, Claude Desktop 2.16120.0 o successivo nasconde i marketplace che la tua organizzazione non ha predisposto e rifiuta le installazioni da essi. Per impedire alle sessioni incorporate di caricare i plugin già installati da quei marketplace, invia loro un elenco strictKnownMarketplaces come impostazioni padre. Senza l'opt-in, Claude Code ignora quell'elenco, e quei plugin continuano a essere caricati.

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

Le flotte il cui policyHelper fornisce le impostazioni gestite non possono usarlo: Claude Code non esegue mai il merge delle impostazioni padre su queste flotte, perché legge le impostazioni gestite esclusivamente dall'output dell'helper.

Impostare l'opt-in

Distribuisci lo snippet di impostazioni gestite da Impostare l'URL del gateway, replicalo in qualsiasi origine lato client con priorità superiore al file, quindi verifica.

1. Distribuisci l'opt-in nel file di impostazioni gestite

Lo snippet sopra include già parentSettingsBehavior: "merge", quindi il file che distribuisci alle macchine lo contiene.

2. Replica lo snippet in qualsiasi origine con priorità superiore al file

Claude Code legge parentSettingsBehavior solo dall'origine selezionata. Aggiungere una qualsiasi chiave di policy a un'origine può rendere quell'origine quella selezionata, quindi in un'origine lato client replica l'intero snippet anziché solo parentSettingsBehavior. Impostazioni gestite lato client tratta le flotte che forniscono la policy tramite Group Policy o profili di configurazione. Un plist di preferenze gestite su macOS o una policy HKLM su Windows ha priorità sul file managed-settings.json, e le impostazioni gestite remote del gateway hanno priorità su entrambi, quindi sulle macchine che accedono al gateway imposta parentSettingsBehavior anche nel blocco cli o code della policy del gateway.

3. Verifica quale origine è selezionata

Su una macchina che esegue solo Claude Desktop, chiama resolveSettings() dell'Agent SDK e leggi policyOrigin nella voce managed del suo elenco sources. Il valore indica l'origine lato client selezionata, plist, hklm o file, che è l'origine che deve contenere lo snippet.

Le sessioni Cowork e Chat non recuperano la policy del gateway, quindi per esse il blocco del gateway non è l'origine selezionata.

Una sessione della scheda Code la recupera quando le impostazioni della policy si trovano sotto code e sono soddisfatte le condizioni per la scheda Code. Le impostazioni code del gateway sono quindi l'origine selezionata per quella sessione.

Limitare le impostazioni padre

Una volta distribuito 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'allowlist di chiavi restrittive, ma alcune chiavi consentite possono concedere accesso anziché limitarlo. A meno che tu non imposti i blocchi allowManaged*Only, le regole di permesso allow e le allowlist della sandbox fornite dall'host si applicano comunque. Le regole deny e ask della tua policy restano in vigore in ogni caso; vengono valutate prima di qualsiasi regola allow.

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

• Voci deny: inoltrate solo con il loro path o name e la modalità.
• Voci di file con mode: mask: inoltrate solo come sentinella, come maschera dell'intero file il cui injectHosts è l'elenco vuoto, quindi il proxy non sostituisce mai il valore reale per una voce fornita dal padre su nessuna piattaforma. Vengono eliminati anche tutti i campi di mascheramento strutturato, quindi un pattern di estrazione fornito dal padre non può sostituire una maschera più rigorosa impostata da un'altra origine per lo stesso percorso.
• Voci envVars con mode: mask: non inoltrate. deny è l'unica restrizione che il canale padre può esprimere tramite le voci envVars.
• awsPairs e sigv4: inoltrati solo come restrizioni. Di sigv4 vengono mantenuti solo i valori deny, e un padre che definisce un qualsiasi blocco sigv4 fissa tutte e tre le forme di richiesta, streaming, presigned e sigv4a, su deny. Una coppia awsPairs non viene mai inoltrata in una forma che possa rifirmare; una coppia che indica una delle variabili AWS convenzionali viene sostituita da una voce inerte che mantiene soppresso l'abbinamento automatico di AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN.

Distribuire i blocchi

Per mantenere le impostazioni padre il più possibile limitate alle sole restrizioni, per quanto consentito dal filtro, aggiungi tutti e cinque i blocchi allowManaged*Only, e le allowlist che governano, alle stesse origini dell'opt-in di merge:

{
  "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 policy del sistema operativo, come una policy del registro HKLM o un plist di preferenze gestite, ha priorità su questo file, quindi fornisci l'intero snippet tramite essa anziché tramite il file. Le impostazioni gestite remote del gateway hanno priorità sulle origini della policy del sistema operativo e del file, ma raggiungono solo i client connessi. Replica i blocchi, le allowlist e l'opt-in di merge nel blocco cli o code della policy e mantieni distribuito questo file, perché le macchine che non si connettono mai ricevono la policy esclusivamente dal file.

Comportamento dei blocchi tra le origini

Impostare un blocco non limita gli altri; ogni chiave è documentata nel riferimento delle impostazioni.

Da un'origine di amministrazione inferiore a quella prevalente, i due blocchi della sandbox si applicano comunque, e allowManagedPermissionRulesOnly blocca comunque le regole allow e le additionalDirectories fornite dal padre. Su Claude Code v2.1.273 o successivo, anche il blocco dei server MCP si applica da un'origine inferiore a quella prevalente e, mentre è attivo, l'elenco gestito allowedMcpServers proviene dall'origine di amministrazione con priorità più alta che ne imposta uno.

Il blocco degli hook e l'effetto di allowManagedPermissionRulesOnly sulle regole dello sviluppatore richiedono per impostazione predefinita l'origine prevalente; con l'opt-in di merge managedSourcesBehavior descritto in come Claude Code combina le origini gestite, Claude Code applica per ogni blocco il valore più restrittivo impostato da qualsiasi origine. Sulle flotte con policyHelper, Claude Code legge i blocchi esclusivamente dall'output dell'helper.

Ogni blocco fa sì che Claude Code ignori le voci dello sviluppatore per quell'impostazione, quindi includi le allowlist della tua organizzazione accanto ai blocchi:

• Domini di rete: un blocco con un elenco di domini gestiti vuoto blocca tutto il traffico in uscita dalla sandbox.
• Server MCP: un blocco senza allowedMcpServers in nessuna origine di amministrazione né nelle impostazioni fornite dal padre carica ogni server che deniedMcpServers non blocca.
• Percorsi di lettura: le voci allowRead riconsentono solo percorsi all'interno delle aree denyRead, quindi abbinale a un denyRead gestito.

Impostazioni non coperte dai blocchi

Queste impostazioni fornite dal padre superano il filtro anche con tutti e cinque i blocchi impostati:

• forceLoginOrgUUID: Claude Code rispetta un valore fornito dal padre quando le impostazioni gestite che applica non impostano un UUID dell'organizzazione. L'accesso al gateway non controlla questa chiave. Un UUID dell'organizzazione nelle impostazioni gestite applicate da Claude Code blocca il valore del padre ed è l'UUID dell'organizzazione che Claude Code impone. Se la tua flotta fissa un'organizzazione Anthropic, consulta Quale origine gestita fornisce le chiavi di accesso per sapere dove impostare forceLoginOrgUUID.
• allowedMcpServers: Claude Code rispetta un'allowlist fornita dal padre quando non è in vigore alcun elenco di amministrazione. allowManagedMcpServersOnly non la blocca, perché il blocco impone come valore gestito l'elenco che prevale, compreso uno fornito dal padre quando nessuna origine di amministrazione fornisce un elenco. Un elenco nell'origine di amministrazione con priorità più alta blocca quello del padre ed è l'elenco che Claude Code impone, quindi imposta allowedMcpServers lì, accanto al blocco. Prima della v2.1.223, un valore per una delle due chiavi in qualsiasi origine di amministrazione bloccava quello del padre.
• availableModels: Claude Code rispetta un elenco di modelli fornito dal padre quando l'origine gestita prevalente non ne imposta uno. Se la tua flotta limita i modelli, imposta availableModels nell'origine prevalente.
• allowedProviders: Claude Code rispetta un'allowlist dei provider API fornita dal padre quando l'origine gestita prevalente non ne imposta una. Se la tua flotta limita i provider API che gli sviluppatori possono usare, imposta allowedProviders nell'origine prevalente. Richiede Claude Code v2.1.285 o successivo.
• strictKnownMarketplaces: Claude Code rispetta un'allowlist di marketplace di plugin fornita dal padre quando l'origine gestita prevalente non ne imposta una. Claude Desktop 2.16120.0 o successivo ne invia una quando la sua configurazione gestita disattiva i marketplace di plugin aggiunti dagli utenti. Se la tua flotta limita i marketplace, imposta strictKnownMarketplaces nell'origine prevalente. Richiede Claude Code v2.1.282 o successivo.
• blockedMarketplaces: una blocklist di marketplace fornita dal padre supera il filtro e si aggiunge a qualsiasi blocklist impostata da un'origine gestita, poiché una blocklist può solo restringere ulteriormente. Richiede Claude Code v2.1.282 o successivo.
• strictPluginOnlyCustomization: questa chiave supera il filtro indipendentemente da qualsiasi blocco, e fa sì che Claude Code ignori le personalizzazioni dello sviluppatore, compresi gli hook di protezione. Nessun blocco la blocca.

Se imposti managedSourcesBehavior su "merge", verifica quale valore di origine si applica per ciascun tipo di chiave.

Come hanno effetto le chiavi di hook e skill nelle impostazioni padre

Le chiavi che la tua applicazione passa nell'opzione managedSettings dell'Agent SDK sono impostazioni padre. Su una macchina in cui un amministratore distribuisce impostazioni gestite, Claude Code ignora le impostazioni padre a meno che l'amministratore non consenta a un host incorporante di aggiungere policy.

Se passi disableAllHooks: true in managedSettings:

• Si fermano: gli hook utente, di progetto e locali, più gli hook dichiarati nel frontmatter degli agenti o nell'opzione settings dell'SDK.
• Continuano a essere eseguiti: le callback degli hook SDK della tua applicazione e gli hook di un amministratore provenienti dalle impostazioni gestite. La tua applicazione non può disattivare gli hook dell'amministratore.

Passare queste chiavi in managedSettings richiede Claude Code v2.1.309 o successivo, oppure TypeScript Agent SDK v0.3.309 o successivo.

Connettere Claude Desktop

Claude Desktop si connette allo stesso gateway tramite una chiave MDM diversa: imposta bootstrapUrl nella configurazione gestita di Claude Desktop su <listen.public_url>/user/bootstrap, e abilita la policy dell'utente con una chiave desktop. Overlay di Claude Desktop tratta entrambe le parti. Richiede Claude Code v2.1.203 o successivo sul server gateway. Una volta connesso, Claude Desktop invia le richieste al modello da ogni scheda abilitata attraverso il gateway.

Claude Desktop fa accedere lo sviluppatore tramite l'identity provider del gateway con lo stesso passaggio di SSO nel browser, quindi recupera la propria configurazione dal gateway anziché da Anthropic. L'accesso ai modelli e la policy seguono le stesse regole per gruppo della CLI. Uno sviluppatore che usa sia la CLI sia Claude Desktop accede a ciascuno separatamente; la sessione del gateway non è condivisa tra i due.

Pipeline CI e macchine remote

Non esiste un flusso con token di servizio per le pipeline non presidiate. L'accesso al gateway esegue sempre il device flow nel browser, quindi un job CI senza uno sviluppatore che approvi l'accesso non può autenticarsi; configura questi job direttamente sul tuo provider. Distribuisci forceLoginMethod e forceLoginGatewayUrl sulle macchine degli sviluppatori e non impostarli sui runner CI. Su una macchina le cui impostazioni gestite li impostano, una sessione che si autentica con ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN o apiKeyHelper termina all'avvio.

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

Il device flow separa la CLI che esegue il polling dal browser che approva, quindi funziona anche una macchina di sviluppo remota senza display: lo sviluppatore esegue /login via SSH sulla macchina remota e apre il link di verifica nel browser del proprio laptop.

Cosa viene imposto agli sviluppatori

Queste garanzie si applicano a ogni sessione in cui si è effettuato l'accesso tramite /login. Le sessioni incorporate avviate da Claude Desktop ricevono la propria policy come descritto in Fornire la policy alle sessioni di Claude Desktop, e la voce sulla telemetria indica dove vanno le loro esportazioni.

• Accesso ai modelli: le richieste per modelli che la policy non concede restituiscono 400, e il selettore /model è filtrato in base all'allowlist availableModels della policy. Questo include il modello con cui una sessione si avvia prima che lo sviluppatore ne scelga uno; consulta Avviare le sessioni su un modello consentito dalla policy.
• Destinazione della telemetria: nelle sessioni in cui si è effettuato l'accesso tramite /login, la CLI invia le sue esportazioni OTLP/HTTP al gateway anziché a un OTEL_EXPORTER_OTLP_ENDPOINT impostato localmente, a meno che una policy non indichi il tuo collector come endpoint. Il gateway inoltra le esportazioni che riceve alle destinazioni in telemetry.forward_to.
  • Nelle sessioni incorporate avviate da Claude Desktop, la CLI invia le sue esportazioni all'OTEL_EXPORTER_OTLP_ENDPOINT configurato. La CLI allega il token di sessione del gateway a queste 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 collector come destinazione forward_to, oppure indicalo in una policy per saltare l'inoltro.
• Credenziali: il token del gateway è l'unica credenziale della sessione. I profili Anthropic e qualsiasi accesso precedente a claude.ai vengono ignorati mentre si è connessi, quindi gli sviluppatori non devono prima uscire da claude.ai. Per una credenziale ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN o apiKeyHelper configurata, o per una chiave API salvata da un precedente accesso alla Claude Console, consulta Administrator policy requires a Cloud gateway sign-in.
• Impostazioni gestite: le chiavi bloccate non possono essere sovrascritte localmente. La CLI applica la policy all'avvio e applica le modifiche a ogni polling orario, a parte le modifiche che si applicano solo al successivo avvio.
• Avvio con il gateway irraggiungibile: le sessioni con accesso effettuato terminano all'avvio con un errore dopo circa 10 secondi anziché avviarsi senza le proprie impostazioni.
• Avvio dopo che il gateway ha terminato la sessione: consulta Imporre l'avvio fail-closed per gli avvii che si aprono senza accesso al gateway e per quelli che terminano quando il gateway risponde con un 401.
• Deprovisioning: una sessione il cui utente è disabilitato nell'IdP scade entro ttl_hours quando il rinnovo successivo fallisce.
• Uscita: /logout elimina la credenziale del gateway dalla macchina dello sviluppatore.
  • Quando il documento di discovery del gateway pubblicizza un revocation_endpoint con lo stesso schema, host e porta dell'URL del gateway, /logout invia anche i token memorizzati a quell'endpoint, in modo che il gateway possa terminare la sessione dal proprio lato. La richiesta è best effort, quindi l'uscita si completa sulla macchina dello sviluppatore indipendentemente dal fatto che l'endpoint risponda. La revoca richiede Claude Code v2.1.275 o successivo sulla macchina dello sviluppatore.
  • Il server gateway incluso nel binario claude non ne pubblicizza alcuno, quindi un'uscita da esso termina la sessione solo sulla macchina dello sviluppatore. Per forzare la chiusura delle sessioni lato server, consulta Rotazione del segreto JWT.

Cosa può vedere l'organizzazione

La telemetria di utilizzo trasmette al collector dell'organizzazione l'identità dello sviluppatore, i conteggi dei token, il modello e la latenza. Il gateway non registra né memorizza il contenuto dei prompt o delle risposte. La raccolta di telemetria più dettagliata, come log e trace, che può includere comandi e percorsi di file, è una 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'allowlist 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.