Autore di immagini · divulgatore e formatore AI
Il tuo assistente è sicuro quanto la chiave che porta in tasca 16 min di lettura
Intelligenza Artificiale ·

Il tuo assistente è sicuro quanto la chiave che porta in tasca

Una ricerca su AWS ha mostrato cosa succede quando un assistente esposto al pubblico ha una chiave che apre troppo. Ecco cosa c’entra con Make, Claude e le automazioni che usi tu, e le tre cose da controllare lunedì.

📌 Questo pezzo parte da una ricerca di un’azienda di sicurezza, quindi una fonte interessata: lo dico subito e lo ripeto dove serve. Non ti serve usare AWS per leggerlo. Ti serve una sola domanda, che alla fine ti lascio in mano: “se il mio assistente più esposto venisse ingannato, quali chiavi ha in tasca e quali porte aprono?”

Immagina il chatbot che risponde ai clienti sul tuo sito. Quello che dice gli orari, che spiega come prenotare una sessione, che raccoglie le richieste di preventivo. Parla con chiunque, a qualsiasi ora, e non sceglie con chi.

Ora fatti una domanda che di solito non ci facciamo, perché il chatbot “funziona e basta”: con quale chiave entra in casa? E quali porte apre?

Se la risposta è “non lo so”, sei in buona compagnia. È esattamente la domanda che una ricerca uscita l’8 ottobre 2026 mette sul tavolo, usando un caso su Amazon Web Services (AWS, i servizi cloud di Amazon). Il caso è tecnico, ma la lezione è da portineria: una chiave troppo larga in mano a chi è più esposto.

Ti racconto cosa è successo, a che misura, e poi cosa puoi controllare nei tuoi strumenti. Prima il fatto, senza ingrandirlo.

Il fatto, alla misura giusta

La ricerca si chiama AgentCorruption. Il lavoro è di Zenity Labs, il laboratorio di ricerca di Zenity, ed è stato pubblicato l’8 ottobre 2026 in due post. Viene presentata anche al SecTor 2026 a Toronto (Zenity Labs, 08/10/2026; The Next Web, 08/10/2026).

Il meccanismo, in parole semplici. Un “agente” è un assistente AI che non si limita a rispondere: usa strumenti, apre pagine, chiama servizi. Qui l’agente era esposto al pubblico e aveva uno strumento per fare richieste web. I ricercatori gli hanno fatto arrivare un testo costruito apposta (una prompt injection: istruzioni nascoste dentro un messaggio, che l’assistente scambia per ordini legittimi).

Quel testo lo ha spinto a bussare a un servizio interno, una specie di portineria della macchina in cui gira. La portineria, che per progetto consegna all’agente la chiave del suo ruolo, gliel’ha data (Zenity Labs). Anche la documentazione AWS conferma che questo è il funzionamento previsto: qualsiasi codice che gira dentro quell’ambiente può chiedere le credenziali del ruolo di esecuzione (documentazione AWS).

Fin qui il bot è la porta, non la falla. La falla è cosa apriva quella chiave.

Prima di andare avanti, i confini, perché i titoli in giro sono più grossi della realtà:

  • Un account AWS e una regione (us-west-2). The Next Web ha anche corretto il proprio titolo, che inizialmente parlava di una regione intera. Un aggiornamento di Zenity, riportato da The Decoder, dice che l’attacco “non ha attraversato il confine dell’account” (The Next Web; The Decoder, agg. 09/10/2026).
  • Una dimostrazione dei ricercatori su un account AWS. Nessuna fonte che ho letto riporta attacchi a clienti reali.
  • Nessun CVE (il numero di catalogo che si assegna alle vulnerabilità ufficiali) (The Next Web).
  • Zenity vende sicurezza per agenti AI. Ha tutto l’interesse a farti sentire che il problema è grosso. Non significa che abbia torto, significa che leggiamo con la matita in mano.

Quindi no, non è successo che “un solo prompt ha bucato l’intera flotta AWS”. Se l’hai letto da qualche parte, è più grosso del vero. Il vero basta e avanza.

Fin dove arrivava quella chiave (e fin dove no)

Pianta dall'alto di un piano di appartamenti disegnata in line art, con una grande chiave che attraversa più stanze e un contorno tratteggiato che delimita solo alcune di esse.

Qui il confine tra dimostrato e ipotizzato conta, quindi vado piano.

Dimostrato, in lettura. Con la chiave del ruolo, i ricercatori hanno potuto elencare gli agenti dell’account, scaricare le immagini dei loro contenitori ed estrarre il codice. Hanno invocato un agente privato di fatturazione (billing_agent) fino a farsi consegnare un file, billing.json, e hanno letto conversazioni complete, compresa una di assistenza clienti (Zenity Labs, “One Role to Rule Them All”). Il ruolo poteva anche leggere i segreti custoditi in Secrets Manager (la cassaforte delle password di AWS): secondo Zenity, e AWS ha poi tolto quel permesso (Zenity Labs).

Dimostrato, in scrittura. Hanno inserito un evento falso nella memoria di un agente, con l’istruzione di visitare una pagina dei ricercatori. Il risultato: la conversazione partiva verso il server dei ricercatori mentre l’utente continuava tranquillamente a chattare (demo video, Zenity Labs).

Pensa a cosa significa dal lato di chi è dall’altra parte dello schermo: scrive, riceve risposte normali, e nel frattempo qualcuno ascolta.

Non dimostrato: cancellare. Il permesso di cancellare gli eventi della memoria c’era nel ruolo. Ma nessuno ha mostrato di averlo usato; il report principale non cita cancellazioni (Zenity Labs). Alcuni titoli parlano di agenti letti, riscritti e cancellati: l’ultimo verbo è più forte di quello che le prove sostengono. Lo scrivo qui apposta, perché è il genere di dettaglio che si perde quando la notizia rimbalza.

Una cosa va detta con precisione, e la dico con le parole giuste. È dimostrato che la chiave dell’agente esposto apriva anche gli altri agenti dello stesso account e della stessa regione. Non è documentato che quegli altri agenti usassero tutti lo stesso ruolo o la stessa chiave. Non è una “chiave condivisa”: è una chiave che apriva molto più di quello che serviva al suo agente.

Pensa al condominio. Non è la storia di una chiave uguale per tutti. È la storia di una chiave del citofono, quello su cui suona chiunque, che per com’è stata fatta apre anche gli appartamenti.

La gravità, in questo schema, non sta nell’abilità dell’attaccante. Un testo ben costruito è bastato per far chiedere la chiave. Il danno lo ha deciso la larghezza del permesso.

Chi ha deciso quella chiave: default, comodità, cliente

Chi ha fatto la chiave così larga? Qui ci sono due versioni, e conviene tenerle entrambe.

La versione di Zenity. Il ruolo attaccato è quello che chiama “default execution role”, agganciato all’agente per impostazione predefinita. Dentro c’erano permessi con asterisco (wildcard): “tutte le risorse AgentCore di questo account e di questa regione” (Zenity Labs).

La versione di AWS. Un portavoce ha detto che la ricerca “inaccurately paints expected and documented behavior as a vulnerability” (“dipinge in modo impreciso come vulnerabilità un comportamento atteso e documentato”), e che come buona pratica consiglia ai clienti di dare ai ruoli di esecuzione solo i permessi di cui gli agenti hanno bisogno (The Next Web).

E la documentazione AWS, in effetti, è chiara su più punti:

  • le policy create dalla loro riga di comando “are designed for development and testing purposes… grant broad access… and are not suitable for production” (sono pensate per sviluppo e prove, danno accesso ampio e non sono adatte alla produzione);
  • raccomanda di evitare i wildcard, e di dare al ruolo privilegi uguali o inferiori a quelli di chi può invocarlo;
  • nel modello di responsabilità condivisa, i controlli di accesso e la prevenzione della prompt injection sono a carico del cliente
    (AWS, best practices; AWS, IAM permissions).

Un limite onesto: nessuna fonte che ho letto collega il ruolo attaccato nella dimostrazione a quello creato dalla console o dalla riga di comando di AWS. Posso dirti due cose separate, senza incollarle: il ruolo predefinito era largo, e AWS stessa scrive che le policy generate per lo sviluppo sono ampie e non adatte alla produzione. Quanto una cosa dipenda dall’altra, non lo so.

Poi c’è quello che AWS ha fatto, a prescindere da chi avesse ragione. Zenity ha osservato il 29 settembre 2026 che il ruolo predefinito risultava ristretto: tolte l’invocazione tra agenti, la lettura delle conversazioni e Secrets Manager. È la data in cui l’hanno osservato, non necessariamente quella in cui è stato cambiato. Dal 14 febbraio 2026 i nuovi agenti partono con una protezione più rigida sul servizio che consegna le credenziali, e dal 30 giugno 2026 quella protezione è obbligatoria per tutti gli agenti (Zenity Labs; AWS, best practices).

Quanto ai tempi: Zenity dice di aver segnalato l’accesso ai metadati il 25 dicembre 2025 e il ruolo troppo largo il 12 gennaio 2026. Il 22 giugno 2026 il ruolo era ancora uguale (Zenity Labs). Non scrivo “tutto risolto”, perché le fonti stesse non sono d’accordo su quanto lo sia. Un bollettino di sicurezza pubblico di AWS sul tema, per la cronaca, non l’ho trovato: la posizione dell’azienda arriva solo da dichiarazioni a stampa.

Mettiamo insieme le due versioni. Hanno ragione tutte e due, a modo loro. AWS: il comportamento è documentato e il cliente deve restringere. Zenity: se il valore predefinito è largo, molti non restringeranno. Per te che costruisci un assistente, la conclusione è la stessa e non dipende da chi vince la disputa: il valore predefinito serve a partire in fretta. La sicurezza la compri restringendo.

Non è un unicorno: stessa famiglia, altri strumenti

Per non farti credere che sia una storia solo di Amazon, ti mostro tre casi paralleli. Chiarisco subito: sono parenti, non gemelli. Quello di AWS è una chiave troppo larga. Questi sono casi di quello che gli esperti chiamano eccesso di agenzia: un assistente esposto che può fare più di quello che dovrebbe. E sono tutte ricerche di aziende di sicurezza, in ambienti di laboratorio.

Tenable e Copilot Studio. Un agente di prenotazioni di viaggio costruito per la prova, con dati finti. I ricercatori sono riusciti a farsi dare record con numeri di carte di credito (finte) e, siccome l’agente aveva anche il permesso di modificare, lo hanno usato su ordine di un estraneo: il prezzo di un viaggio è passato da 1.000 a 0 dollari (Tenable, 11/12/2025). Nessuna risposta di Microsoft riportata.

ShareLeak (Capsule Security). Un testo nascosto nel campo di un modulo SharePoint ha fatto sì che un agente di Copilot Studio estraesse dati dei clienti (nomi, indirizzi, telefoni) e li mandasse via email all’esterno. Ha un CVE (CVE-2026-21520) ed è stato corretto da Microsoft (CSO Online, 15/04/2026).

PipeLeak. Istruzioni nascoste in un modulo “lead” pubblico di Agentforce, eseguite quando un utente interno chiede all’agente di elaborare quel contatto, con estrazione di dati del CRM. Salesforce dice di aver risolto lo scenario specifico e parla di un vettore “dipendente dalla configurazione” (CSO Online).

Il filo comune non è la stessa chiave. È un testo che arriva dall’esterno e sposta dati interni. Chi parla con il pubblico è la porta d’ingresso di tutto il resto.

Il principio, da una fonte che non vende niente

Quando la fonte della notizia è un’azienda di sicurezza, cerco sempre un principio che regga anche senza di lei. Qui ce n’è uno di OWASP, ente non commerciale che pubblica l’elenco dei rischi principali per i sistemi AI.

Nella voce sull’Excessive Agency (eccesso di agenzia) c’è scritto di limitare i permessi che si danno alle estensioni “to the minimum necessary” (al minimo necessario), di eseguire le azioni per conto dell’utente “in the context of that specific user” (nel contesto di quello specifico utente) e tra i rischi elenca proprio l’accesso ai sistemi con “a generic high-privileged identity” (un’identità generica con privilegi alti) (OWASP, LLM06:2025).

Non ti dice di separare le chiavi per ogni livello di esposizione: ti dice di tenerle strette. Il resto è un’applicazione del principio che faccio io. E a dicembre 2025 OWASP ha pubblicato una Top 10 dedicata alle applicazioni con agenti per il 2026, dove “Identity and Privilege Abuse” (abuso di identità e privilegi) compare tra le minacce principali. Qui mi fermo: il testo completo non l’ho aperto, quindi ti dico solo che esiste e quando è uscito (OWASP, 09/12/2025).

C’è anche una frase di Michael Bargury, co-fondatore e CTO di Zenity, che mi sembra onesta nei due sensi. Prima dice che la sicurezza del cloud è fatta di segmentazione e minimo privilegio. Poi aggiunge:

“AI agents, however, need their creative space to be useful. Mixing the two creates an inherent conflict.”

(Gli agenti AI, però, hanno bisogno del loro spazio creativo per essere utili. Mescolare le due cose crea un conflitto intrinseco.)

Michael Bargury, Zenity, citato da The Next Web

Ricorda: è il CTO dell’azienda che vende la soluzione. Però il conflitto che descrive lo riconosci anche tu, se lavori con questi strumenti. Un assistente che non può toccare niente è sicuro e inutile. Uno che può toccare tutto è utile finché non lo inganni.

Ne ho parlato, da un altro lato, in Claude ha Cancellato l’HD di 50 Persone. La Colpa è tua!: lo stesso accesso che rende un agente potente è quello che lo rende pericoloso. Cambiano i protagonisti, la logica no.

Il ponte: nei tuoi strumenti, chi può usare questa chiave?

Fin qui il caso era di Amazon. Tu probabilmente non usi AWS. Usi Make per collegare le cose, magari n8n, magari Claude con dei connettori a Drive, a Gmail, al calendario. Dove sta la chiave larga, lì?

Attenzione, perché qui la storia cambia di forma. Su AWS il problema era l’ampiezza del permesso. Negli strumenti di tutti i giorni compare spesso la sua versione “di casa”: la connessione che molti possono usare, e che quindi nasce larga per comodità. Non esiste una regola valida per tutti, del tipo “per default usano tutti lo stesso account”. Ho letto la documentazione di tre strumenti e fanno tre cose diverse.

Make. Dalla guida ufficiale: “All users in your team in Make can use and manage any connections you create in that team” (tutti gli utenti del tuo team possono usare e gestire qualsiasi connessione creata nel team). La stessa connessione si può riusare in altri moduli, anche in scenari diversi. Si possono però creare più connessioni per la stessa app, e per un account personale la guida suggerisce un team separato in cui sei l’unico membro (dal piano Teams in su) (Make Help Center). Tradotto: la separazione non arriva da sola, la fai tu.

n8n. Le credenziali si possono condividere con singoli utenti o con un progetto. Chi le usa non ne vede i dettagli, ma il proprietario e gli amministratori dell’istanza vedono e condividono tutto. I progetti separano workflow, variabili e credenziali. La condivisione c’è su tutti i piani Cloud, mentre nella versione che installi da te serve il piano Business o Enterprise (documentazione n8n). Qui si condivide solo se scegli di farlo.

Claude (Team ed Enterprise). L’amministratore aggiunge il connettore, ma ogni membro si autentica con il proprio account. Fa eccezione il connettore con credenziale condivisa, che “gives everyone who uses it that credential’s access” (dà a tutti quelli che lo usano l’accesso di quella credenziale). Nel contesto Research la guida consiglia di disattivare gli strumenti che possono compiere azioni di scrittura su applicazioni esterne, e di usare “Allow always” solo per strumenti di cui ti fidi. Avverte anche che server malevoli possono nascondere istruzioni (Claude Help Center). Qui il default è il contrario: ognuno con la sua chiave, salvo che qualcuno ne metta una comune.

Tre strumenti, tre comportamenti. Per questo la domanda utile non è “il mio strumento è sicuro?”. È più piccola e più concreta: nel mio strumento, chi può usare questa connessione, e cosa può farci?

Per ChatGPT e per i plugin dei siti WordPress non ti dico niente: non ho una fonte ufficiale aperta e verificata, e preferisco lasciarli fuori che improvvisare. Se li usi, la domanda vale uguale. La risposta vai a cercarla nella loro guida.

Una cosa in più, sulle istruzioni nascoste nelle pagine web, che sono la porta d’ingresso della stessa famiglia di attacchi: ne ho scritto in Claude ha il suo browser integrato, ecco cosa ci ho fatto.

Lunedì mattina: una domanda e tre mosse

Scrivania vista dall'alto con tre tesserini d'accesso, ciascuno collegato a una sola stanza disegnata, accanto a un foglio a quadretti e a una matita.

Non ti scrivo una procedura per esperti, e nemmeno ti chiedo di spegnere i tuoi assistenti. Ti propongo un controllo di mezz’ora, con carta e penna.

La domanda. Se il mio assistente più esposto, quello che parla con l’esterno, venisse ingannato da un testo costruito apposta: quali chiavi ha in tasca, e quali porte aprono?

Mossa 1: una chiave dedicata, con solo i permessi che servono a lui.
Per ogni assistente o automazione che parla con l’esterno (chatbot del sito, risposte ai clienti, moduli di contatto), usa un account o una chiave solo suoi, con i permessi minimi per fare quel lavoro. Non quello che usi tu per tutto. Lo scopo è ridurre il raggio: se il portiere viene ingannato, deve poter aprire il portone e basta. Il principio è quello della documentazione AWS (ruolo con privilegi pari o minori) e di OWASP (minimo necessario).

Io questo errore l’ho fatto sul mio sistema: una porta sola, e chi entrava entrava dappertutto. Il racconto di come l’ho spezzata in stanze, ognuna con il suo tesserino, è in Ho dato a Claude accesso completo a tutto quello che so. Il risultato che mi interessava: se qualcuno rubasse un tesserino, si troverebbe in mano l’accesso a una stanza e nient’altro.

Mossa 2: all’assistente clienti, solo lettura.
Se deve rispondere con informazioni, deve poter leggere quelle informazioni. Scrivere, modificare, cancellare, mandare email: solo se serve davvero a quel compito. Nel caso Tenable il permesso di modifica c’era e un estraneo l’ha usato. Se uno strumento ti permette di spegnere le azioni di scrittura che non ti servono, spegnile, come consiglia anche la guida di Claude.

Mossa 3: elenca quali automazioni usano la stessa connessione, e spezzala.
In Make, apri le tue connessioni e guarda quali scenari le usano. Se un’automazione pubblica (il modulo sul sito) usa la stessa connessione di una che tocca l’archivio o le fatture, creane una seconda per quella esposta. In n8n guarda come hai condiviso le credenziali e se i progetti li hai separati davvero. In Claude controlla se qualche connettore ha una credenziale condivisa, perché lì tutti ottengono lo stesso accesso.

Se usi Bedrock, la riga per te è una sola: leggi la guida AWS “Security best practices for AgentCore Runtime” e il report di Zenity. Qui non faccio una procedura tecnica.

Cosa porti a casa

Il caso AWS è stato ridimensionato dalle sue stesse fonti: un account, una regione, una dimostrazione di laboratorio fatta da chi vende sicurezza, nessun attacco a clienti reali riportato, cancellazione mai dimostrata. E AWS, dal canto suo, dice che il comportamento è documentato. Tutto vero, e il pezzo non cambia.

Perché la lezione non sta nell’enormità dell’attacco. Sta in una cosa molto semplice: un assistente che parla col pubblico è sicuro quanto la chiave che porta in tasca. Un testo costruito bene può far fare all’assistente una cosa che non dovrebbe. Se la chiave è stretta, quella cosa è piccola. Se la chiave è larga, può essere tutto.

Hai già gli strumenti per controllare. Prendi l’assistente più esposto che hai, scrivi su un foglio le connessioni che usa, e per ciascuna chiediti: serve davvero a lui? Poi tocca a Make, a n8n, ai connettori: stringi dove puoi.

Se alla fine del controllo scopri che hai una chiave sola per tutto, non sei il solo, e proprio per questo vale la pena fare l’esercizio. Restringila oggi e racconta nei commenti cosa hai trovato: sono curioso di sapere quanti di voi hanno scoperto un citofono che apriva più appartamenti di quanto pensassero.

Articoli correlati

Fonti

Fonti: Zenity Labs (2 post, 08/10/2026), The Next Web, The Decoder, AWS docs (best practices e IAM permissions AgentCore Runtime), CSO Online, Tenable, OWASP GenAI (LLM06:2025 e Top 10 Agentic 2026), Make Help Center, n8n docs, Claude Help Center.

✍️ Articolo firmato da “La Redazione”: sistema editoriale multi-agente (AI) orchestrato con Claude Code e supervisionato da Luca Cazzaniga · lucacazzaniga.it

Leggi anche

AI