Governance: lettura prima di tutto e deny-closed

La governance in Olivares AI si fonda su due principi che puoi tenere a mente contemporaneamente: osserva prima di applicare, e quando applichi, il default è negare. Il prodotto mappa e audita ciò che ogni agente può raggiungere molto prima di bloccare una singola azione, e i controlli che esegue sono deny-closed.

Lettura prima di tutto: osservazione prima dell’applicazione

La postura predefinita della piattaforma è investigativa, non preventiva. Costruisce la mappa degli accessi lettura/scrittura acquisendo log, OpenTelemetry e audit nativi fuori banda — non è mai nel percorso dati dell’agente, quindi un collector che fallisce non può mandare in down la produzione. Da quella mappa confronta permesso con osservato e presenta le deviazioni affinche un umano le valuti.

Questo è importante per come leggi il resto di questa pagina. Il prodotto osserva e governa ampiamente; non attua ampiamente. Dove può intraprendere un’azione sulla tua infrastruttura, tale capacità e una di queste tre cose, e il catalogo dei moduli indica quale:

• live — cablato e attivo oggi (un insieme ristretto);
• on-demand — il backend è costruito e collegato a un punto di iniezione ma resta deny-closed o degradato finche non lo configuri (un executor, un dispatcher, una credenziale di inferenza);
• seam — un’interfaccia dichiarata, deny-closed, senza backend nel binario predefinito.

Quindi un’assenza di applicazione e generalmente per progetto, non una dimenticanza. Lettura prima di tutto significa che il default onesto e osservare e registrare, e bloccare solo le superfici che hai esplicitamente attivato.

Il modello di autorizzazione entro cui governi

Ogni decisione governata passa attraverso lo stesso nucleo di autorizzazione che protegge il resto dell’API. Tre proprietà meritano di essere interiorizzate prima di modificare qualsiasi cosa.

RBAC e deny-by-default. Un principale senza appartenenza a un tenant viene negato — non esiste alcuna concessione implicita. I permessi sono circoscritti al tenant, è un handler agisce solo sul singolo tenant a cui la richiesta si e risolta, il che chiude le classi confused-deputy e IDOR per costruzione. I ruoli formano una scala: viewer legge, editor scrive, admin gestisce lo IAM del tenant, owner ha tutto. Leggere il grafo degli accessi è deliberatamente un privilegio da editor in su — una mappa completa di ciò che ogni agente può raggiungere e una roadmap di ricognizione — e ogni lettura viene scritta nel registro di audit.

Il punto di policy può solo restringere. Sopra RBAC puoi collegare un punto di decisione di policy basato su attributi. La composizione e un’intersezione — RBAC ∩ ABAC nativo ∩ PDP esterno — quindi una policy può solo restringere ulteriormente ciò che RBAC ha già consentito; non può mai ampliare una concessione. Questo è applicato, non una convenzione. Scegli al massimo un motore esterno:

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

Con Cedar scrivi regole forbid; un insieme di regole vuoto lascia valida la decisione RBAC. Con OPA il tuo Rego deve essere permit-by-default, dove un risultato mancante o qualsiasi errore di trasporto fallisce chiuso. Una configurazione PDP non valida disabilita solo il PDP esterno e registra il fatto — ABAC nativo e RBAC continuano a governare, e un motore mal configurato non lascia mai una richiesta non governata. Ogni restrizione applicata dal PDP viene registrata nell’audit.

Livelli di rischio e il minimo di doppio controllo

Le azioni che raggiungono la coda di approvazione sono classificate in quattro livelli di rischio — low, medium, high, critical — seguendo la tassonomia OWASP per agenti AI. (Questo è un asse separato dai livelli di conformita dell’EU AI Act; non confondere i due.) Il livello viene riderivato dalla policy attiva a ogni decisione di sicurezza, mai letto da uno snapshot memorizzato, quindi un cambio di policy ha effetto immediato e una riga obsoleta non può mai tenere la soglia più bassa della classificazione attuale.

Un’azione critical comporta un minimo obbligatorio di due persone: almeno due approvatori umani distinti, derivato dalla doppia autorizzazione NIST SP 800-53 AC-3(2). Il minimo viene applicato due volte — alla creazione (la soglia memorizzata non può mai partire sotto di esso) e riderivato alla decisione (una riga declassata o legacy non può comunque passare con un solo approvatore) — cosi anche una policy operatore che abbassa esplicitamente il livello non può rendere un’azione critica a mano singola. L’insieme critico integrato comprende la famiglia irreversibile che modella l’estate: deploy e ritiro in produzione, cancellazione dati, modifiche all’applicazione della sicurezza, custodia e rotazione delle chiavi, e riabilitazione dell’estate dopo un kill switch.

I livelli inferiori non cambiano la meccanica del motore — un’approvazione già esistente richiede almeno un umano — sono il vocabolario su cui si basano altri controlli (ad esempio, intensificare l’autenticazione su un’azione critica).

Il gate di approvazione human-in-the-loop

Dove il prodotto blocca un’azione, il ciclo e: una superficie presenta (drift dalla mappa degli accessi, una segnalazione dal modulo di sicurezza) -> un operatore autorizzato decide -> la decisione viene registrata nel registro di audit. Il motore di approvazione che supporta tutto questo è reale oggi: una richiesta si apre deny-closed, legata a un hash del piano, e con scadenza temporale. Gli invarianti sono applicati lato server, basati sull’identità utente stabile (un token di sistema non ha identità e non può decidere):

• Separazione dei compiti — il richiedente non può mai decidere sulla propria richiesta.
• Guardia contro decisori duplicati — un umano conta una sola volta verso la soglia.
• Scadenza — derivata alla lettura, quindi una richiesta scaduta non può mai vincolarsi anche prima che una scansione ne materializzi la scadenza.

Ciò che sta ancora maturando e la console di revisione operatore più ricca; gli endpoint e il motore vengono distribuiti oggi. La guida Governare e approvare illustra il flusso dal vivo.

La dipendenza che rende tutto questo credibile e l’identità per agente. L’audit attribuisce l’attività a una credenziale, non intrinsecamente a un agente; un account di servizio condiviso riduce l’attribuzione al livello dell’identità — presentata onestamente come segnalazione, mai recuperata silenziosamente. Vedi permesso vs osservato e fedeltà per capire cosa questo fa al segnale su cui governi.

Break-glass: la valvola di sfogo registrata

Il doppio controllo necessita di una valvola di sfogo per l’incidente delle 03:00 quando un approvatore è irraggiungibile. Il break-glass e quella valvola, ed è rumoroso per costruzione. L’attivazione e di livello admin e richiede un vero umano (un token di sistema viene rifiutato), un step-up verificato via hardware (AAL3), una giustificazione scritta e una sessione attivamente registrata come precondizione. La concessione ha una scadenza — default un’ora, massimo un giorno — e una concessione scaduta non può autorizzare nulla.

Mentre una concessione è attiva, un’azione nell’ambito può procedere senza il suo quorum di approvazione, ma ogni utilizzo viene aggiunto a un trail immutabile e al registro di audit, nominando la concessione, l’azione e il soggetto — un’azione proceduta sotto break-glass è permanentemente distinguibile da una approvata. Una revisione post-evento obbligatoria chiude il ciclo: una nuova concessione non può essere attivata mentre una precedente non è stata revisionata, e la revisione deve provenire da un umano diverso dall’attivatore.

Il kill switch: il gate di negazione a livello di estate

Il kill switch e l’arresto di emergenza con un click, e inverte intenzionalmente l’ergonomia abituale. L’attivazione è deliberatamente economica — livello admin, un motivo obbligatorio, nessun quorum di approvazione, nessuno step-up, nessun break-glass — perché un arresto che attende il consenso non è un arresto. Il livello di garanzia della sessione di attivazione viene registrato per la forensics; un abuso dell’attivazione costa solo disponibilità, che è la direzione sicura.

La riga di stop e la singola fonte di verità. Ogni gate di attuazione governata la consulta dal vivo su ogni azione e fallisce chiuso su un errore di lettura — l’esatto inverso del contratto fail-open dei gate di budget, perché uno stato di stop illeggibile non deve mai significare “via libera”. L’attivazione revoca inoltre il lavoro in coda che i gate non possono raggiungere: ogni approvazione di attuazione in sospeso nell’ambito viene cancellata nella stessa transazione, cosi un intento pre-stop non può maturare in una concessione che scatta nel momento in cui l’estate torna attivo. Le azioni di governance sono esenti — lo stop ferma l’estate agentico, mai i controlli che lo governano.

La riabilitazione non è mai unilaterale. E bloccata da una nuova approvazione a doppio controllo (il minimo di critical con due umani distinti, ri-verificato strutturalmente al momento del cambio cosi una policy declassata non può renderla a mano singola), e non esiste deliberatamente nessun percorso break-glass per la riabilitazione: “l’estate resta fermato” e lo stato sicuro. Una revisione post-evento obbligatoria da parte di un umano non coinvolto chiude l’incidente.

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 (il grafo degli accessi, il registro stesso) si auto-registrano in una scrittura committata. Il registro e append-only e hash-chained, ogni record porta i campi di integrità della catena, quindi riscrivere la storia e rilevabile e non contiene mai PII. Non puoi effettuare un cambiamento non governato che il registro dimentichi silenziosamente.

Correlati

• Permesso vs osservato — il drift su cui agiscono queste decisioni.
• Fedeltà — quanto e affidabile il segnale alla base di una decisione.
• Governare e approvare — il flusso di approvazione dal vivo, passo per passo.
• Kill switch — il gate di negazione a livello di estate in termini di prodotto.
• Trasparenza e limiti — la postura deny-closed, investigativa per default al completo.