Agentic loop (3): sicurezza e governance

Il loop, per funzionare, legge contenuto non fidato dentro il contesto e ha strumenti per agire: è la sua superficie d'attacco. Parte 3 di 3: prompt injection e lethal trifecta, perché la sicurezza vive nell'harness e non nel prompt, l'osservabilità e la governance nel ciclo (least privilege, human-in-the-loop, policy runtime, audit).

AICybersecurityGovernanceAIAgenticCybersecurityPrompt InjectionAI GovernanceLLMComplianceOn-Premise
Diagramma della sicurezza dell'agentic loop: a sinistra le tre condizioni della lethal trifecta (dati privati, contenuto non fidato, capacità di esfiltrare), al centro la difesa che sta nell'harness e non nel prompt, a destra i sei controlli applicati a runtime e in basso l'audit trail immutabile
Le tre condizioni della lethal trifecta e i controlli che le mitigano, applicati nell’harness a runtime su ogni tool call. Schema basato sull’analisi di Simon Willison.

Serie in 3 parti. (1) anatomia del ciclo · (2) contesto, pattern e multi-agente · (3) sicurezza e governance. Questa è la parte finale.

Nelle prime due parti abbiamo costruito un agente capace: il ciclo base e i pattern per farlo durare. Quello stesso agente, che legge il mondo e agisce, è una superficie d’attacco e le difese efficaci vivono nell’harness.

Dove vive la sicurezza

Il loop, per funzionare, legge contenuto non fidato dentro il contesto: pagine web, file, output di strumenti, risposte di API. Ed è qui la superficie d’attacco: quel contenuto può veicolare istruzioni che il modello, non potendole distinguere dal resto, tende a seguire. È la prompt injection e nella sua forma agentica è particolarmente insidiosa perché il modello ha strumenti con cui agire (il “confused deputy”: il componente fidato che usa i propri privilegi per conto dell’attaccante).

Il rischio massimo è la combinazione che Simon Willison ha battezzato “lethal trifecta”: accesso a dati privati, esposizione a contenuto non fidato e capacità di esfiltrare verso l’esterno. Se un agente ha tutti e tre, un’istruzione nascosta in una pagina può fargli leggere dati sensibili e mandarli fuori. Le mitigazioni non stanno nel prompt (“ignora istruzioni malevole” non è un controllo di sicurezza): stanno nell’harness.

  • Least privilege sugli strumenti: l’agente può fare solo ciò che serve, con permessi minimi.
  • Human-in-the-loop sulle azioni ad alto impatto: approvazione esplicita prima di un’operazione irreversibile.
  • Sandboxing e isolamento dell’ambiente di esecuzione.
  • Policy applicate a runtime sulle tool call (allow/block/redact), non affidate alla buona volontà del modello.
  • PII redaction prima che i dati raggiungano il modello o escano verso l’esterno.
  • Kill switch e budget come ultima linea.

È esattamente il ruolo di un framework come Admina: interporsi tra il modello e il mondo, con audit trail immutabile, oscuramento dei dati e policy bidirezionali su ogni chiamata e ogni strumento.

Osservabilità e tracce

Un sistema non deterministico che compie azioni va tracciato. Ogni passo del loop (contesto in ingresso, decisione, tool call, argomenti, risultato) va registrato in modo da consentirne il replay, con un audit trail immutabile. Serve per il debug (riprodurre un comportamento che dipende dal campionamento è impossibile senza log) e per la conformità (dimostrare cosa ha fatto l’agente e perché). È anche il presupposto tecnico per stare dentro requisiti come NIS2 e l’EU AI Act quando l’agente opera su processi regolati.

Cosa ne pensiamo

Il loop è un obiettivo, quattro passi e una condizione di stop. Renderlo affidabile, sicuro e governabile è dove sta il lavoro. E quel lavoro non è nel prompt né nella scelta del modello: è nell’harness. È qui che si applicano context engineering, terminazione, retry, least privilege, policy, oscuramento e audit.

È la ragione per cui progettiamo i sistemi agentici mettendo la governance nel ciclo, non accanto: il framework Admina come punto di controllo tra modello e strumenti, i quattro pilastri di OISG come criterio (Open, Intelligent, Secure, Governed) e l’esecuzione on-premise quando l’agente tocca dati o azioni che non ci si può permettere di affidare a un interruttore altrui: lo stesso principio del possedere il pavimento operativo di cui abbiamo scritto per l’inferenza locale. Un agente con strumenti e senza policy applicate a runtime può eseguire azioni irreversibili senza che nessuno se ne accorga.

Riferimenti


Torna alla parte 1: anatomia del ciclo o alla parte 2: contesto, pattern e multi-agente.

Vuoi supporto?Sei sotto attacco?Stato dei servizi
Vuoi supporto?Sei sotto attacco?Stato dei servizi