Kan ett mejl få er AI-assistent att lämna ut interna uppgifter

När en organisation kopplar Microsoft 365 Copilot, som Microsoft numera kallar Microsoft Copilot, eller ChatGPT till inkorgen, dokumenten och webben börjar assistenten läsa text som någon utanför organisationen har skrivit. Prompt injection är när den texten innehåller instruktioner som modellen följer i stället för det användaren bad om. Varje datakälla som kopplas på är därför också en väg in, och vad ett enda mejl i värsta fall kan få ut avgörs av vad assistenten når.

Vad är prompt injection, och varför gäller det assistenten ni redan har?

Prompt injection är inte ett fel i en enskild produkt utan en egenskap hos tekniken. Storbritanniens myndighet för cybersäkerhet, NCSC, skrev i december 2025 att dagens språkmodeller inte upprätthåller någon säkerhetsgräns mellan instruktioner och data i samma prompt. För modellen är allt text, och en mening i ett mejl kan styra svaret trots att användaren aldrig skrev den.

Den variant som berör de flesta organisationer kallas indirekt prompt injection. Angriparen skriver aldrig till assistenten. Angriparen skriver ett mejl, ett dokument eller en webbsida, och väntar på att assistenten ska läsa det åt någon annan. OpenAI beskriver i sin genomgång av prompt injection från november 2025 hur instruktionerna ofta ligger gömda i vanligt innehåll som en webbsida, ett dokument eller ett mejl, och skriver att riskerna ökar när assistenten får tillgång till mer känsliga data och tar större initiativ.

Därför spelar behörigheterna roll. Microsoft skriver i sin dokumentation om Copilot att assistenten bara visar organisationens data som den enskilda användaren har minst läsbehörighet till. Det skyddar mot att någon ser uppgifter som den personen inte har rätt till, men det betyder också att assistentens räckvidd är användarens räckvidd. Allt en medarbetare kan öppna, inklusive mappar som delats för brett för länge sedan, kan assistenten hämta in i ett svar.

Ett mejl räckte för att få ut interna uppgifter ur Copilot

Det fall som visade mönstret i en stor produkt kom 2025. Säkerhetsforskarna i Aim Labs, då en del av Aim Security, hittade en sårbarhet i Microsoft 365 Copilot som de kallade EchoLeak och rapporterade den till Microsoft. Microsoft publicerade den den 11 juni 2025 som CVE-2025-32711 och klassade den som kritisk, med 9,3 av 10 i sin egen bedömning. Den amerikanska sårbarhetsdatabasen NVD satte 7,5. Båda bedömningarna anger att angreppet varken krävde någon behörighet eller någon handling från användaren.

Aim Labs egen redogörelse, i dag publicerad av Cato Networks där forskargruppen nu ingår, beskriver mekanismen. Angriparen skickade ett mejl som var formulerat som om det riktade sig till mottagaren och som aldrig nämnde AI eller Copilot. Därför fångades det inte av Microsofts filter mot inskjutna instruktioner. När användaren senare ställde en fråga som fick Copilot att hämta in mejlet följde assistenten instruktionerna och lade de känsligaste uppgifterna den hade framför sig i en adress i svaret. Adressen hämtades automatiskt, så att uppgifterna lämnade organisationen utan att någon klickade. För det krävdes också att angriparen tog sig runt Microsofts egna spärrar mot länkar och bilder i Copilots svar. Enligt Aim Labs kunde allt i Copilots sammanhang läcka: samtalshistoriken och det assistenten hämtat från användarens mejl, filer och kanaler.

Mejlet behövde ingen egen behörighet, eftersom det lånade assistentens.

Sårbarheten är åtgärdad. Microsoft skriver att den är helt åtgärdad och att kunderna inte behöver göra något, och vid publiceringen bedömde företaget att den inte utnyttjats. Aim Labs anger att Microsoft bekräftat att inga kunder drabbats. Det som gör fallet relevant är alltså inte sårbarheten själv utan mönstret: ett mejl utifrån fick tillgång till det som fanns innanför, därför att assistenten läste båda i samma ström.

Fångar inte filtren sådant här?

Ofta, men inte alltid, och det är skillnaden som räknas. En stor öppen mätning av hur filtren håller mot en angripare som försöker på riktigt är LLMail-Inject, en tävling som Microsoft organiserade tillsammans med ISTA och ETH Zürich och som är antagen till Findings-delen av konferensen EMNLP 2026. Deltagarna fick skicka ett mejl till en simulerad e-postassistent och skulle få den att skicka ett mejl som användaren aldrig bett om, alltså få assistenten att handla och inte bara svara. Varje delnivå i tävlingen hade ett av flera skydd, och en del delnivåer hade alla på en gång. I huvudomgången, från december 2024 till februari 2025, skickade 292 lag in 370 724 försök, av vilka inte alla var angrepp.

Utfallet går att läsa åt två håll, och båda läsningarna stämmer. De allra flesta försöken fick aldrig assistenten att skicka något. Forskarna skriver att det fanns många hinder på vägen till ett lyckat angrepp, och att det gav en betydande förbättring att stapla skydden på varandra. Men omkring 7 200 inskick fick assistenten att anropa sin funktion för att skicka mejl utan att något skydd stoppade det. En angripare behöver inte lyckas ofta. Det räcker att lyckas en gång i rätt inkorg. Tävlingen gällde en simulerad assistent som kunde skicka mejl och modeller som i dag är äldre, så talen säger något om hur skydd beter sig mot ihärdiga angripare och inget om nivån i en viss produkt. Forskarna körde i efterhand angreppen ur tävlingen mot modeller som släppts senare, utan att anpassa dem, och en betydande del lyckades fortfarande.

NCSC drar samma slutsats ur själva tekniken. Myndigheten skriver att prompt injection kommer att förbli en kvarvarande risk som inte helt kan byggas bort med en produkt eller en apparat, och att den i stället måste hanteras genom hur systemet utformas, byggs och används. Microsoft säger i praktiken detsamma om sitt eget skydd. Defender for Office 365 Plan 2 upptäcker enligt Microsofts beskrivning prompt injection i inkommande mejl, men skyddet är inriktat på tre slags försök, bland annat att föra ut data via en webbadress, och Microsoft skriver själv att skydden i assistenten fortfarande behövs för det som filtret i mejlflödet inte kan se.

Vilka datakällor ska er AI-assistent få läsa?

Det bruk som gör prompt injection dyrt är inte att assistenten används. Det är att den slås på med användarens fulla räckvidd, utan att någon frågat vad den räckvidden innehåller eller vem som kan skriva i det assistenten läser. Microsoft anger att Copilot grundar sina svar på innehåll i Microsoft Graph, som mejl, chattar och dokument som användaren har behörighet till. Inkorgen följer alltså med, och den tar emot text från hela internet. Delade dokument och gemensamma kanaler kan redigeras av kunder och partner. Webbsökningen hämtar sidor som vem som helst kan ha publicerat.

Att assistenten läser inkorgen är ofta själva poängen, och därför avgör resten hur mycket ett mejl kan nå. Mycket av det som ligger inom räckhåll är ett resultat av gamla delningsbeslut. En projektyta med kundavtal som någon en gång delade med hela organisationen blir åtkomlig för varje assistent som läser åt en medarbetare, och det ändras i delningen och inte i assistenten. Microsoft erbjuder själv verktyg för det arbetet, bland annat en funktion som tillfälligt begränsar att innehåll från utvalda SharePoint-webbplatser dyker upp i sökningar och i Copilots svar medan behörigheterna gås igenom. Behörigheterna ändras inte av funktionen, bara vad som går att hitta. Administratören väljer också vilka agenter som får användas och kan påverka om webbsökningen är tillgänglig, och OpenAI ger organisationer kontroll över vilka funktioner som får användas i deras arbetsytor i ChatGPT. Samma råd ger OpenAI om sina egna agenter: där det går, begränsa agentens tillgång till bara de känsliga data som behövs för uppgiften.

Arbetet med behörigheterna verkar därför på något annat än filtren gör. Den som städar bort gamla breda delningar och bestämmer vilka agenter och kopplingar som slås på har minskat vad ett mejl kan nå, oavsett vilken teknik nästa angrepp använder för att lura assistenten. När assistenten dessutom får agera själv, skicka och boka, blir frågan en annan och större, och den behandlas i Agentisk AI: gränserna sätts i systemet, inte i prompten.

Invändningen: inställningarna hade inte stoppat EchoLeak

Det finns ett motsatt förhållande som väger tungt. Aim Labs skriver att ingen administratörsinställning och inget beteende hos användaren, så vitt forskarna vet, hade kunnat förhindra att EchoLeak utnyttjades. Det som stängde hålet var Microsofts egen rättning, gjord innan sårbarheten blev offentlig. Den som läser fallet som ett argument för att organisationen själv kan stoppa prompt injection genom att ställa in rätt har alltså läst fel.

Det finns också ett pris för att begränsa. En assistent som inte får läsa inkorgen kan inte sammanfatta inkorgen, och det kan vara just det medarbetarna vill ha hjälp med. Att stänga av källor av försiktighet kan ge en assistent som ingen använder, och då har organisationen betalat för säkerhet i form av ett verktyg som står oanvänt.

Leverantören stänger hålen, men det är ni som bestämmer hur mycket som står innanför.

Invändningen flyttar alltså frågan snarare än stänger den. Att angreppet alls var möjligt, och att uppgifterna hade en väg ut, låg hos leverantören, och det var leverantören som stängde det. Vad angreppet kunde nå var en annan sak. Enligt Aim Labs var det allt i assistentens sammanhang, alltså samtalet och det Copilot hämtat ur Microsoft Graph. Copilot hämtar enligt Microsoft bara det användaren har behörighet till, och de behörigheterna bestämmer organisationen själv över.

Hur öppen är er AI-assistent?

Två organisationer med samma licens kan ha helt olika exponering, och skillnaden syns inte i licenslistan. Ta den assistent ni använder och skriv upp varje datakälla den är kopplad till. Skriv bredvid varje källa två saker: vem utanför organisationen som kan lägga in text i den, och vad assistenten når när den läser den. De två kolumnerna kan bara ni själva fylla i.

Svaren delar upp organisationerna. Den vars assistent bara läser interna källor som ingen utomstående kan skriva i, till exempel en avgränsad kunskapsbas, har en liten yta, och kan bredda användningen i den takt arbetet kräver. Den vars assistent läser inkorgen och delade ytor med kunder, och samtidigt har breda behörigheter som ingen gått igenom, har gett varje okänd avsändare en möjlig väg till allt medarbetaren når. Den som inte kan fylla i den första kolumnen vet inte vilka vägar in som står öppna, och då är det kartläggningen som är nästa steg och inte ett nytt filter.

Samma kartläggning är utgångspunkten när AI-verktygen ni redan betalar för ska användas på riktigt: tydliga svar om vilka data som får gå vart öppnar mer användning än en försiktig avstängning gör.