Il bypass della sandbox di Microsoft Copilot Cowork ha trasformato una Skill affidabile in un canale di esfiltrazione

Microsoft ha mitigato una vulnerabilità di Copilot Cowork dopo che i ricercatori hanno dimostrato che una singola Skill malevola poteva aggirare la sandbox del prodotto ed esfiltrare dati di lavoro. Secondo quanto riportato, il bypass della sandbox di Microsoft Copilot Cowork creava un canale di comando tra il server di un aggressore e l'ambiente isolato dell'agente.

PromptArmor afferma che quel canale poteva raggiungere i dati disponibili tramite Outlook, SharePoint, Teams, plugin connessi e la sessione attiva. Il ricercatore ha segnalato il problema il 24 giugno 2026 e Microsoft ha confermato la mitigazione il 19 agosto.

La scoperta mette in discussione una promessa fondamentale degli agenti per il lavoro. Una sandbox può isolare il codice, ma l'isolamento conta poco quando un servizio affidabile diventa una via non monitorata attraverso il suo confine. Microsoft afferma che Cowork ora valuta le Skills e avverte gli utenti di caricarle solo da fonti affidabili.

Secondo la cronologia della divulgazione, la vulnerabilità segnalata non è più uno zero-day aperto. Tuttavia, la lezione di progettazione va oltre una singola implementazione corretta. Gli agenti aziendali combinano istruzioni non affidabili, asset eseguibili, dati dell'organizzazione e strumenti autenticati in un unico flusso di lavoro.

Questa combinazione rende il confine di fiducia più difficile da definire rispetto al software aziendale tradizionale. La domanda centrale non è più se un agente venga eseguito all'interno di una sandbox. Gli acquirenti devono chiedersi quali servizi attraversino tale sandbox, cosa accettino tali servizi e quali attività i team di sicurezza possano osservare.

Come funzionava la catena di esfiltrazione dei file di Copilot Cowork

Secondo quanto riportato, l'exploit ha trasformato un servizio legittimo di trasferimento file in un canale di comando bidirezionale che le restrizioni di rete della sandbox non riuscivano a bloccare.

Copilot Cowork è un sistema agentico Microsoft 365 in grado di pianificare ed eseguire attività in più passaggi. Può lavorare con documenti, cercare informazioni dell'organizzazione, creare file, inviare messaggi e richiamare Skills specializzate.

Una Skill è un pacchetto di istruzioni riutilizzabile che guida l'agente in uno specifico flusso di lavoro. Microsoft supporta Skills integrate, personalizzate, condivise e basate su plugin, a seconda dell'ambiente Cowork e della configurazione amministrativa.

L'esempio di PromptArmor iniziava con una normale attività aziendale. Un utente chiedeva a Cowork di confrontare un contratto con una proposta tramite una Skill di coerenza documentale scaricata da una fonte esterna.

La Skill ha prodotto il confronto richiesto, quindi l'attività visibile sembrava riuscita. Tuttavia, PromptArmor afferma che uno script incluso nel pacchetto invocava anche un servizio di sincronizzazione file operante al di fuori della sandbox dell'agente.

Secondo quanto riportato, Cowork utilizzava quel servizio per spostare file tra l'archiviazione esterna e l'ambiente di lavoro isolato. Il servizio accettava un URL che identificava il file da recuperare.

Secondo l'analisi del bypass della sandbox del ricercatore, codice malevolo poteva invece fornire un URL controllato dall'aggressore. Tale comportamento permetteva allo script di indurre un servizio esterno a contattare un'infrastruttura che la sandbox non poteva raggiungere direttamente.

Il server dell'aggressore restituiva un file contenente un comando. Lo script malevolo leggeva quel file, eseguiva il comando all'interno di Cowork e codificava il risultato in un altro URL richiesto.

Questa seconda richiesta riportava l'output del comando al server dell'aggressore. Ripetere il processo ogni pochi secondi stabiliva, secondo quanto riportato, un ciclo di comando e controllo, consentendo a un aggressore di impartire nuove istruzioni in base ai risultati precedenti.

Non si trattava di una singola richiesta in uscita. Creava un percorso interattivo verso un ambiente connesso ai servizi dell'organizzazione.

PromptArmor afferma che la sua dimostrazione utilizzava il server Model Context Protocol di Cowork. MCP è un'interfaccia standard attraverso cui un'applicazione di IA può richiamare strumenti connessi e recuperare dati.

Il ricercatore sostiene che l'aggressore potesse usare i comandi per interrogare i servizi disponibili tramite quella connessione MCP. La dimostrazione includeva l'elenco dei messaggi Outlook e il recupero del contenuto di un thread email.

Secondo quanto riportato, lo stesso percorso di accesso esponeva file SharePoint, cronologia della sessione, dati dei plugin e altre informazioni disponibili all'utente attivo. La portata effettiva dipenderebbe dalle autorizzazioni dell'utente e dai servizi connessi.

Un dettaglio rendeva il comportamento segnalato particolarmente preoccupante. PromptArmor afferma che selezionare il controllo di arresto non terminava i processi già in esecuzione in background.

Il turno visibile dell'agente poteva concludersi mentre lo script malevolo continuava a interrogare il server dell'aggressore. Un utente poteva quindi credere che l'attività fosse terminata mentre il canale occulto restava attivo.

PromptArmor ha segnalato il problema a Microsoft il 24 giugno. Microsoft ha richiesto informazioni aggiuntive il 24 luglio, ha discusso una correzione fino ai primi di agosto e ha confermato la mitigazione il 19 agosto.

Le prove pubbliche provengono principalmente dal resoconto tecnico e dalla dimostrazione di PromptArmor. Microsoft non ha pubblicato un avviso dettagliato che spieghi la modifica al codice, le versioni interessate o la telemetria disponibile per indagini retrospettive.

Perché il bypass della sandbox di Microsoft Copilot Cowork è importante

La vulnerabilità prendeva di mira il servizio che collega la sandbox a dati utili, anziché sconfiggere l'isolamento tramite una tradizionale evasione.

Una sandbox tradizionale cerca di contenere codice non affidabile limitando file, processi, dispositivi e connessioni di rete. Questo modello funziona solo quando ogni percorso che attraversa il confine applica una convalida altrettanto rigorosa.

Gli agenti moderni complicano questa configurazione perché il lavoro utile richiede eccezioni controllate. Un agente deve ricevere documenti, restituire file generati, richiamare strumenti, accedere a sistemi aziendali e conservare uno stato sufficiente per completare attività lunghe.

Ogni eccezione diventa un intermediario tra l'ambiente isolato e qualcosa di più affidabile. L'intermediario può essere sicuro quando convalida sia le destinazioni sia i flussi di dati. Diventa pericoloso quando codice non affidabile può riutilizzarlo per altri scopi.

Il resoconto di PromptArmor non descrive un classico exploit di corruzione della memoria o una fuga dal sistema operativo. La Skill malevola di Copilot Cowork sarebbe rimasta all'interno della sandbox abusando di un servizio privilegiato esterno.

Questa distinzione è importante nelle revisioni della sicurezza aziendale. Un fornitore può affermare correttamente che il codice venga eseguito in isolamento, trascurando però un intermediario che effettua richieste esterne arbitrarie per conto di quel codice.

La tensione architetturale è al centro del valore di Cowork. Microsoft presenta il prodotto come un agente che va oltre la chat e completa il lavoro in Microsoft 365.

Nell'annuncio del prodotto Cowork di Microsoft, l'azienda ha evidenziato flussi di lavoro per la posta in arrivo, ricerca, generazione di documenti, integrazioni e Skills riutilizzabili. Tali capacità richiedono accesso a un prezioso contesto aziendale.

La documentazione attuale di Cowork afferma che le attività elaborano i file degli utenti all'interno di un ambiente temporaneo e isolato, entro il perimetro del servizio Microsoft 365. Afferma inoltre che l'ambiente viene rimosso al termine dell'attività.

Questo modello di sicurezza limita l'esposizione diretta, ma non elimina il rischio derivante dagli strumenti connessi. Un ambiente isolato può comunque diventare un punto di lancio quando un intermediario affidabile accetta input controllato dall'aggressore.

Ecco perché il bypass della sandbox di Microsoft Copilot Cowork mette sotto pressione sia Microsoft sia gli acquirenti aziendali. Microsoft deve dimostrare che il confine riparato copra ogni intermediario, non soltanto il percorso di sincronizzazione identificato da un ricercatore.

I clienti devono inoltre rivedere le proprie ipotesi sulle autorizzazioni degli utenti. Cowork opera con gli accessi dell'utente attivo, quindi un'attività sfruttata non necessita di una compromissione separata dell'account per raggiungere dati autorizzati.

Il principio del privilegio minimo riduce comunque il raggio d'azione. Non impedisce l'uso improprio di accessi che l'utente possiede legittimamente.

Un dipendente che confronta due documenti potrebbe avere l'autorizzazione per leggere email riservate, cartelle di trattative o discussioni interne. Tali autorizzazioni possono diventare disponibili a un agente tramite le sue connessioni approvate.

L'input malevolo arrivava inoltre come componente riutilizzabile di un flusso di lavoro, non come un eseguibile palesemente ostile. Questa modalità di pacchettizzazione riduce i sospetti degli utenti perché le Skills sono progettate per apparire come estensioni di produttività.

L'exploit unisce quindi due problemi di sicurezza che le organizzazioni spesso gestiscono separatamente. Uno è il rischio della supply chain del software derivante dai pacchetti scaricati. L'altro è il rischio di autorizzazione degli agenti che agiscono come utenti autenticati.

I programmi di sicurezza devono affrontarli insieme. Revisionare il codice senza mappare i dati accessibili ignora l'impatto, mentre governare le autorizzazioni senza ispezionare gli asset delle Skills ignora il punto di ingresso.

Una Skill malevola di Copilot Cowork può comunque sembrare utile

La Skill più pericolosa non è quella che fallisce visibilmente, ma quella che completa il compito assegnato mentre esegue una seconda attività nascosta.

La dimostrazione di PromptArmor utilizzava un flusso di lavoro di confronto documentale perché riflette una normale richiesta di lavoro basato sulla conoscenza. Secondo quanto riportato, la Skill generava un rapporto completo di coerenza mentre lo script malevolo apriva il canale occulto.

Questo duplice comportamento indebolisce un segnale di sicurezza familiare. Gli utenti spesso considerano un output corretto come prova che lo strumento abbia operato come previsto.

Per un agente, la qualità dell'output e l'integrità dell'esecuzione sono questioni distinte. Un rapporto utile non rivela ogni script, chiamata di servizio o richiesta di dati effettuata durante la sua produzione.

L'attuale guida alle Skills personalizzate di Microsoft afferma che Cowork valuta automaticamente le Skills. I controlli documentati variano in base al livello di diffusione e rischio.

I controlli statici esaminano struttura, codice incluso e testo alla ricerca di schemi di prompt injection. I controlli comportamentali valutano output, azioni, uso degli strumenti, conflitti e prestazioni con prompt realistici.

La documentazione descrive ulteriori controlli per le distribuzioni a rischio più elevato. Questi possono includere convalida degli asset, test di fiducia e sicurezza, valutazione avversariale, test di regressione e revisione umana.

Microsoft rivolge inoltre agli utenti un avvertimento diretto: caricare Skills solo da fonti di cui si fidano. Questo consiglio riconosce che l'ispezione automatizzata non può trasformare codice arbitrario di terze parti in una dipendenza sicura.

La tempistica di tali controlli documentati merita un trattamento prudente. La documentazione live di Microsoft riflette il prodotto attuale, non necessariamente l'esatta configurazione testata da PromptArmor prima del 19 agosto.

Non è quindi sicuro affermare che ogni controllo attuale sia fallito durante la dimostrazione. È altrettanto incauto presumere che i controlli elencati rileverebbero ogni variante dell'attacco.

La scansione statica presenta limiti intrinseci. Il comportamento malevolo può essere suddiviso tra file, nascosto dietro funzioni normali, scaricato in seguito o attivato solo in condizioni particolari.

Anche i test comportamentali campionano un insieme limitato di esecuzioni. Una Skill può agire in modo sicuro durante la valutazione e attivare logica dannosa dopo una data, su un tenant bersaglio o quando compaiono dati specifici.

La recente ricerca accademica considera le Skills degli agenti come una superficie della supply chain del software, anziché semplici modelli di prompt. La ricerca SkillGate ha valutato uno scanner ibrido rispetto a un benchmark contenente 1.650 pacchetti Skill.

I suoi autori hanno riportato un punteggio F1 di 0,817 e un tasso di falsi positivi dell'1,13 percento. Questi risultati supportano lo screening in fase di esecuzione, ma mostrano anche che il rilevamento resta probabilistico.

Il confronto non è una valutazione diretta di Cowork e il paper si concentra sulle Skills degli agenti di coding. Tuttavia, il suo modello di minaccia corrisponde strettamente al problema più ampio.

Un pacchetto di istruzioni riutilizzabile può includere script, documentazione dall'aspetto affidabile e comportamenti nascosti. Installarlo amplia la base effettiva di codice e istruzioni dell'agente.

I tradizionali store di applicazioni affrontano rischi analoghi attraverso firme, revisioni, reputazione, rimozione rapida e dichiarazioni dei permessi. Le Skills degli agenti richiedono tali misure, oltre alla visibilità sull'esecuzione guidata dal modello.

Il modello può scegliere quando e come richiamare i file di supporto. Questa flessibilità rende una Skill più adattabile, ma rende anche difficile produrre un manifest completo del comportamento.

Microsoft supporta la condivisione organizzativa e i plugin dell'App Store insieme alle Skills personalizzate. Gli amministratori possono governare disponibilità e distribuzione dei plugin, connettori e utenti assegnati.

Questi controlli creano un percorso di distribuzione più solido rispetto al download di un archivio sconosciuto. Non eliminano la necessità di ispezionare pacchetti condivisi privatamente o caricati personalmente.

Le aziende dovrebbero trattare una Skill dannosa di Copilot Cowork come una dipendenza applicativa non attendibile. Provenienza, versioning, approvazione e revoca contano quanto le istruzioni in linguaggio naturale che contiene.

La Promessa della Sandbox si Scontra con la Realtà degli Agenti Connessi

Il conflitto principale è tra il contenimento come promessa di sicurezza e la connettività come funzionalità che rende prezioso un agente aziendale.

Microsoft afferma che Cowork può inviare e-mail, pianificare riunioni, creare documenti, pubblicare su Teams, cercare informazioni organizzative e gestire file. Queste azioni lo trasformano da chatbot in un sistema operativo.

Ogni connettore aggiunto aumenta il valore di un'attività riuscita. Aumenta però anche il potenziale impatto quando l'integrità dell'esecuzione viene compromessa.

L'exploit segnalato non ha richiesto che Cowork ricevesse più autorizzazioni di quelle previste. Avrebbe invece trasformato il livello di strumenti autenticati esistente in un'interfaccia controllata dall'aggressore.

Questo è il ribaltamento che gli acquirenti aziendali dovrebbero ricordare. Una sandbox proteggeva l'ambiente di esecuzione, ma un servizio di sincronizzazione esterno avrebbe offerto al codice una via per aggirare la propria policy di rete.

Lo stesso schema può comparire tra le piattaforme agentiche. Gli agenti in sandbox dipendono comunemente da automazione del browser, archivi di artefatti, gateway di strumenti, server MCP, broker di credenziali e runtime dei connettori.

I team di sicurezza spesso esaminano ciascun componente in modo indipendente. Gli aggressori cercano le combinazioni.

Un servizio di file apparentemente a basso rischio può diventare un proxy di rete. Un endpoint di strumenti destinato all'agente può diventare un'API di accesso ai dati per codice dannoso.

Un worker in background progettato per l'affidabilità può mantenere un attacco dopo l'interruzione dell'attività visibile. Nessuno di questi componenti deve apparire pericoloso se considerato isolatamente.

Il confronto immediato non è Microsoft contro un singolo concorrente. Il confronto più utile è tra la promessa di contenimento dell'industria e la realtà operativa degli agenti connessi.

Anthropic, OpenAI, Microsoft, Google e i fornitori di agenti di coding affrontano tutti versioni di questa tensione. I loro prodotti acquistano utilità leggendo più contesto e intraprendendo più azioni.

Il difetto segnalato in Cowork è un esempio specifico di implementazione. Non dovrebbe essere generalizzato come prova che ogni distribuzione di sandbox o MCP presenti la stessa vulnerabilità.

Tuttavia, mostra perché l'etichetta di sandbox non può fungere da valutazione completa della sicurezza. Gli acquirenti hanno bisogno di un modello del flusso dei dati che includa ogni servizio con accesso oltre il confine.

Hanno inoltre bisogno di chiarezza sulla durata dei processi. Microsoft documenta i controlli di sospensione e annullamento per le attività Cowork, ma il test di PromptArmor avrebbe rilevato che un processo in background sopravviveva all'azione di arresto visibile.

Microsoft potrebbe aver modificato questo comportamento nell'ambito della mitigazione, oppure potrebbe aver chiuso soltanto il percorso di rete. La divulgazione pubblica non spiega la correzione con questo livello di dettaglio.

Questa lacuna di verifica è importante. Le organizzazioni non possono determinare dalla cronologia pubblica se Microsoft abbia aggiunto la convalida delle destinazioni, modificato l'autorizzazione del servizio, terminato i processi in background, migliorato il rilevamento o combinato diversi controlli.

L'assenza di un advisory dettagliato non significa che la mitigazione sia fallita. Significa che i clienti devono cercare garanzie tramite indicazioni per il tenant, canali di supporto, dati di audit e test controllati.

L'architettura di sicurezza dovrebbe presupporre che un controllo preventivo prima o poi non intercetterà un pacchetto ostile. Un progetto resiliente limita quindi ciò che quel pacchetto può raggiungere e rende visibile il comportamento anomalo.

Per gli agenti connessi, ciò significa limitare le destinazioni in uscita, autenticare le richieste dei broker, associare i servizi a specifiche attività e separare l'accesso in lettura dalle autorizzazioni di azione.

Significa anche revocare le credenziali quando un'attività termina. Una sessione agente annullata dovrebbe terminare i processi correlati e invalidare qualsiasi autorizzazione temporanea creata per quell'esecuzione.

Infine, il monitoraggio deve collegare l'attività dell'agente alla telemetria di sicurezza convenzionale. Una chiamata di una Skill, un trasferimento di file, una chiamata MCP e una richiesta in uscita insolita possono sembrare innocui in console separate.

Insieme, possono descrivere una catena di attacco.

La Mitigazione Non Colma la Lacuna di Verifica

Microsoft ha confermato la mitigazione, ma i clienti non dispongono ancora di sufficienti dettagli pubblici per ricostruire l'esposizione o convalidare ogni controllo interessato.

PromptArmor afferma che Microsoft ha confermato la mitigazione del problema il 19 agosto, quasi otto settimane dopo la divulgazione iniziale. Questa tempistica indica una correzione coordinata anziché un exploit pubblico irrisolto.

Il ricercatore non ha pubblicato prove di uno sfruttamento diffuso. La dimostrazione prova un percorso tecnico in condizioni testate, non il numero di tenant effettivamente colpiti nella pratica.

Nella divulgazione non compaiono conteggi pubblici di incidenti, intervalli di versioni interessate, identificatori di vulnerabilità o indicatori di compromissione. I lettori non dovrebbero interpretare la proof of concept come prova di una violazione estesa.

Anche la conclusione opposta sarebbe prematura. Senza un advisory Microsoft dettagliato, le organizzazioni non possono presumere che l'assenza di incidenti divulgati significhi che non si sia verificato alcun uso dannoso.

L'indagine retrospettiva dipende dalla telemetria. Gli amministratori devono sapere se i log di Cowork espongono versioni delle Skills caricate, esecuzione di script, richieste ai broker, chiamate MCP e durata dei processi in background.

Microsoft afferma che l'attività di Cowork può apparire nei log di audit unificati e che le policy Purview si applicano al servizio. L'attuale documentazione amministrativa descrive inoltre controlli per plugin, modelli, uso del browser e attività automatizzate.

Questi controlli sono rilevanti, ma una copertura di audit generale non equivale a una copertura di rilevamento per questo exploit. Un log può registrare una richiesta di servizio consentita senza contrassegnarne la destinazione come ostile.

Le organizzazioni che hanno testato Cowork prima del 19 agosto dovrebbero chiedere a Microsoft quali eventi possano identificare il comportamento vulnerabile. Dovrebbero anche conservare i record di audit pertinenti prima della scadenza delle finestre di conservazione.

La revisione più importante riguarda la provenienza delle Skills. I team dovrebbero inventariare Skills personalizzate, archivi caricati, script inclusi e pacchetti condivisi dall'organizzazione utilizzati nel periodo interessato.

I pacchetti sconosciuti o non verificabili meritano la rimozione in attesa di revisione. I team di sicurezza dovrebbero confrontare gli hash crittografici dove disponibili, perché un nome di Skill familiare non stabilisce l'integrità del file.

Gli amministratori dovrebbero quindi associare ogni Skill agli utenti che l'hanno eseguita e ai dati a cui tali utenti potevano accedere. Questo produce una stima dell'esposizione più accurata rispetto alla sola scansione del testo delle Skills.

La telemetria di rete in uscita può offrire un ulteriore segnale. Richieste verso domini non familiari, intervalli di polling ripetuti o dati codificati nelle stringhe di query degli URL meritano un'indagine.

Tuttavia, le richieste segnalate transitavano attraverso un servizio esterno alla sandbox. Il monitoraggio degli endpoint sul dispositivo di un dipendente potrebbe quindi non rilevarle.

I log lato cloud e la telemetria del fornitore diventano essenziali. I clienti dovrebbero chiedere se Microsoft possa esporre l'attività, la Skill, l'utente, il tenant e la destinazione richiesta d'origine per i trasferimenti intermediati.

Le organizzazioni necessitano inoltre di una policy per i futuri caricamenti. Consentire a qualsiasi utente di importare una Skill da Internet pubblico trasforma la valutazione della fiducia in una decisione individuale.

Un modello più sicuro utilizza un registro interno con proprietà, stato della revisione, versioni approvate e date di scadenza. Le Skills ad alto rischio dovrebbero ricevere sia una revisione del codice sia test in fase di esecuzione.

Le Skills condivise necessitano di controllo delle modifiche dopo l'approvazione. Un pacchetto benigno può diventare pericoloso tramite un aggiornamento, un account del manutentore compromesso o un file complementare sostituito.

L'approvazione dovrebbe quindi applicarsi a una versione specifica, non a un nome permanente. Ogni modifica sostanziale dovrebbe essere seguita da una nuova revisione.

Questi passaggi non implicano che Cowork sia eccezionalmente insicuro. Riflettono il livello di governance appropriato per qualsiasi agente che possa accedere a e-mail, documenti, chat e applicazioni aziendali.

I knowledge worker dovrebbero inoltre mantenere il materiale sorgente sensibile all'interno di repository con ambiti chiaramente definiti. Una migliore gestione della conoscenza può ridurre l'esposizione non necessaria dei dati quando i team organizzano l'accesso attorno alle effettive esigenze di lavoro.

L'obiettivo non è rimuovere il contesto utile da ogni agente. È impedire che un comodo flusso di lavoro erediti l'intera portata digitale di un dipendente senza una revisione deliberata.

Tre Segnali Mostreranno se la Sicurezza degli Agenti Sta Recuperando

Il prossimo test sarà verificare se Microsoft trasformerà una mitigazione in controlli misurabili e visibili al tenant per ogni percorso che attraversa la sandbox di Cowork.

Il primo segnale è una spiegazione dettagliata della correzione da parte di Microsoft. I clienti devono sapere se Cowork ora convalida le destinazioni di sincronizzazione, associa le richieste allo storage approvato e termina i processi quando le attività si arrestano.

Un advisory tecnico rafforzerebbe la fiducia perché gli amministratori potrebbero testare i confini pertinenti. Il silenzio non dimostrerebbe un'esposizione continua, ma manterrebbe la verifica dipendente dai canali di supporto privati.

Il secondo segnale è una telemetria del tenant più ricca. I team di sicurezza dovrebbero osservare nuovi eventi Cowork che coprano hash delle Skills, esecuzione di script inclusi, operazioni MCP, destinazioni dei broker e processi in background associati alle attività.

Questi record devono essere utilizzabili attraverso i sistemi di rilevamento esistenti. Un registro di attività visibile soltanto all'interno di una sessione Cowork non supporterà la ricerca di minacce su scala aziendale.

Il terzo segnale è una governance delle Skills più solida. Il sistema di valutazione documentato da Microsoft descrive già controlli statici, comportamentali, avversariali, di regressione e umani a diversi livelli di rischio.

La domanda chiave è quanto coerentemente tali controlli si applichino alle Skills importate, personali, condivise e distribuite tramite store. Gli acquirenti dovrebbero cercare pacchetti firmati, approvazioni per versioni fisse, allowlist centralizzate e revoca rapida.

Microsoft dovrebbe inoltre chiarire se i file complementari di una Skill ricevono lo stesso scrutinio del suo file di istruzioni principale. Lo scenario di PromptArmor dipendeva da codice dannoso incluso, non soltanto da prosa ingannevole.

Questi segnali rafforzeranno o indeboliranno la più ampia argomentazione a favore degli agenti autonomi per il lavoro. Una migliore verifica dimostrerebbe che i fornitori trattano le Skills come componenti eseguibili della supply chain.

Una visibilità limitata lascerebbe ai clienti una quota rilevante del rischio. Verrebbe loro chiesto di fidarsi di una sandbox corretta senza vedere i confini che sono cambiati.

Per le aziende che stanno valutando Cowork ora, la risposta pratica è una distribuzione graduale. Confermate la mitigazione, limitate chi può caricare Skills, esaminate i pacchetti esistenti, riducete al minimo gli accessi e monitorate i servizi connessi.

La correzione segnalata del bypass della sandbox di Microsoft Copilot Cowork non elimina il suo monito architetturale. Gli agenti concentrano istruzioni, codice, credenziali e contesto organizzativo in un unico percorso di esecuzione.

Prima di estendere il deployment, ponetevi una domanda concreta: il vostro team di sicurezza è in grado di ricostruire ogni Skill, processo, chiamata a uno strumento e richiesta esterna che sta dietro a un'attività completata? Se la risposta non è chiara, fate di questa visibilità un requisito prima di concedere un accesso più ampio.