Un agente che agisce da solo: la guida di sei agenzie su come non consegnargli le chiavi

La differenza che cambia tutto

Un assistente che risponde a una domanda produce testo. Se sbaglia, avete un testo sbagliato. Un agente fa qualcosa: apre un ticket, invia un messaggio, modifica un record, approva una richiesta, chiama un altro sistema. Se sbaglia, avete un'azione compiuta.

È su questa distinzione che si regge la guida congiunta pubblicata il 1° maggio 2026 da sei agenzie: l'australiana ACSC, le statunitensi CISA e NSA, il centro canadese per la cybersicurezza, e i centri neozelandese e britannico. Nel documento si definiscono «authoring agencies», e la raccomandazione che mettono al centro è insolitamente diretta per un testo di questo tipo: non concedere mai all'agente «broad or unrestricted access, especially to sensitive data or critical systems», e usarlo «only for low-risk and non-sensitive tasks».

Va letta per quello che è: non un invito a non usarli, ma un invito a non iniziare dal caso d'uso più delicato.

I cinque modi in cui un agente diventa un problema

Il documento organizza i rischi in cinque categorie, e la ripartizione è più utile di quanto sembri perché separa problemi che di solito vengono confusi:

• rischi di privilegio — l'agente può fare più di quanto dovrebbe;
• rischi di progettazione e configurazione — è stato costruito o impostato male;
• rischi di comportamento — fa qualcosa di imprevisto pur restando nei limiti che gli avete dato;
• rischi strutturali — nascono dall'interazione fra più agenti e più sistemi, non da un singolo componente;
• rischi di responsabilità — quando qualcosa va storto, non è chiaro chi risponda.

Le prime due si affrontano con la tecnica. La terza si affronta con il monitoraggio. Le ultime due, che sono anche le più trascurate, si affrontano solo con delle decisioni prese prima.

1. 01
   Il vice confuso

   l'agente ha accesso a finanze, posta e contratti per «fare il suo lavoro»
2. 02
   L'abuso

   qualcuno lo induce a compiere un'azione: l'agente ha i permessi, quindi la esegue
3. 03
   Il danno

   i registri risultano legittimi, perché l'azione è stata compiuta da chi poteva compierla

Lo scenario del confused deputy riportato nella guida è esattamente questo: un agente per gli approvvigionamenti, con accesso ampio a sistemi finanziari, posta elettronica e archivi contrattuali, produce «audit logs that appear legitimate and delay detection». Non è che manchino i log. È che i log dicono la verità, e la verità è che l'operazione era autorizzata.

L'idea centrale: dare all'agente un'identità propria

Il consiglio più concreto del documento, e quello con più conseguenze pratiche, riguarda l'identità. Gli sviluppatori dovrebbero costruire ogni agente «as a distinct principal, a cryptographically anchored identity with its own unique keys or certificates». E, sul versante dei controlli: «Deny access for any agent or cryptographic key that is not present in the trusted registry».

Questo significa smettere di far girare gli agenti con le credenziali di un servizio generico o, peggio, con quelle di una persona. Un agente con un'identità propria è osservabile: si può revocare senza toccare altro, si può vedere cosa ha fatto separandolo da chi lo ha avviato, si può limitare a un insieme di operazioni. Un agente che parla con le credenziali di un utente eredita tutto ciò che quell'utente può fare, e sparisce nei suoi log.

C'è poi il tema della propagazione. La guida osserva che alcuni sistemi sono in grado di creare autonomamente sotto-agenti — «spawning» — per svolgere compiti secondari. È il punto in cui i rischi strutturali diventano reali: se l'agente A può creare l'agente B, e B eredita i permessi di A, il perimetro dei permessi ha smesso di essere una decisione vostra.

Le tre regole operative che vale la pena copiare

Il consenso proporzionato al rischio. «Implement consensus controls for actions based on risk; use multi-agent approval for moderate-stakes actions and human-in-the-loop approval in addition to multi-agent consensus for high-stakes actions». Tradotto: per le azioni con conseguenze medie serve che più di un agente sia d'accordo; per quelle gravi serve che ci sia anche una persona. Non «un umano approva tutto» — che non regge il carico — ma una soglia.

I log non appartengono all'agente. Due indicazioni testuali: «Quarantine requests to delete logs or audit records until reviewed and approved by a human» e «Isolate agents into enclaves with no write access to logs». È il principio più antico della sicurezza applicato a un soggetto nuovo: chi compie l'azione non tiene il registro dell'azione.

Il permesso non si auto-concede. «Prohibit agents from modifying their own privileges or initiating unapproved delegation without explicit expiry timers and recorded grant chains». Un agente non deve poter allargare il proprio perimetro né delegare a un altro senza che quella delega abbia una scadenza e una traccia.

A queste si aggiungono due indicazioni sul modo di partire: distribuzione a fasi, «with progressively increasing access and autonomy», e comportamento predefinito conservativo — «Set system configurations to fail-safe by default requiring agents to stop and escalate issues to human reviewers in uncertain scenarios». Nel dubbio, l'agente si ferma. Non prova.

Cosa ammettono le agenzie stesse

La parte più onesta del documento sono i limiti che dichiara, e conviene riportarli senza addolcirli.

Sugli strumenti: «Gaps in agentic AI cyber security tooling and the immaturity of relevant standards further amplify these risks. Governance mechanisms designed for human actors do not always translate effectively to autonomous AI agents». Sulle verifiche: «Many existing evaluation methods for agentic AI security are still evolving. They may be sensitive to minor semantic changes, vary by scenario and only partially capture real-world deployment conditions». E la conclusione che ne discende: «organisations should assume that agentic AI systems may behave unexpectedly».

Un limite di campo va aggiunto: la guida «primarily focuses on large language model (LLM)-based agentic AI systems». Non copre quindi le automazioni deterministiche, che pongono problemi diversi.

Il blog del centro britannico riassume tutto in una riga che funziona come criterio di ammissione: «If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment».

Da dove cominciare, se state cominciando

L'appendice della guida elenca i prerequisiti da avere prima di introdurre agenti — e sono, quasi interamente, cose non legate all'AI: gestione delle identità, segmentazione, registrazione degli eventi, gestione delle vulnerabilità. È il messaggio meno appariscente e forse il più utile: un agente autonomo non aggiunge sicurezza a un ambiente disordinato, ne amplifica il disordine, perché agisce più in fretta di quanto voi riusciate a guardare.

Tre domande per un primo giro di tavolo, prima di qualunque scelta tecnica: cosa può fare questo agente che io non possa annullare? Con quale identità lo fa? Chi risponde se lo fa nel momento sbagliato? Se le prime due non hanno risposta, la terza siete voi.