TLDR

  • Morris II descrive worm per applicazioni GenAI: prompt non fidati che si replicano attraverso output, memoria, RAG o azioni automatiche.
  • Il tema è diventato più urgente con agenti AI, tool permission, MCP, coding assistant e workflow che leggono contenuti esterni.
  • Il rischio non è solo il modello che sbaglia: è il sistema intorno al modello che esegue, invia, commenta, legge repo o chiama tool.
  • La difesa passa da isolamento, permessi minimi, provenienza del contesto, review prima degli effetti e log leggibili.

Il vecchio worm ha imparato a leggere

Il nome Morris II è scelto bene perché punge la memoria.

Il Morris worm originale, nel 1988, è diventato il racconto classico dell'esperimento che scappa dal laboratorio. Propagazione, assunzioni sbagliate, Internet ancora piccola e conseguenze molto grandi.

Morris II aggiorna la paura: non più solo codice che si replica sfruttando una vulnerabilità fissa, ma testo ostile che entra in un sistema GenAI, viene trattato come istruzione e spinge l'applicazione a riprodurlo o ad agire.

Hacker Journal lo presentava come worm che infetta l'IA. La ricerca "Here Comes The AI Worm" lo formalizza con prompt autoreplicanti in scenari come assistenti email e RAG. Nel 2026, il paper sugli adaptive computer worms sposta ancora più avanti l'asticella: agenti AI che possono ragionare sul target e adattare la strategia.

Non serve panico.

Serve architettura.

La differenza tra prompt e istruzione

Un'app GenAI legge testo.

Il problema è che non tutto il testo ha lo stesso ruolo. Le istruzioni del proprietario dell'app dovrebbero avere un peso. Il contenuto scritto da un utente sconosciuto, da una pagina web, da una issue pubblica, da un'email o da un documento caricato dovrebbe averne un altro.

Quando questi strati si mescolano, nasce la prompt injection.

Il worm AI aggiunge una proprietà più inquietante: l'input malevolo non vuole solo alterare una risposta. Vuole essere copiato nel prossimo output, salvato in memoria, inoltrato a un altro utente, inserito in un commento, recuperato da un indice RAG o passato a un altro agente.

Schema acid pixel di una catena difensiva contro prompt worm

Quindi il punto non è "il modello è cattivo".

Il punto è: cosa gli permetti di fare quando legge testo non fidato?

RAG: memoria utile, memoria contaminabile

RAG significa recuperare documenti o frammenti da una base di conoscenza e passarli al modello come contesto.

È utilissimo. È anche una nuova superficie.

Se un documento contaminato entra nell'indice, può riapparire più tardi in una risposta. Se quel contenuto contiene istruzioni ostili e il sistema non separa bene "dati" e "comandi", l'agente può trattarlo come qualcosa da seguire.

La forma mentale è semplice:

  • un utente carica contenuto;
  • il contenuto finisce in memoria o indice;
  • un altro flusso lo recupera;
  • il modello lo legge insieme alle istruzioni buone;
  • l'output produce un'azione o un nuovo testo contaminato.

Non è magia nera. È pipeline.

E le pipeline vanno progettate.

Agenti: quando l'output ha mani

Un chatbot che risponde male è fastidioso.

Un agente che risponde male e può chiamare tool è un'altra cosa.

Quando un sistema può leggere repository, commentare issue, aprire pull request, inviare email, interrogare CRM, modificare ticket, lanciare script o parlare con MCP server, l'output non è più solo testo. Diventa azione.

The Hacker News ha raccontato GitLost: una issue pubblica può influenzare workflow agentici con accesso a repository privati, se l'organizzazione ha concesso contesto troppo largo. Il punto è lo stesso: un contenuto esterno non dovrebbe diventare comando solo perché l'agente lo ha letto.

Anche la supply chain cambia. Non devi più chiederti solo "che pacchetto ho installato?". Devi chiederti:

  • quale agente ha suggerito quel pacchetto;
  • quale tool ha chiamato;
  • quale prompt ha letto;
  • quale contesto ha considerato autorevole;
  • quali permessi aveva quando ha agito.

La provenienza non riguarda più solo il codice. Riguarda il percorso che ha prodotto il codice.

Morris II non è una ricetta, è un test di architettura

La domanda utile non è "posso riprodurre Morris II?".

La domanda utile è: il mio sistema si farebbe usare come vettore?

Ecco un test mentale difensivo:

  • se un utente esterno scrive "ignora le regole" dentro una issue, l'agente lo tratta come dato o come istruzione?
  • se un documento RAG contiene un comando mascherato, il modello può trasformarlo in output operativo?
  • se l'agente scrive una risposta, può anche inviarla senza revisione?
  • se legge un repo pubblico, può leggere anche repo privati non necessari?
  • se chiama un tool, quel tool ha permessi larghi o minimi?
  • se succede qualcosa, hai log comprensibili o solo una risposta finale?

Se rispondi "non lo so", il sistema non è pronto.

La catena difensiva

La difesa non deve essere teatrale. Deve essere noiosa e ripetibile.

Separare istruzioni e contenuto:

Le regole dell'app devono vivere in un canale diverso dai dati recuperati. Il modello deve sapere che documenti, email, pagine web, issue e commenti sono input non fidati.

Limitare i tool:

Un agente che deve riassumere un'issue non ha bisogno di leggere tutti i repository privati. Un agente che deve suggerire codice non dovrebbe pubblicare, deployare o inviare segreti.

Mettere gate prima degli effetti:

Inviare email, aprire PR, commentare su GitHub, modificare ticket, chiamare API esterne e salvare memoria persistente sono effetti. Gli effetti meritano conferma, policy o sandbox.

Tracciare provenienza:

Ogni output importante dovrebbe poter rispondere a una domanda: da quali fonti arriva? Quali parti del contesto erano non fidate? Quali tool sono stati chiamati?

Pulire memoria e indice:

Il RAG non è una discarica. Serve ingestion con controlli, separazione per tenant, metadata, versioning e possibilità di rimuovere contenuti contaminati.

Collegamenti con gli articoli già pubblicati

Questo pezzo si incastra con tre filoni di Able2Code.

Il primo è la prompt injection negli agenti di coding: Prompt injection negli agenti AI: quando il tuo coding tool legge il testo sbagliato.

Il secondo è GitLost: GitLost: quando una issue pubblica può far leggere un repo privato a un agente AI.

Il terzo è la parte storica: Storie hacker: quando la curiosità diventa incidente.

Morris II sta esattamente in mezzo: storia, malware, prompt injection, agenti e supply chain.

La cosa da ricordare

Un worm classico sfrutta un sistema che esegue codice.

Un worm AI sfrutta un sistema che interpreta testo e poi agisce.

Questa differenza è sottile solo finché l'agente non ha permessi reali. Appena l'agente legge, scrive, invia, modifica o chiama tool, il testo diventa una superficie d'attacco con conseguenze operative.

La frase da appendere al monitor:

input non fidato, effetti controllati.

È meno epica di "destroy all humans".

È molto più utile.

FAQ

Morris II è malware reale o ricerca?

Il nome nasce da ricerca accademica sui worm GenAI e da dimostrazioni controllate. Il punto non è copiare un attacco, ma capire il threat model prima che diventi normale nei sistemi agentici.

Cosa c'entra il Morris worm originale?

Il parallelo è la propagazione. Nel 1988 il worm si replicava tra sistemi con assunzioni sbagliate; oggi il rischio è che istruzioni non fidate si replichino tra modelli, memorie, email, issue, tool e agenti.

Una prompt injection può davvero propagarsi?

Sì, se l'applicazione prende input non fidato, lo inserisce nel contesto del modello e poi usa l'output per inviare messaggi, aggiornare memoria, commentare ticket o alimentare altri sistemi.

Basta filtrare il prompt?

No. I filtri aiutano, ma la difesa robusta nasce dall'architettura: separare istruzioni e contenuti, limitare tool e permessi, richiedere conferma umana per effetti esterni e registrare ogni passaggio.

Per chi è rilevante?

Per chi usa agenti di coding, assistenti email, RAG aziendali, workflow GitHub, MCP server, chatbot interni o automazioni che leggono testo scritto da utenti esterni.

Fonti