Notion ujawnia wyciek transkryptów czatów AI po incydencie u dostawcy Fireworks AI - Security Bez Tabu

Notion ujawnia wyciek transkryptów czatów AI po incydencie u dostawcy Fireworks AI

Cybersecurity news

Wprowadzenie do problemu / definicja

Notion poinformował o incydencie bezpieczeństwa związanym z zewnętrznym dostawcą infrastruktury AI, który doprowadził do ujawnienia części transkryptów rozmów prowadzonych z Notion AI. To kolejny przykład ryzyka łańcucha dostaw w ekosystemie sztucznej inteligencji, gdzie dane użytkowników są przetwarzane nie tylko przez dostawcę końcowej aplikacji, ale również przez partnerów odpowiedzialnych za inferencję modeli, klasyfikację danych i obsługę funkcji pomocniczych.

W skrócie

Według przekazanych informacji incydent objął mniej niż 1% workspace’ów. Źródłem problemu nie był bezpośredni kompromis środowiska Notion, lecz naruszenie po stronie Fireworks AI, wykorzystywanego do obsługi części funkcji Notion AI. Ujawnione dane obejmowały transkrypty czatów używane przez funkcję Insights.

Notion podkreślił, że większość zapisów miała charakter „nieprzypisywalny”, czyli była pozbawiona metadanych jednoznacznie wskazujących autora, workspace lub organizację. Po wykryciu incydentu firma odłączyła integrację z dostawcą, usunęła dane z jego środowiska, wyłączyła funkcję Insights oraz zaleciła użytkownikom rotację haseł, kluczy API i innych sekretów, jeśli zostały wpisane do czatów.

Kontekst / historia

Sprawę należy analizować w szerszym kontekście bezpieczeństwa usług GenAI i zależności od podmiotów trzecich. Notion korzystał z Fireworks AI w dwóch obszarach: do realizacji części zadań klasyfikacyjnych związanych z funkcją Insights oraz jako dostawcy inferencji dla wybranych modeli open-weight dostępnych w produkcie.

Z ujawnionych informacji wynika, że 2 listopada 2026 r. Notion otrzymał od dostawcy pierwsze powiadomienie o nieautoryzowanym dostępie do niewielkiego zbioru danych, który początkowo miał zawierać wyłącznie syntetyczne dane testowe. Do 3 listopada firma odcięła komunikację z Fireworks AI i usunęła dane ze środowiska partnera. Następnie 6 listopada pojawiła się kolejna informacja, że incydent mógł objąć również dane klientów. 8 listopada dostawca potwierdził nowy zestaw danych, a analiza wykazała obecność transkryptów czatów Notion AI. 11 listopada Notion poinformował dodatkowo o unieważnieniu ujawnionych kluczy API wykrytych podczas dochodzenia.

Analiza techniczna

Z technicznego punktu widzenia incydent dotyczył danych przetwarzanych w modelu współdzielonym przez zewnętrznego dostawcę AI. Ujawnione transkrypty pochodziły z datasetu używanego przez funkcję Insights, która miała zapewniać administratorom wgląd w sposób korzystania z AI przez zespoły.

Kluczowe znaczenie ma charakter ujawnionych danych. Notion wskazał, że w większości przypadków transkrypty nie były bezpośrednio powiązane z tożsamością użytkownika ani identyfikatorem workspace’u. Ogranicza to ryzyko natychmiastowej atrybucji, ale go nie eliminuje. Sama treść rozmowy może zawierać informacje umożliwiające identyfikację osoby, projektu, klienta, architektury środowiska czy procesu biznesowego.

Firma zaznaczyła również, że transkrypty nie zawierały wyników wywołań narzędzi. To istotne rozróżnienie, ponieważ może oznaczać, że wyciek nie objął części danych pobieranych dynamicznie z innych systemów. Nadal jednak wysokie pozostaje ryzyko ekspozycji danych wpisywanych bezpośrednio przez użytkowników do interfejsu AI, takich jak fragmenty kodu, dane projektowe, tokeny, sekrety czy opisy incydentów.

Incydent pokazuje też praktyczny problem deklaracji typu „zero data retention”. Nawet jeśli dostawca komunikuje brak retencji danych, w rzeczywistych procesach operacyjnych mogą powstawać zbiory pośrednie związane z testami, klasyfikacją, telemetrią, debugowaniem lub analizą użycia. To właśnie takie zasoby stają się atrakcyjnym celem dla atakujących i jednocześnie trudnym obszarem do pełnego nadzoru po stronie klienta.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko dotyczy poufności informacji przekazywanych do asystentów AI przez użytkowników biznesowych. W wielu organizacjach narzędzia tego typu służą do streszczania dokumentów, analizowania kodu, generowania treści operacyjnych i pracy na danych wewnętrznych. Jeśli w rozmowach znalazły się hasła, tokeny API, dane dostępowe, informacje o klientach, szczegóły architektury systemów lub dane regulowane, skutki mogą wykraczać daleko poza sam wyciek treści czatu.

  • kompromitacja sekretów i konieczność ich natychmiastowej rotacji,
  • ekspozycja informacji wrażliwych biznesowo,
  • możliwość wtórnych ataków phishingowych i socjotechnicznych,
  • naruszenia wymagań compliance i ochrony danych,
  • trudności audytowe związane z ustaleniem pełnego zakresu danych przekazanych do zewnętrznego pipeline’u AI.

W praktyce nawet „nieprzypisywalne” transkrypty mogą mieć wysoką wartość wywiadowczą. Wystarczy, że użytkownik umieścił w rozmowie nazwę klienta, logi aplikacyjne, strukturę sieci, stack technologiczny lub opis wewnętrznego procesu, aby dane stały się użyteczne dla przeciwnika.

Rekomendacje

Organizacje korzystające z narzędzi AI w środowiskach produkcyjnych powinny potraktować ten incydent jako sygnał do przeglądu kontroli bezpieczeństwa dla usług opartych na modelach zewnętrznych.

  • zweryfikować, czy organizacja lub użytkownicy otrzymali powiadomienie o potencjalnym wpływie incydentu,
  • przeanalizować, jakie transkrypty mogły zostać ujawnione,
  • natychmiast zrotować hasła, tokeny, klucze API i inne sekrety, które mogły znaleźć się w czatach,
  • sprawdzić logi użycia poświadczeń pod kątem anomalii i nieautoryzowanych prób dostępu,
  • wdrożyć politykę zakazującą wklejania sekretów, danych klientów i materiałów regulowanych do asystentów AI bez odpowiednich zabezpieczeń,
  • ograniczyć zakres danych przekazywanych do zewnętrznych dostawców AI zgodnie z zasadą minimalizacji,
  • wymagać od dostawców pełnej przejrzystości w zakresie retencji, telemetrii, datasetów pośrednich i podprocesorów,
  • objąć narzędzia AI klasyfikacją ryzyka dostawców trzecich oraz regularnymi przeglądami bezpieczeństwa.

Z perspektywy architektonicznej warto rozważyć dodatkowe mechanizmy ochronne, takie jak DLP dla promptów, redakcję danych wrażliwych przed wysłaniem do modelu, separację tenantów, kontrolę egressu do dostawców AI oraz centralne rejestrowanie użycia usług GenAI. W środowiskach o podwyższonych wymaganiach bezpieczeństwa uzasadniona może być także migracja do modeli hostowanych prywatnie lub do rozwiązań z gwarantowanym przetwarzaniem w dedykowanej infrastrukturze.

Podsumowanie

Incydent związany z Fireworks AI i Notion pokazuje, że bezpieczeństwo rozwiązań AI należy oceniać nie tylko przez pryzmat aplikacji końcowej, ale całego łańcucha przetwarzania danych. Nawet szybkie odłączenie integracji i działania ograniczające skutki zdarzenia nie zmieniają faktu, że wyciek transkryptów czatów może prowadzić do ujawnienia sekretów, danych operacyjnych i poufnej wiedzy biznesowej.

Dla organizacji najważniejszy wniosek jest jasny: trzeba ściśle kontrolować, jakie dane trafiają do zewnętrznych modeli, gdzie są przetwarzane i jak długo mogą pozostawać dostępne poza podstawowym środowiskiem usługi.

Źródła

  • https://www.bleepingcomputer.com/news/security/notion-says-fireworks-breach-exposed-customer-ai-chat-transcripts/
  • https://www.notion.com/security/advisories/security-incident-involving-a-third-party-ai-vendor-nov9
  • https://www.notion.com/help/security-incident-involving-a-third-party-ai-vendor
  • https://www.bleepingcomputer.com/news/security/fireworks-ai-discloses-new-breach-after-cloud-provider-hack/