Una vulnerabilità resa nota il 27 agosto 2026 ha mostrato che Amazon Kiro, un IDE con funzioni di intelligenza artificiale, poteva essere indotto a inviare dati sensibili locali verso un server esterno. Il punto critico per le aziende è semplice: quando strumenti AI leggono il contenuto di un progetto e allo stesso tempo possono usare configurazioni, strumenti e rete, un file apparentemente innocuo può trasformarsi in un canale di fuga dei dati.
Che cosa è successo in Amazon Kiro
Secondo i ricercatori di Mindgard, la vulnerabilità interessava Kiro IDE 0.7.45 su Windows e consentiva un’esfiltrazione di informazioni attraverso una combinazione di prompt injection e funzionalità chiamate “Kiro Powers”. Non è stato assegnato un identificativo CVE a questo problema specifico.
In pratica, il contenuto controllato da un attaccante all’interno di un repository poteva influenzare il comportamento dell’agente AI di Kiro. Da lì, l’agente poteva leggere informazioni sensibili presenti localmente e farle finire in una configurazione rilevante per la sicurezza, che veniva poi usata dal programma per generare traffico verso un endpoint esterno.
Il tema non riguarda solo chi sviluppa software: molte aziende stanno iniziando a usare strumenti AI per scrivere codice, generare script, analizzare file di configurazione o automatizzare attività IT. Quando questi strumenti hanno accesso al file system locale, alla rete e a componenti eseguibili, il confine tra “assistente” e “azione concreta sul sistema” diventa molto sottile.
Perché questa falla è diversa dalle solite prompt injection
La particolarità del caso Kiro è che l’utente non doveva inserire un prompt malevolo né richiamare esplicitamente il contenuto ostile. Bastava aprire un progetto appositamente predisposto in un certo modo e poi inviare un qualunque messaggio all’agente AI perché si attivasse il flusso vulnerabile.
Questo punto è importante perché smentisce un’idea ancora diffusa: “basta stare attenti a cosa si chiede al chatbot”. Nei tool agentici moderni il problema non è solo il testo digitato dall’utente. Anche file di progetto, documentazione, configurazioni, commenti, pagine web lette dal tool e istruzioni persistenti possono influenzare il modello.
Quando il sistema tratta questi contenuti come contesto operativo, e non solo come testo da riassumere, si crea una possibile rottura del confine di fiducia. In altre parole, un’informazione presa dal repository può diventare un’istruzione capace di modificare il comportamento del software.
Come funzionava l’attacco, in termini pratici
Mindgard ha spiegato che lo sfruttamento richiedeva due azioni da parte dell’utente:
- aprire il progetto malevolo tramite un file workspace usando la funzione “File Open Workspace From File”, e non aprendo semplicemente la cartella;
- inviare poi un messaggio all’agente.
La vulnerabilità risultava riproducibile sia in workspace considerati attendibili sia in workspace non attendibili. La difficoltà di sfruttamento è stata valutata come bassa.
Qui il dettaglio tecnico più utile per chi gestisce un ufficio IT è questo: l’attacco non si basava su una macro, su un allegato eseguibile o su un installer sospetto, ma su un progetto apparentemente legittimo che sfruttava il modo in cui l’IDE interpretava contenuti, istruzioni e configurazioni. È un cambio di paradigma: il rischio si sposta dal singolo file infetto al comportamento emergente di più componenti collegati tra loro.
Il ruolo di Kiro Powers e dei file di steering
Kiro Powers, secondo quanto riportato, estende le capacità dell’IDE combinando configurazioni di server MCP, file di steering denominati “POWER.md”, hook e conoscenza contestuale. Il file di steering agisce come una sorta di manuale persistente: fornisce contesto all’agente e indica quali strumenti sono disponibili e quando usarli.
Questo modello è utile per aumentare produttività e automazione, ma introduce anche un problema noto nella sicurezza applicata all’AI: ciò che aiuta il modello a essere più efficace può anche amplificare la portata di istruzioni ostili. Se un file del progetto riesce a indirizzare l’agente verso operazioni sensibili, il passaggio dal “capire” al “fare” avviene senza che l’utente percepisca chiaramente il rischio.
È lo stesso motivo per cui oggi i ricercatori osservano con attenzione tutti gli ambienti di sviluppo AI che uniscono interpretazione del contesto, accesso ai file, invocazione di tool esterni e scrittura di configurazioni.
La correzione e la cronologia del problema
Amazon ha corretto la vulnerabilità nella versione 0.8.140 di Kiro IDE. Un portavoce dell’azienda ha dichiarato che il problema è stato affrontato con l’aggiornamento del 15 gennaio, poco dopo la segnalazione ricevuta. Nella fonte viene anche indicato che la versione più recente dell’IDE è la 1.0.337.
Per le aziende questo passaggio è essenziale: la notizia non segnala un rischio attuale identico per chi ha già aggiornato, ma dimostra che i tool AI di sviluppo devono essere trattati come software ad alta esposizione, non come semplici plugin di comodità.
Il caso si inserisce inoltre in una serie più ampia di problemi già emersi attorno a Kiro. A giugno 2026 Amazon aveva corretto una falla di controllo accessi insufficiente, tracciata come CVE-2026-10591 con punteggio CVSS 8.8, che poteva consentire a un attore remoto non autenticato di eseguire comandi arbitrari tramite istruzioni costruite per scrivere in percorsi sensibili all’esecuzione.
Un problema più grande di Amazon Kiro
La lezione più importante non è “Kiro è insicuro”, ma “gli strumenti AI agentici aprono nuove superfici di attacco”. La fonte richiama infatti altri casi scoperti nel 2026 in prodotti diversi, tra cui Codex CLI, Cursor CLI, Cursor, GitHub Copilot CLI, Google Gemini CLI e Anthropic Claude Code.
Il filo conduttore è sempre lo stesso:
- l’attaccante inserisce istruzioni indirette in contenuti che il tool legge;
- il modello interpreta quelle istruzioni come parte del contesto operativo;
- il programma compie azioni sul sistema locale o in rete;
- l’utente non riceve sempre segnali chiari del fatto che il comportamento è stato alterato.
Per un imprenditore questo significa che l’adozione dell’AI in azienda non può essere valutata solo in termini di produttività. Serve una verifica concreta di permessi, aggiornamenti, segregazione degli ambienti, logging e backup.
Cosa significa per la tua azienda
Se nella tua azienda usi strumenti AI per sviluppo, automazione interna o gestione IT, questo caso suggerisce alcune misure immediate.
Primo: aggiorna senza eccezioni. Un inventario software incompleto è oggi uno dei problemi più comuni nelle PMI. Se un team usa IDE o tool AI installati localmente, bisogna sapere quali versioni sono presenti e chi le utilizza. In questo contesto, un servizio di gestione delle postazioni e degli aggiornamenti aiuta a evitare che rimangano in uso versioni vulnerabili.
Secondo: limita ciò che i tool AI possono leggere e fare. Non tutti gli agenti devono avere accesso all’intero disco, a cartelle condivise, a credenziali locali o a file contenenti dati clienti. Conviene separare gli ambienti di sviluppo, usare account con privilegi minimi e impedire che strumenti sperimentali lavorino su file sensibili reali.
Terzo: definisci una regola semplice per l’apertura di progetti esterni. Repository scaricati da Internet, demo, proof of concept e workspace ricevuti da terzi non dovrebbero essere aperti direttamente su macchine che contengono dati aziendali importanti. È preferibile usare ambienti isolati o virtualizzati.
Quarto: tratta la prompt injection come un rischio applicativo, non formativo. La sola sensibilizzazione del personale non basta, perché in casi come questo l’utente può attivare il problema con un’azione normale e apparentemente innocua. Servono protezioni tecniche, verifica delle configurazioni e monitoraggio del traffico in uscita.
Quinto: prepara il piano di contenimento. Se un agente AI può leggere file locali, occorre chiedersi quali dati potrebbero uscire e come accorgersene. Log centralizzati, alert su connessioni anomale e una strategia di sicurezza informatica più strutturata diventano fondamentali.
Sesto: proteggi i dati con backup verificati. In casi simili si parla soprattutto di esfiltrazione, ma gli stessi strumenti potrebbero anche alterare configurazioni o file di progetto. Un sistema di backup remoto ben gestito riduce l’impatto operativo se occorre ripristinare rapidamente configurazioni pulite o verificare modifiche sospette.
Infine, se il tool AI entra in contatto con dati personali, il tema va letto anche in chiave organizzativa e normativa. Non basta dire che “è un assistente di sviluppo”: bisogna sapere quali dati può trattare, dove finiscono e con quali controlli.
Come impostare una policy interna sugli strumenti AI
Molte aziende hanno introdotto strumenti AI in modo informale: una licenza attivata da un reparto, una prova gratuita, un’estensione installata da un consulente. Il risultato è che l’uso reale spesso sfugge all’IT e alla direzione.
Una policy efficace dovrebbe almeno chiarire quattro punti:
- quali tool sono autorizzati;
- quali dati non devono essere caricati o esposti al tool;
- in quali ambienti è consentito aprire codice o progetti di terzi;
- chi approva nuove integrazioni che danno all’AI accesso a file, rete o sistemi interni.
Non serve un documento complicato. Per una PMI è meglio una regola concreta e applicabile, accompagnata da controlli tecnici di base, piuttosto che linee guida generiche che nessuno legge.
Domande frequenti
Se usiamo AI solo per programmare, siamo davvero a rischio?
Sì. Gli IDE agentici non si limitano a suggerire codice: possono leggere file, modificare configurazioni e interagire con strumenti esterni. È proprio questa combinazione a creare il rischio.
Basta aggiornare Kiro per essere al sicuro?
Aggiornare è indispensabile, ma non sufficiente. Il problema più ampio riguarda la gestione di tutti i tool AI con accesso al sistema locale, non solo Kiro.
Una PMI senza sviluppatori deve preoccuparsi?
Sì, se usa strumenti AI capaci di accedere a file, script, configurazioni o dati interni. Lo stesso schema di rischio può comparire anche fuori dallo sviluppo software.