¿El provider de Terraform es de código abierto y bajo qué licencia?

Sí. El provider, terraform-provider-olivares, se publica bajo AGPL-3.0-only — no Apache-2.0. Gestiona de forma declarativa tu propio control plane self-hosted (agentes, políticas, deployments, vínculos de identidad, presupuestos) contra la API estable del producto. Planifica en consecuencia si tu modelo de distribución es sensible al copyleft.

¿El enfoque de Backstage es un plugin real o un iframe?

El objetivo de diseño es un plugin nativo, read-first, que expone el inventario de agentes, las sesiones en vivo y el mapa de acceso R/RW dentro de tu portal, autenticado contra el control plane. Es integración con el portal, no un segundo dashboard. Trata la profundidad del plugin como pre-1.0 — consulta la referencia de módulos para ver el estado.

Integra tus agentes de IA en la plataforma que ya operas

Q: ¿Olivares AI reemplaza a nuestro proveedor de identidad?

No. No es un IdP. Federa la identidad de los agentes en modo read-only — lee los rosters de Entra Agent ID, AWS AgentCore Identity y Google Agent Identity y los reconcilia contra un roster SPIFFE/WIF, de modo que el grafo de acceso lleva una atribución firme o aproximada por cada edge. No emite credenciales y no escribe nada de vuelta en esos registros.

El problema: los agentes están llegando más rápido de lo que tu plataforma puede modelarlos

Operas una plataforma interna de desarrollo. Tienes un catálogo de servicios, un IdP, infraestructura como código, reconciliación GitOps y un portal que los ingenieros abren de verdad. Esa maquinaria existe precisamente para que nada importante se ejecute sin modelar — ningún servicio sin propietario, ningún acceso sin política, ningún cambio sin diff.

Los agentes de IA rompen ese contrato. Una sesión de Claude Code, un servidor MCP, un agente autónomo programado — cada uno puede leer y escribir en las mismas bases de datos, object stores y APIs que tocan tus servicios, pero aparecen fuera del catálogo. Los levantan los desarrolladores, no los aprovisionas tú. Se autentican como service accounts compartidas tan a menudo como no. Y los hyperscalers lo han empeorado al convertir la identidad de agente en una primitiva GA en tres registros mutuamente incompatibles.

La señal del mercado es contundente. Gartner espera que más del 40% de los proyectos de IA agéntica se cancelen para finales de 2027 (Gartner, nota de prensa), y el estudio Cost of a Data Breach 2025 de IBM (Ponemon) encontró que, de las organizaciones que sufrieron una brecha relacionada con IA, aproximadamente el 97% carecía de controles de acceso de IA adecuados. Un hallazgo preliminar del MIT del proyecto NANDA — the GenAI Divide, vía Fortune, agosto de 2025, aún no revisado por pares — informa de que alrededor del 95% de los pilotos de GenAI no mostraron impacto medible en la cuenta de resultados, y que las herramientas adquiridas externamente tuvieron éxito alrededor del doble de veces que las construidas internamente. Leído frente al trabajo de un equipo de plataforma, apunta en la misma dirección: la proliferación de agentes no gobernados ni modelados es por donde se fuga el valor y se cuela el riesgo.

Cómo encaja Olivares AI en la plataforma que ya operas

Olivares AI es una plataforma abierta y self-hostable que descubre los agentes de IA en tu infraestructura, mapea lo que cada uno puede leer y escribir, y gobierna y audita ese acceso. El objetivo de diseño para los equipos de plataforma no es otra consola — es hacer de los agentes ciudadanos de primera clase de la plataforma que ya operas.

Agentes como entidades de catálogo de primera clase

La plataforma descubre agentes, servidores MCP, sesiones e identidades no humanas, y construye un mapa de acceso: un grafo de cada edge agente → base de datos / store / API, cada uno marcado como lectura (R) o lectura-escritura (RW). Ese grafo es la entrada de catálogo que un agente debería haber tenido desde el principio — qué es, qué toca y si lo que toca coincide con lo que tiene permitido.

Esa última distinción es el núcleo del producto. Los edges se clasifican en permitido vs observado, de modo que la deriva del mínimo privilegio es visible en vez de asumida. Consulta el mapa de acceso y la página de concepto sobre permitido vs observado.

La advertencia de honestidad importa aquí y la mantenemos a la vista: la fidelidad R/RW está escalonada. La cobertura es clean en fuentes con auditoría nativa, lossy donde los edges son toscos, y opaque donde no hay ninguna señal pasiva de lectura/escritura; la atribución es firm cuando una fuente lleva identidad por agente y approximate cuando una cuenta compartida la oculta. El mapa muestra el nivel en vez de fingir certeza — consulta fidelidad.

Gestión como código: un provider de Terraform/OpenTofu

Para un equipo de plataforma, la configuración como código es lo mínimo exigible. Olivares AI incluye terraform-provider-olivares, que gestiona tu propio control plane self-hosted de forma declarativa contra su API estable. El provider expone resources y data sources para agentes, políticas, deployments, vínculos de identidad de agente, presupuestos, configuración de capacidades y rutas de notificación, con import, plan/apply y gestión de drift — de modo que los agentes que gobiernas se reconcilian igual que ArgoCD o Flux ya reconcilian el resto de tu estate.

Un detalle de licencia que conviene precisar, porque difiere del SDK de connectors: el provider es AGPL-3.0-only, no Apache-2.0.

resource "olivares_agent" "billing_assistant" {
  name = "billing-assistant"
  # ...gestionado junto al resto de tu plataforma, como código
}

resource "olivares_policy" "billing_least_privilege" {
  # intención de mínimo privilegio, versionada en Git, reconciliada como todo lo demás
}

El HCL anterior es ilustrativo de la forma, no un contrato de copy-paste — genera contra el schema propio publicado del provider. El producto es pre-1.0: trata la cobertura de resources como un seguimiento de la superficie de la API, y consulta la referencia de módulos para ver qué está cableado hoy.

Encaje con tu IdP — federación, no reemplazo

Olivares AI no es un proveedor de identidad y no intenta serlo. Federa la identidad de agente en modo read-only: lee los rosters de Microsoft Entra Agent ID, AWS AgentCore Identity y Google Agent Identity, y los reconcilia contra un roster SPIFFE/WIF de modo que cada edge del mapa de acceso lleva una atribución firme o aproximada. Las identidades dedicadas de agente y de workload resuelven a atribución firme; los principals de blueprint, los credential providers y los agentes de service account siguen siendo aproximados en vez de promoverse a una identidad fabricada. No emite credenciales y no escribe nada de vuelta en esos registros — la federación es estrictamente read-only.

También expone una clase de drift útil para la seguridad de plataforma: credenciales estáticas de larga duración detectadas en identidades de agente, en línea con la guía de los Five Eyes 2026 hacia credenciales de corta duración. La autenticación de cliente OAuth basada en SVID (el trabajo draft-ietf-oauth-spiffe-client-auth) está implementada como design-toward — no hay reclamación de conformidad hasta que un servidor de autorización publique el flujo correspondiente. Consulta identidad y federación.

Un enfoque de portal: Backstage, read-first

Si tus desarrolladores viven en Backstage, el inventario de agentes debería vivir ahí también. El objetivo de diseño es un plugin nativo, read-first — inventario, sesiones en vivo y el mapa de acceso R/RW renderizados dentro del portal y autenticados contra el control plane — no un iframe y no un segundo dashboard. Read-first es deliberado: encaja con la postura del producto (más abajo) y mantiene la integración con el portal de bajo riesgo.

CLI-first, con una API estable por debajo

Toda la plataforma es un único binario Go, controlplane, que arranca a un grafo de acceso poblado; la consola web está embebida en el mismo origin que la API. Todo lo que puedes hacer en la UI lo puedes pilotar desde la CLI o desde la superficie OpenAPI 3.1, que es sobre lo que el provider de Terraform, un plugin de Backstage y tu propia automatización se construyen. Empieza con la referencia de configuración, el flujo de trabajo de la CLI, y la superficie de gobierno MCP.

Qué es esto — y qué no es

Es un producto con forma de seguridad, así que mantenemos una línea dura sobre lo que afirma.

Read-first y deny-closed. Observa y gobierna ampliamente; no actúa ampliamente. La mayor parte de la actuación es live-on-demand o una junta declarada y deny-closed — un apply de deploy devuelve 503 hasta que aprovisionas un executor, no un no-op silencioso. Consulta permitido vs observado y la página de honestidad y límites.
Pre-1.0, open-core. El catálogo son 23 módulos; aproximadamente 20 están cableados en una instalación estándar. Nada de esto implica que los 23 estén totalmente en vivo — la referencia de módulos marca el estado por módulo.
Air-gap se refiere al control plane, no a Claude. El plano de gobierno y observación se ejecuta totalmente self-hosted y puede estar air-gapped. La inferencia de Claude nunca es self-hosted — Anthropic no publica weights, así que cualquier llamada a Claude llega a una API. Solo los modelos que realmente alojas tú (vLLM, Ollama) se ejecutan offline. Consulta security.
No certificado. Está diseñado hacia el EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 y otros, con evidencia de auditoría extraída de un ledger append-only, encadenado por hash. No está certificado en SOC 2 / ISO / EU AI Act. Consulta compliance.
Complementa tus control towers; no afirma reemplazarlas. La federación de identidad y la exportación de postura son read-only por diseño.

Si quieres primero la imagen arquitectónica, lee la arquitectura; si quieres saber dónde nos situamos respecto a gateways, observabilidad y agent control towers, consulta la comparación. Y si estás sopesando la licencia y el límite del open-core, open source es la versión honesta.

Personas relacionadas: líderes de seguridad, SRE y sysadmin, y educación superior.