Una vez conectada una fuente y cuando el mapa de accesos muestra lo que cada agente puede leer y escribir, el siguiente trabajo es gobernarlo: decidir quién y qué puede actuar, y convertir cada decisión en un hecho registrado. Esta página cubre el flujo de aprobación: los niveles de riesgo, el control dual, el break-glass y el ledger al que todos ellos se anclan.
La gobernanza es deny-closed por defecto. Un principal sin rol en un tenant es denegado; no existe concesión implícita. El producto observa de forma amplia pero no actúa de forma amplia: allí donde gobierna una acción, lo hace deny-closed, nunca como ejecutor general.
El modelo de autorización
Toda llamada de gobernanza pasa por el mismo núcleo de autorización que el resto de la API: RBAC primero, acotado a un único tenant, con una capa de política externa opcional por encima.
Los roles forman una escalera: viewer (lectura), editor (escritura), admin (IAM del tenant), owner
(todo dentro del tenant). Leer el mapa de accesos deliberadamente no es el nivel más bajo:
un mapa de lo que cada agente puede tocar es una hoja de ruta de reconocimiento, así que se concede desde editor hacia arriba,
acotado al tenant, y cada lectura se escribe en el ledger.
Un policy decision point opcional (Cedar embebido, u OPA sobre HTTP) puede añadir reglas basadas en atributos por encima. Se compone como una intersección — RBAC ∩ ABAC nativo ∩ PDP externo — y tiene un invariante:
La capa de política solo puede quitar acceso, nunca añadirlo. Una política puede denegar algo que RBAC habría permitido; nunca puede conceder algo que RBAC deniega. Un PDP mal configurado o inalcanzable falla en cerrado, y desactivar el PDP externo nunca deja las peticiones sin gobernar: el RBAC y el ABAC nativos siguen gobernando.
Niveles de riesgo
Una acción gobernada se clasifica en uno de cuatro niveles — low, medium, high,
critical — derivados de la taxonomía de riesgo de agentes de IA de OWASP. El nivel determina cuánto control
humano requiere la acción antes de poder proceder.
El nivel no se almacena en la fila de aprobación. Se vuelve a derivar a partir del conjunto de políticas actual más un valor por defecto incorporado en cada decisión, de modo que un cambio de política surte efecto de inmediato y un snapshot obsoleto nunca puede mantener el listón por debajo de la clasificación viva (deny-closed).
| Nivel | Control por defecto |
|---|---|
low / medium | asignado solo por política explícita |
high | el valor por defecto para todo lo que llega a la cola de aprobación — una aprobación humana |
critical | un suelo obligatorio de dos personas (ver más abajo) |
El conjunto critical incorporado cubre lo genuinamente irreversible: deploy y retirada en producción,
borrado y eliminación de datos, cambios de aplicación de seguridad y de kill-switch, custodia y rotación
de claves, y offboarding de NHI. Una política de aprobación con un risk_tier explícito puede subir o
bajar el valor por defecto por acción — esa es la palabra auditada del operador — pero nunca puede bajar
una acción critical por debajo del suelo de control dual.
Peticiones de aprobación y control dual
Una petición de aprobación se abre deny-closed y acotada en el tiempo: empieza pendiente, lleva un vencimiento y no autoriza nada hasta que suficientes humanos deciden sobre ella. Una política de aprobación coincidente es autoritativa para el umbral y los timeouts, de modo que un solicitante nunca puede bajar su propio listón.
Se aplican tres invariantes en el servidor, no por convención:
- Separación de funciones. El solicitante no puede decidir su propia petición. Esto se basa en la identidad estable del usuario, no en la cadena de credenciales que una sola persona podría variar.
- Una decisión por humano. Un índice único respalda contra una condición de carrera de decisor duplicado; la misma persona no puede contar dos veces para el umbral.
- El vencimiento obliga. Una petición vencida nunca puede recibir una decisión vinculante: el estado efectivo se vuelve a derivar en cada decisión, haya barrido o no.
Para las acciones critical el umbral tiene un suelo de dos aprobadores humanos distintos (NIST
SP 800-53 AC-3(2) autorización dual). El suelo se aplica tanto cuando se crea la petición
(el umbral almacenado nunca puede empezar por debajo de dos) como al volver a aplicarse en el punto de
decisión (una petición creada antes de que la acción se volviera crítica sigue sin poder superarse con un
solo humano). Un único aprobador nunca puede satisfacer una acción crítica.
Una decisión critical requiere además una sesión verificada por hardware: el humano que
decide debe tener un step-up reciente de WebAuthn o PIV (AAL3). Un token de sistema no aporta garantía
humana y es rechazado — un token de sistema no puede aprobar.
Cada decisión anexa una fila inmutable al rastro de decisiones de la petición y un evento de ledger que registra la decisión, el estado resultante y el nivel de riesgo bajo el cual se tomó.
Break-glass
El control de dos personas tiene una válvula de escape para el incidente de las 03:00 en el que el segundo aprobador está inalcanzable. Un admin — siempre un humano real, nunca un token de sistema — activa una concesión de emergencia acotada en el tiempo que permite que una acción restringida proceda sin su quórum. El camino nunca es silencioso:
- La activación requiere una justificación, se autoaudita en el ledger dentro de la misma transacción y emite un hallazgo crítico al canal de notificaciones.
- Cada uso anexa una fila inmutable y un evento de ledger que nombra la concesión, la acción y el sujeto. Una acción que procedió bajo break-glass es permanentemente distinguible de una correctamente aprobada.
- La concesión está acotada en el tiempo — un valor por defecto de una hora, con un tope máximo de 24. Una «emergencia» que necesita más tiempo es un modo de operación, no una emergencia, y debe pasar por el control dual normal.
- Revisión posterior forzada. No se puede activar una nueva concesión mientras cualquier concesión anterior esté sin revisar, y la revisión debe venir de un humano distinto del activador. No puedes apilar emergencias para esquivar el escrutinio.
El break-glass relaja un quórum ausente; nunca anula un rechazo humano explícito. Una petición que alguien denegó deliberadamente permanece denegada.
La garantía de decisiones registradas
Sea cual sea la profundidad del flujo de trabajo anterior, una decisión de gobernanza es un hecho registrado. Las acciones mutadoras se anexan al audit ledger con el actor real dentro de la misma transacción que el cambio, y las lecturas sensibles (el mapa de accesos, el propio ledger) se autoauditan en una escritura confirmada. No puedes hacer un cambio sin gobernar que el ledger olvide silenciosamente.
El ledger es append-only, encadenado por hash y firmado con Ed25519. Cada registro lleva seq,
prev_hash, hash y sig, de modo que reescribir la historia es criptográficamente detectable, y el
ledger nunca contiene PII. Para la copia externa e inmutable que pide un auditor, el ledger
se expone como un export de pull autenticado en /v1/audit/export, con los valores de format
cef, leef, syslog, otlp y ocsf. Cada registro exportado lleva los campos de integridad
de la cadena, de modo que un SIEM o un almacén WORM puede reverificar la cadena offline: la firma separada
defiende frente a un compromiso limitado a la base de datos, y la copia fuera del equipo frente a un host
totalmente comprometido.
Alcance honesto
El núcleo de autorización, el motor de aprobación y el ledger funcionan hoy. Lo que aún está madurando es la superficie más rica de revisión para el operador — una consola completa de cola de aprobaciones; los endpoints y los invariantes del lado del servidor están entregados, la UI pulida es el camino por delante. Como con el resto de la plataforma, esto es open core pre-1.0: lee Honestidad y límites para saber qué está vivo frente a qué es design-toward. Olivares AI está diseñado en dirección a los controles de SOC 2, ISO 27001 y EU AI Act, no certificado frente a ellos.
Relacionado
- Gobernanza — el modelo de autorización y la postura de autoauditoría al completo.
- Permitido frente a observado — la deriva sobre la que actúan estas decisiones.
- Conectar una fuente — cablear las señales a partir de las que se construye la deriva.
- Kill switch — la parada de emergencia graduada para el estate.