SpyBara
Go Premium

claude-apps-gateway.md 2026-10-03 23:57 UTC to 2026-10-04 22:58 UTC

This page contains 124 additions and 121 deletions.

2026
Sun 4 22:58

Puerta de enlace de aplicaciones Claude para Amazon Bedrock, Claude Platform en AWS, Google Cloud y Microsoft Foundry

Ejecute Claude Code a través de Amazon Bedrock, Claude Platform en AWS, Google Cloud o Microsoft Foundry detrás de una puerta de enlace autohospedada con inicio de sesión SSO, acceso a modelos por grupo y telemetría OTLP.

Claude apps gateway es un servicio autohospedado que se sitúa entre los clientes de Claude Code de sus desarrolladores y su proveedor de modelos. Los desarrolladores inician sesión con su proveedor de identidad corporativo (IdP) en lugar de mantener claves API o credenciales de nube. La puerta de enlace mantiene la credencial ascendente, aplica el acceso a modelos y configuraciones administradas por grupo de IdP, y retransmite la telemetría de uso a su propia pila de observabilidad.

Se incluye en el binario claude, por lo que el mismo ejecutable que ejecuta Claude Code en una computadora portátil ejecuta el servidor de puerta de enlace con claude gateway --config gateway.yaml.

Esta página cubre:

Las páginas complementarias profundizan más. La referencia de configuración cubre todas las opciones en el archivo YAML que escribe el inicio rápido, y la guía de implementación cubre la configuración por IdP, la implementación en Kubernetes y Cloud Run, y las operaciones.

Por qué puerta de enlace de aplicaciones Claude

La descripción general de la puerta de enlace cubre qué hace una puerta de enlace y por qué ejecutaría una. La puerta de enlace de aplicaciones Claude es la propia puerta de enlace de Anthropic, integrada en el binario claude y probada junto con cada lanzamiento de Claude Code, por lo que reenvía los encabezados y campos de solicitud que Claude Code envía sin que los operadores mantengan una lista de permitidos separada. Una vez implementada, le proporciona:

  • Credenciales: la clave API ascendente o la credencial de nube vive solo en su infraestructura. Los desarrolladores se autentican con SSO corporativo y reciben tokens portadores de corta duración, por lo que la desvinculación ocurre en su IdP. Desaprovisione un usuario y su acceso a la puerta de enlace expira dentro de la duración de la sesión, una hora por defecto.
  • Control de acceso: sus grupos de IdP se asignan a listas de permitidos de modelos y políticas de configuración administrada. La puerta de enlace aplica el acceso a modelos del lado del servidor, rechazando solicitudes de modelos no otorgados, y selecciona la política de configuración administrada de cada grupo, que la CLI aplica en el nivel de configuración administrada. Diferentes equipos obtienen diferentes modelos, herramientas y permisos, y un desarrollador no puede anular lo que su política bloquea.
  • Entrega de configuración: la puerta de enlace entrega la configuración administrada a los clientes conectados por sí misma, reemplazando la configuración administrada por servidor de la consola de administrador de claude.ai.
  • Telemetría: cada destino configurado recibe métricas del Protocolo OpenTelemetry (OTLP) con recuentos de tokens, modelo, identidad del usuario y latencia por defecto, con registros y trazas como activaciones opcionales por destino.
  • Enrutamiento ascendente: los clientes hablan la API de Mensajes de Anthropic a la puerta de enlace, y la puerta de enlace traduce para cada ascendente, ya sea Amazon Bedrock, Plataforma Claude en AWS, Plataforma de Agentes de Google Cloud, Microsoft Foundry, o la API de Anthropic, con conmutación por error entre ellos. Puede cambiar regiones, proveedores u orden de conmutación por error sin que los desarrolladores lo noten o reconfiguren.
Diagrama que muestra clientes de Claude Code y las pestañas Chat, Cowork y Code de Claude Desktop conectándose sobre HTTPS con tokens portadores a una puerta de enlace de aplicaciones Claude autohospedada dentro de su infraestructura, que inicia sesión de usuarios contra su IdP, almacena estado de autenticación en PostgreSQL, retransmite telemetría a su recopilador OTLP, y reenvía inferencia a Amazon Bedrock, Plataforma Claude en AWS, Google Cloud, Microsoft Foundry o la API de Anthropic

Para ver qué características de Claude Code funcionan a través de la puerta de enlace y qué soporta el servidor en sí, consulte Disponibilidad y limitaciones a continuación. Para decisiones como costo, derivación, ejecutar múltiples puertas de enlace y plataformas sin servidor, consulte la guía de implementación.

Otras implementaciones de puerta de enlace

Si ya ejecuta una puerta de enlace LLM o puerta de enlace API que cumple con sus necesidades, continúe usándola; Otras puertas de enlace LLM cubre la configuración de Claude Code contra ella.

La guía de compatibilidad de protocolo de puerta de enlace documenta qué espera Claude Code de cualquier puerta de enlace: los puntos finales que llama, los encabezados y campos de cuerpo a reenviar, y qué deja de funcionar cuando se eliminan. Una puerta de enlace de aplicaciones Claude en ejecución también sirve su propia referencia de protocolo en GET /protocol, que describe los puntos finales que expone a clientes de Claude Code: inicio de sesión SSO, inferencia, entrega de configuración administrada, descubrimiento de modelos y telemetría. Obténgalo con curl https://claude-gateway.internal.example.com/protocol desde cualquier puerta de enlace implementada, como la que produce el inicio rápido a continuación.

Los cambios importantes en el protocolo se anuncian con anticipación, pero no se garantiza compatibilidad hacia atrás indefinida.

Inicio rápido

Este inicio rápido recorre la ruta mínima: registrar un cliente OAuth en su IdP, escribir un gateway.yaml, ejecutar la puerta de enlace junto con Postgres usando Docker Compose y verificar el inicio de sesión de extremo a extremo. Utiliza un upstream de Amazon Bedrock; Claude Platform en AWS, Agent Platform de Google Cloud, Microsoft Foundry y la API de Anthropic son igualmente compatibles intercambiando el bloque upstreams como se muestra en la referencia de configuración. Al final tiene una puerta de enlace a la que un desarrollador puede /login.

Requisitos previos

Tenga estos elementos en su lugar antes de comenzar:

Lo que necesita Detalles
Claude Code v2.1.195 o posterior El subcomando claude gateway y el flujo de inicio de sesión de la puerta de enlace se envían en v2.1.195. Las compilaciones públicas anteriores no los incluyen. Tanto la máquina que ejecuta el servidor de la puerta de enlace como la máquina de cada desarrollador deben estar en v2.1.195 o posterior; ejecute claude update para obtener la versión más reciente. El upstream de Claude Platform en AWS requiere Claude Code v2.1.198 o posterior en el servidor de la puerta de enlace.
Proveedor de identidad OpenID Connect (OIDC) Okta, Microsoft Entra ID, Google Workspace, Keycloak, o Dex, o cualquier otro IdP compatible con OIDC como PingFederate. La puerta de enlace ejecuta el descubrimiento OIDC estándar y el flujo de código de autorización en su contra. SAML y LDAP no son compatibles.
PostgreSQL 14 o posterior Respalda el flujo de inicio de sesión del dispositivo, donde la devolución de llamada del navegador escribe y la CLI de sondeo lee, además de contadores de límite de velocidad. Cualquier Postgres administrado funciona, incluido el nivel más pequeño. Sin límites de gasto configurados, la puerta de enlace almacena algunos KB de estado de autenticación de corta duración; con límites de gasto, también contiene tablas duraderas de gasto, auditoría e identidad que deben respaldarse. Se recomienda TLS a través de ?sslmode=require.
Upstream de modelo Credenciales de Amazon Bedrock, credenciales de Claude Platform en AWS, credenciales de Google Cloud, un recurso de Microsoft Foundry o una clave de API de Anthropic. Se admiten múltiples upstreams con conmutación por error.
HTTPS La puerta de enlace debe ser accesible a través de https:// desde portátiles de desarrolladores y desde cualquier navegador utilizado para el inicio de sesión; la puerta de enlace sirve la página de verificación del dispositivo en el mismo oyente. Proporcione un certificado TLS a través de listen.tls o ejecute detrás de una entrada que termine TLS, y establezca listen.public_url en el origen externo en ambos casos. En /login, Claude Code acepta un origen http:// simple solo cuando el host de la puerta de enlace es loopback: localhost, 127.0.0.1 o ::1.
Dirección de red privada En /login, Claude Code requiere que el nombre de host o la dirección IP de la puerta de enlace se resuelvan solo a direcciones privadas: RFC 1918, link-local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 o loopback. Para una puerta de enlace que aloja, cualquier dirección pública fuera de un bloque que declare se rechaza; consulte el modelo de amenaza en la guía de implementación. Si las máquinas de desarrolladores enrutan HTTPS a través de un proxy corporativo, el inicio de sesión también requiere que el host del proxy se resuelva a direcciones privadas; si no es así, agregue el host de la puerta de enlace a NO_PROXY para que la CLI se conecte directamente. Si su red interna está numerada desde espacio IPv4 público que su organización posee, declare esos bloques para que /login acepte una puerta de enlace allí.
Runtime de Linux El servidor de la puerta de enlace se ejecuta solo en el binario nativo de Linux. macOS funciona para desarrollo local. Windows no es compatible como plataforma de servidor.

Pasos

1

Registrar un cliente OAuth en su IdP

Decida primero el nombre de host de la puerta de enlace, porque el URI de redirección debe coincidir con él. Cree una nueva aplicación web OIDC y establezca el URI de redirección en https://claude-gateway.<su-dominio>/oauth/callback, donde el host es el mismo valor que establece como listen.public_url en el paso 3. Anote el client_id y client_secret. Las instrucciones por IdP están en Configuración del proveedor de identidad.

2

Aprovisionar una base de datos PostgreSQL

Cualquier Postgres 14 o posterior funciona, incluido el nivel administrado más pequeño. La puerta de enlace ejecuta sus propias migraciones de esquema al arrancar, por lo que el rol de la base de datos necesita derechos para crear y alterar tablas; consulte store.

3

Escribir gateway.yaml

Los secretos se leen a través de la expansión ${ENV_VAR} para que el archivo en sí pueda vivir en control de versiones. Use un nombre de host public_url que se resuelva a una IP privada en su red, porque /login rechaza direcciones públicas. La configuración mínima tiene cinco secciones, y todos los demás campos tienen un valor predeterminado:

listen:
host: 0.0.0.0
port: 8080
# Requerido a menos que el host sea una dirección loopback. Se utiliza para el IdP
# redirect_uri y el documento de descubrimiento.
public_url: https://claude-gateway.internal.example.com

oidc:
issuer: https://login.example.com        # debe servir /.well-known/openid-configuration
client_id: 0oa1example2
client_secret: ${OIDC_CLIENT_SECRET}
allowed_email_domains: [example.com]        # rechazar id_tokens fuera de su organización
userinfo_fallback: true                  # para IdPs cuyo id_token omite email/groups; inofensivo de otra manera

session:
jwt_secret: ${GATEWAY_JWT_SECRET}        # openssl rand -base64 32
ttl_hours: 1                             # también limita la latencia de revocación en el desaprovisionamiento de IdP

store:
postgres_url: ${GATEWAY_POSTGRES_URL}    # agregue ?sslmode=require para Postgres administrado

upstreams:
- provider: bedrock
region: us-east-1
auth: {} # vacío: cadena de credenciales predeterminada de AWS
# (IRSA, rol de tarea EC2/ECS, variables de entorno, ~/.aws)

# Los modelos se traducen por upstream automáticamente. El catálogo integrado
# asigna claude-opus-4-8 a us.anthropic.claude-opus-4-8 y así sucesivamente para cada
# modelo Claude compatible con Bedrock. Establezca false y agregue una lista `models:` para
# exponer solo modelos específicos.
auto_include_builtin_models: true

Esta configuración es suficiente para un bucle de inicio de sesión funcional con el catálogo de modelos predeterminado de Amazon Bedrock. Una vez que se está ejecutando, agregue RBAC por grupo y configuraciones administradas a través de managed.policies, fan-out de telemetría a través de telemetry y conmutación por error de múltiples upstreams, ARN de rendimiento aprovisionado o regiones no estadounidenses a través de models.

4

Ejecutarlo

Construya una imagen de contenedor alrededor del binario claude que cumpla con los requisitos de imagen, luego ejecútela junto con Postgres. El archivo Compose hace referencia a la imagen como registry.example.com/claude-gateway:2.1.198; sustituya su propio registro y etiqueta de imagen:

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
# Credenciales de AWS: en producción, omita estas y use un rol de instancia
# Para pruebas locales de Compose, pase las suyas propias:
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: }

La puerta de enlace es un único binario de Linux que lee la configuración, se conecta a Postgres y aplica sus migraciones de esquema, ejecuta el descubrimiento OIDC en su IdP, construye clientes upstream e inicia la escucha.

El arranque es de cierre seguro para la configuración, la conexión de Postgres, el descubrimiento OIDC y la construcción del cliente upstream. Si alguno de esos es inaccesible o está mal configurado, la puerta de enlace sale con un error en lugar de servir tráfico en un estado degradado.

Un arranque exitoso no valida la ruta de inferencia, porque las credenciales de instancia de Amazon Bedrock y Agent Platform de Google Cloud se resuelven en la primera solicitud, no al arrancar.

Observe stderr para la secuencia de arranque. Las líneas de registro utilizan el formato [gateway] <timestamp> <level> <message>, los eventos de auditoría son JSON de una sola línea con un campo evt, y un banner de inicio, omitido a continuación, se imprime entre las líneas de migración y escucha. Una base de datos nueva imprime una línea migration N applied por migración de esquema; una base de datos ya migrada no imprime ninguna. Debería ver, en orden:

{"ts":"2026-06-10T17:03:21.114Z","evt":"config.load","path":"/etc/claude/gateway.yaml","sha256":"…"}
[gateway] 2026-06-10T17:03:21.395Z info esperando bloqueo de migración (otra réplica puede estar migrando; verifique pg_locks para la clave 6775156 si esto persiste)
[gateway] 2026-06-10T17:03:21.408Z info migración 1 aplicada
…
[gateway] 2026-06-10T17:03:21.431Z info migración 6 aplicada
[gateway] 2026-06-10T17:03:21.512Z info claude gateway escuchando en http://0.0.0.0:8080

La puerta de enlace también registra una advertencia de que access_control.allow_cidrs está vacío. Eso es lo esperado aquí, porque nada limita qué direcciones de cliente sirve la puerta de enlace hasta que establezca una lista de permitidos. La referencia access_control tiene los rangos recomendados.

Si el arranque sale antes de la línea claude gateway listening on, la última línea de stderr nombra el problema:

  • un Postgres inaccesible
  • un rol de Postgres sin permiso DDL
  • un documento de descubrimiento OIDC inaccesible o inválido
  • una violación del esquema de configuración con la ruta del campo ofensivo

Corrija y reinicie.

Si ya tiene una entrada que termina TLS, omita Compose y ejecute el binario directamente con claude gateway --config gateway.yaml. Establezca public_url en el origen de la entrada y enlace listen a una dirección loopback o interna del clúster.

5

Verificar la superficie de autenticación

Tres comprobaciones confirman que la puerta de enlace puede autenticar a un usuario real antes de compartirla con un desarrollador.

Los ejemplos utilizan la URL pública de la puerta de enlace; para la configuración local de Compose sin una entrada, sustituya http://localhost:8080 en las dos primeras comprobaciones. La tercera comprobación abre verification_uri_complete, que se construye a partir de public_url, por lo que para Compose local establezca public_url: http://localhost:8080 en gateway.yaml y agregue http://localhost:8080/oauth/callback como un segundo URI de redirección en el cliente OAuth del paso 1, porque la puerta de enlace construye el redirect_uri de IdP a partir de public_url. El enlace de verificación se abre en su navegador local.

En Windows PowerShell, ejecute curl.exe; el curl simple es un alias para Invoke-WebRequest y rechaza estas banderas.

Primero, obtenga el documento de descubrimiento, que confirma que la puerta de enlace está activa, la configuración es válida y todas las comprobaciones de arranque pasaron:

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 respuesta incluye campos adicionales, como response_types_supported y scopes_supported.

Segundo, solicite una autorización de dispositivo, que confirma que el flujo de inicio de sesión del dispositivo funciona y que Postgres es accesible y escribible:

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
}

Tercero, pruebe la rama del navegador abriendo verification_uri_complete en un navegador y confirmando el código. Debería ser redirigido a la página de inicio de sesión de su IdP y, después de iniciar sesión, volver a la puerta de enlace con una confirmación de inicio de sesión.

Use la primera comprobación fallida para localizar el problema:

  • La primera comprobación falla: el arranque no se completó; verifique stderr
  • La segunda comprobación falla: Postgres no es accesible desde la puerta de enlace o el rol no puede escribir; verifique la cadena de conexión y los permisos
  • La tercera comprobación no llega al IdP: verifique que el URI de redirección de IdP coincida exactamente con https://<gateway>/oauth/callback
  • La tercera comprobación llega al IdP pero rebota con un error: lea el registro de auditoría de la puerta de enlace, que registra cada rechazo de autenticación con el motivo, como email domain not allowed
6

Iniciar sesión de un desarrollador

Este último paso ocurre en una máquina de desarrollador, no en el servidor. Establezca forceLoginMethod en "gateway" y forceLoginGatewayUrl en el public_url de su puerta de enlace en el archivo de configuración administrada de esa máquina, luego ejecute /login, presione Intro en la pantalla Cloud gateway y complete el inicio de sesión del navegador. Establecer la URL de la puerta de enlace a continuación cubre la distribución de ambas claves a cada máquina de desarrollador.

Conectar desarrolladores

Los desarrolladores se conectan desde sus propias laptops con un único inicio de sesión en el navegador, usando su cuenta de trabajo corporativa. No necesitan una cuenta de claude.ai, una clave de API ni una suscripción, porque las solicitudes al modelo pasan por el gateway usando la credencial ascendente de la organización. La conexión se controla mediante la configuración administrada del lado del cliente que distribuyes a través de MDM, por lo que no hay configuración manual del lado del desarrollador; esta sección cubre lo que configura el administrador.

La CLI toma la huella digital del certificado TLS hoja del gateway en la primera conexión y la fija por nombre de host. Vuelve a verificar esa fijación durante el inicio de sesión, en las actualizaciones silenciosas de la sesión y en las obtenciones de configuración administrada, mientras que las solicitudes de inferencia usan la validación TLS estándar sin la fijación. Las solicitudes enrutadas a través de un proxy HTTPS omiten la verificación de la fijación, así que agrega el host del gateway a NO_PROXY para mantenerlas directas.

Publica la huella digital SHA-256 esperada junto con la URL del gateway para que los desarrolladores tengan algo con qué compararla. El prompt de /login muestra los primeros 16 caracteres de la huella digital en hexadecimal en minúsculas, sin dos puntos. Para imprimir la huella digital completa en ese formato a partir del archivo del certificado, ejecuta:

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

Cuando el certificado rota, todos los desarrolladores vuelven a ver el prompt de confianza, así que trata las rotaciones como un evento planificado y vuelve a publicar la huella digital. Si la política de tu gateway incluye ajustes que requieren aprobación, el desarrollador también vuelve a ver ese diálogo de aprobación después de aceptar el nuevo certificado, porque Claude Code vincula la memoria de aprobación al certificado fijado.

Un gateway puede devolver el campo opcional email en su respuesta de token para indicar la cuenta que usó un inicio de sesión. Cuando lo hace, el desarrollador confirma la cuenta antes de que Claude Code guarde la credencial. Después de un inicio de sesión confirmado, /status muestra la cuenta.

La confirmación requiere Claude Code v2.1.275 o posterior en la máquina del desarrollador; un cliente con una versión anterior ignora el campo. El servidor de gateway incluido en el binario claude no devuelve el campo, por lo que sus inicios de sesión se completan sin la confirmación.

Una vez que el desarrollador inicia sesión, el selector de modelos muestra los modelos de su lista de permitidos availableModels. La configuración administrada se aplica al inicio y se actualiza cada hora, y la telemetría se enruta a tu recopilador.

Las sesiones se actualizan silenciosamente antes de que venza ttl_hours. Cuando una actualización falla después del desaprovisionamiento en el IdP, Claude Code le pide al desarrollador que vuelva a iniciar sesión.

Establecer la URL del gateway

Tres claves van en el archivo de configuración administrada de cada sistema operativo que implementas a través de MDM o directamente en el disco. forceLoginMethod y forceLoginGatewayUrl abren /login directamente en la pantalla Cloud gateway con la URL ya completada, y parentSettingsBehavior: "merge" permite que Claude Desktop entregue la lista de permitidos de salida del gateway a las sesiones de Claude Code que inicia, como se explica en Entregar la política a las sesiones de Claude Desktop:

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

El desarrollador presiona Enter para conectarse. El prompt de huella digital TLS de la primera conexión sigue apareciendo. Una vez que el archivo está en una máquina, un desarrollador que no ha completado el inicio de sesión en el gateway ve uno de los mensajes descritos en Administrator policy requires a Cloud gateway sign-in. Los desarrolladores que seleccionan un proveedor de nube mediante una variable de entorno como CLAUDE_CODE_USE_BEDROCK no necesitan el inicio de sesión en el gateway.

Un desarrollador no puede configurar esto manualmente. El selector de inicio de sesión no tiene una opción de gateway, y forceLoginGatewayUrl se ignora en los archivos de configuración propios de un desarrollador. forceLoginMethod por sí solo, sin una URL, deja al desarrollador ante un mensaje "Contact your IT administrator". Las claves de inicio de sesión van en el archivo que distribuyes a las máquinas, no en el bloque managed.policies[].cli del gateway, que solo llega a los clientes que ya están conectados.

Permitir un gateway en un espacio de direcciones público de tu propiedad

Algunas organizaciones numeran su red interna a partir de un bloque IPv4 público de su propiedad, como el espacio de direcciones propio de un operador o un /8 heredado, por lo que su gateway no puede tener una dirección privada. Enumera esos bloques en el ajuste de configuración administrada gatewayInternalNetworks. Entonces /login acepta un gateway dentro de un bloque enumerado cuando la máquina del desarrollador se conecta a él desde una dirección dentro del mismo bloque. Esto requiere Claude Code v2.1.268 o posterior en la máquina del desarrollador; las versiones anteriores ignoran la clave y aplican la regla de direcciones privadas.

Agrega la clave a la misma fuente de configuración administrada que las claves de inicio de sesión: el archivo de configuración administrada, el perfil de MDM o la política del registro. Claude Code la ignora en la configuración de usuario, de proyecto y administrada por el servidor.

Este ejemplo declara un bloque. Reemplaza 203.0.113.0/24 por tu propio bloque. Es un rango de documentación, y Claude Code los rechaza.

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

Claude Code valida la lista en /login antes de contactar a cualquier gateway:

  • Cada entrada es un bloque IPv4 escrito como su primera dirección y un prefijo de /8 a /32.
  • La lista contiene como máximo cuatro bloques, y no hay dos que se superpongan.
  • Ningún bloque se superpone con el espacio de direcciones privadas: 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 y 100.64.0.0/10. /login ya acepta un gateway ahí sin esta clave.
  • Ningún bloque se superpone con espacio que nunca es la red de una organización: 198.18.0.0/15 y 192.0.0.0/24, que los clientes de VPN y NAT64 usan como direcciones locales; los rangos de documentación 192.0.2.0/24, 198.51.100.0/24 y 203.0.113.0/24; y los rangos reservados 0.0.0.0/8, 192.88.99.0/24 y el de multidifusión 224.0.0.0/4. Puedes declarar bloques dentro de 240.0.0.0/4, que algunas redes grandes usan como espacio interno de unidifusión.

Los bloques de managed-settings.json y sus archivos drop-in managed-settings.d/ se combinan en una sola lista, y estos límites se aplican a la lista combinada. Para reducir un bloque, reemplaza su entrada en lugar de agregar una segunda que se superponga en un drop-in; /login rechaza la superposición.

Si una entrada incumple una regla, o el valor no es una lista de cadenas, Claude Code rechaza todo nuevo inicio de sesión en un gateway en esa máquina e indica el problema en el mensaje. El inicio de sesión en un gateway con una dirección privada también falla, y los inicios de sesión existentes siguen funcionando. Prueba el valor en una máquina antes de implementarlo. Claude Code también incluye un valor con un tipo incorrecto entre la configuración administrada no válida que informa.

Con una lista válida, /login aplica tres verificaciones a un gateway cuya dirección está dentro de un bloque enumerado:

  • Todas las direcciones a las que resuelve el nombre de host del gateway están dentro de ese mismo bloque. Claude Code rechaza un nombre que también tiene registros fuera de él, incluidas direcciones privadas e IPv6.
  • La máquina del desarrollador se conecta desde dentro del mismo bloque. Claude Code rechaza una máquina detrás de NAT, dentro de un contenedor o de WSL2, o en una VPN cuyo grupo de direcciones está fuera del bloque, e indica la dirección desde la que se conectó la máquina.
  • La conexión es directa. Si HTTPS_PROXY se aplica al host del gateway, /login la rechaza e indica la entrada de NO_PROXY que debes agregar.

Cuando las tres se cumplen, el prompt de confianza agrega una línea que indica la dirección de la máquina, la dirección del gateway y el bloque declarado que contiene ambas.

La clave no cambia nada para otros gateways: el inicio de sesión en uno con una dirección privada funciona como antes, y el inicio de sesión en uno con una dirección pública fuera de todos los bloques enumerados se rechaza como antes.

Un bloque declarado restringe quién puede iniciar sesión, pero no prueba dónde está una máquina, así que declara solo espacio de direcciones que controla tu organización. Un bloque compartido con otros inquilinos, como el rango público de un proveedor de nube, permite que cualquiera dentro de él pase la misma verificación.

Entregar la política a las sesiones de Claude Desktop

Claude Desktop ejecuta sus pestañas Cowork y Code, además de la pestaña Chat cuando la activas, sobre sesiones de Claude Code integradas y envía sus solicitudes al modelo a través del gateway. Pasa la política a cada una de esas sesiones, construida a partir de la configuración que el gateway le sirve en /user/bootstrap: la lista de modelos permitidos, las herramientas deshabilitadas y la lista de permitidos de salida derivadas del bloque cli de la política coincidente, además de la superposición desktop.

Otras claves de cli, como los hooks, env y las reglas de permisos con alcance como Bash(npm *), solo llegan a los clientes que inician sesión a través de /login. Claude Desktop lee la URL del gateway de su propia configuración administrada e inicia sesión con su propio flujo, independiente de las claves forceLoginMethod y forceLoginGatewayUrl de Establecer la URL del gateway.

Los ajustes que pasa un proceso que inicia Claude Code son la configuración del proceso padre. Claude Code ignora la configuración del proceso padre en cualquier máquina que tenga una fuente administrada implementada por un administrador, a menos que la fuente que entrega la política establezca parentSettingsBehavior: "merge".

Qué máquinas necesitan la activación

Las máquinas que solo ejecutan Claude Desktop la necesitan. Claude Desktop aplica por sí mismo la lista de modelos y la lista de herramientas deshabilitadas a las sesiones integradas, pero la lista de permitidos de salida solo les llega como configuración del proceso padre, en forma de reglas de dominio de WebFetch y reglas de red del sandbox. Sin la activación, esas sesiones se ejecutan sin la restricción de salida, y nada te lo advierte. El gateway sigue rechazando las solicitudes de inferencia para modelos que la política no concede.

Una lista de marketplaces de plugins permitidos también llega a las sesiones integradas solo como configuración del proceso padre. Cuando desactivas los marketplaces de plugins agregados por el usuario en la configuración administrada de Claude Desktop, Claude Desktop 2.16120.0 o posterior oculta los marketplaces que tu organización no aprovisionó y rechaza instalaciones desde ellos. Para evitar que las sesiones integradas carguen plugins ya instalados desde esos marketplaces, les envía una lista strictKnownMarketplaces como configuración del proceso padre. Sin la activación, Claude Code ignora esa lista, y esos plugins se siguen cargando.

Las máquinas en las que los desarrolladores inician sesión a través de /login no la necesitan; cada sesión de Claude Code obtiene su política del gateway.

Las flotas cuyo policyHelper proporciona la configuración administrada no pueden usarla: Claude Code nunca combina la configuración del proceso padre en esas flotas, porque lee la configuración administrada únicamente de la salida del helper.

Configurar la activación

Implementa el fragmento de configuración administrada de Establecer la URL del gateway, replícalo en cualquier fuente del lado del cliente que tenga prioridad sobre el archivo y luego verifica.

1

Implementa la activación en el archivo de configuración administrada

El fragmento anterior ya incluye parentSettingsBehavior: "merge", así que el archivo que distribuyes a las máquinas lo contiene.

2

Replica el fragmento en cualquier fuente que tenga prioridad sobre el archivo

Claude Code lee parentSettingsBehavior solo de la fuente seleccionada. Agregar cualquier clave de política a una fuente puede convertirla en la seleccionada, así que en una fuente del lado del cliente replica el fragmento completo en lugar de solo parentSettingsBehavior. Configuración administrada del lado del cliente cubre las flotas que entregan la política a través de Group Policy o de perfiles de configuración. Un plist de preferencias administradas en macOS o una política HKLM en Windows tiene prioridad sobre el archivo managed-settings.json, y la configuración administrada remota del propio gateway tiene prioridad sobre ambos, así que en las máquinas que inician sesión en el gateway establece también parentSettingsBehavior en el bloque cli de la política del gateway.

3

Verifica qué fuente está seleccionada

En una máquina que solo ejecuta Claude Desktop, llama a resolveSettings() del Agent SDK y lee policyOrigin en la entrada managed de su lista sources. El valor indica la fuente del lado del cliente seleccionada, plist, hklm o file, que es la fuente que debe contener el fragmento. Las sesiones integradas de Claude Desktop no obtienen la política del gateway, por lo que el bloque cli del gateway nunca cuenta como la fuente seleccionada para ellas.

Restringir la configuración del proceso padre

Una vez que implementas parentSettingsBehavior: "merge", cualquier proceso host que inicie Claude Code puede proporcionar configuración del proceso padre; no solo Claude Desktop, sino también una aplicación del Agent SDK o una extensión de IDE.

Claude Code filtra la configuración del proceso padre con una lista de permitidos de claves restrictivas, pero algunas claves permitidas pueden conceder acceso en lugar de restringirlo. A menos que establezcas los bloqueos allowManaged*Only, las reglas de permisos de tipo allow y las listas de permitidos del sandbox que proporciona el host siguen aplicándose. Las reglas deny y ask de tu política siguen vigentes en cualquier caso; se evalúan antes que cualquier regla allow.

Claude Code reenvía las entradas de sandbox.credentials proporcionadas por el proceso padre en forma reducida:

  • Entradas deny: se reenvían solo con su path o name y el modo.
  • Entradas de archivo con mode: mask: se reenvían solo como centinela, como una máscara de archivo completo cuyo injectHosts es la lista vacía, de modo que el proxy nunca sustituye el valor real en una entrada proporcionada por el proceso padre en ninguna plataforma. También se descartan todos los campos de enmascaramiento estructurado, de modo que un patrón de extracción proporcionado por el proceso padre no puede desplazar una máscara más estricta que otra fuente establece para la misma ruta.
  • Entradas envVars con mode: mask: no se reenvían. deny es la única restricción que el canal del proceso padre puede expresar mediante entradas envVars.
  • awsPairs y sigv4: se reenvían solo como restricciones. De sigv4 solo se conservan los valores deny, y un proceso padre que define cualquier bloque sigv4 fija las tres formas de solicitud, streaming, presigned y sigv4a, en deny. Un par de awsPairs nunca se reenvía en una forma que pueda volver a firmar; un par que nombra una de las variables convencionales de AWS se reemplaza por una entrada inerte que mantiene suprimido el emparejamiento automático de AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN.

Implementar los bloqueos

Para que la configuración del proceso padre sea lo más restrictiva posible según lo que admite el filtro, agrega los cinco bloqueos allowManaged*Only, y las listas de permitidos que controlan, a las mismas fuentes que la activación de 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 política del sistema operativo, como una política de registro HKLM o un plist de preferencias administradas, tiene prioridad sobre este archivo, así que en ese caso entrega el fragmento completo a través de ella en lugar del archivo. La configuración administrada remota del gateway tiene prioridad sobre las fuentes de política del sistema operativo y de archivo, pero solo llega a los clientes conectados. Replica los bloqueos, las listas de permitidos y la activación de merge en el bloque cli de la política y mantén este archivo implementado, porque las máquinas que nunca se conectan, incluidas las que solo ejecutan Claude Desktop, obtienen su política únicamente del archivo.

Comportamiento de los bloqueos entre fuentes

Establecer un bloqueo no restringe los demás; cada clave está documentada en la referencia de configuración.

Desde una fuente de administrador por debajo de la ganadora, los dos bloqueos del sandbox siguen aplicándose, y allowManagedPermissionRulesOnly sigue bloqueando las reglas allow y los additionalDirectories proporcionados por el proceso padre. En Claude Code v2.1.273 o posterior, el bloqueo de servidores MCP también se aplica desde una fuente por debajo de la ganadora, y mientras está activado, la lista administrada allowedMcpServers proviene de la fuente de administrador de mayor prioridad que establece una.

El bloqueo de hooks y el efecto de allowManagedPermissionRulesOnly sobre las reglas propias del desarrollador requieren, de forma predeterminada, la fuente ganadora; con la activación de merge de managedSourcesBehavior descrita en cómo combina Claude Code las fuentes administradas, Claude Code aplica para cada bloqueo el valor más estricto que establezca cualquier fuente. En las flotas con policyHelper, Claude Code lee los bloqueos únicamente de la salida del helper.

Cada bloqueo hace que Claude Code ignore las entradas propias del desarrollador para ese ajuste, así que incluye las listas de permitidos de tu organización junto a los bloqueos:

  • Dominios de red: bloquear con una lista de dominios administrados vacía bloquea todo el tráfico saliente del sandbox.
  • Servidores MCP: bloquear sin allowedMcpServers en ninguna fuente de administrador ni en la configuración proporcionada por el proceso padre carga todos los servidores que deniedMcpServers no bloquea.
  • Rutas de lectura: las entradas allowRead solo vuelven a permitir rutas dentro de las regiones de denyRead, así que combínalas con un denyRead administrado.

Ajustes que los bloqueos no cubren

Estos ajustes proporcionados por el proceso padre pasan el filtro incluso con los cinco bloqueos establecidos:

  • forceLoginOrgUUID: Claude Code respeta un valor proporcionado por el proceso padre cuando la fuente de administrador de mayor prioridad no establece un UUID de organización. El inicio de sesión en el gateway no verifica esta clave. Un UUID de organización en la fuente de administrador de mayor prioridad bloquea el valor del proceso padre y es el que Claude Code aplica.
  • allowedMcpServers: Claude Code respeta una lista de permitidos proporcionada por el proceso padre cuando no hay ninguna lista de administrador vigente. allowManagedMcpServersOnly no la bloquea, porque el bloqueo aplica la lista que resulte ganadora como valor administrado, incluida una proporcionada por el proceso padre cuando ninguna fuente de administrador proporciona una lista. Una lista en la fuente de administrador de mayor prioridad bloquea la del proceso padre y es la que Claude Code aplica, así que establece allowedMcpServers ahí, junto al bloqueo. Antes de v2.1.223, un valor para cualquiera de las dos claves en cualquier fuente de administrador bloqueaba el del proceso padre.
  • availableModels: Claude Code respeta una lista de modelos proporcionada por el proceso padre cuando la fuente administrada ganadora no establece una. Si tu flota restringe los modelos, establece availableModels en la fuente ganadora.
  • allowedProviders: Claude Code respeta una lista de proveedores de API permitidos proporcionada por el proceso padre cuando la fuente administrada ganadora no establece una. Si tu flota restringe qué proveedores de API pueden usar los desarrolladores, establece allowedProviders en la fuente ganadora. Requiere Claude Code v2.1.285 o posterior.
  • strictKnownMarketplaces: Claude Code respeta una lista de marketplaces de plugins permitidos proporcionada por el proceso padre cuando la fuente administrada ganadora no establece una. Claude Desktop 2.16120.0 o posterior envía una cuando su configuración administrada desactiva los marketplaces de plugins agregados por el usuario. Si tu flota restringe los marketplaces, establece strictKnownMarketplaces en la fuente ganadora. Requiere Claude Code v2.1.282 o posterior.
  • blockedMarketplaces: una lista de marketplaces bloqueados proporcionada por el proceso padre pasa el filtro y se suma a cualquier lista de bloqueados que establezca una fuente administrada, ya que una lista de bloqueados solo puede restringir más. Requiere Claude Code v2.1.282 o posterior.
  • strictPluginOnlyCustomization: esta clave pasa el filtro independientemente de cualquier bloqueo, y hace que Claude Code ignore la personalización propia del desarrollador, incluidos los hooks de protección. Ningún bloqueo la bloquea.

Con el ajuste predeterminado de "gana el primero", un valor de administrador bloquea el del proceso padre solo cuando está en la fuente de administrador de mayor prioridad, excepto en el caso de allowedMcpServers mientras el bloqueo de servidores MCP está activado. Con la activación de merge de managedSourcesBehavior, cómo combina Claude Code las fuentes administradas indica qué valor de fuente se aplica en su lugar.

Conectar Claude Desktop

Claude Desktop se conecta al mismo gateway mediante una clave de MDM diferente: establece bootstrapUrl en la configuración administrada de Claude Desktop en <listen.public_url>/user/bootstrap, y activa la política del usuario con una clave desktop. Superposición de Claude Desktop cubre ambas partes. Requiere Claude Code v2.1.203 o posterior en el servidor del gateway.

Claude Desktop inicia la sesión del desarrollador a través del proveedor de identidad del gateway con el mismo paso de SSO en el navegador y luego obtiene su configuración del gateway en lugar de Anthropic. El acceso a los modelos y la política siguen las mismas reglas por grupo que la CLI. Un desarrollador que usa tanto la CLI como Claude Desktop inicia sesión en cada uno por separado; la sesión del gateway no se comparte entre ellos.

Una vez conectado, Claude Desktop envía las solicitudes al modelo de todas las pestañas activadas a través del gateway. De forma predeterminada muestra las pestañas Cowork y Code. Para activar también la pestaña Chat, establece chatTabEnabled en true en la configuración administrada de Claude Desktop, o en el bloque desktop de la política en un gateway que ejecute Claude Code v2.1.227 o posterior.

Pipelines de CI y máquinas remotas

No existe un flujo de token de servicio para pipelines desatendidos. El inicio de sesión en el gateway siempre ejecuta el flujo de dispositivo del navegador, por lo que un trabajo de CI sin un desarrollador que apruebe el inicio de sesión no puede autenticarse; configura esos trabajos directamente con tu proveedor.

Una vez que un desarrollador inicia sesión, cada sesión de Claude Code en esa máquina usa la sesión del gateway, incluidas las ejecuciones no interactivas de claude -p y las sesiones iniciadas por el Agent SDK. Claude Code aplica la política del gateway a cada una de ellas.

El flujo de dispositivo separa la CLI que consulta del navegador que aprueba, así que una máquina de desarrollo remota sin pantalla también funciona: el desarrollador ejecuta /login por SSH en la máquina remota y abre el enlace de verificación en el navegador de su laptop.

Qué se aplica a los desarrolladores

Estas garantías se aplican a todas las sesiones iniciadas a través de /login. Las sesiones integradas que inicia Claude Desktop reciben su política como se describe en Entregar la política a las sesiones de Claude Desktop, y el punto sobre telemetría indica adónde van sus exportaciones.

  • Acceso a modelos: las solicitudes de modelos que la política no concede devuelven 400, y el selector de /model se filtra según la lista de permitidos availableModels de la política. Esto incluye el modelo con el que se inicia una sesión antes de que el desarrollador elija uno; consulta Iniciar sesiones con un modelo que la política permite.
  • Destino de la telemetría: en las sesiones iniciadas a través de /login, la CLI envía sus exportaciones OTLP/HTTP al gateway en lugar de a un OTEL_EXPORTER_OTLP_ENDPOINT establecido localmente, a menos que una política indique tu recopilador como endpoint. El gateway reenvía las exportaciones que recibe a los destinos de telemetry.forward_to.
    • En las sesiones integradas que inicia Claude Desktop, la CLI envía sus exportaciones al OTEL_EXPORTER_OTLP_ENDPOINT configurado. La CLI adjunta el token de sesión del gateway a esas exportaciones solo cuando ese endpoint apunta al propio gateway.
    • Si no hay un destino configurado para una señal, el gateway la acepta y la descarta.
    • Si ya recopilas la telemetría de Claude Code directamente, agrega tu recopilador como destino de forward_to, o indícalo en una política para omitir el reenvío.
  • Credenciales: el token del gateway es la única credencial de la sesión. Los perfiles de Anthropic y cualquier inicio de sesión anterior en claude.ai se ignoran mientras la sesión está iniciada, así que los desarrolladores no necesitan cerrar primero la sesión de claude.ai. Para una credencial configurada de ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN o apiKeyHelper, o una clave de API guardada por un inicio de sesión anterior en Claude Console, consulta Administrator policy requires a Cloud gateway sign-in.
  • Configuración administrada: las claves bloqueadas no se pueden anular localmente. La CLI aplica la política al inicio y aplica los cambios en cada consulta horaria, salvo los cambios que solo se aplican en el siguiente inicio.
  • Inicio con el gateway inaccesible: las sesiones iniciadas terminan al arrancar con un error después de unos 10 segundos en lugar de iniciarse sin su configuración.
  • Inicio después de que el gateway finaliza la sesión: consulta Aplicar un inicio con cierre ante fallos para ver qué inicios se abren sin sesión en el gateway y cuáles terminan cuando el gateway responde con un 401.
  • Desaprovisionamiento: una sesión cuyo usuario está deshabilitado en el IdP vence dentro de ttl_hours cuando falla la siguiente actualización.
  • Cierre de sesión: /logout elimina la credencial del gateway de la máquina del desarrollador.
    • Cuando el documento de descubrimiento del gateway anuncia un revocation_endpoint en el mismo esquema, host y puerto que la URL del gateway, /logout también envía los tokens almacenados a ese endpoint para que el gateway pueda finalizar la sesión de su lado. La solicitud se hace con el mejor esfuerzo, así que el cierre de sesión se completa en la máquina del desarrollador tanto si el endpoint responde como si no. La revocación requiere Claude Code v2.1.275 o posterior en la máquina del desarrollador.
    • El servidor de gateway incluido en el binario claude no anuncia ninguno, así que un cierre de sesión en él finaliza la sesión solo en la máquina del desarrollador. Para forzar el cierre de las sesiones del lado del servidor, consulta Rotación del secreto JWT.

Qué puede ver la organización

La telemetría de uso lleva al recopilador de la organización la identidad del desarrollador, los recuentos de tokens, el modelo y la latencia. El gateway no registra ni almacena el contenido de los prompts ni de las respuestas. Si se recopila telemetría más detallada, como registros y trazas, que puede incluir comandos y rutas de archivos, es una elección por destino de la organización.

Disponibilidad y limitaciones

La tabla cubre qué características de Claude Code funcionan cuando los desarrolladores se conectan a través del gateway, y qué soporta el servidor del gateway en sí. Donde algo no es compatible, la columna Notas proporciona la alternativa.

El gateway entrega los valores anthropic-beta que la CLI envía a cada ascendente, por lo que los operadores no mantienen una lista de permitidos de betas. Para Amazon Bedrock, que ignora el encabezado, el gateway mueve los valores al campo anthropic_beta del cuerpo de la solicitud; los otros ascendentes reciben el encabezado tal como se envía.

Característica Estado Notas
Reenvío de inferencia (Amazon Bedrock, Claude Platform en AWS, Agent Platform de Google Cloud, Microsoft Foundry, Anthropic) Disponible Con traducción de modelos por ascendente y conmutación por error. El ascendente de Amazon Bedrock utiliza el endpoint bedrock-runtime y la cadena de credenciales predeterminada de AWS. El ascendente Amazon Bedrock Mantle requiere Claude Code v2.1.283 o posterior en el servidor del gateway, y el ascendente Claude Platform en AWS requiere v2.1.198 o posterior.
Acceso a modelos y configuración administrada por grupo de IdP Disponible El acceso a modelos se aplica del lado del servidor; la configuración administrada se entrega por grupo de IdP y la CLI la aplica en el nivel de configuración administrada
Claude Desktop Disponible con participación opcional El gateway sirve la configuración de Claude Desktop en /user/bootstrap una vez que una política participa con una clave desktop, y Claude Desktop envía solicitudes de modelo desde sus pestañas Cowork y Code, y desde la pestaña Chat cuando la habilitas, a través del gateway. Para activar la pestaña Chat, consulta Conectar Claude Desktop. Requiere Claude Code v2.1.203 o posterior en el servidor del gateway.
Distribución de telemetría (OTLP/HTTP) Disponible Marcada con la identidad en cada exportación; codificaciones protobuf y JSON
Proveedores de identidad OIDC Disponible Cualquier IdP compatible con OIDC; el gateway ejecuta el descubrimiento OIDC estándar y el flujo de código de autorización. Consulta Configuración del proveedor de identidad para la configuración por IdP
Límites de gasto por usuario y por grupo Disponible Consulta Límites de gasto
Búsqueda web del lado del servidor No disponible La CLI no puede ver a qué proveedor ascendente enruta el gateway, por lo que no puede verificar la compatibilidad con la búsqueda web y deshabilita WebSearch en las sesiones del gateway
Remote Control No disponible La CLI muestra un error que nombra el gateway
/design-sync y /design-login No disponible Ambos necesitan claude.ai, que la CLI no contacta en las sesiones del gateway, por lo que ninguno de los dos comandos aparece allí
Características que necesitan obtener flags de características, como /import y claude import No disponible La CLI omite la obtención de flags en las sesiones del gateway. Características que necesitan obtener flags de características enumera lo que eso desactiva
Caché de prompts estándar Disponible El gateway reenvía los puntos de interrupción cache_control a cada ascendente. Dónde vive la caché cubre qué bloques marca la CLI, incluido el contexto del sistema que añade a mitad de la conversación
TTL de caché de 1 hora No disponible La CLI omite la beta de TTL de caché extendido en las sesiones del gateway, porque no todos los ascendentes a los que el gateway puede enrutar soportan el TTL de 1 hora, por lo que la caché de prompts a través del gateway utiliza el TTL de 5 minutos; consulta la nota sobre el encabezado beta anterior
Modo automático Disponible Sigue las reglas de proveedores de terceros: solo los modelos elegibles en proveedores de terceros pueden usarlo. Antes de v2.1.207, el modo automático en las sesiones del gateway requería establecer CLAUDE_CODE_ENABLE_AUTO_MODE=1, que se podía entregar a través del bloque env de la política administrada
Optimizaciones exclusivas de primera parte, como el alcance de caché global y las herramientas eficientes en tokens No disponible La CLI no las habilita en las sesiones del gateway; consulta la nota sobre el encabezado beta anterior
OTLP/gRPC No compatible Solo OTLP sobre HTTP
SAML, LDAP y otra autenticación no OIDC No compatible Solo OIDC. Coloca un puente OIDC delante si es necesario
Multiinquilino (múltiples emisores OIDC) No compatible Un emisor por gateway. Ejecuta instancias separadas
Servidor Windows No compatible Despliega en Linux. macOS solo para desarrollo local
Gráfico Helm No disponible El gateway se ejecuta como un Deployment estándar sin estado; consulta la guía de despliegue
Interfaz de administración No disponible La configuración es el archivo YAML; vuelve a desplegar para cambiarla

Próximos pasos

El inicio rápido lo deja con una configuración mínima ejecutándose bajo Docker Compose. Para llevarlo más lejos:

  • Expanda gateway.yaml más allá de la configuración mínima, por ejemplo para agregar RBAC por grupo, conmutación por error de múltiples ascendentes, o destinos de telemetría. La referencia de configuración cubre cada opción.
  • Pase de Compose a una implementación de producción en Kubernetes o Cloud Run, configure su IdP correctamente, y revise el modelo de seguridad. La guía de implementación y operaciones cubre la configuración por IdP, los requisitos de imagen de contenedor, sondeos de salud y solución de problemas.
  • Coloque límites de gasto en desarrolladores individuales o grupos para que una carga de trabajo descontrolada no pueda consumir todo su compromiso. Límites de gasto cubre la API de administrador y cómo funciona la aplicación.
  • Para un ejemplo completo trabajado en AWS, con ECS Fargate o EKS, Amazon RDS y Secrets Manager, consulte Implementar en AWS.
  • Para un ejemplo completo trabajado en Google Cloud, con Cloud Run, Cloud SQL y Secret Manager, consulte Implementar en Google Cloud.