Gobernanza: read-first y deny-closed

La gobernanza en Olivares AI se asienta sobre dos principios que puedes tener presentes a la vez: observa antes de aplicar y cuando apliques, di no por defecto. El producto mapea y audita todo lo que cada agente puede alcanzar mucho antes de poner una sola acción bajo control, y los controles que sí ejecuta son deny-closed.

Read-first: observación antes de aplicación

La postura por defecto de la plataforma es detectiva, no preventiva. Construye el mapa de acceso read/write ingiriendo logs, OpenTelemetry y auditoría nativa fuera de banda — nunca está en la ruta de datos del agente, así que un colector que falle no puede tirar producción consigo. A partir de ese mapa contrasta lo permitido frente a lo observado y expone la deriva para que la juzgue un humano.

Esto importa para cómo lees el resto de esta página. El producto observa y gobierna de forma amplia; no actúa de forma amplia. Allí donde puede ejecutar una acción sobre tu infraestructura, esa capacidad es una de tres cosas, y el catálogo de módulos marca cuál:

• live — conectada y actuando hoy (un conjunto reducido);
• on-demand — el backend está construido y conectado a un punto de inyección pero permanece deny-closed o degradado hasta que lo aprovisiones (un executor, un dispatcher, una credencial de inferencia);
• seam — una interfaz declarada y deny-closed sin backend en el binario por defecto.

Por tanto, una ausencia de aplicación suele ser por diseño, no un descuido. Read-first significa que el comportamiento honesto por defecto es observar y registrar, y poner bajo control solo las superficies que has activado explícitamente.

El modelo de autorización dentro del cual gobiernas

Toda decisión gobernada pasa por el mismo núcleo de autorización que protege el resto de la API. Tres propiedades conviene interiorizar antes de cambiar nada.

El RBAC es deny-by-default. Un principal sin pertenencia a un tenant queda denegado — no existe concesión implícita. Los permisos tienen ámbito de tenant, y un handler actúa solo sobre el único tenant al que se resolvió la petición, lo que cierra por construcción las clases confused-deputy e IDOR. Los roles forman una escalera: viewer lee, editor escribe, admin gestiona el IAM del tenant, owner lo tiene todo. Leer el grafo de acceso es deliberadamente un privilegio de editor para arriba — un mapa completo de lo que cada agente puede tocar es una hoja de ruta de reconocimiento — y cada una de esas lecturas se escribe en el ledger de auditoría.

El policy seam solo restringe. Sobre el RBAC puedes conectar un punto de decisión de política basada en atributos. La composición es una intersección — RBAC ∩ ABAC nativo ∩ PDP externo — de modo que una política solo puede restringir aún más lo que el RBAC ya permitía; nunca puede ampliar una concesión. Esto se aplica, no es una convención. Eliges como máximo un motor externo:

# Embedded Cedar (pure-Go, no sidecar) or OPA over HTTP. Default: none.
OLIVARES_PDP_ENGINE=cedar   # or: opa | none

Con Cedar redactas reglas forbid; un conjunto de reglas vacío deja en pie la decisión del RBAC. Con OPA tu Rego debe ser permit-by-default, donde un resultado ausente o cualquier error de transporte falla cerrado. Una configuración de PDP inválida deshabilita solo el PDP externo y registra el hecho — el ABAC nativo y el RBAC siguen gobernando, y un motor mal configurado nunca deja una petición sin gobernar. Toda restricción que aplica el PDP queda auditada.

Niveles de riesgo y el suelo de doble control

Las acciones que llegan a la cola de aprobación se clasifican en cuatro niveles de riesgo — low, medium, high, critical — siguiendo la taxonomía de agentes de IA de OWASP. (Este es un eje distinto de los niveles de cumplimiento de la EU AI Act; no los confundas.) El nivel se re-deriva de la política viva en cada decisión de seguridad, nunca se lee de una instantánea almacenada, de modo que un cambio de política surte efecto de inmediato y una fila obsoleta nunca puede mantener el listón más bajo que la clasificación actual.

Una acción critical lleva un suelo obligatorio de dos personas: al menos dos aprobadores humanos distintos, tomado de la autorización dual de NIST SP 800-53 AC-3(2). El suelo se aplica dos veces — al crear (el umbral almacenado nunca puede arrancar por debajo de él) y re-derivado al decidir (una fila degradada o heredada sigue sin poder cruzarse con un solo aprobador) — de modo que incluso una política de operador que rebaje el nivel explícitamente no puede ejecutar una acción crítica en solitario. El conjunto crítico integrado es la familia irreversible que moldea el estate: deploy y retirada en producción, borrado de datos, cambios en la aplicación de seguridad, custodia y rotación de claves, y la reactivación del estate tras un kill switch.

Los niveles inferiores no cambian la mecánica del motor — una aprobación que ya existe exige al menos un humano — son el vocabulario sobre el que se apoyan otros controles (por ejemplo, escalar la autenticación en una acción crítica).

El gate de aprobación human-in-the-loop

Allí donde el producto pone una acción bajo control, el bucle es: una superficie presenta (deriva del mapa de acceso, un hallazgo del módulo de seguridad) → un operador autorizado decide → la decisión se registra en el ledger de auditoría. El motor de aprobación que respalda esto es real hoy: una petición se abre deny-closed, ligada a un hash de plan y acotada en el tiempo. Las invariantes se aplican en el lado servidor, ancladas a la identidad de usuario estable (un token de sistema no tiene identidad y no puede decidir):

• Separación de funciones — el solicitante nunca puede decidir su propia petición.
• Guarda de decisor duplicado — un humano cuenta una sola vez para un umbral.
• Caducidad — derivada en la lectura, de modo que una petición caducada nunca puede vincular ni siquiera antes de que un barrido materialice su caducidad.

Lo que aún está madurando es la consola de revisión del operador más completa; los endpoints y el motor están disponibles hoy. La guía Gobernar y aprobar recorre el flujo vivo.

La dependencia que hace creíble todo esto es la identidad por agente. La auditoría atribuye la actividad a una credencial, no inherentemente a un agente; una cuenta de servicio compartida colapsa la atribución al nivel de la identidad — expuesto honestamente como un hallazgo, nunca recuperado en silencio. Consulta permitido frente a observado y fidelidad para ver qué hace eso a la señal sobre la que gobiernas.

Break-glass: la válvula de escape auditada

El control de dos personas necesita una válvula de escape para el incidente de las 03:00 en que un aprobador está inalcanzable. Break-glass es esa válvula, y es ruidosa por construcción. La activación es de nivel admin y exige un humano real (un token de sistema se rechaza), un step-up verificado por hardware (AAL3), una justificación por escrito y una sesión activamente grabada como condición previa. La concesión está acotada en el tiempo — una hora por defecto, tope duro de un día — y una concesión caducada no puede autorizar nada.

Mientras una concesión está activa, una acción dentro de su ámbito puede proceder sin su quórum de aprobación, pero cada uso se añade a un rastro inmutable y al ledger de auditoría, nombrando la concesión, la acción y el sujeto — una acción que procedió bajo break-glass es permanentemente distinguible de una aprobada. Una revisión posterior forzada cierra el bucle: una nueva concesión no puede activarse mientras una anterior siga sin revisar, y la revisión debe venir de un humano distinto del activador.

El kill switch: el gate de denegación de todo el estate

El kill switch es la parada de emergencia de un solo clic, e invierte la ergonomía habitual a propósito. Activarlo es deliberadamente barato — de nivel admin, un motivo obligatorio, sin quórum de aprobación, sin step-up, sin break-glass — porque una parada que espera al consenso no es una parada. El nivel de aseguramiento de la sesión que lo activa queda registrado para análisis forense; el abuso de la activación cuesta solo disponibilidad, que es la dirección segura.

La fila de parada es la única fuente de verdad. Todo gate de actuación gobernado la consulta en vivo en cada acción y falla cerrado ante un error de lectura — el inverso exacto del contrato fail-open de los gates de presupuesto, porque un estado de parada ilegible nunca debe significar «adelante». Activarla también revoca el trabajo en cola que los gates no pueden alcanzar: toda aprobación de actuación pendiente dentro de su ámbito se cancela en la misma transacción, de modo que una intención previa a la parada no pueda madurar hasta una concesión que se despache en cuanto el estate vuelva. Las acciones de gobernanza en sí están exentas — la parada detiene el estate agéntico, nunca los controles que lo gobiernan.

La reactivación nunca es unilateral. Está condicionada a una nueva aprobación de doble control (el suelo critical de dos humanos distintos, re-verificado estructuralmente en el cambio de modo que una política degradada no pueda hacerlo en solitario), y deliberadamente no hay ruta de break-glass para la reactivación: «el estate sigue parado» es el estado seguro. Una revisión posterior forzada por un humano no implicado cierra el incidente.

La garantía de decisiones registradas

Sea cual sea la profundidad del flujo de arriba, una decisión de gobernanza es un hecho registrado. Las acciones mutadoras se añaden al ledger de auditoría con el actor real en la misma transacción que el cambio, y las lecturas sensibles (el grafo de acceso, el propio ledger) se autoauditan en una escritura confirmada. El ledger es append-only y hash-chained, cada registro porta los campos de integridad de la cadena, de modo que reescribir la historia es detectable y nunca contiene PII. No puedes hacer un cambio sin gobernar que el ledger olvide en silencio.

Relacionado

• Permitido frente a observado — la deriva sobre la que actúan estas decisiones.
• Fidelidad — cuánta confianza hay en la señal bajo una decisión.
• Gobernar y aprobar — el flujo de aprobación vivo, paso a paso.
• Kill switch — el gate de denegación de todo el estate en términos de producto.
• Honestidad y límites — la postura deny-closed y detectiva por defecto al completo.