Perché l’infrastruttura gestita dall’AI ha bisogno di prove, non solo di permessi

Fino a pochi anni fa bastava un SSH e un comando per modificare un server. Oggi affidiamo a un agente AI operazioni complesse: migrazioni, scalabilità automatica, patch di sicurezza. Prima di lasciarlo agire in produzione serve qualcosa di più di un semplice “puoi farlo”.

I vecchi modelli di sicurezza non bastano più.

RBAC e GitOps non rispondono alla domanda giusta

I controlli classici si limitano a dire chi può scrivere e quale stato finale desideriamo. Nessuno però chiede: “Questa modifica è sicura in questo momento?”.

Un operatore umano porta con sé contesto ed esperienza. Un agente AI no. Quando propone un cambio su un database o un’infrastruttura, il sistema vede solo i permessi, non il ragionamento. Con le operazioni stateful – una migrazione di schema, un cutover dei dati – il rischio cresce perché ogni passo è irreversibile e dipende da vincoli di tempo e rollback.

Il cambio di paradigma: prove crittografiche

L’idea è semplice: ogni modifica proposta deve viaggiare insieme a una prova crittograficamente valida che ne attesti la sicurezza. Il flusso è lineare:

1. L’agente descrive l’operazione e il motivo.
2. Il sistema genera la prova (dry-run, drift detection, scansioni di sicurezza, digests delle immagini, impatto sugli SLO).
3. Un motore di policy valuta se la modifica rispetta le regole aziendali.
4. La firma viene verificata; se manca o è stata manomessa, il processo si ferma.
5. Solo allora il cambio viene eseguito.
6. Tutto resta registrato in un ledger immodificabile.

Un esempio concreto: migrazione da Oracle a PostgreSQL

Trasferire un’applicazione Oracle/APEX su PostgreSQL in Kubernetes non è un semplice kubectl apply. Serve una sequenza precisa: verifica del cluster, freeze del sorgente, export dei dati, restore point, shadow table, validazione riga per riga, switch del traffico e audit finale.

In un caso reale, la prova ha incluso 23 controlli, 20 eventi di esecuzione e 20 artefatti firmati. Il punteggio finale era 100 %. La chiave ed25519 ha garantito che nulla fosse stato alterato.

Policy + prova: difesa a due livelli

Anche con la prova valida, serve ancora un’autorizzazione esplicita. Durante i test lo stesso agente è stato bloccato due volte: una per mancanza di autorizzazione nella policy, l’altra perché la firma era stata manomessa. Serve entrambi i livelli: la prova dice “è sicuro”, la policy dice “è permesso”.

Cosa cambia per chi gestisce Kubernetes

Argo CD e Crossplane restano utili, ma non sono stati pensati per agenti autonomi. Non spiegano perché una modifica sia sicura in un dato istante. Se punti a deployment gestiti dall’AI, scaling autonomo o workload soggetti a compliance, devi integrare la generazione di prove, policy as code e audit firmati.

Da dove partire

• Verifica che il tuo sistema di deploy possa produrre prove crittografiche.
• Definisci allow-list esplicite per le operazioni consentite agli agenti.
• Registra ogni mutazione con firma e motivazione.
• Misura il “punteggio di sicurezza” prima di ogni esecuzione.

L’infrastruttura si sta muovendo verso l’autonomia. Anche il controllo dei cambiamenti deve evolversi: non basta chiedere il permesso, serve dimostrare che l’operazione è sicura. Solo così potrai dormire sonni tranquilli mentre un agente AI esegue migrazioni di produzione alle tre di notte.