A abordagem Backstage é um plugin real ou um iframe?

O alvo de design é um plugin nativo, primeiro de leitura, que apresenta o inventário de agentes, as sessões em direto e o mapa de acessos R/RW dentro do seu portal, autenticado com o control plane. É integração no portal, não um segundo painel. Trate a profundidade do plugin como pré-1.0 — consulte a referência de módulos para o estado atual.

Coloque os seus agentes de IA na plataforma que já opera

Q: O provider Terraform é open source e sob que licença?

Sim. O provider, terraform-provider-olivares, é publicado sob AGPL-3.0-only — e não Apache-2.0. Faz a gestão do seu próprio control plane self-hosted (agentes, políticas, implementações, ligações de identidade, orçamentos) de forma declarativa contra a API estável do produto. Planeie em conformidade se o seu modelo de distribuição for sensível ao copyleft.

Q: A Olivares AI substitui o nosso fornecedor de identidade?

Não. Não é um IdP. Federa a identidade dos agentes em modo só de leitura — lê os registos do Entra Agent ID, do AWS AgentCore Identity e do Google Agent Identity e reconcilia-os com um registo SPIFFE/WIF, de modo a que o grafo de acessos carregue uma atribuição firme ou aproximada por aresta. Não emite credenciais e não escreve nada de volta nesses registos.

O problema: os agentes chegam mais depressa do que a sua plataforma os consegue modelar

Opera uma plataforma interna de desenvolvimento. Tem um catálogo de serviços, um IdP, infraestrutura como código, reconciliação GitOps e um portal que os engenheiros realmente abrem. Essa maquinaria existe precisamente para que nada importante corra sem estar modelado — nenhum serviço sem dono, nenhum acesso sem política, nenhuma alteração sem um diff.

Os agentes de IA quebram esse contrato. Uma sessão do Claude Code, um servidor MCP, um agente autónomo agendado — cada um pode ler e escrever nas mesmas bases de dados, object stores e APIs em que os seus serviços tocam, mas aparecem fora do catálogo. São criados por programadores, não aprovisionados por si. Autenticam-se como contas de serviço partilhadas tantas vezes quanto não. E os hyperscalers pioraram a situação ao tornar a identidade de agentes uma primitiva GA em três registos mutuamente incompatíveis.

O sinal do mercado é direto. A Gartner espera que mais de 40% dos projetos de IA agêntica sejam cancelados até ao final de 2027 (Gartner, imprensa), e o estudo Cost of a Data Breach 2025 da IBM (Ponemon) constatou que, das organizações que sofreram uma violação relacionada com IA, cerca de 97% não dispunham de controlos de acesso de IA adequados. Uma conclusão preliminar do MIT, do projeto NANDA — the GenAI Divide, via Fortune, agosto de 2025, ainda não revista por pares — relata que cerca de 95% dos pilotos de GenAI não mostraram impacto mensurável em P&L, e que as ferramentas adquiridas externamente tiveram sucesso cerca de duas vezes mais do que as construídas internamente. Lido à luz do trabalho de uma equipa de plataforma, isto aponta na mesma direção: a proliferação de agentes não governados e não modelados é onde o valor se escapa e o risco se infiltra.

Como a Olivares AI se encaixa na plataforma que já opera

A Olivares AI é uma plataforma aberta e self-hostable que descobre os agentes de IA na sua infraestrutura, mapeia o que cada um pode ler e escrever, e governa e audita esse acesso. O objetivo de design para equipas de plataforma não é mais uma consola — é tornar os agentes cidadãos de primeira classe da plataforma que já opera.

Agentes como entidades de primeira classe no catálogo

A plataforma descobre agentes, servidores MCP, sessões e identidades não humanas, e constrói um mapa de acessos: um grafo de cada aresta agente → base de dados / store / API, cada uma marcada como leitura (R) ou leitura-escrita (RW). Esse grafo é a entrada de catálogo que um agente deveria sempre ter tido — o que é, em que toca, e se aquilo em que toca corresponde àquilo que lhe é permitido.

Esta última distinção é o cerne do produto. As arestas são classificadas como permitidas vs observadas, de modo a que o desvio do least-privilege seja visível em vez de presumido. Consulte o mapa de acessos e a página de conceitos sobre permitido vs observado.

A ressalva de honestidade importa aqui e mantemo-la à vista: a fidelidade de R/RW é escalonada. A cobertura é clean em fontes com auditoria nativa, lossy onde as arestas são grosseiras, e opaque onde não há qualquer sinal passivo de leitura/escrita; a atribuição é firm quando uma fonte carrega identidade por agente e approximate quando uma conta partilhada a oculta. O mapa mostra o nível em vez de fingir certeza — consulte fidelidade.

Gestão como código: um provider Terraform/OpenTofu

Para uma equipa de plataforma, a configuração como código é o mínimo indispensável. A Olivares AI disponibiliza terraform-provider-olivares, que faz a gestão do seu próprio control plane self-hosted de forma declarativa contra a sua API estável. O provider expõe recursos e fontes de dados para agentes, políticas, implementações, ligações de identidade de agentes, orçamentos, configuração de capacidades e rotas de notificação, com import, plan/apply e tratamento de desvio — de modo a que os agentes que governa sejam reconciliados da mesma forma que o ArgoCD ou o Flux já reconciliam o resto do seu património.

Um detalhe de licença a ser preciso, porque difere do SDK de conectores: o provider é AGPL-3.0-only, não Apache-2.0.

resource "olivares_agent" "billing_assistant" {
  name = "billing-assistant"
  # ...managed alongside the rest of your platform, as code
}

resource "olivares_policy" "billing_least_privilege" {
  # least-privilege intent, versioned in Git, reconciled like everything else
}

O HCL acima é ilustrativo da forma, não um contrato para copiar e colar — gere contra o esquema publicado do próprio provider. O produto está em pré-1.0: trate a cobertura de recursos como seguindo a superfície da API e verifique a referência de módulos para saber o que está ligado hoje.

Encaixe com o seu IdP — federação, não substituição

A Olivares AI não é um fornecedor de identidade e não tenta sê-lo. Federa a identidade dos agentes em modo só de leitura: lê os registos do Microsoft Entra Agent ID, do AWS AgentCore Identity e do Google Agent Identity, e reconcilia-os com um registo SPIFFE/WIF, de modo a que cada aresta no mapa de acessos carregue uma atribuição firme ou aproximada. Identidades dedicadas de agente e de workload resolvem para atribuição firme; principais de blueprint, fornecedores de credenciais e agentes com contas de serviço permanecem aproximados em vez de serem promovidos a uma identidade fabricada. Não emite credenciais e não escreve nada de volta nesses registos — a federação é estritamente só de leitura.

Também expõe uma classe de desvio útil para a segurança de plataforma: credenciais estáticas de longa duração detetadas em identidades de agentes, em linha com a orientação Five Eyes 2026 no sentido de credenciais de curta duração. A autenticação de cliente OAuth baseada em SVID (o trabalho draft-ietf-oauth-spiffe-client-auth) está implementada como design-toward — não há qualquer reivindicação de conformidade até que um servidor de autorização publique o fluxo correspondente. Consulte identidade e federação.

Uma abordagem de portal: Backstage, primeiro de leitura

Se os seus programadores vivem no Backstage, o inventário de agentes também deve viver lá. O alvo de design é um plugin nativo, primeiro de leitura — inventário, sessões em direto e o mapa de acessos R/RW renderizados dentro do portal e autenticados contra o control plane — não um iframe e não um segundo painel. Primeiro de leitura é deliberado: corresponde à postura do produto (abaixo) e mantém a integração no portal de baixo risco.

Primeiro a CLI, com uma API estável por baixo

A plataforma inteira é um binário Go, controlplane, que arranca para um grafo de acessos já populado; a consola web está embebida na mesma origem que a API. Tudo o que pode fazer na interface pode controlá-lo a partir da CLI ou da superfície OpenAPI 3.1, que é aquilo sobre que o provider Terraform, um plugin Backstage e a sua própria automação se constroem. Comece pela referência de configuração, pelo fluxo de trabalho da CLI e pela superfície de governação MCP.

O que isto é — e o que não é

Este é um produto com forma de segurança, por isso mantemos uma linha rígida sobre o que afirma.

Primeiro de leitura e deny-closed. Observa e governa de forma ampla; não atua de forma ampla. A maior parte da atuação é live-on-demand ou uma junção declarada e deny-closed — um apply de implementação devolve 503 até aprovisionar um executor, não um no-op silencioso. Consulte permitido vs observado e a página de honestidade e limites.
Pré-1.0, open-core. O catálogo tem 23 módulos; cerca de 20 estão ligados numa instalação padrão. Nada aqui implica que os 23 estejam totalmente em funcionamento — a referência de módulos marca o estado por módulo.
Air-gap significa o control plane, não o Claude. O plano de governação e observação corre totalmente self-hosted e pode ser air-gapped. A inferência do Claude nunca é self-hosted — a Anthropic não publica pesos, pelo que qualquer chamada ao Claude alcança uma API. Apenas os modelos que realmente faz self-host (vLLM, Ollama) correm offline. Consulte segurança.
Não certificado. Está concebido no sentido de EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 e outros, com evidência de auditoria extraída de um registo append-only com cadeia de hashes. Não é certificado SOC 2 / ISO / EU-AI-Act. Consulte conformidade.
Complementa as suas control towers; não afirma substituí-las. A federação de identidade e a exportação de postura são, por design, só de leitura.

Se quiser primeiro o quadro arquitetural, leia a arquitetura; se quiser saber onde nos situamos relativamente a gateways, observabilidade e control towers de agentes, consulte a comparação. E se está a ponderar a licença e a fronteira open-core, open source é a versão honesta.

Personas relacionadas: líderes de segurança, SRE e sysadmin e ensino superior.