Avviso Microsoft Simon: il worm di Word di Copilot trasforma file affidabili in veicoli
Microsoft deve affrontare un nuovo avviso su Copilot dopo che un ricercatore ha riprodotto attraverso Word un attacco prompt auto-propagante, nonostante due tentativi di mitigazione. La vicenda microsoft simon, evidenziata dal tecnologo Simon Willison, riguarda più del testo bianco nascosto che influenza una singola risposta dell'AI. Le istruzioni possono passare in un nuovo documento e trasformare quel file affidabile in un ulteriore veicolo.
Il data scientist norvegese Håkon Måløy ha reso pubblica la ricerca il 28 luglio 2026, dopo essersi coordinato con Microsoft per 144 giorni. Afferma che l'attacco è rimasto riproducibile con tutte le mitigazioni attuali implementate. Microsoft afferma di aver affrontato le conclusioni da lui segnalate e di continuare a rafforzare le misure di protezione per questa più ampia classe di rischi.
Il conflitto centrale è tra l'utilità di Copilot e il modello di fiducia richiesto da tale utilità. Word deve consentire a Copilot di leggere documenti di riferimento, interpretarne il significato e creare nuovo materiale. Le stesse capacità permettono a contenuti ostili di competere con le istruzioni effettive dell'utente e di entrare in lavori altrimenti legittimi.
Questo ricorda la ricerca Morris-II sui prompt auto-replicanti, ma il veicolo ora è un normale documento d'ufficio. L'attacco segnalato non richiede macro eseguibili, credenziali tenant rubate o accesso continuativo al file malevolo originale. Si basa su dipendenti che chiedono a un assistente AI di svolgere un'attività di redazione ordinaria.
Il documento Word non resta la minaccia originale
La scoperta chiave di Måløy è la propagazione: una fonte avvelenata può far sì che un output dall'aspetto pulito trasporti le stesse istruzioni nascoste.
L'attacco inizia quando qualcuno riceve un documento Word controllato da un attaccante. Potrebbe arrivare tramite email, Teams, SharePoint o un altro normale canale di condivisione. L'utente include successivamente quel documento come materiale sorgente per un'attività di redazione o modifica con Copilot.
Måløy ha inserito un prompt malevolo nel documento sorgente usando testo bianco piccolo su sfondo bianco. Normalmente gli utenti di Word non vedrebbero quel testo durante la revisione della pagina. Copilot può comunque riceverlo perché l'elaborazione del documento rimuove formattazioni come colore e dimensione del carattere prima di inviare il testo al modello linguistico.
Questa distinzione è importante. Il testo bianco su bianco non è un nuovo metodo di occultamento e la prompt injection tramite materiale nascosto è già ben documentata. Il cambiamento rilevante è ciò che accade dopo che Copilot legge il payload.
Secondo la divulgazione tecnica di Måløy, il prompt nascosto conteneva due attività collegate. Una ordinava a Copilot di modificare il materiale redatto. La seconda gli diceva di riprodurre il prompt nel documento risultante.
La sua prova di concetto utilizzava un'azienda fittizia e report finanziari. Secondo quanto riferito, Copilot ha dimezzato le cifre finanziarie durante la redazione di un report, quindi ha aggiunto il prompt malevolo in testo bianco da otto punti. L'output sembrava un documento aziendale creato internamente.
Un collega poteva in seguito usare quel report come contesto per un'altra attività con Copilot. Le istruzioni nascoste si sarebbero attivate nuovamente, alterando il nuovo report e copiandosi in quel file. In questa seconda fase, il documento originale controllato dall'attaccante non era più necessario.
È questo che rende utile il termine “worm”, con un'importante precisazione. I worm tradizionali eseguono codice e cercano automaticamente nuove macchine o servizi. Questa dimostrazione utilizza invece istruzioni per il modello, riutilizzo dei documenti e normali flussi di lavoro umani per proseguire la catena.
La propagazione è quindi condizionale. Qualcuno o un flusso di lavoro automatizzato deve inserire un file infetto nel contesto di Copilot. La ricerca non dimostra che ogni documento Word infetti autonomamente ogni file vicino.
Questa limitazione non elimina il rischio. Le organizzazioni riutilizzano costantemente report, proposte, policy, modelli, riepiloghi di riunioni e analisi di mercato. Un veicolo può spostarsi perché i dipendenti si fidano del suo contenuto aziendale, non perché lo riconoscono come software eseguibile.
Il file generato acquisisce inoltre credibilità istituzionale. Può riportare un autore interno, una formattazione approvata, un branding familiare e una posizione di archiviazione plausibile. Questi segnali favoriscono il riutilizzo anche se il documento ha ereditato istruzioni da una fonte esterna.
Il riepilogo sulla sicurezza di Simon Willison identifica chiaramente questo salto di livello. La prompt injection non influenza più soltanto la risposta immediata. L'output del modello diventa input persistente per un'altra attività assistita dal modello.
Questo è l'evento dietro la keyword microsoft simon. Willison ha portato alla luce la scoperta, Måløy ha svolto la ricerca e Microsoft possiede l'ambiente di produttività interessato. Tenere distinti questi ruoli è essenziale per valutare le prove.
Perché le ricerche Microsoft Simon rimandano a una crisi d'integrità
Il pericolo immediato non riguarda soltanto informazioni rubate. È la corruzione silenziosa dei documenti che le persone usano per prendere decisioni.
La copertura della prompt injection si concentra spesso sulla riservatezza. Un attaccante nasconde istruzioni in contenuti esterni, un assistente le segue e informazioni protette escono tramite un link o una chiamata a uno strumento. Resta una minaccia seria, ma la dimostrazione con Word pone l'accento sull'integrità.
L'integrità delle informazioni significa che i registri restano accurati, attribuibili e resistenti a modifiche non autorizzate. L'esempio di Måløy prende di mira le cifre finanziarie perché una modifica numerica è facile da illustrare. Manipolazioni simili potrebbero riguardare il linguaggio contrattuale, eccezioni alle policy, previsioni, requisiti tecnici o riepiloghi di ricerche.
Un report modificato può apparire grammaticalmente curato e internamente coerente. Il documento non deve contenere assurdità evidenti per causare danni. Piccole modifiche plausibili possono essere più pericolose perché i revisori hanno meno probabilità di metterle in discussione.
Måløy ha osservato che alcuni cambiamenti sperimentali erano difficili da notare anche quando sapeva dove cercare. Talvolta istruiva Copilot a evidenziare le modifiche, così da poter monitorare il risultato. Un attaccante reale non avrebbe alcun motivo di offrire tale assistenza.
L'attaccante beneficia anche della distanza. Quando un output contaminato diventa la fonte per un altro report, gli investigatori devono ricostruire una catena di riferimenti. Il file malevolo originale potrebbe essere assente, eliminato o archiviato fuori dal reparto che indaga sulla discrepanza.
I controlli di sicurezza convenzionali assegnano spesso fiducia in base a identità e posizione. Un file creato da un dipendente all'interno di un tenant Microsoft 365 approvato appare più sicuro di un allegato proveniente da un mittente sconosciuto. L'auto-propagazione indebolisce questa ipotesi perché il documento interno può ereditare istruzioni esterne.
L'attacco può anche attraversare confini organizzativi tramite la collaborazione ordinaria. Le aziende scambiano proposte, report, bozze legali e piani di progetto con fornitori e clienti. Un file interno infetto potrebbe diventare una fonte esterna per un'altra organizzazione.
Questo crea pressione per i team di sicurezza, i responsabili dei registri, gli auditor e i proprietari aziendali. Non possono trattare il testo generato dall'AI come una semplice questione di qualità della scrittura. Hanno bisogno di prove che mostrino quali fonti sono entrate in un documento e quali modifiche ha effettuato il modello.
Le attuali indicazioni di Microsoft per Word invitano già gli utenti a rivedere l'output dell'AI perché può contenere errori o imprecisioni. Le sue indicazioni su Copilot affermano inoltre che gli utenti dovrebbero modificare e verificare i contenuti generati prima di farvi affidamento.
La revisione umana rimane preziosa, ma non rappresenta un confine di sicurezza completo. Un revisore può verificare l'argomentazione visibile senza ispezionare testo nascosto, struttura del documento o provenienza delle fonti. Modifiche sottili possono inoltre sopravvivere perché si adattano alla narrazione circostante.
Le organizzazioni dovrebbero distinguere la revisione della qualità dalla revisione contro la manipolazione ostile. La revisione della qualità chiede se la prosa sia chiara e fattualmente credibile. La revisione della sicurezza chiede se contenuti non affidabili abbiano influenzato il comportamento, siano persistiti in modo invisibile o abbiano oltrepassato un confine di autorizzazione.
La distinzione diventa più urgente man mano che gli assistenti assumono azioni di modifica. Generare un riepilogo usa e getta limita la persistenza. Modificare un documento condiviso può cambiare un artefatto che in seguito entra in approvazioni, archivi e sistemi AI a valle.
Per i knowledge worker, ciò mette in discussione una supposizione familiare sulla memoria personale e istituzionale. I documenti salvati non sono passivi quando i flussi di lavoro AI li interpretano ripetutamente come contesto. Un artefatto avvelenato può influenzare output futuri senza modificare il modello sottostante.
I team che costruiscono una base di conoscenza ricercabile dovrebbero quindi preservare l'identità della fonte e lo stato di revisione. La comodità del recupero non deve cancellare la differenza tra istruzioni affidabili e prove non affidabili.
Come un prompt nascosto diventa un veicolo auto-replicante
Il meccanismo funziona perché Copilot deve interpretare il contenuto del documento prima di poter decidere se quel contenuto sia pertinente, sicuro o istruttivo.
Una prompt injection indiretta inserisce istruzioni ostili nel materiale che un sistema AI legge per conto dell'utente. L'utente non digita il comando malevolo. Lo fornisce un documento, un'email, una pagina web, la risposta di uno strumento o una memoria recuperata.
Microsoft chiama questa categoria più ampia attacco cross-prompt injection, o XPIA. L'attacco passa dal contenuto esterno al processo decisionale dell'assistente. Cerca di far comportare i dati come un comando.
La dimostrazione con Word inizia a quel confine. Un utente chiede a Copilot di redigere un report finanziario usando diversi allegati. Copilot deve leggere tali allegati per individuare fatti utili, anche quando uno contiene istruzioni nascoste.
Il modello riceve linguaggio affidabile e non affidabile nello stesso contesto computazionale. Regole di sistema, richieste dell'utente, materiale di riferimento e messaggi precedenti possono avere etichette o marcatori strutturali. Tuttavia, il modello interpreta comunque tutti come token quando predice la propria risposta.
Måløy paragona il rilevamento basato sul modello al chiedere a un interprete di eseguire un programma non affidabile per decidere se quel programma sia sicuro. L'analogia è imperfetta, poiché il linguaggio naturale non è codice eseguibile convenzionale. Coglie però la dipendenza circolare al centro del problema.
Il sistema vuole che il modello comprenda profondamente materiale di riferimento arbitrario. Un filtro più debole potrebbe non rilevare parafrasi, offuscamenti, formattazioni insolite o istruzioni inserite in un linguaggio aziendale plausibile. Un modello altrettanto capace usato come filtro può a sua volta affrontare la prompt injection.
Microsoft descrive diverse protezioni, tra cui filtraggio dell'input, separazione delle istruzioni, confini di grounding e filtraggio dell'output. La sua difesa dalla prompt injection identifica inoltre il testo nascosto o invisibile come segnale di avvertimento.
Questi livelli possono ridurre il successo dell'attacco senza creare una distinzione completa tra contenuto e intento. Måløy afferma che Microsoft ha bloccato la formulazione originale della sua prova di concetto. Ha quindi modificato l'attività richiesta e la formulazione, preservando il meccanismo di propagazione.
La cronologia della divulgazione mostra la ripetuta contesa. Måløy ha inviato il suo rapporto iniziale a Microsoft il 6 marzo e Microsoft ne ha confermato la ricezione il 9 marzo. Microsoft ha confermato il comportamento segnalato il 31 marzo.
Una prima mitigazione è stata implementata il 3 aprile con la nuova esperienza Edit with Copilot. Entro il 9 aprile, la formulazione originale non funzionava più. Måløy ha riferito di aver riprodotto quel comportamento quel giorno usando una nuova attività di prompt relativa alla manipolazione finanziaria.
Microsoft ha in seguito ritardato la divulgazione mentre preparava un'altra mitigazione. Måløy afferma che un aggiornamento del modello è stato implementato il 14 luglio. Ha riprodotto il worming il 15 luglio utilizzando il modello più recente disponibile durante i suoi test, poi ha ritardato la pubblicazione di altre due settimane.
Il 28 luglio, ha segnalato che l'attacco era ancora riproducibile. Ha pubblicato la classe di vulnerabilità e ha trattenuto il payload esatto. Questa scelta consente ai difensori di esaminare il rischio del flusso di lavoro senza fornire un prompt d'attacco pronto da copiare.
Il meccanismo in due fasi è rimasto coerente attraverso tali revisioni. Innanzitutto, istruzioni ostili influenzano l'attività attiva di redazione o modifica. In secondo luogo, Copilot copia tali istruzioni nell'output, creando un vettore persistente.
Questo secondo passaggio distingue la dimostrazione dalla maggior parte delle injection in una singola sessione. La persistenza non dipende dalla memoria del modello né da un account compromesso. Risiede in un file normale che le persone possono archiviare, approvare e ridistribuire.
Le protezioni di Microsoft restano comunque importanti. Aumentare lo sforzo necessario per un'injection riuscita può ridurre l'esposizione e bloccare formulazioni note. La difesa in profondità limita inoltre i danni quando un livello fallisce.
Tuttavia, il blocco specifico dei payload crea un ciclo di manutenzione sfavorevole. Gli attaccanti possono variare la formulazione, il contesto del documento e le azioni richieste. I difensori devono coprire un ampio spazio semantico preservando al contempo la capacità dell'assistente di seguire istruzioni legittime.
La promessa di produttività di Copilot incontra il suo confine di fiducia
Lo stesso accesso ai documenti che rende Copilot utile offre al testo controllato dagli attaccanti una strada verso attività ad alta fiducia.
Microsoft presenta Copilot in Word come uno strumento per redigere, riassumere, riscrivere e portare informazioni da altri documenti in nuovi contenuti. Queste funzioni richiedono un ampio accesso al materiale di lavoro dell'organizzazione.
Nell'aprile 2026, Microsoft ha introdotto capacità aggiuntive di Word per professionisti del settore legale, finanziario e della compliance. Le funzionalità includevano la gestione di commenti e modifiche rilevate per flussi di lavoro ad alta intensità di dettaglio. Microsoft ha dichiarato che l'integrità dei documenti non era negoziabile per tali utenti.
La divulgazione del worm mette quella promessa di fronte a una realtà difficile. I professionisti che operano in contesti ad alta criticità traggono il massimo beneficio quando Copilot può leggere molte fonti ed eseguire modifiche significative. Devono anche affrontare conseguenze maggiori quando istruzioni nascoste manipolano tali azioni.
Questo è il principale antagonista dell'articolo: accesso utile al contesto contro controllo affidabile delle istruzioni. Rimuovere tutto il contesto esterno limiterebbe drasticamente il prodotto. Trattare ogni frase significativa come un possibile comando può a sua volta danneggiare la normale redazione.
Il problema va oltre Microsoft. La retrieval-augmented generation, o RAG, fornisce a un modello informazioni esterne selezionate prima che risponda. Qualsiasi sistema RAG può esporre il modello a materiale controllato dagli attaccanti, a meno che fonti e azioni non siano strettamente vincolate.
Il paper Morris-II del 2024 ha dimostrato prompt auto-replicanti avversari in ambienti di assistenti email basati su IA generativa. Tali prompt potevano propagarsi attraverso applicazioni connesse e favorire il furto di dati in interazioni ripetute.
Il lavoro di Måløy porta il concetto nei flussi di lavoro di Word usati dalle organizzazioni mainstream. Sostituisce un ambiente email sperimentale con la familiare redazione e modifica di documenti. Il percorso d'attacco sfrutta inoltre la fiducia associata ai file interni.
Altri fornitori di IA affrontano la stessa tensione architetturale. Gli assistenti Google Workspace possono riassumere e creare documenti da contenuti condivisi. I prodotti Anthropic e OpenAI possono elaborare file caricati, record recuperati e dati di applicazioni connesse.
Il confronto pertinente non riguarda quale modello segua un particolare payload. Gli attacchi tramite prompt sono probabilistici e le prestazioni cambiano in base ai prompt, alle versioni dei modelli, al contesto e alle protezioni. Un singolo successo o fallimento non può stabilire una classifica duratura.
La domanda migliore riguarda la progettazione del sistema. Il prodotto mantiene la provenienza delle fonti, limita le azioni, rende visibili le modifiche al modello e impedisce che l'output generato diventi silenziosamente un'istruzione fidata? Gli amministratori possono indagare la catena dopo un comportamento sospetto?
Microsoft afferma di usare più salvaguardie per bloccare istruzioni dannose e mantenere le attività allineate alle richieste degli utenti. Consiglia inoltre ai clienti di installare gli aggiornamenti, usare protezioni a più livelli, diffidare dei contenuti sconosciuti e rivedere l'output generato.
Måløy offre una valutazione più circoscritta. Riconosce a Microsoft il merito di aver bloccato i payload segnalati e mitigato precedenti vettori basati su memoria ed email. Ciononostante, afferma che nessuna azione lato cliente affronta pienamente la classe di propagazione tramite documenti al momento della pubblicazione.
Queste affermazioni non si escludono a vicenda. Microsoft può migliorare le difese mentre persiste una vulnerabilità più ampia. I controlli di sicurezza spesso riducono probabilità e impatto senza eliminare un'intera categoria di attacchi.
Il disaccordo riguarda ciò che i clienti dovrebbero dedurre da tale rischio residuo. Il linguaggio di Microsoft enfatizza la difesa continua. L'analisi di Måløy sostiene che le organizzazioni debbano presumere un certo compromesso ogni volta che contenuti controllati dagli attaccanti raggiungono un modello linguistico integrato.
Questa affermazione più forte non è stata testata in modo indipendente su ogni configurazione di Copilot. Il report pubblico documenta una proof of concept nelle condizioni indicate, non un tasso di infezione misurato tra i tenant di produzione.
Cosa la storia di Microsoft Simon non dimostra ancora
La dimostrazione è seria, ma non stabilisce un'infezione di massa autonoma né conferma lo sfruttamento contro organizzazioni reali.
Il report di Måløy presenta scenari di proof of concept controllati che utilizzano un'azienda fittizia. Non afferma che gli attaccanti abbiano già usato questo metodo contro i clienti. Alla divulgazione non accompagnano alcun conteggio pubblico degli incidenti, totale degli utenti interessati o tasso di successo misurato.
L'attacco richiede inoltre un innesco nel flusso di lavoro. Un documento dannoso deve entrare nel contesto di Copilot, tramite un allegato esplicito o il recupero da OneDrive. Un utente o un processo automatizzato deve quindi accettare, salvare o riutilizzare il documento risultante.
Copilot non infetta semplicemente ogni file Word accessibile all'account. Il modello deve selezionare o ricevere il vettore, seguire l'istruzione nascosta e riprodurla correttamente. Ogni fase introduce incertezza.
Il ricercatore ha dimostrato sia l'allegato diretto sia la selezione automatica per rilevanza nel suo ambiente. In quest'ultimo caso, Copilot ha trovato un documento dannoso di analisi di mercato in OneDrive, pur essendo archiviato separatamente dai file interni correlati.
Questo risultato merita attenzione perché il recupero automatico riduce la consapevolezza dell'utente sulla fonte. Tuttavia, non ci dice con quale frequenza Copilot selezioni un documento inserito intenzionalmente in tenant, autorizzazioni, argomenti o raccolte documentali diversi.
Il payload usava anche testo bianco, una tecnica di occultamento rilevabile. Gli strumenti di sicurezza possono ispezionare l'XML dei documenti, segnalare la formattazione nascosta o convertire i file in testo normalizzato per la revisione. Tali controlli potrebbero intercettare questo esempio pur non rilevando istruzioni mascherate semanticamente.
Måløy ha intenzionalmente trattenuto il prompt esatto, limitando la riproduzione indipendente. Tale decisione riduce l'abuso immediato, ma significa anche che i ricercatori esterni non possono ancora verificare ogni dettaglio. The Register ha riferito che Microsoft ha confermato la ricerca dopo aver ricevuto il materiale completo.
Il comportamento del modello è un'altra fonte di incertezza. Un prompt che riesce in un test può fallire dopo un aggiornamento o in un altro contesto. Al contrario, un payload bloccato non dimostra che l'intera classe sia stata chiusa.
Il quadro di microsoft simon dovrebbe quindi rimanere preciso. Le prove supportano una dimostrazione di prompt auto-propagante veicolato da documenti in Copilot per Word. Non supportano affermazioni su un'epidemia diffusa o su una convenzionale epidemia di malware.
Le valutazioni del rischio dovrebbero considerare la conseguenza insieme alla frequenza. Un basso tasso di successo può comunque essere rilevante quando gli artefatti interessati includono report finanziari, contratti, comunicazioni normative o procedure di sicurezza. Il riutilizzo ripetuto assistito dall'IA può creare molte occasioni di innesco.
Le imprese dovrebbero evitare risposte che rendano i dipendenti gli unici responsabili del rilevamento. Dire agli utenti di ispezionare ogni fonte e ogni output trasferisce un problema tecnico di fiducia a un processo di revisione frettoloso.
Controlli ragionevoli includono la limitazione dell'accesso di Copilot a repository approvati, la scansione dei documenti caricati alla ricerca di materiale nascosto e la separazione delle fonti esterne dai modelli fidati. Le organizzazioni possono inoltre richiedere l'approvazione umana prima che file modificati dall'IA entrino in flussi di lavoro consequenziali.
La provenienza dei documenti è altrettanto importante. I sistemi dovrebbero registrare quali fonti hanno contribuito a un output e quali modifiche ha proposto Copilot. I revisori hanno bisogno di prove visibili, non soltanto di un documento finale pulito.
I team di sicurezza dovrebbero testare le proprie configurazioni attraverso esercitazioni interne sicure. I test dovrebbero variare fonti degli allegati, comportamento di recupero, tipi di documento, autorizzazioni e riutilizzo a valle. I risultati di un tenant non dovrebbero essere trattati come universali.
Anche i piani di risposta agli incidenti necessitano di una strategia di tracciamento della discendenza dei documenti. Se viene trovato un vettore, gli investigatori devono identificare file derivati, destinatari, posizioni di archiviazione e sessioni Copilot successive. Eliminare il primo file noto non rimuoverebbe le copie a valle.
Tre segnali mostreranno se il worm IA di Word è contenuto
Il prossimo test è se Microsoft può fermare la propagazione come classe, rendere visibile una discendenza affidabile e resistere alla riproduzione indipendente.
Il primo segnale è una mitigazione Microsoft che affronti la propagazione dell'output anziché un altro payload noto. Un aggiornamento significativo impedirebbe a Copilot di copiare silenziosamente istruzioni non fidate nei documenti generati. Dovrebbe funzionare con parafrasi e variazioni delle attività.
Un simile controllo rafforzerebbe la fiducia se test indipendenti mostrassero l'interruzione della catena del vettore. Un altro blocco specifico per formulazione indebolirebbe tale conclusione, anche se fermasse il prompt ricevuto da Microsoft.
Il secondo segnale è una migliore provenienza all'interno di Word e Microsoft 365. Gli utenti necessitano di un registro duraturo che colleghi il testo generato ai relativi documenti di riferimento. Necessitano inoltre di un tracciamento visibile delle modifiche eseguite dal modello, comprese quelle accettate nel file finale.
La provenienza non impedirebbe ogni injection. Ridurrebbe l'invisibilità che rende difficile tracciare il worm dimostrato. Potrebbe inoltre aiutare i team di sicurezza a individuare documenti correlati dopo la scoperta di un file interessato.
Il terzo segnale è il test indipendente sulle configurazioni Copilot attuali. I ricercatori dovrebbero esaminare allegati espliciti, recupero da OneDrive, Edit with Copilot e altri flussi di lavoro per la creazione di documenti. Dovrebbero riportare condizioni e tassi di successo senza rilasciare prematuramente payload operativi.
Una riproduzione indipendente fallita indebolirebbe le affermazioni più ampie, ma non eliminerebbe il problema architetturale. Una riproduzione affidabile dopo un'altra mitigazione mostrerebbe che la classe rimane attiva oltre l'ambiente di un singolo ricercatore.
Per ora, le organizzazioni dovrebbero trattare i file di origine esterna come dati non fidati ogni volta che Copilot li elabora. Dovrebbero applicare la stessa cautela ai documenti generati internamente la cui cronologia delle fonti è sconosciuta.
La domanda pratica non è più se un testo nascosto possa ingannare la risposta di un singolo chatbot. È se gli artefatti creati dall'IA possano trasportare intenti ostili nel successivo flusso di lavoro fidato. La storia di microsoft simon afferma che possano farlo nelle condizioni dimostrate, mentre Microsoft sostiene che le salvaguardie a più livelli continuino a migliorare.
Chi utilizza Copilot per attività importanti dovrebbe porsi subito una domanda prima di riutilizzare qualsiasi file generato: riusciamo a identificare ogni fonte, ogni modifica apportata dall'AI e ogni istruzione nascosta al suo interno? Se la risposta è no, il documento non è ancora abbastanza affidabile da diventare il contesto di qualcun altro.
