Il recinto che autorizza

Policy engine, version control per agenti, sandbox deterministici, proxy di orchestrazione con controlli granulari: un intero ecosistema del contenimento sta nascendo, con una premessa: più recinti costruiamo, più siamo al sicuro.

Il problema è che i recinti non funzionano, anzi, funzionano esattamente, ma per uno scopo diverso dal contenimento.

Ogni volta che aggiungiamo un layer di sicurezza a un agente, il layer autorizza. La sandbox non dice solo «non puoi uscire da qui»: dice anche, implicitamente, «dentro qui puoi fare tutto». Il policy engine non blocca solo le azioni pericolose: certifica che quelle consentite sono state valutate e approvate. Il version control per agenti non traccia solo i cambiamenti: crea la possibilità che ogni azione sia reversibile, e quindi tollerabile.

Non stiamo costruendo muri. Stiamo costruendo certificati di agibilità.

Il meccanismo è psicologico più che tecnico. La presenza di un guardrail non riduce il rischio oggettivo: sposta la percezione del rischio. E quando la percezione si sposta, le decisioni operative la seguono.

Un agente che ieri non avresti mai connesso a un database di produzione oggi ci accedi, perché «abbiamo il policy engine». Un drone che non avresti mai lasciato operare senza supervisione umana costante oggi lo mandi in missione, perché «il sandbox deterministico garantisce i limiti operativi». Un coding agent che modifica repository in autonomia era impensabile sei mesi fa: oggi è una best practice, perché «c'è il version control, possiamo sempre rollbackare».

In tutti questi casi, la sicurezza non ha ridotto l'esposizione al rischio. L'ha aumentata, fornendo la giustificazione per farlo. L'infrastruttura di sicurezza non è un freno all'adozione degli agenti: è il lasciapassare dell'adozione. Più strati di protezione aggiungiamo, più contesti ad alto rischio diventano disponibili.

Non è un recinto che si stringe. È un recinto che si allarga, e ogni paletto nuovo sposta il confine un po' più in là.

Non è una critica ai guardrail in sé. I sandbox servono, le policy qualche volta funzionano, i sistemi di monitoring sono indispensabili. Il punto è che stiamo usando l'infrastruttura di sicurezza come surrogato del giudizio.

Rimuoviamo la distanza operativa, quel margine di valutazione umana che separava l'automazione dal mondo reale, e la sostituiamo con una verifica automatica. Ci convinciamo che il guardrail ha controllato, quindi possiamo procedere. Ma il guardrail ha controllato solo ciò per cui è stato programmato. Non ciò che potrebbe accadere.

C'è una distinzione tra contenere un rischio e delegare la responsabilità di contenerlo. La prima è ingegneria. La seconda è una scelta con conseguenze.

Quando un agente ha accesso a un file system, a un database di produzione, a un attuatore fisico, ci chiediamo «quanti layer di sicurezza abbiamo messo?».ma dovremmo chiederci «perché gli abbiamo dato accesso?».

I layer di sicurezza rispondono alla prima domanda, mai alla seconda. Anzi, peggio ancora, più layer aggiungiamo, più ci sentiamo esentati dal porci la seconda.

Il contenimento vero non è una questione di guardrail. È una questione architetturale. Non si risolve aggiungendo controlli: si decide dove l'agente può operare, con quali privilegi, a quale distanza dal mondo reale. La distanza operativa, quel margine di valutazione umana che stiamo erodendo, non è un accessorio da eliminare in nome dell'efficienza. È l'ultimo contenimento che conta. Ed è l'unico che non si può delegare.

La metrica della sicurezza agentica oggi è: quanti layer hai.
Dovrebbe essere: quanto spazio lasci tra l'agente e il mondo.