Gobierno self-hosted junto al Claude apps gateway: guía de co-deployment

Anthropic lanzó el Claude apps gateway a finales de junio de 2026. Es un servicio self-hosted incluido dentro del binario claude (v2.1.195+). Se ejecuta con claude gateway --config gateway.yaml, respaldado por PostgreSQL, y coloca autenticación OIDC delante de tu flota de Claude Code: sesiones de IdP corporativo en lugar de claves API gestionadas localmente. Es un avance real. Para equipos que ejecutan Claude Code contra Bedrock, Vertex, Foundry o la API de Anthropic directamente, el gateway centraliza identidad, acceso a modelos y controles de gasto detrás de un único fichero de configuración.

Este post trata de lo que viene después. Tu estate de IA es casi seguro más que Claude. Probablemente ejecutas servidores MCP de múltiples proveedores. Puede que tengas cargas de trabajo con OpenAI o Gemini, inferencia self-hosted con vLLM u Ollama, pipelines de CI que nunca ven un navegador, y frameworks de agentes que delegan entre proveedores. El apps gateway es Claude-only y OIDC-only. Eso es una decisión de alcance, no un defecto — pero implica que la cuestión de gobierno solo está parcialmente resuelta.

El modelo de co-deployment descrito aquí coloca una plataforma de gobierno self-hosted junto al gateway, leyendo tanto de la telemetría del gateway como del resto de tu infraestructura de agentes. Complementario, no competitivo: el gateway gestiona la autenticación, la plataforma gestiona el gobierno.

Lo que el apps gateway hace bien

El gateway resuelve un problema concreto e importante: dar a Claude Code una capa de identidad adecuada. Antes de que existiese, cada desarrollador llevaba una clave API o usaba una credencial compartida, y no había forma estandarizada de aplicar acceso a modelos, techos de gasto o managed settings a nivel de organización.

Con el gateway desplegado:

• Los desarrolladores se autentican mediante tu proveedor de identidad OIDC (un issuer por instancia de gateway).
• Los grupos del IdP se mapean a allowlists de modelos y políticas de managed settings en gateway.yaml.
• Los límites de gasto se aplican por usuario, por grupo o por organización, con una Admin API de spend limits.
• La telemetría se reenvía por OTLP/HTTP, estampada con user.id, user.email y user.groups.
• Los eventos de auditoría (11 tipos: config.load, session.mint, auth.denied, inference, etc.) se emiten como JSON de línea única en stderr.

Es infraestructura bien diseñada para su alcance declarado. Anthropic publica el protocolo del gateway e invita a implementaciones de terceros, lo cual es una postura inusualmente abierta para un proveedor de modelos.

Lo que no cubre

Anthropic documenta las siguientes decisiones de alcance con claridad. No son defectos — definen dónde pertenece la frontera de co-deployment:

• Solo OIDC. Sin SAML, sin LDAP. Si tu IdP usa SAML, necesitas un bridge OIDC delante del gateway.
• Issuer único. Un proveedor OIDC por instancia de gateway. Los deployment multi-tenant necesitan instancias separadas.
• Solo Claude. El catálogo de modelos es de modelos Claude. OpenAI, Gemini, inferencia local y otros proveedores quedan fuera del alcance del gateway.
• Sin flujo de service-token. Los pipelines de CI/CD desatendidos no tienen una vía de autenticación no interactiva documentada a través del gateway.
• Sin UI de administración. La configuración es el fichero YAML; los cambios requieren un redeploy.
• Sin chart Helm. El gateway se ejecuta como un deployment estándar, pero no hay chart empaquetado.

Más allá de estos límites documentados, hay preocupaciones de capa de gobierno que el gateway no fue diseñado para abordar:

• Inventario y postura de servidores MCP. Qué servidores MCP están desplegados, qué herramientas exponen y si sus capacidades declaradas coinciden con su comportamiento observado — nada de esto es trabajo del gateway.
• Enforcement de políticas cross-proveedor. Una política que diga “las bases de datos de producción son solo lectura para todos los agentes” necesita aplicarse en Claude, OpenAI y modelos self-hosted. El gateway gobierna el acceso a modelos Claude; no gobierna los recursos que esos modelos tocan, ni lo que hacen otros modelos.
• Mapeo de acceso a nivel de sesión. Construir el grafo de qué sesión de agente alcanzó qué base de datos, object store o endpoint de API — y si ese acceso fue lectura o lectura/escritura — requiere correlacionar telemetría, hooks y señales de infraestructura. El gateway reenvía OTLP tal cual; no analiza lo que la telemetría describe.
• Auditoría tamper-evident. El gateway emite eventos de auditoría JSON en stderr. Esos eventos necesitan aterrizar en un ledger append-only con cadena de hashes si van a respaldar paquetes de evidencia de compliance.

El modelo de co-deployment

La arquitectura es deliberadamente simple: el gateway y la plataforma de gobierno se ejecutan uno junto al otro en tu infraestructura, cada uno haciendo lo que sabe hacer.

  Estaciones de trabajo                     Tu infraestructura
  ┌─────────────────────┐
  │ Claude Code          │
  │ (v2.1.195+)         │
  └──────┬──────────────┘
         │
         │ OIDC device flow
         │ /v1/messages
         ▼
  ┌──────────────────────────────┐      ┌────────────────────────────────┐
  │ Claude apps gateway          │      │ Olivares AI (self-hosted)      │
  │                              │      │                                │
  │ • Auth OIDC (1 issuer)       │      │ • Receptor OTLP (gRPC + HTTP)  │
  │ • Allowlists de modelos      │  ──▶ │ • Correlación de hooks Claude  │
  │ • Límites de gasto           │ OTLP │ • Postura de gateway.yaml      │
  │ • Managed settings           │      │ • Ingesta de eventos auditoría │
  │ • Fan-out OTLP               │      │ • Gobierno multi-proveedor     │
  │ • Auditoría JSON en stderr   │  ──▶ │ • Inventario servidores MCP    │
  │                              │ logs │ • Grafo de aristas (R/RW)      │
  │ Solo modelos Claude.         │      │ • Ledger auditoría hash-chain  │
  │ Solo OIDC.                   │      │                                │
  └──────────────────────────────┘      │ TODOS los proveedores,         │
                                        │ TODAS las superficies.         │
                                        └────────────────────────────────┘
                                                     ▲
         Otro tráfico de agentes ────────────────────┘
         (OpenAI, Gemini, vLLM, Ollama, servidores MCP, pipelines CI)

Dos flujos de datos conectan el gateway con la plataforma:

Fan-out OTLP. La configuración telemetry.forward_to del gateway ya soporta destinos OTLP/HTTP. Apunta uno de ellos al receptor OTLP de Olivares. El atributo session.id correlaciona la telemetría reenviada por el gateway con los registros de runtime de sesión del propio receptor de hooks del conector Claude. Los atributos de identidad (user.id, user.email, user.groups) añadidos por el gateway viajan por la allowlist de atributos del operador y se convierten en etiquetas de atribución en aristas de sesión y muestras de coste — no se necesita código de receptor nuevo.

Ingesta de eventos de auditoría. El conector claude-apps-gateway lee los eventos de auditoría JSON del gateway. Los 11 tipos de evento documentados (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) se mapean a observaciones del SDK: las denegaciones relevantes para seguridad se convierten en findings, los eventos de inferencia en aristas de acceso, los session mints en observaciones de identidad y los eventos operativos en contadores de métricas. La PII en los eventos en crudo se hashea con SHA-256 antes de entrar en cualquier observación; los emails e identificadores son pseudónimos.

El conector claude-apps-gateway también inventaria el propio gateway.yaml: issuer OIDC, mapeos grupo-IdP-a-modelo, proveedores upstream, destinos OTLP y postura de spend admin. Este inventario es metadatos estructurales — topología, no credenciales.

Findings de postura de la configuración del gateway

El conector genera una familia de findings de postura derivados de la configuración del gateway. Son las cosas que un operador de gobierno necesita saber sobre un deployment de gateway:

Estos findings aparecen en la misma vista de postura que los findings de todos los demás conectores. El conector de MCP podría reportar una herramienta sin sandbox. El conector de Bedrock podría señalar un hueco en guardrails. El conector del gateway reporta que falta una política catch-all. Una superficie, una vista.

Cómo se ve en configuración

El conector de Claude ejecuta un receptor OTLP en los puertos estándar de OpenTelemetry y un endpoint de hooks para los hooks PreToolUse/PostToolUse de Claude Code. Junto a él, el conector del apps gateway lee la configuración y el flujo de auditoría del gateway. Ambos conectores se distribuyen bajo Apache-2.0 e importan solo del SDK, nunca del core del engine.

# olivares.yaml (abreviado)
connectors:
  - name: olivares.claude
    config:
      grpc_addr: "127.0.0.1:4317"
      http_addr: "127.0.0.1:4318"
      hook_path: "/hooks"
      enforcement: |
        {"rules":[
          {"tool":"Bash","decision":"ask","reason":"acceso shell requiere confirmación"},
          {"resource_kind":"file","mode":"write","decision":"ask"}
        ]}
      gateway: "direct"
      semconv_opt_in: "gen_ai_latest_experimental"

  - name: olivares.claude-apps-gateway
    config:
      config_path: "/etc/claude-gateway/gateway.yaml"
      audit_log_path: "/var/log/claude-gateway/audit.jsonl"

El campo gateway en el conector de Claude etiqueta cada muestra de coste con la superficie de deployment (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), de modo que FinOps pueda segmentar el gasto por vía del proveedor. El campo semconv_opt_in activa el perfil de ingesta GenAI vendor-neutral (fijado a OpenTelemetry semconv v1.41.1), lo que significa que OpenAI, Gemini o cualquier agente instrumentado con OTel alimenta el mismo pipeline de mapa de acceso y costes — no solo Claude Code.

Posicionamiento honesto

Hay cosas que vale la pena decir directamente.

Esto no es un sustituto del gateway. El inference proxy de Olivares implementa un subconjunto del protocolo publicado del gateway de Anthropic (OAuth discovery, autorización de dispositivo RFC 8628, entrega de managed settings, y la superficie de administración de spend limits — vistas, escrituras y enforcement per-seat, con sus divergencias respecto al protocolo de cable documentadas). Es útil cuando ese subconjunto es suficiente. No es un sustituto completo del flujo OIDC de navegador del gateway, y su semántica de spend por grupos difiere deliberadamente (gana el más restrictivo, en lugar de las reglas de merge del gateway). Si el gateway de Anthropic cumple tus requisitos de autenticación, ejecútalo.

El conector es solo lectura. El conector claude-apps-gateway observa la configuración y la salida de auditoría del gateway. No modifica gateway.yaml, no inyecta políticas y no intercepta la ruta /v1/messages. Es visibilidad, no control.

Olivares AI es pre-release. El producto no está certificado bajo SOC 2, ISO/IEC 27001, el Reglamento de IA de la UE ni ningún otro marco, y no hay ninguna auditoría en curso. Está diseñado hacia los objetivos de control que esos marcos examinan, de modo que esté listo para auditarse cuando llegue el momento.

El valor está en la combinación. Un equipo que solo ejecuta Claude Code contra un proveedor, con un IdP y sin servidores MCP de otros vendedores, puede encontrar el gateway solo suficiente. El co-deployment demuestra su valor cuando el estate es heterogéneo: múltiples proveedores, servidores MCP de múltiples vendedores, modelos self-hosted, pipelines de CI, requisitos de compliance que abarcan toda la superficie de agentes. Ahí es donde “autenticación de Claude” y “gobierno del estate” son problemas genuinamente distintos.

FAQ

¿Olivares AI sustituye al Claude apps gateway?

No. La doctrina es “y, no o.” El gateway de Anthropic es el propietario de la sesión de autenticación de Claude Code, el enrutamiento de acceso a modelos y la selección de upstream. Olivares AI convierte ese deployment en una superficie gobernada dentro de un control plane más amplio que también cubre proveedores que no son Claude, servidores MCP, modelos self-hosted y el resto de tu estate de agentes. Si ya ejecutas el gateway, consérvalo.

¿Puedo ejecutar Olivares AI sin el Claude apps gateway?

Sí. El conector claude-apps-gateway es opcional. El conector principal de Claude (connectors/claude) ingesta telemetría OTLP y hooks directamente de las sesiones de Claude Code, con o sin un gateway delante. Si no usas el gateway de Anthropic, pierdes su vía de autenticación de sesión OIDC pero conservas el gobierno completo: inventario de sesiones, mapeo de aristas de acceso, atribución de costes, enforcement de hooks, postura MCP y la vista multi-proveedor.

Para la topología de deployment en detalle, consulta /architecture. Para gobierno de servidores MCP entre proveedores, consulta /product/mcp. Para la superficie completa del producto, consulta /product.