Sicurezza degli agenti
Gli agenti leggono testi scritti da sconosciuti e poi agiscono con le tue credenziali. Questa pagina illustra la regola fondamentale, entrambe le liste OWASP del 2026, gli incidenti finora registrati e le difese che li avrebbero evitati.
La trifecta letale
- Accesso ai dati privatiEmail, repository, database, file o qualsiasi altra risorsa protetta dalle tue credenziali.
- Esposizione a contenuti non attendibiliPagine web, issue, ticket di assistenza, email in arrivo e descrizioni degli strumenti: qualsiasi testo che un aggressore può scrivere.
- Possibilità di comunicare con l'esternoInviare email, aprire pull request, recuperare URL o visualizzare immagini remote. Simon Willison ha definito questa combinazione di tre elementi nel giugno 2025.
Se un agente riunisce tutti e tre gli elementi, presumi che un prompt injection possa indurlo a consegnare i tuoi dati a un aggressore. Non fare affidamento sul fatto che il modello si rifiuti: elimina almeno un elemento da ogni agente e sessione.
Checklist di sicurezza
22 verifiche relative a input, strumenti, runtime, MCP, CI e operazioni. Spuntale man mano e scarica il risultato come file Markdown.
Registro degli incidenti
Per ogni incidente pubblico di sicurezza degli agenti dal aprile 2025: cosa è successo, perché l'attacco è riuscito e cosa modificare nella tua configurazione.
Incidenti recenti
- MCP Python SDK: hijacking delle sessioni e accesso ai task di altre sessioni
- L'approvazione automatica di WebFetch in Claude Code esponeva dati tramite huggingface.co
- Comment and Control: il testo delle PR sottrae segreti agli agenti CI
- MCP TypeScript SDK ha esposto le risposte tra client
- ClawHavoc: centinaia di skill ClawHub malevole diffondono AMOS
OWASP Top 10 per applicazioni agentiche 2026
L'OWASP GenAI Security Project ha pubblicato questa lista il 9 dicembre 2025. Include i rischi che emergono quando un modello pianifica, conserva la memoria, usa strumenti e collabora con altri agenti.
ASI01Dirottamento degli obiettivi dell’agentUn attaccante modifica l’obiettivo che l’agent cerca di raggiungere, di solito tramite istruzioni nascoste nei contenuti che legge. L’agent persegue quindi l’obiettivo dell’attaccante usando i tool e i permessi dell’utente.
ASI02Uso improprio e sfruttamento dei toolL’agent usa tool legittimi in modo dannoso, per esempio eliminando record, inviando messaggi o concatenando chiamate, perché è stato manipolato o dispone di tool con permessi più ampi di quelli necessari per il task.
ASI03Abuso di identità e privilegiGli agent agiscono tramite credenziali, token delegati e permessi ereditati. Gli attaccanti sfruttano queste identità, o le lacune tra di esse, per aumentare i privilegi o agire a nome di qualcun altro.
ASI04Vulnerabilità della supply chain agenticaTool, server MCP, skill, plugin, modelli e prompt caricati in fase di build o durante l’esecuzione possono essere malevoli o compromessi. Poiché gli agent ne caricano molti in modo dinamico, un singolo componente compromesso raggiunge tutte le sessioni che lo usano.
ASI05Esecuzione imprevista di codice (RCE)Gli agent che scrivono ed eseguono codice, o passano l’output del modello a shell e interpreti, possono essere indotti a eseguire sull’host comandi scelti dall’attaccante.
ASI06Avvelenamento di memoria e contestoGli attaccanti inseriscono fatti o istruzioni falsi nella memoria dell’agent, nei documenti recuperati o nel contesto salvato. L’avvelenamento persiste e condiziona le sessioni successive, molto tempo dopo che l’input originale è scomparso.
ASI07Comunicazione non sicura tra agentI messaggi tra agent vengono trasmessi senza un’autenticazione adeguata, controlli d’integrità o validazione; possono quindi essere falsificati, riprodotti o modificati per sviare l’agent che li riceve.
ASI08Guasti a cascataUn singolo errore, come un input avvelenato, un risultato errato di uno strumento o un agente compromesso, si propaga tra agenti connessi e passaggi automatizzati più rapidamente di quanto le persone riescano a intervenire.
ASI09Sfruttamento della fiducia tra persone e agentiGli agenti sembrano sicuri e disponibili, quindi le persone tendono ad approvare le loro proposte. Gli aggressori sfruttano questa fiducia per indurre una persona a confermare un'azione dannosa o a rivelare informazioni.
ASI10Agenti fuori controlloUn agente compromesso o che si è discostato dal comportamento previsto continua ad agire autonomamente, al di fuori dell'ambito e della supervisione assegnati.
OWASP Top 10 per applicazioni LLM 2026
Questa edizione è stata pubblicata il 4 agosto 2026 e sostituisce la lista del 2025. Excessive Agency è salita dal sesto al terzo posto e System Prompt Leakage è stata rinominata Hidden Context Exposure.
LLM01Prompt InjectionUn input modifica il comportamento del modello in modi non previsti dallo sviluppatore. Può provenire direttamente dall'utente o indirettamente da documenti, pagine web e risultati degli strumenti letti dal modello.
LLM02Divulgazione di informazioni sensibiliIl modello o l'applicazione rivela dati personali, credenziali, segreti aziendali o altro materiale riservato nel proprio output, attingendo ai dati di training, al contesto o ai sistemi connessi.
LLM03Autonomia eccessivaL'applicazione assegna al modello più funzioni, autorizzazioni o autonomia di quante ne richieda l'attività, così un output manipolato o errato può causare danni concreti. È passata dal sesto posto nel 2025 al terzo nel 2026.
LLM04Catena di fornituraModelli, dataset, adapter, pacchetti e plugin di terze parti possono essere manomessi o vulnerabili, trasferendo questo rischio alla tua applicazione.
LLM05Avvelenamento di dati e modelliGli aggressori manipolano i dati di pre-training, fine-tuning o embedding per inserire backdoor, distorsioni o comportamenti errati che emergono solo in seguito, in produzione.
LLM06Consumo senza limitiSenza limiti alle richieste, alle dimensioni degli input o alle risorse di calcolo, gli aggressori possono far lievitare i costi, esaurire le risorse o copiare un modello con un elevato volume di query.
LLM07DisinformazioneIl modello genera output falsi o fuorvianti ma credibili, sui quali utenti o sistemi a valle agiscono senza verificarli.
LLM08Esposizione del contesto nascostoIn precedenza chiamata divulgazione del system prompt. I system prompt, le istruzioni nascoste e altri elementi del contesto che l'utente non dovrebbe vedere possono essere estratti, rivelando regole, logica o segreti inseriti al loro interno.
LLM09Vulnerabilità di vettori ed embeddingDifetti nella generazione, nell'archiviazione e nel recupero degli embedding consentono agli aggressori di iniettare contenuti, sottrarre dati tra tenant o ricostruire il testo sorgente. I sistemi RAG sono i più esposti.
LLM10Gestione impropria dell'outputL'output del modello raggiunge browser, shell, database o altri componenti senza validazione né codifica, aprendo la strada a XSS, SQL injection, esecuzione di codice ed esfiltrazione di dati.
Difese
Quindici difese documentate, ciascuna collegata alla propria fonte. Combinale, perché nessuna da sola blocca tutti gli attacchi.
Interrompi la trifecta letale
La regola di Simon Willison: un agente che può leggere dati privati, vede contenuti non attendibili e può inviare dati all'esterno può essere usato contro di te tramite qualsiasi testo legga. Elimina almeno uno di questi tre elementi da ogni agente o sessione. Per esempio, l'agente che smista issue pubbliche non deve avere accesso a segreti, mentre quello che gestisce i segreti non deve avere un canale in uscita.
Limita l'agente dopo input non attendibili
La ricerca sui pattern di progettazione per la sicurezza degli agenti stabilisce una regola: una volta che un agente ha acquisito input non attendibili, questi non devono poter innescare azioni rilevanti. Tra i pattern ci sono action-selector, plan-then-execute, dual LLM e minimizzazione del contesto. Scegline uno per ogni workflow: per esempio, fissa il piano prima che l'agente legga dati non attendibili.
Traccia il flusso dei dati con CaMeL
CaMeL divide l'agente in due parti: un planner privilegiato genera codice a partire dalla richiesta dell'utente, mentre un modello isolato gestisce i dati non attendibili. I valori provenienti dalla parte isolata portano tag di capability e le policy li verificano prima dell'esecuzione di qualsiasi tool. Nel paper ha risolto il 77% dei task di AgentDojo con sicurezza dimostrabile, contro l'84% di un agente senza protezioni.
Usa credenziali con privilegi minimi
Per impostazione predefinita, concedi agli agenti accesso in sola lettura limitato al progetto e non usare mai una chiave admin o service_role, che in Supabase aggira la sicurezza a livello di riga. Limita i token di CI e dei repository al singolo job per cui servono. L'incidente di Amazon Q Developer è stato ricondotto a un token GitHub con privilegi eccessivi in CodeBuild.
Richiedi l'approvazione per le azioni rilevanti
Richiedi la conferma di una persona per le chiamate ai tool che scrivono, eliminano, inviano o spendono, e nega l'azione se nessuno risponde. Supabase raccomanda l'approvazione manuale delle chiamate ai tool MCP. In OpenClaw, imposta tools.exec.ask su always e lascia askFallback su deny. Mostra tutti gli argomenti, così chi esamina la richiesta può vedere cosa verrà eseguito.
Esegui codice e tool in una sandbox
Esegui i comandi shell e il codice generato in un container o una VM senza credenziali e con accesso limitato alla sola workspace. OpenClaw ha la sandbox disattivata per impostazione predefinita e tools.exec.security impostato su full sugli host gateway: attiva la sandbox, imposta la sicurezza di exec su deny o allowlist, imposta fs.workspaceOnly su true e lascia disattivata la modalità elevata. Verifica il risultato con openclaw sandbox explain.
Limita l'accesso alla rete in uscita
Nega per impostazione predefinita il traffico in uscita degli agenti e dei server MCP, poi consenti solo gli host necessari a ciascuno. Non approvare automaticamente le richieste a host multi-tenant su cui chiunque può pubblicare: è così che CVE-2026-54316 ha trasformato huggingface.co in un canale di esfiltrazione. Un server email dovrebbe poter raggiungere la propria API di posta e nient'altro, come ha dimostrato postmark-mcp.
Tieni i control plane fuori da Internet
Fai il bind dei gateway degli agenti, delle dashboard e dei proxy di debug a loopback e richiedi un token di almeno 24 caratteri, ad esempio generato con openssl rand -hex 32. Per l'accesso remoto, usa un tunnel SSH o Tailscale Serve; usa Tailscale Funnel solo con autenticazione tramite password. Esegui periodicamente openclaw security audit --deep.
Verifica l'audience dei token MCP
La specifica di autorizzazione MCP impone al server di rifiutare i token di accesso non emessi per quel server e vieta di inoltrare il token di un client a un'API upstream. I client inviano gli indicatori di risorsa RFC 8707, così ogni token è associato a un solo server. Un server proxy deve ottenere il consenso di ogni client, altrimenti rischia di diventare un confused deputy.
Isola le sessioni e i tenant MCP
Crea un'istanza separata del server e del transport per ogni sessione, invece di condividerne una tra più client. Associa ogni sessione e task al principal autenticato che li ha creati e verifica tale associazione a ogni richiesta. Entrambi gli avvisi MCP SDK del 2026 erano dovuti a uno stato condiviso o non associato.
Verifica skill, plugin e server MCP
Fissa le versioni esatte, esamina il diff prima di ogni aggiornamento e controlla i risultati di scanner come VirusTotal e lo stato dell'audit di sicurezza di ClawHub. Quando approvi un server, calcola l'hash delle descrizioni dei tool e genera un avviso se cambiano: così puoi rilevare i rug pull. OpenClaw non blocca l'installazione per impostazione predefinita, quindi configura personalmente security.installPolicy.
Controlla chi può scrivere all'agente
Limita i DM agli utenti associati o a una allowlist, richiedi una menzione prima che l'agente intervenga nelle chat di gruppo e imposta session.dmScope su per-channel-peer, in modo che i mittenti non condividano mai il contesto. Chiunque possa scrivere all'agente può provare a dargli istruzioni: l'elenco dei mittenti fa quindi parte della superficie d'attacco.
Tieni i segreti fuori dalle esecuzioni CI non attendibili
Non eseguire un agente con i segreti del repository nei workflow che gli esterni possono attivare tramite pull request, issue o commento. Considera ostili i titoli, le descrizioni e i commenti di questi eventi. Se un passaggio ha davvero bisogno dei segreti, eseguilo solo dopo l'approvazione di un maintainer.
Considera non attendibili gli output del modello
Codifica o sanifica gli output del modello prima di visualizzarli e non passarli mai senza controlli a una shell, una query SQL o un browser. Blocca il caricamento automatico di immagini Markdown e link verso domini esterni, e imposta una Content Security Policy rigorosa. EchoLeak ha esfiltrato dati tramite URL caricati automaticamente.
Verifica le firme dell'agente, poi autorizzalo
Per identificare un agente che chiama il tuo sito o la tua API, verifica la sua firma Web Bot Auth con le chiavi pubblicate dall'operatore in /.well-known/http-message-signatures-directory. L'agente di ChatGPT firma come Signature-Agent https://chatgpt.com. Una firma valida indica chi gestisce l'agente, non quale utente l'ha inviato né cosa può fare quell'utente: autorizza quindi ogni richiesta separatamente.
Domande sulla sicurezza degli agenti
Che cos'è il prompt injection negli agenti AI?
Il prompt injection è testo che il modello interpreta come istruzioni, anche se è stato ricevuto come dato, per esempio in una pagina web, un’email o la descrizione di un tool. In un agent, queste istruzioni possono attivare chiamate ai tool eseguite con le tue credenziali. OWASP lo classifica come LLM01:2026; Agent Goal Hijack (ASI01) riguarda la sua forma agentica.
Che cos’è la trifecta letale per gli agent?
È il termine coniato da Simon Willison per descrivere un agent che combina l’accesso a dati privati, l’esposizione a contenuti non attendibili e la possibilità di comunicare con l’esterno. Quando sono presenti tutti e tre gli elementi, un prompt injection può leggere i tuoi dati e inviarli all’esterno. La fuga di token MCP di Supabase del 2025 è un caso da manuale.
Come posso proteggere un server MCP?
Rifiuta i token di accesso non emessi per il tuo server e non inoltrare mai il token di un client a un’API upstream. Crea un’istanza del server e del trasporto per ogni sessione e associa sessioni e task all’utente autenticato. Usa TypeScript SDK 1.26.0 o versioni successive e Python SDK 1.27.2 o versioni successive: correggono una fuga di risposte tra client e il dirottamento delle sessioni.
Un system prompt migliore può impedire il prompt injection?
Non farci affidamento. Le ricerche sui pattern di progettazione per gli agent sostengono che, una volta acquisito un input non attendibile, un agent deve essere vincolato in modo che l’input non possa attivare azioni con conseguenze rilevanti. CaMeL, che applica questi vincoli tramite il tracciamento delle capability, ha risolto il 77% dei task di AgentDojo con sicurezza dimostrabile, contro l’84% di un agent senza difese.
Qual è la differenza tra OWASP LLM Top 10 e Agentic Top 10?
OWASP Top 10 for LLM Applications, la cui edizione 2026 è stata pubblicata il 4 agosto 2026, tratta i rischi di qualsiasi applicazione basata su un modello linguistico. OWASP Top 10 for Agentic Applications, pubblicata il 9 dicembre 2025, tratta i cambiamenti introdotti quando il modello pianifica, usa tool, conserva la memoria e comunica con altri agent. La maggior parte di chi sviluppa agent ha bisogno di entrambe.
È sicuro esporre un gateway OpenClaw a internet?
No. Lascia gateway.bind sul valore predefinito loopback e, se ti serve l’accesso remoto, usa un tunnel SSH o Tailscale Serve. OpenA2A ha contato 192,492 gateway esposti il 1 settembre 2026; CVE-2026-25253 ha dimostrato che anche le installazioni accessibili solo tramite loopback devono essere aggiornate tempestivamente.