El problema: no puedes gobernar lo que no puedes ver
Los agentes ya están ahí. Un asistente de programación con una credencial de base de datos, un servicio RAG interno que silenciosamente obtuvo acceso de escritura a un object store, un job programado que llama a un servidor MCP que nadie registró. Los aprovisionaron equipos que iban deprisa, y la organización de seguridad hereda el blast radius sin haber visto jamás el mapa. Los analistas tienen un nombre para esta forma —proliferación de agentes— y la brecha de gobernanza que la sustenta es medible.
De las organizaciones que sufrieron una brecha relacionada con IA, aproximadamente el 97% carecía de controles de acceso a IA adecuados (IBM Cost of a Data Breach 2025, Ponemon). Eso no es una cuestión de madurez de herramientas; es la ausencia de una superficie de control. Al mismo tiempo Gartner prevé que más del 40% de los proyectos de IA agéntica se cancelen para finales de 2027, y proyecta que los «guardian agents» supongan entre el 10 y el 15% del mercado de IA agéntica para 2030 (Gartner, nota de prensa) — el mercado está incorporando el hecho de que los agentes no gobernados no sobreviven al contacto con una revisión de seguridad real.
El patrón es más amplio que los equipos de seguridad. En un estudio preliminar, aún no revisado por pares, aproximadamente el 95% de los pilotos de GenAI no mostró un impacto medible en la cuenta de resultados, y las herramientas adquiridas externamente tuvieron éxito cerca del doble de veces que los desarrollos internos (MIT «GenAI Divide», proyecto NANDA, vía Fortune, agosto de 2025 — preliminar). Sea cual sea la causa, una infraestructura llena de agentes de los que nadie puede dar cuenta es exactamente la condición bajo la cual se agravan tanto el riesgo de brecha como el riesgo de piloto malgastado.
Esto encaja limpiamente con el marco AI TRiSM —trust, risk and security management para IA— donde la gobernanza y la inspección en runtime se sitúan como capas distintas. Olivares AI está construido para ser la capa que descubre, observa y gobierna el acceso de los agentes, y es honesto sobre dónde se detiene eso.
Lo que Olivares AI le da a un responsable de seguridad
Un mapa de acceso de lectura/escritura tipado como superficie de control
El mapa de acceso modela cada agente como un nodo y cada recurso que puede alcanzar —bases de datos, object stores, servidores MCP, APIs, colas— como un nodo, con cada arista tipada R (lectura) o RW (lectura-escritura). Ese tipado de R frente a RW es la clave: la deriva de mínimo privilegio y el blast radius de un incidente son ambos función del acceso de escritura, no de la mera conectividad, y una lista plana de «tiene acceso» oculta exactamente eso. Esto es reconocimiento para defensores — el mismo mapa que querría un atacante, construido para quienes defienden la infraestructura.
Leer el grafo completo es deliberadamente una acción privilegiada, acotada al tenant y plenamente auditada, porque un mapa completo de lo que cada agente puede tocar es en sí mismo una hoja de ruta de reconocimiento. El mapa almacena la relación —origen, recurso, R/RW, fuente, confianza, timestamps— y nunca los payloads, los cuerpos de SQL, los secretos o la PII que fluyeron a través de la arista. Lo que no se almacena no puede filtrarse.
Permitido frente a observado: el diff que se convierte en hallazgo
Cada arista lleva dos hechos independientes: si el acceso está permitido (un grant o una política lo permite) y si ha sido observado (la telemetría y la auditoría nativa muestran que ocurre). El diff entre esas dos capas es la señal de control:
- Acceso inesperado — observado pero no permitido. Un agente tocó algo que ningún grant cubre. Este es el titular relevante para seguridad.
- Grants sin usar — permitidos pero nunca observados. Tu lista concreta de limpieza de mínimo privilegio, no un vago recordatorio de «revisa tu IAM».
El diff es deliberadamente conservador. Allí donde la plataforma todavía no puede vincular
con firmeza una credencial que actúa al agente para el que se escribió su grant, la arista
se marca como reconciliation_pending — incertidumbre honesta, nunca una violación
fabricada. Consulta permitido frente a observado
para el contrato completo de reconciliación.
Fidelidad que se niega a farolear
Una herramienta de seguridad que exagera lo que sabe es peor que ninguna. Cada arista
lleva dos ejes honestos. La cobertura de la clasificación R/RW está escalonada en
clean | lossy | opaque — clean allí donde la auditoría nativa la hace inequívoca
(Postgres vía pgAudit, object storage vía CloudTrail, los warehouses, más un backstop eBPF
a nivel de kernel), hasta los stores opaque (Redis, SQLite, D1) donde el modo se marca
como unknown en lugar de adivinarse. La atribución es firm allí donde una señal de
identidad por agente resuelve el acceso a un único agente, y approximate allí donde una
cuenta de servicio compartida oculta qué agente actuó. Una arista clean/firm y una
apenas vista nunca se representan como igualmente ciertas — lee el
modelo de fidelidad.
Gobernanza deny-closed, control dual y un kill switch
La gobernanza es read-first y deny-closed. El núcleo de autorización es deny-by-default y acotado al tenant, cerrando por construcción las clases de confused-deputy e IDOR. Cualquier política basada en atributos que conectes encima solo puede restringir más — la composición es una intersección, de modo que una política nunca puede ampliar un grant.
Allí donde el producto controla una acción, el bucle es: una superficie presenta (deriva,
un hallazgo) → un operador autorizado decide → la decisión queda registrada. El motor de
aprobación impone la separación de funciones (un solicitante no puede decidir su propia
petición) y una protección contra decisores duplicados, anclada en una identidad humana
estable — un token de sistema no tiene identidad y no puede decidir. Una acción critical
lleva un mínimo obligatorio de dos personas tomado de NIST SP 800-53 AC-3(2), impuesto
tanto en la creación como rederivado en la decisión, de modo que ni siquiera una política
de operador que rebaje el nivel puede hacer que una acción crítica se realice en solitario.
Existe una válvula de break-glass auditada para el incidente de las 03:00 — ruidosa por
construcción, con elevación de hardware, acotada en el tiempo y forzada a revisión
posterior.
El kill switch es la puerta de denegación a escala de toda la infraestructura. Activarlo es deliberadamente barato (nivel admin, un motivo, sin quórum) porque una parada que espera al consenso no es una parada; cada puerta de actuación gobernada consulta la fila de parada en vivo y falla cerrada ante un error de lectura. La reactivación nunca es unilateral — está condicionada a una aprobación de control dual nueva y no tiene ruta de break-glass, porque «la infraestructura sigue detenida» es el estado seguro.
Evidencia tamper-evident
Cada acción mutadora se añade a un ledger de auditoría append-only y encadenado por hash en la misma transacción que el cambio, con el actor real; las lecturas sensibles se autoauditan en una escritura confirmada. Reescribir el historial es detectable, y el ledger nunca contiene PII. El módulo de compliance mapea esa evidencia de runtime sobre marcos de control, de modo que una evaluación se alimenta de la realidad observada en lugar de un cuestionario.
Lo que esto es — y lo que no es
- Self-hosted y soberano. El control plane funciona en tu propia infraestructura y puede estar air-gapped. Olivares AI es una plataforma abierta y self-hostable (AGPL-3.0). Consulta el modelo de seguridad y la arquitectura.
- Detective por defecto; deny-closed allí donde actúa. Observa y gobierna de forma amplia; no actúa de forma amplia. Allí donde puede tomar una acción, esa superficie es en vivo, bajo demanda o una costura declarada — y el catálogo de módulos marca cuál. Una ausencia de enforcement es habitualmente intencionada.
- Pre-1.0, con un catálogo publicado de 23 módulos (aproximadamente 20 conectados hoy). No todo está en vivo; decimos qué es qué en lugar de dar a entender una cobertura completa.
- El air-gap se aplica al control plane de Olivares, no a tus modelos. Un modelo alojado como Claude nunca está air-gapped; solo los modelos self-hosted (vLLM, Ollama) funcionan offline. Olivares gobierna el acceso en cualquiera de los casos.
- No certificado. Olivares AI está diseñado conforme a SOC 2, ISO/IEC 42001 y la EU AI Act; no posee ninguna certificación y no afirmamos tenerla.
Las infraestructuras de educación superior e investigación tienen una versión paralela de este problema — un uso amplio de IA entre profesorado y personal mientras la gobernanza formal de IA y la cobertura de uso aceptable van por detrás (investigación de EDUCAUSE, 2025). Si ese es tu contexto, consulta educación superior; los equipos de plataforma que operan la infraestructura deberían empezar por ingeniería de plataforma.
A dónde ir a continuación
- Mapa de acceso — el grafo R/RW tipado y la superposición de permitido frente a observado sobre una captura real.
- Kill switch — la puerta de denegación a escala de toda la infraestructura en términos de producto.
- Compliance — evidencia tamper-evident mapeada a marcos de control.
- Conceptos de gobernanza — read-first, deny-closed, control dual.
- Comparativa — cómo Olivares se sitúa junto a gateways, observabilidad y torres de control.
- Empezar — ve el mapa sobre una infraestructura de demo.