Un utente sostiene di aver spinto Bing AI (Copilot) a restituire indirizzi e‑mail di dipendenti Microsoft. In questa guida analizziamo cosa significa davvero, come lo valuta il programma Microsoft AI Bounty e come preparare una segnalazione solida e conforme al MSRC.
Panoramica del caso: cosa è successo e perché è importante
Secondo la descrizione condivisa dall’utente, una sequenza di prompt avrebbe indotto Bing AI a fornire indirizzi e‑mail di dipendenti ed executive Microsoft, come se li avesse “estratti” da un ipotetico database interno. L’obiettivo dell’utente è capire se questa tecnica rientra nei criteri del programma di bug bounty di Microsoft, e quale severità potrebbe essere assegnata (importante o critica).
Il punto centrale è distinguere tra due scenari profondamente diversi, con impatti e valutazioni opposti:
- Data leakage reale (fuga di dati): il sistema espone informazioni interne, non pubbliche e verificabili, senza il consenso e al di fuori del comportamento atteso.
- Allucinazione del modello (false attribution): il sistema “inventa” indirizzi verosimili, che però non corrispondono a persone reali o non sono associati alle persone indicate.
Questa distinzione è fondamentale: una fuga di dati sensibili può rientrare nell’ambito dell’AI Bounty e condurre a una severità alta; un’allucinazione, pur essendo un problema d’affidabilità, tende a ricadere in categorie a severità inferiore o fuori ambito bounty se non dimostra impatto concreto sulla riservatezza.
Cosa ha verificato Microsoft finora
In un confronto con l’utente, un membro del team di supporto Microsoft (Johann – MSFT) ha esaminato alcuni indirizzi condivisi e li ha giudicati non autentici, sebbene parzialmente offuscati. In altre parole, i risultati riportati non costituivano prova che Bing AI avesse davvero esfiltrato dati interni: erano plausibili, ma non riconducibili a contatti reali o verificabili del perimetro aziendale. Questo non esclude in assoluto la possibilità di una vulnerabilità; significa, però, che la dimostrazione fornita non è sufficiente a classificare il caso come fuga di dati.
Alla luce di ciò, Microsoft invita a seguire la procedura di responsible disclosure attraverso i canali ufficiali MSRC. Solo dopo una revisione completa (con prove tecniche non offuscate e riproducibili) il team determinerà se sussista una vulnerabilità in ambito AI Bounty e quale severità attribuirle.
Come ragiona il Microsoft Security Response Center (MSRC) su casi AI
Il Microsoft AI Bounty Program copre vulnerabilità che compromettono confidenzialità, integrità o disponibilità di sistemi/servizi AI, inclusi scenari come:
- Esposizione di dati sensibili (es. record interni, PII aziendale) che non dovrebbero essere raggiungibili dal modello.
- Bypass di guardrail e policy di sicurezza che consentano accesso o rivelazione di contenuti protetti.
- Vettori di prompt injection o retrieval abuse che portino a comportamenti pericolosi o non previsti con impatto sulla sicurezza.
Per essere ammissibile, il ricercatore deve dimostrare che l’effetto è riproducibile e che i dati provengono da fonti interne non pubbliche o comunque non accessibili senza autorizzazione. Devono inoltre essere rispettate le regole di legalità (niente accesso non autorizzato a sistemi o account, niente diffusione pubblica di PII reali) e deve essere evitato ogni sfruttamento della falla al di là del minimo necessario alla prova.
Requisiti tipici di ammissibilità
- Riproducibilità: istruzioni passo‑passo per ottenere lo stesso risultato partendo da un profilo pulito, idealmente su più sessioni/dispositivi.
- Prove tecniche: trascrizioni dei prompt, risposte integrali (non offuscate nei canali privati), eventuali log di rete o di sistema pertinenti.
- Attributo alla sorgente: evidenza che i dati non fossero pubblici e che la loro origine sia il sistema/servizio Microsoft in esame (non un seed pre-caricato dall’utente o una fonte pubblica agganciata).
- Impatto: spiegazione chiara del rischio (es. possibilità di enumerare account, rischio di phishing mirato, danni reputazionali, esposizione su larga scala).
Fuori ambito o di severità inferiore
- Allucinazioni di e‑mail o identità non corrispondenti a persone reali o prive di correlazione verificabile con personale Microsoft.
- Contenuti ottenuti da fonti pubbliche (es. pagine web ufficiali, profili pubblici) senza alcun accesso a dati interni.
- Abusi che richiedono manipolazioni irrealistiche o accessi non consentiti per riprodursi.
Data leakage o allucinazione? Un metodo rapido per capirlo
Per orientarsi sin da subito, si può usare il seguente schema di diagnosi. Non è una classificazione ufficiale, ma aiuta a impostare il report in modo utile al MSRC.
| Domanda/Verifica | Se “Sì” | Se “No” |
|---|---|---|
| Le e‑mail restituite corrispondono a contatti reali, confermati e non pubblici? | Possibile fuga di dati → raccogli prove, procedi con MSRC. | Probabile allucinazione → focalizza il report su rischio di falsa attribuzione. |
| La risposta è riproducibile da sessione pulita, senza “insegnare” al modello i dati? | Rafforza l’ipotesi di data leakage. | Indizio di allucinazione o dipendenza da contesto iniettato. |
| L’output include pattern interni (alias, domini secondari, formati interni) non pubblici? | Segnale di potenziale sorgente interna. | Pattern generici: più probabile generazione ergonomica ma non reale. |
| È possibile estendere l’estrazione a elenco massivo (enumerazione) con prompt variati? | Impatto maggiore → possibile severità alta. | Risultati sporadici o non scalabili → impatto più contenuto. |
Come preparare una segnalazione efficace per il MSRC
Indipendentemente dal verdetto finale, la qualità del report incide sul tempo di triage e sulla valutazione dell’impatto. Ecco come procedere:
Passaggi consigliati
- Documenta il contesto: versione del prodotto/servizio (Bing AI/Copilot nel browser, app, integrazione), account utilizzato (test/consumer/enterprise), eventuali plugin o connettori abilitati.
- Raccogli prompt e risposte: conserva l’intera conversazione in ordine cronologico. Evita l’offuscamento nei materiali che invierai nel portale privato; se devi condividere in pubblico, offusca con cura.
- Dimostra la riproducibilità: ripeti il test con una fresh session, su altro dispositivo o rete, evitando di “insegnare” al modello informazioni che vuoi dimostrare siano segreti.
- Verifica l’autenticità dei dati: ove possibile, prova che le e‑mail esistono realmente e non siano pubbliche. Non contattare persone reali: limita la verifica a evidenze tecniche e fonti legittime.
- Stima l’impatto: spiega in cosa consisterebbe il rischio (enumerazione di indirizzi interni, phishing mirato, correlazione con organigrammi, ecc.).
- Proponi mitigazioni: suggerisci filtri, validazioni e controlli che avrebbero evitato l’output nocivo.
Che cosa includere nel report (MSRC Researcher Portal)
- Descrizione tecnica passo‑passo per riprodurre il comportamento.
- Prove non offuscate (allegati, testi integrali, registrazioni screen) in un canale privato.
- Valutazione dell’impatto e possibili mitigazioni.
- Eventuali limiti o condizioni (ad es. “funziona solo con questi plugin attivi”).
Template di esempio per il tuo invio
Titolo: Bing AI restituisce indirizzi e‑mail interni non pubblici in seguito a prompt X/Y Ambiente: - Prodotto/Canale: (Copilot nel browser, Copilot in Edge, ecc.) - Account: (tipo, tenant, permessi, plugin) - Data e ora del test: (UTC) - Sessione: (nuova/esistente, cronologia) Passi per riprodurre: 1. Prompt iniziale: "..." 2. Prompt di raffinamento: "..." 3. Risultato atteso vs. risultato osservato: "..." Prove: - Trascrizione completa (allegata) - Screenshot/registrazioni (allegate) - Eventuali log pertinenti Analisi: - Perché ritengo si tratti di data leakage e non di allucinazione - Come si può scalare l'extract (se applicabile) Impatto: - Tipologia di dati esposti (PII aziendale, business records) - Rischio: phishing mirato, ricognizione interna, ecc. - Estensione: singoli esempi vs. elenco massivo Mitigazioni proposte: - (Esempio) Redazione automatica dei pattern e‑mail “@microsoft.com” - (Esempio) Classificatore di PII su output LLM prima della consegna - (Esempio) Restrizioni sui connettori/strumenti in memoria
Severità: cosa aspettarsi (e cosa no)
La classificazione di gravità non è automatica e viene decisa dal MSRC dopo l’analisi completa. Detto questo, puoi orientarti con la seguente mappa informativa (non vincolante):
| Scenario | Esempio | Severità probabile (indicativa) | Note |
|---|---|---|---|
| Fuga di dati confermata, massiva | Enumerazione di centinaia/migliaia di indirizzi interni reali e non pubblici | Critica | Alto impatto su privacy e rischio di attacchi mirati; richiede prove solide. |
| Fuga di dati confermata, limitata | Pochi indirizzi reali e non pubblici ottenuti stabilmente | Importante | Impatto concreto ma non su larga scala. |
| Allucinazione plausibile | Indirizzi verosimili ma non corrispondenti a contatti reali | Moderata o Bassa | Problema di affidabilità; può restare fuori ambito se non c’è rischio reale. |
| Dati già pubblici | Recupero di e‑mail da fonti ufficiali/indicizzate | Fuori ambito o Bassa | Nessuna confidenzialità violata. |
Perché la prova “offuscata” non basta
Condividere esempi offuscati sui canali pubblici è buona prassi, ma al MSRC occorrono evidenze non offuscate in canale privato per poter verificare. Senza la possibilità di controllare l’autenticità dei dati, il team non può stabilire se si tratti di data leakage o semplice allucinazione. È comprensibile dal punto di vista privacy e triage: verificare richiede analisi della corrispondenza con anagrafiche interne o con sistemi aziendali non pubblici.
Come distinguere “Sensitive Personal Data” e “Business Records”
Nel contesto AI, indirizzi e‑mail aziendali possono rientrare in categorie che, a seconda del contesto, hanno impatti diversi:
- Sensitive Personal Data: quando l’e‑mail è associata a una persona identificabile in un contesto che accresce il rischio (es. ruoli sensibili, correlazioni con dati non pubblici).
- Business Records: quando l’informazione è legata a processi/strumenti interni e non è destinata al pubblico.
La remunerazione di un bounty dipende dal rischio dimostrato: una fuga massiva di contatti reali e non pubblici peserà più di singoli esempi o di risultati inventati.
Mitigazioni tecniche che Microsoft (o qualunque provider AI) può adottare
Se stai scrivendo la sezione “Mitigazioni” del tuo report, puoi ispirarti a queste idee:
- Riconoscimento pattern e‑mail → redaction automatica di stringhe che corrispondono a domini aziendali (es. “@microsoft.com”), con eccezioni solo per contenuti dichiaratamente pubblici.
- Classificatore di PII sull’output → blocco o mascheramento quando viene superata una soglia di rischio (es. più di N indirizzi in un’unica risposta).
- Policy di tool e connettori → se l’LLM può accedere a fonti esterne (plugin, Graph, SharePoint, ecc.), applicare least privilege, allowlist di origini e quote/limiti sulla densità di dati sensibili in risposta.
- Memoria e contesto → isolamento rigoroso tra sessioni, scadenze brevi della memoria conversazionale, controlli su context bleeding.
- RLHF/finetuning di rifiuto → addestrare il modello a rifiutare richieste di elenchi di PII o di dati potenzialmente confidenziali, con messaggi di sicurezza coerenti.
- Controlli di sicurezza in catena → applicare filtri sia pre che post generazione (dual gate), con auditing e segnali di rischio su pattern di enumerazione.
Checklist rapida per il ricercatore
- Ho verificato che gli indirizzi siano reali e non pubblici?
- Ho riprodotto da sessione pulita senza pre‑iniettare conoscenze?
- Ho raccolto e ordinato prompt e risposte integralmente?
- Ho descritto un percorso passo‑passo per il team MSRC?
- Ho stimato impatto e scalabilità (singolo caso vs enumerazione)?
- Ho proposto mitigazioni plausibili?
- Ho preparato prove non offuscate da caricare nel portale privato?
FAQ (domande frequenti)
Gli indirizzi parzialmente offuscati bastano per il bounty?
No. Per il triage il team ha bisogno di verificare che si tratti di contatti reali e non pubblici; questo richiede la versione non offuscata in canale privato.
Se il modello “inventa” indirizzi verosimili è comunque una vulnerabilità?
È un problema reale di affidabilità (falsa attribuzione), che può avere impatti reputazionali. Tuttavia, in assenza di dati autentici e non pubblici, spesso non viene classificato come data leakage e tende ad avere severità inferiore.
Se le e‑mail sono in realtà ricavate da fonti pubbliche?
In genere non rientra nel perimetro di una vulnerabilità di sicurezza. Il report dovrebbe dimostrare che la fonte non è pubblica e che l’accesso è avvenuto mediante il sistema Microsoft in modo non previsto.
Devo evitare di contattare gli indirizzi estratti?
Sì. Non contattare persone reali e non usare eventuali dati ottenuti. Limita la verifica a fonti legittime e condividi le prove esclusivamente tramite i canali privati del MSRC.
È obbligatorio proporre mitigazioni?
Non è obbligatorio, ma è fortemente apprezzato: mostra comprensione tecnica e aiuta a quantificare l’impatto, oltre a velocizzare la valutazione.
Conclusioni
Il caso descritto è emblematico della frontiera tra sicurezza e affidabilità nell’era degli LLM. Il fatto che un rappresentante Microsoft (Johann – MSFT) abbia giudicato non autentici gli indirizzi condivisi indica un’alta probabilità che si tratti di allucinazione e non di fuga di dati. Tuttavia, solo una segnalazione completa, con prove riproducibili e non offuscate nel portale MSRC, potrà stabilire la reale natura del fenomeno. Se vi fosse davvero un percorso per ottenere indirizzi interni non pubblici in modo consistente, la severità potrebbe essere da “Importante” a “Critica”, in funzione di scala, affidabilità e impatto dimostrati. In assenza di queste evidenze, il caso ricade con più probabilità in un problema di false attribution, trattato con criteri diversi e, verosimilmente, con una severità più bassa.
In sintesi: segui la responsible disclosure passando per il Microsoft AI Bounty Program e il MSRC Researcher Portal. Prepara tutto ciò che serve per consentire al team di riprodurre il comportamento, verifica l’autenticità delle e‑mail e descrivi in modo trasparente l’impatto. La classificazione finale (critica, importante, moderata, bassa) e l’eventuale ricompensa verranno decise da Microsoft sulla base delle policy del bounty e delle prove fornite.
Riepilogo operativo
- I risultati mostrati finora non dimostrano una fuga di dati: gli indirizzi condivisi sono stati giudicati non autentici.
- Il comportamento va comunque segnalato al MSRC con prove riproducibili, non offuscate e una descrizione tecnica accurata.
- La severità verrà determinata solo dopo il triage MSRC; senza dati interni reali e non pubblici, è più probabile una classificazione da allucinazione con severità inferiore.