Una volta che una sorgente è collegata e la mappa degli accessi mostra cosa ogni agente può leggere e scrivere, il lavoro successivo e governarlo: decidere chi e cosa può agire, e rendere ogni decisione un fatto registrato. Questa pagina copre il workflow di approvazione — livelli di rischio, doppio controllo, break-glass e il registro a cui tutti si ancorano.
La governance e deny-closed per default. Un principale senza ruolo in un tenant viene negato; non esiste alcuna concessione implicita. Il prodotto osserva ampiamente ma non attua ampiamente — dove governa un’azione, lo fa deny-closed, mai come esecutore indiscriminato.
Il modello di autorizzazione
Ogni chiamata di governance passa attraverso lo stesso nucleo di autorizzazione del resto dell’API: RBAC prima di tutto, circoscritto a un singolo tenant, con un livello opzionale di policy esterna sopra.
I ruoli formano una scala — viewer (lettura), editor (scrittura), admin (IAM del tenant), owner (tutto nel tenant). Leggere la mappa degli accessi deliberatamente non e il livello più basso: una mappa di ciò che ogni agente può toccare e una roadmap di ricognizione, quindi è concessa da editor in su, circoscritta al tenant, e ogni lettura viene scritta nel registro.
Un punto di decisione di policy opzionale (Cedar embedded, o OPA via HTTP) può aggiungere regole basate su attributi sopra. Si compone come un’intersezione — RBAC ∩ ABAC nativo ∩ PDP esterno — e ha un invariante:
Il livello di policy può solo togliere accesso, mai aggiungerlo. Una policy può negare qualcosa che RBAC avrebbe consentito; non può mai concedere qualcosa che RBAC nega. Un PDP mal configurato o irraggiungibile fallisce chiuso, e disabilitare il PDP esterno non lascia mai le richieste non governate — RBAC e ABAC nativi continuano a governare.
Livelli di rischio
Un’azione governata viene classificata in uno dei quattro livelli — low, medium, high, critical — derivati dalla tassonomia di rischio OWASP per agenti AI. Il livello determina quanto controllo umano richiede l’azione prima di poter procedere.
Il livello non viene memorizzato sulla riga di approvazione. Viene riderivato dall’insieme di policy corrente più un default integrato a ogni decisione, quindi un cambio di policy ha effetto immediato e uno snapshot obsoleto non può mai tenere la soglia sotto la classificazione attuale (deny-closed).
| Livello | Controllo predefinito |
|—-|—-|
| low / medium | assegnato solo da policy esplicita |
| high | il default per qualsiasi cosa raggiunga la coda di approvazione — un’approvazione umana |
| critical | un minimo obbligatorio di due persone (vedi sotto) |
L’insieme critical integrato copre le azioni genuinamente irreversibili: deploy e ritiro in produzione, cancellazione e rimozione dati, modifiche all’enforcement della sicurezza e al kill switch, custodia e rotazione delle chiavi, e offboarding NHI. Una policy di approvazione con un risk_tier esplicito può alzare o abbassare il default per azione — e la parola registrata dell’operatore — ma non può mai abbassare un’azione critical sotto il minimo di doppio controllo.
Richieste di approvazione e doppio controllo
Una richiesta di approvazione si apre deny-closed e con scadenza temporale: inizia come pending, porta una scadenza e non autorizza nulla finche un numero sufficiente di umani non decide. Una policy di approvazione corrispondente è autorevole per la soglia e i timeout, quindi un richiedente non può mai abbassare la propria soglia.
Tre invarianti sono applicati lato server, non per convenzione:
- Separazione dei compiti. Il richiedente non può decidere sulla propria richiesta. Si basa sull’identità utente stabile, non sulla stringa della credenziale che una singola persona potrebbe variare.
- Una decisione per umano. Un indice unico protegge da una race condition di decisori duplicati; la stessa persona non può contare due volte verso la soglia.
- La scadenza vincola. Una richiesta scaduta non può mai ricevere una decisione vincolante — lo stato effettivo viene riderivato a ogni decisione, scansione o meno.
Per le azioni critical la soglia è fissata a due approvatori umani distinti (doppia autorizzazione NIST SP 800-53 AC-3(2)). Il minimo viene applicato sia quando la richiesta e creata (la soglia memorizzata non può mai partire sotto due) sia al punto di decisione (una richiesta creata prima che l’azione diventasse critica non può comunque passare con un solo umano). Un singolo approvatore non può mai soddisfare un’azione critica.
Una decisione critical richiede inoltre una sessione verificata via hardware: l’umano che decide deve avere uno step-up WebAuthn o PIV (AAL3) recente. Un token di sistema non porta garanzia umana e viene rifiutato — un token di sistema non puo approvare.
Ogni decisione aggiunge una riga immutabile al trail delle decisioni della richiesta e un evento nel registro che registra la decisione, lo stato risultante e il livello di rischio sotto cui è stata presa.
Break-glass
Il doppio controllo ha una valvola di sfogo per l’incidente delle 03:00 dove il secondo approvatore è irraggiungibile. Un admin — sempre un vero umano, mai un token di sistema — attiva una concessione di emergenza a scadenza temporale che permette a un’azione bloccata di procedere senza il suo quorum. Il percorso non è mai silenzioso:
- L’attivazione richiede una giustificazione, si auto-registra nel registro nella stessa transazione ed emette una segnalazione critica sul canale di notifica.
- Ogni utilizzo aggiunge una riga immutabile e un evento nel registro che nomina la concessione, l’azione e il soggetto. Un’azione proceduta sotto break-glass è permanentemente distinguibile da una correttamente approvata.
- La concessione ha scadenza temporale — default un’ora, massimo rigido 24. Un‘“emergenza” che necessita di più tempo e una modalità operativa, non un’emergenza, e deve passare attraverso il normale doppio controllo.
- Revisione post-evento obbligatoria. Una nuova concessione non può essere attivata mentre una precedente non è stata revisionata, e la revisione deve provenire da un umano diverso dall’attivatore. Non puoi accumulare emergenze per evitare lo scrutinio.
Il break-glass attenua un quorum mancante; non sovrascrive mai un rifiuto esplicito da parte di un umano. Una richiesta che qualcuno ha deliberatamente negato resta negata.
La garanzia delle decisioni registrate
Qualunque sia la profondità del workflow sovrastante, una decisione di governance e un fatto registrato. Le azioni mutanti vengono aggiunte al registro di audit con l’attore reale nella stessa transazione del cambiamento, e le letture sensibili (la mappa degli accessi, il registro stesso) si auto-registrano in una scrittura committata. Non puoi effettuare un cambiamento non governato che il registro dimentichi silenziosamente.
Il registro e append-only, hash-chained e firmato con Ed25519. Ogni record porta seq, prev_hash, hash e sig, quindi riscrivere la storia e crittograficamente rilevabile, e il registro non contiene mai PII. Per la copia esterna è immutabile che un auditor richiede, il registro è esposto come export pull autenticato a /v1/audit/export, con valori di format cef, leef, syslog, otlp e ocsf. Ogni record esportato porta i campi di integrità della catena, cosi un SIEM o un archivio WORM può ri-verificare la catena offline — la firma staccata difende contro una compromissione del solo database, e la copia fuori dal server contro un host completamente compromesso.
Ambito onesto
Il nucleo di autorizzazione, il motore di approvazione è il registro funzionano oggi. Ciò che sta ancora maturando e la superficie di revisione operatore più ricca — una console completa per la coda di approvazione; gli endpoint e gli invarianti lato server sono distribuiti, la UI rifinita e il percorso futuro. Come per il resto della piattaforma, questa è open core pre-1.0: leggi Trasparenza e limiti per cosa è attivo rispetto a cosa e in fase di progettazione. Olivares AI è progettato verso i controlli SOC 2, ISO 27001 e EU AI Act, non certificato rispetto ad essi.
Correlati
- Governance — il modello di autorizzazione e la postura di auto-audit al completo.
- Permesso vs osservato — il drift su cui agiscono queste decisioni.
- Collegare una sorgente — cablare i segnali da cui viene costruito il drift.
- Kill switch — l’arresto di emergenza graduato per l’estate.