Il problema: non puoi governare ciò che non puoi vedere
Gli agenti sono già lì. Un assistente di coding con una credenziale di database, un servizio RAG interno che ha silenziosamente ottenuto l’accesso in scrittura a un object store, un job pianificato che chiama un server MCP che nessuno ha registrato. Sono stati provisionati da team che si muovevano in fretta, e l’organizzazione di sicurezza eredita il raggio d’impatto senza aver mai visto la mappa. Gli analisti hanno un nome per questa forma — proliferazione degli agenti — e il divario di governance che vi è sotto è misurabile.
Tra le organizzazioni che hanno subito una violazione legata all’AI, circa il 97% non disponeva di controlli di accesso AI adeguati (IBM Cost of a Data Breach 2025, Ponemon). Non è una questione di maturità degli strumenti; è l’assenza di una superficie di controllo. Allo stesso tempo Gartner prevede che oltre il 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027, e proietta che gli “agenti guardiani” rappresenteranno il 10–15% del mercato dell’AI agentica entro il 2030 (Gartner, comunicato stampa) — il mercato sta scontando il fatto che gli agenti non governati non sopravvivono all’impatto con una vera revisione di sicurezza.
Il fenomeno è più ampio dei team di sicurezza. In uno studio preliminare, non ancora sottoposto a peer review, circa il 95% dei pilot di GenAI non ha mostrato alcun impatto misurabile sul conto economico, e gli strumenti acquistati esternamente hanno avuto successo circa il doppio delle volte rispetto agli sviluppi interni (MIT “GenAI Divide”, progetto NANDA, via Fortune, ago 2025 — preliminare). Qualunque ne sia la causa, un parco pieno di agenti di cui nessuno può rendere conto è esattamente la condizione in cui sia il rischio di violazione sia il rischio di pilot sprecati si compongono.
Tutto questo si mappa con precisione sull’impostazione AI TRiSM — trust, risk e security management per l’AI — dove governance e ispezione runtime si collocano come livelli distinti. Olivares AI è costruito per essere il livello che scopre, osserva e governa l’accesso degli agenti, ed è onesto su dove ciò si ferma.
Cosa offre Olivares AI a un responsabile di sicurezza
Una mappa degli accessi tipizzata in lettura/scrittura come superficie di controllo
La mappa degli accessi modella ogni agente come un nodo e ogni risorsa che può raggiungere — database, object store, server MCP, API, code — come un nodo, con ogni arco tipizzato R (lettura) o RW (lettura-scrittura). Questa tipizzazione R rispetto a RW è il punto: sia il drift rispetto al least-privilege sia il raggio d’impatto di un incidente sono funzione dell’accesso in scrittura, non della mera connettività, e un elenco piatto di “ha accesso” nasconde proprio questo. Questa è ricognizione per chi difende — la stessa mappa che vorrebbe un attaccante, costruita per chi difende il parco infrastrutturale.
Leggere il grafo completo è deliberatamente un’azione privilegiata, circoscritta al tenant e completamente sottoposta ad audit, perché una mappa completa di ciò che ogni agente può toccare è essa stessa una roadmap per la ricognizione. La mappa memorizza la relazione — origine, risorsa, R/RW, sorgente, confidenza, timestamp — e mai i payload, i corpi SQL, i segreti o i PII che hanno attraversato l’arco. Ciò che non viene memorizzato non può trapelare.
Permesso vs osservato: il confronto che diventa una rilevazione
Ogni arco porta con sé due fatti indipendenti: se l’accesso è permesso (un grant o una policy lo consente) e se è stato osservato (telemetria e audit nativo ne mostrano l’occorrenza). Il confronto tra questi due livelli è il segnale di controllo:
- Accesso inatteso — osservato ma non permesso. Un agente ha toccato qualcosa che nessun grant copre. È questo il titolo rilevante per la sicurezza.
- Grant inutilizzati — permessi ma mai osservati. La tua lista concreta di pulizia per il least-privilege, non un vago promemoria del tipo “rivedi il tuo IAM”.
Il confronto è deliberatamente conservativo. Dove la piattaforma non può ancora
collegare con certezza una credenziale agente all’agente per cui era stato scritto il
suo grant, l’arco viene marcato reconciliation_pending — incertezza onesta, mai una
violazione inventata. Vedi permesso vs osservato
per il contratto di riconciliazione completo.
Una fedeltà che si rifiuta di bluffare
Uno strumento di sicurezza che sopravvaluta ciò che sa è peggio di nessuno strumento.
Ogni arco porta con sé due assi onesti. La copertura della classificazione R/RW è
suddivisa in livelli clean | lossy | opaque — clean dove l’audit nativo la rende
inequivocabile (Postgres tramite pgAudit, object storage tramite CloudTrail, i
warehouse, più un backstop eBPF a livello kernel), fino agli store opaque (Redis,
SQLite, D1) dove la modalità viene marcata unknown anziché ipotizzata.
L’attribuzione è firm dove un segnale di identità per singolo agente risolve
l’accesso a un unico agente, e approximate dove un account di servizio condiviso
nasconde quale agente abbia agito. Un arco clean/firm e uno appena intravisto non
vengono mai rappresentati come ugualmente certi — leggi il
modello di fedeltà.
Governance deny-closed, doppio controllo e un kill-switch
La governance è read-first e deny-closed. Il nucleo di autorizzazione è deny-by-default e circoscritto al tenant, chiudendo per costruzione le classi di vulnerabilità confused-deputy e IDOR. Qualsiasi policy attribute-based che collegi al di sopra può solo restringere ulteriormente — la composizione è un’intersezione, quindi una policy non può mai ampliare un grant.
Dove il prodotto pone un gate su un’azione, il ciclo è: una superficie presenta (un
drift, una rilevazione) → un operatore autorizzato decide → la decisione viene
registrata. Il motore di approvazione applica la separazione dei compiti (un
richiedente non può decidere sulla propria richiesta) e una protezione contro il
decisore duplicato, ancorate a un’identità umana stabile — un token di sistema non ha
identità e non può decidere. Un’azione critical porta con sé un floor obbligatorio a
due persone derivato da NIST SP 800-53 AC-3(2), applicato sia in fase di creazione sia
ri-derivato in fase di decisione, così che persino una policy operatore che abbassi il
livello non possa rendere un’azione critica decidibile da una sola persona. Esiste una
valvola di break-glass sottoposta ad audit per l’incidente delle 03:00 — rumorosa
per costruzione, con step-up hardware, limitata nel tempo e forzata alla revisione a
posteriori.
Il kill-switch è il gate di negazione esteso a tutto il parco. Attivarlo è deliberatamente poco costoso (livello admin, una motivazione, nessun quorum) perché un arresto che attende il consenso non è un arresto; ogni gate di attuazione governato consulta la riga di stop in tempo reale e fallisce in chiusura in caso di errore di lettura. La riattivazione non è mai unilaterale — è sottoposta a una nuova approvazione a doppio controllo e non ha alcun percorso di break-glass, perché “il parco resta fermo” è lo stato sicuro.
Evidenze a prova di manomissione
Ogni azione che modifica lo stato viene aggiunta a un registro di audit append-only e concatenato tramite hash nella stessa transazione della modifica, con l’attore reale; le letture sensibili si auto-sottopongono ad audit in una scrittura committata. Riscrivere la storia è rilevabile, e il registro non contiene mai PII. Il modulo di conformità mappa quelle evidenze runtime sui framework di controllo, così che una valutazione si alimenti dalla realtà osservata anziché da un questionario.
Cos’è — e cosa non è
- In self-hosting e sovrano. Il piano di controllo gira sulla tua infrastruttura e può essere air-gapped. Olivares AI è una piattaforma aperta e self-hostable (AGPL-3.0). Vedi il modello di sicurezza e l’architettura.
- Investigativo per impostazione predefinita; deny-closed dove agisce. Osserva e governa in modo ampio; non attua in modo ampio. Dove può intraprendere un’azione, quella superficie è live, su richiesta o un punto di estensione dichiarato — e il catalogo dei moduli indica quale. Un’assenza di enforcement è di solito intenzionale.
- Pre-1.0, con un catalogo pubblicato di 23 moduli (circa 20 collegati oggi). Non tutto è live; diciamo cos’è cosa anziché lasciar intendere una copertura completa.
- L’air-gap si applica al piano di controllo di Olivares, non ai tuoi modelli. Un modello in hosting come Claude non è mai air-gapped; solo i modelli self-hosted (vLLM, Ollama) funzionano offline. In entrambi i casi Olivares governa l’accesso.
- Non certificato. Olivares AI è progettato in direzione di SOC 2, ISO/IEC 42001 e l’EU AI Act; non detiene alcuna certificazione e non ne rivendichiamo nessuna.
I parchi infrastrutturali dell’istruzione superiore e della ricerca hanno una versione parallela di questo problema — un uso esteso dell’AI tra docenti e personale, mentre la governance formale dell’AI e la copertura delle policy di uso accettabile restano indietro (ricerca EDUCAUSE, 2025). Se questo è il tuo contesto, vedi istruzione superiore; i team di piattaforma che gestiscono l’infrastruttura dovrebbero partire da platform engineering.
Dove andare adesso
- Mappa degli accessi — il grafo tipizzato R/RW e la sovrapposizione permesso vs osservato su una cattura reale.
- Kill-switch — il gate di negazione esteso a tutto il parco, in termini di prodotto.
- Conformità — evidenze a prova di manomissione mappate sui framework di controllo.
- Concetti di governance — read-first, deny-closed, doppio controllo.
- Compare — come Olivares si colloca accanto a gateway, observability e control tower.
- Inizia subito — vedi la mappa su un parco demo.