Fireworks-breach ramte Notion. Kender I jeres AI-underleverandører?

MA Martin Mensbo Christiansen · 12. november 2026 · 9 min læsning

Nærbillede af frakoblede, gennemsigtige netværksstik i pink og blåt lys

Notion bekræftede den 10. og 11. november, at et brud hos AI-leverandøren Fireworks AI eksponerede Notion AI-chattransskriptioner fra under 1 procent af Notions arbejdsrum. De fleste danske virksomheder har aldrig hørt om Fireworks. Det er netop pointen. Når I slår AI til i et værktøj som Notion, sendes jeres medarbejderes prompts ofte videre til leverandører, I aldrig selv har valgt, og som I ikke har en aftale med. Mængdemæssigt er sagen lille. Men den peger på et svagt led, der findes i næsten alle SaaS-værktøjer med indbygget AI: underleverandøren.

Vi har læst Notions egen redegørelse og Fireworks' sikkerhedsbulletin samt Googles trusselsanalyse om LLMjacking, der udkom få dage før. Gennemgangen herunder samler, hvad der skete, hvorfor løftet om zero data retention ikke beskyttede chattene, og hvad I konkret bør gøre med jeres AI-underleverandører. Formålet er at give jer et grundlag at handle på, uanset om I bruger Notion eller et helt andet værktøj.

Hvad skete der hos Fireworks AI og Notion?

Fireworks AI er en af verdens mest brugte platforme til AI-infrastruktur. Den kører åbne modeller og baggrundsjob for titusindvis af kunder. Notion brugte Fireworks til to ting: som generel inferensudbyder for open-weight-modeller inde i produktet, og til de klassifikationsjob, der ligger bag funktionen Insights, som giver administratorer et overblik over teamets AI-brug.

Da Notion den 8. november fik udleveret det datasæt, angriberne havde haft adgang til, viste det sig at indeholde Notion AI-chattransskriptioner fra Insights. For langt de fleste berørte arbejdsrum var de, med Notions ord, uden mærkning af, hvem der havde skrevet dem, eller hvilket arbejdsrum de kom fra, og uden resultater fra værktøjskald. Beskyttelsen holder kun, så længe medarbejderne ikke selv har skrevet navne, kundedata eller adgangskoder direkte i chatten. Notion har slået Insights fra under undersøgelsen, er holdt op med at bruge Fireworks til open-weight-modeller og har kontaktet de berørte kunder. Har I ikke hørt fra Notion, har de ikke fundet jeres arbejdsrum blandt de ramte.

Tidslinjen: fra stjålne nøgler til eksponerede chats

Bruddet voksede i flere omgange. Fireworks opdagede den 6. oktober, at interne loginoplysninger var blevet misbrugt, og oplyste i første omgang den 10. oktober, at angriberen havde fået fat i miljøvariabler, altså API-nøgler og tokens, i et begrænset antal kundekonti. Den 23. oktober blev en tredjeparts cloududbyder, der husede Fireworks' forsknings- og udviklingsmaskiner, kompromitteret. Dagen efter brugte angriberen den adgang til at nå Fireworks' udviklingsmiljø og køre et uautoriseret arbejdsforløb, der ramte flere kundedata. Fireworks har ikke set ny uautoriseret adgang siden den 25. oktober.

Ifølge uafhængig dækning hos The Hacker News omfattede de berørte data ressourcemetadata, faktureringsoplysninger som adresser, fakturaer, betalingshistorik og saldo, og for visse kunder en delmængde af ufærdige modelvægte og datasæt. Betalingskortnumre opbevares ikke af Fireworks og var ikke ramt. På Notions side løb forløbet fra den 2. november, hvor Notion fik besked om adgang til syntetiske testdata, over afbrydelse og sletning den 3. november, til den endelige bekræftelse af kundedata den 8. november og kontakt til de berørte den 9. november.

Fireworks er oven i købet certificeret efter SOC 2 Type 2, ISO 27001, ISO 27701 og ISO 42001. Et certificeret led i kæden blev altså alligevel ramt. Certificeringer fortæller, at en leverandør har styr på sine processer, men de fjerner ikke risikoen, og de siger intet om, hvad der sker, når leverandørens egen underleverandør bliver angrebet.

Hvorfor zero data retention ikke er hele sandheden

Fireworks oplyser, at selskabets inferens, Training SDK og produktet Nexus kører med zero data retention som standard og ikke blev ramt. Alligevel lå der Insights-transskriptioner i det eksponerede datasæt. Forklaringen ligger i, hvad zero data retention faktisk dækker. Løftet gælder den løbende inference, hvor en prompt behandles og straks glemmes. Insights byggede derimod på klassifikationsjob, og det er præcis den slags batch- og analysedata, der kan ligge lagret, selv når realtidsinferensen ikke gemmer noget.

Den skelnen er vigtig for enhver, der køber AI ind via et SaaS-produkt. Zero data retention er et kontraktløfte om bestemte typer behandling, ikke en teknisk garanti for, at jeres data aldrig ligger noget sted hos en underleverandør. Spørg derfor konkret: dækker løftet også analyse-, klassifikations- og evalueringsjob, og hvor længe gemmes datasæt til træning og batchkørsler? Det er ikke nok at få et ja til zero data retention på forsiden af en aftale. I skal vide, hvilke arbejdsgange det gælder. Sagen er dermed også en påmindelse om, at databeskyttelse i AI handler om hele kæden af behandlinger, ikke kun om det første kald.

LLMjacking: når stjålne AI-nøgler bliver en forretning

Fireworks kobler angrebet til en økonomisk motiveret kriminel gruppe, der sælger adgang til sprogmodeller videre gennem ulovlige routing-gateways. Mønstret har fået navnet LLMjacking, og det forklarer, hvorfor angriberne gik efter loginoplysninger og datasæt frem for noget andet. Det handlede om at kunne videresælge modeladgang.

Google beskrev mønstret indgående den 2. november. Ifølge Google Threat Intelligence Group og Mandiant kaprer angriberne virksomheders adgang til sprogmodeller med stjålne nøgler eller eksponerede endepunkter. I enkelte sager løb de svigagtige cloudregninger op over 100.000 dollar på en enkelt dag, og i nogle tilfælde nåede den samlede regning 1 million dollar, før adgangen blev lukket. De stjålne nøgler samles i det, Google kalder LLM Mixers, altså gateways, der videresælger adgangen til undergrundsabonnenter. En af dem kørte mere end 500.000 kald på under otte timer og sendte tæt på en million dollar i tokenomkostninger videre til offeret, mens tjenesten selv solgte ubegrænset adgang for omkring 60 dollar om måneden.

Pointen for jer er dobbelt. En stjålen API-nøgle er ikke kun et databrud, den er også en regning, der kan vokse eksplosivt på timer. Og en AI-gateway uden stramme grænser er netop det, angriberne leder efter. Derfor er forbrugslofter og snævre nøglerettigheder noget af det første, I bør have på plads.

Er I ramt? Sådan tjekker I det

Bruger I Notion, så start med at få bekræftet, om jeres arbejdsrum-ejer har modtaget en mail fra Notion. Er I blandt de berørte, kan I gennemgå de eksponerede transskriptioner sikkert inde i arbejdsrummet, og I bør behandle dem som eksponerede. Har nogen indsat adgangskoder, API-nøgler eller andre hemmeligheder i Notion AI i perioden, skal de udskiftes med det samme.

Men sagen er kun ét eksempel i en bølge af angreb mod AI-forsyningskæden. Vi har tidligere beskrevet, hvordan en falsk udvidelse plantede en bagdør i et udviklingsværktøj, hvordan AI-værktøjer er blevet en ny angrebsflade, og hvad virksomheder kan lære af et supply chain-brud. Det fælles træk er, at risikoen flytter ud til leverandører og værktøjer, som den enkelte virksomhed sjældent har kortlagt. Gå derfor jeres vigtigste SaaS-værktøjer igennem, dokumentation, CRM, support og mødenoter, og noter for hver af dem, hvilke modeller og inferensplatforme der ligger bag AI-funktionerne.

GDPR: dataansvar, underdatabehandlere og 72-timers-reglen

I en opsætning som denne er den danske virksomhed dataansvarlig. Notion er databehandler, og Fireworks er underdatabehandler. Indeholder de eksponerede chats personoplysninger, skal den dataansvarlige vurdere, om der er sket et brud på persondatasikkerheden. Er der det, skal det som udgangspunkt anmeldes til Datatilsynet uden unødig forsinkelse og om muligt senest 72 timer efter, at man er blevet bekendt med bruddet, efter artikel 33 i databeskyttelsesforordningen. De 72 timer er kalendertimer, så weekender og helligdage tæller med. Selv hvis I vurderer, at bruddet ikke skal anmeldes, skal I kunne dokumentere den vurdering.

Sagen er også en test af artikel 28 om databehandlere. Underdatabehandlere skal godkendes, og jeres databehandleraftale skal give jer ret til at vide, hvilke AI-underleverandører en tjeneste bruger. Mange standardaftaler nøjes med en generel liste og en ret til at gøre indsigelse. Det holder dårligt, når AI-funktioner tilføjer nye underleverandører hurtigt. Er I omfattet af NIS2, bør I desuden se hændelsen som et lærebogseksempel på leverandørkæderisiko. Vores guide til AI Act og compliance gennemgår, hvor de forskellige krav rammer.

Hvad danske virksomheder bør gøre nu

Her er en håndfuld konkrete tiltag, som de fleste organisationer kan sætte i gang med det samme:

Lav en liste over underdatabehandlere for AI-funktionerne i jeres vigtigste SaaS-værktøjer, og hold den opdateret. Den er lige så vigtig som listen for selve produktet.
Spørg leverandørerne, om zero data retention også dækker analyse-, klassifikations- og evalueringsjob, og hvor længe datasæt gemmes. Få svaret på skrift.
Indfør en klar regel om, at adgangskoder og følsomme persondata aldrig indsættes i en AI-chat, og brug secret scanning, hvor det kan lade sig gøre.
Sæt forbrugsloft og projektbegrænsning på alle AI-API-nøgler, så en stjålen nøgle ikke kan løbe op i en ubegrænset regning. Giv hver nøgle så få rettigheder som muligt.
Hav en proces klar til 72-timers-vurderingen, så I kan handle hurtigt, hvis en leverandør melder om et brud, der kan ramme jeres persondata.

Ofte stillede spørgsmål

Er vores Notion-arbejdsrum ramt?

Har I ikke hørt fra Notion, har de ikke identificeret jeres arbejdsrum blandt de ramte, og der er ikke noget, I skal gøre lige nu. Er I berørt, får arbejdsrum-ejeren en mail med instruktioner. I kan så gennemgå de eksponerede transskriptioner inde i arbejdsrummet og bør udskifte alle adgangskoder og nøgler, der er indsat i Notion AI i perioden.

Hvad er zero data retention, og hvorfor beskyttede det ikke chattene?

Zero data retention betyder, at leverandøren behandler jeres prompt og svar uden at gemme dem bagefter. Det gælder den løbende inference. Insights-transskriptionerne kom fra klassifikationsjob og datasæt, ikke fra realtidsinferens, og derfor var de ikke dækket. Spørg altid jeres leverandør, hvilke arbejdsgange zero data retention konkret omfatter.

Hvad er LLMjacking?

LLMjacking er, når angribere kaprer en virksomheds adgang til sprogmodeller med stjålne nøgler og videresælger adgangen gennem ulovlige gateways. Ofret betaler regningen. Ifølge Google er der set svigagtige regninger på over 100.000 dollar om dagen og op til 1 million dollar i alt, før adgangen blev lukket.

Skal vi anmelde sagen til Datatilsynet?

Indeholder de eksponerede data personoplysninger, og er der en risiko for de registrerede, skal I som dataansvarlig som udgangspunkt anmelde bruddet til Datatilsynet senest 72 timer efter, at I er blevet bekendt med det, efter artikel 33. Vurderer I, at anmeldelse ikke er nødvendig, skal I kunne dokumentere vurderingen.

Hvordan undgår vi, at en stjålen API-nøgle løber op i en kæmpe regning?

Sæt forbrugsloft på hver API-nøgle, giv nøglen adgang til så få modeller og miljøer som muligt, rotér nøgler jævnligt, og slå phishing-resistent multifaktorgodkendelse til. Overvåg samtidig for pludselige spring i forbrug, som er det første tegn på LLMjacking.

AI-forsyningskæden har fået lag, som de færreste virksomheder har tegnet et kort over. Jeres leverandører bruger underleverandører. Det gør de alle. Det, I har brug for at vide, er hvem de er, og hvad de kan komme til at ligge inde med, hvis de bliver ramt. Fireworks-sagen er en billig lektie, så længe I bruger den til at gennemgå jeres egen kæde, inden den dyre version rammer.

Fortsæt læsningen

Anthropics officielle grafik for Claude Mythos.