Anthropic enviou o gateway de aplicativos Claude no final de junho de 2026. É um serviço auto-hospedado incluído no binário claude (v2.1.195+). Você o executa com claude gateway --config gateway.yaml, faz backup com PostgreSQL, e ele coloca o login OIDC à frente da sua frota Claude Code: sessões corporativas do IdP em vez de chaves de API gerenciadas localmente. Isso é um verdadeiro avanço. Para equipes que executam Claude Code contra Bedrock, Vertex, Foundry ou diretamente a API Anthropic, o gateway centraliza identidade, acesso aos modelos e controle de gastos em um único arquivo de configuração.
Esta postagem é sobre o que acontece a seguir. Seu patrimônio em IA quase certamente é mais do que Claude. Você provavelmente executa servidores MCP de múltiplos fornecedores. Pode ter cargas de trabalho OpenAI ou Gemini, inferência auto-hospedada através de vLLM ou Ollama, pipelines de CI que nunca acessam um navegador e frameworks de agente que delegam entre provedores. O gateway de aplicativos é apenas Claude e apenas OIDC. Isso é uma decisão de escopo, não um defeito — mas significa que a questão de governança está apenas parcialmente respondida.
O modelo de coimplantação descrito aqui coloca uma plataforma de governança auto-hospedada junto ao gateway, lendo tanto da telemetria do gateway quanto do restante da sua infraestrutura de agentes. Complementar, não competitivo: o gateway trata da autenticação, a plataforma trata da governança.
O que o gateway de aplicativos faz bem
O gateway resolve um problema específico e importante: fornecer ao Claude Code uma camada de identidade adequada. Antes de sua existência, cada desenvolvedor carregava uma chave de API ou usava uma credencial compartilhada, e não havia uma maneira padronizada de aplicar acesso ao modelo, limites de gastos ou configurações gerenciadas no nível organizacional.
Com o gateway implementado:
- Os desenvolvedores se autenticam através do seu provedor de identidade OIDC (um emissor por instância de gateway).
- Grupos do IdP são mapeados para listas de permissão de modelos e políticas de configurações gerenciadas no
gateway.yaml. - Limites de gastos são aplicados por usuário, por grupo ou por organização, com uma API de Administração de limites de gastos.
- A telemetria é distribuída por OTLP/HTTP, marcada com
user.id,user.emaileuser.groups. - Eventos de auditoria (11 tipos:
config.load,session.mint,auth.denied,inference, etc.) são emitidos como JSON de linha única no stderr.
Esta é uma infraestrutura bem projetada para seu escopo declarado. Anthropic publica o protocolo de gateway e convida implementações de terceiros, o que é uma postura incomumente aberta para um provedor de modelo.
O que não cobre
Anthropic documenta claramente as seguintes decisões de escopo. Estes não são defeitos — eles definem onde pertence um limite de co-implantação:
- Somente OIDC. Sem SAML, sem LDAP. Se seu IdP usa SAML, você precisa de uma ponte OIDC na frente do gateway.
- Emitente único. Um provedor OIDC por instância de gateway. Implantações multi-inquilino precisam de instâncias separadas.
- Apenas Claude. O catálogo de modelos é de modelos Claude. OpenAI, Gemini, inferência local e outros provedores estão fora do escopo do gateway.
- Sem fluxo de token de serviço. Pipelines não supervisionados CI/CD não têm caminho de autenticação não interativa documentado através do gateway.
- Sem interface de administração. A configuração é o arquivo YAML; mudanças exigem um redesdobramento.
- Sem chart Helm. O gateway executa-se como uma implantação padrão, mas não há chart empacotado.
Além desses limites documentados, existem preocupações de camada de governança que o gateway não foi projetado para tratar:
- Inventário e postura de servidores MCP. Quais servidores MCP estão implantados, quais ferramentas eles expõem e se suas capacidades declaradas correspondem ao comportamento observado — nada disso é função do gateway.
- Aplicação de políticas entre provedores. Uma política que diz “bancos de dados de produção são somente leitura para todos os agentes” precisa se aplicar ao Claude, OpenAI e aos modelos hospedados localmente. O gateway governa o acesso ao modelo Claude; ele não governa os recursos que esses modelos acessam, nem quais outros modelos acessam.
- Mapeamento de acesso a nível de sessão. Construir o gráfico de qual sessão de agente acessou qual banco de dados, armazenamento de objetos ou endpoint de API — e se esse acesso foi leitura ou leitura/write — requer correlacionar telemetria, hooks e sinais de infraestrutura. O gateway retransmite OTLP literalmente; ele não analisa o que a telemetria descreve.
- Auditoria à prova de violação. O gateway emite eventos de auditoria em JSON no stderr. Esses eventos precisam chegar a um registro encadeado por hash, somente para acréscimo, se eles forem apoiar pacotes de evidência de conformidade.
O modelo de co-implantação
A arquitetura é deliberadamente simples: o gateway e a plataforma de governança operam lado a lado na sua infraestrutura, cada um fazendo o que é bom em fazer.
Developer workstations Your infrastructure
┌─────────────────────┐
│ Claude Code │
│ (v2.1.195+) │
└──────┬──────────────┘
│
│ OIDC device flow
│ /v1/messages
▼
┌──────────────────────────────┐ ┌────────────────────────────────┐
│ Claude apps gateway │ │ Olivares AI (self-hosted) │
│ │ │ │
│ • OIDC auth (1 issuer) │ │ • OTLP receiver (gRPC + HTTP) │
│ • Model allowlists │ ──▶ │ • Claude hooks correlation │
│ • Spend limits │ OTLP │ • gateway.yaml posture │
│ • Managed settings │ │ • Audit event ingest │
│ • OTLP fan-out │ │ • Multi-provider governance │
│ • JSON audit on stderr │ ──▶ │ • MCP server inventory │
│ │ logs │ • Access-edge graph (R/RW) │
│ Claude models only. │ │ • Hash-chained audit ledger │
│ OIDC only. │ │ │
└──────────────────────────────┘ │ ALL providers, ALL surfaces. │
└────────────────────────────────┘
▲
Other agent traffic ────────────────────────┘
(OpenAI, Gemini, vLLM, Ollama, MCP servers, CI pipelines)Dois fluxos de dados conectam o gateway à plataforma:
Distribuição em fan-out OTLP. A configuração telemetry.forward_to do gateway já suporta destinos OTLP/HTTP. Aponte um deles para o receptor Olivares OTLP. O atributo session.id correlaciona a telemetria retransmitida pelo gateway com registros de tempo de execução de sessão do próprio receptor de hooks do conector Claude. Atributos de identidade (user.id, user.email, user.groups) adicionados pelo gateway seguem a lista de permissões de atributos do operador e se tornam rótulos de atribuição nas bordas de sessão e nas amostras de custo — nenhum código de receptor novo é necessário.
Ingestão de eventos de auditoria. O conector claude-apps-gateway lê os eventos de auditoria em JSON do gateway. Os 11 tipos de eventos documentados (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) são mapeados para observações do SDK: negações relevantes para segurança tornam-se achados, eventos de inferência tornam-se conexões de acesso, gêneros de sessão tornam-se observações de identidade e eventos operacionais tornam-se contadores métricos. PII nos eventos brutos é SHA-256 com hash antes de entrar em qualquer observação; e-mails e identificadores são pseudonimizados.
O conector claude-apps-gateway também inventaria o próprio gateway.yaml: emissor OIDC, mapeamentos de IdP-grupo-para-modelo, provedores upstream, destinos OTLP e postura de administração de gastos. Este inventário é metadado estrutural — topologia, não credenciais.
Constatações de postura a partir da configuração do gateway
O conector gera uma família de constatações de postura derivadas da configuração do gateway. Estas são as coisas que um operador de governança precisa saber sobre uma implantação de gateway:
| Constatação | Gravidade | O que é detectado |
|---|---|---|
| Nenhum destino OTLP configurado | Média | A telemetria não é encaminhada; a frota está invisível para monitoramento |
| Nenhuma política universal | Alta | Usuários que não correspondem a nenhum grupo IdP recebem todos os modelos e nenhuma configuração gerenciada |
| Sem limites de gastos | Médio | A API de administração de gastos e a aplicação não estão configuradas |
| Literais de segredo em YAML | Alta | client_secret, jwt_secret ou senhas de banco de dados escritas como literais em vez de referências ${VAR} ou ${file:...} |
| TTL de sessão longo (>12h) | Médio | Latência de desprovisionamento: a sessão de um usuário revogado permanece válida |
| PKCE desativado | Baixo | O fluxo OIDC não usa Chave de Prova para Troca de Código |
| Sinais de telemetria sensíveis | Baixo | logs: true ou traces: true em um destino — estes podem carregar comandos completos do bash e caminhos de arquivos |
Estas descobertas aparecem na mesma visualização de postura que as descobertas de todos os outros conectores. O conector MCP pode relatar uma ferramenta não isolada em sandbox. O conector Bedrock pode sinalizar um guardrail gap. O conector de gateway informa que um catch-all de política está ausente. Uma superfície, uma visão.
Como isso aparece na configuração
O conector Claude executa um receptor OTLP nas portas padrão OpenTelemetry e um endpoint de hooks para os hooks PreToolUse/PostToolUse do Claude Code. Juntamente com ele, o conector apps-gateway lê a configuração do gateway e o fluxo de auditoria. Ambos os conectores são distribuídos sob Apache-2.0 e importam apenas do SDK, nunca do núcleo do 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":"shell access requires confirmation"},
{"resource_kind":"file","mode":"write","decision":"ask"}
]}
gateway: "direct"
semconv_opt_in: "gen_ai_latest_experimental"
- name: olivares.claude-apps-gateway
config:
config_path: "/etc/claude-gateway/gateway.yaml"
audit_log_path: "/var/log/claude-gateway/audit.jsonl"O campo gateway no conector Claude etiqueta cada amostra de custo com a superfície de implementação (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), para que o FinOps possa detalhar o gasto por caminho do provedor. O campo semconv_opt_in habilita o perfil de ingestão GenAI independente de fornecedor (fixado no OpenTelemetry semconv v1.41.1), o que significa que OpenAI, Gemini, ou qualquer agente instrumentado com OTel alimenta o mesmo mapa de acesso e pipeline de custo — não apenas Claude Code.
Posicionamento honesto
Existem coisas sobre as quais vale a pena ser direto.
Isto não é uma substituição de gateway. O proxy de inferência Olivares implementa um subconjunto do protocolo de gateway publicado pelo Anthropic (descoberta OAuth, autorização de dispositivo RFC 8628, entrega de configurações gerenciadas e a superfície administrativa de limites de gastos — visualizações, escritas e aplicação por assento, com suas divergências do protocolo de transmissão documentadas). Ele é útil quando esse subconjunto é suficiente. Não é uma substituição completa para o fluxo de navegador OIDC do gateway, e sua semântica de gastos em grupo difere deliberadamente (mais restritivo vence em vez das regras de mesclagem do gateway). Se o gateway Anthropic atende aos seus requisitos de autenticação, use-o.
O conector é somente leitura. O conector claude-apps-gateway observa a configuração e a saída de auditoria do gateway. Ele não modifica o gateway.yaml, não injeta políticas e não intercepta o caminho /v1/messages. Ele é visibilidade, não controle.
Olivares AI está em pré-lançamento. O produto não é certificado sob SOC 2, ISO/IEC 27001, a Lei de IA da UE ou qualquer outro framework, e nenhuma auditoria está em andamento. Ele é projetado para os objetivos de controle que esses frameworks examinam, portanto está pronto para ser auditado quando chegar a hora.
O valor está na combinação. Uma equipe que apenas executa Claude Code contra um provedor, com um único IdP, e sem servidores MCP de outros fornecedores, pode achar que apenas o gateway é suficiente. A coimplantação ganha seu lugar quando o ambiente é heterogêneo: múltiplos provedores, servidores MCP de vários fornecedores, modelos auto-hospedados, pipelines de CI, requisitos de conformidade que abrangem toda a superfície do agente. É aí que “autenticação Claude” e “governança do ambiente” são realmente problemas diferentes.
FAQ
O Olivares AI substitui o gateway dos aplicativos Claude?
Não. A doutrina é “e, não ou.” O gateway Anthropic possui a sessão de autenticação Claude Code, roteamento de acesso ao modelo e seleção de upstream. O Olivares AI torna essa implantação uma superfície governada dentro de um plano de controle mais amplo que também cobre provedores não-Claude, servidores MCP, modelos autohospedados e o restante do seu conjunto de agentes. Se você já executa o gateway, continue com ele.
Posso executar o Olivares AI sem o gateway de aplicativos Claude?
Sim. O conector claude-apps-gateway é opcional. O conector principal Claude (connectors/claude) ingere telemetria OTLP e hooks diretamente de sessões Claude Code, com ou sem um gateway na frente. Se você não usar o gateway Anthropic, perderá o caminho de autenticação de sessão OIDC, mas manterá a governança completa: inventário de sessões, mapeamento de acesso-edge, atribuição de custos, aplicação de hooks, postura MCP e a visão multi-fornecedor.
Para a topologia de implantação em detalhes, veja /architecture. Para governança de servidores MCP entre fornecedores, veja /product/mcp. Para a superfície completa do produto, veja /product.