Badacz bezpieczeństwa Frank Chu odkrył, że tl;dv — usługa tworzenia notatek ze spotkań oparta na AI, integrująca się z Zoom i Teams — wyciekła 181 874 prywatne transkrypcje spotkań z powodu braku jednej reguły bezpieczeństwa Firebase, co pozwalało każdemu zalogowanemu użytkownikowi na odczytanie całego zestawu rekordów. Wyciek dotknął 84 312 użytkowników w 35 003 domenach, co stanowi przypomnienie, że drobny błąd w konfiguracji może narazić najbardziej poufne rozmowy korporacyjne.

Jak doszło do wycieku

tl;dv przechowuje notatki w bazie danych Firestore firmy Google Firebase. W Firestore programiści tworzą reguły bezpieczeństwa, które decydują o tym, kto może odczytywać lub zapisywać każdy dokument. Większość kolekcji tl;dv została poprawnie zabezpieczona, ale w kolekcji meetings brakowało reguły sprawdzającej tożsamość osoby żądającej dostępu. Wynik był prosty: po zalogowaniu się do aplikacji API zwracało listę wszystkich dokumentów dotyczących spotkań przechowywanych przez usługę.

Nie było tu wyrafinowanego exploita, złośliwego ładunku ani naruszenia samego modelu AI. Luka była klasycznym przeoczeniem w kontroli dostępu — brakującą linią kodu, która powinna brzmieć: „tylko właściciel lub zaproszeni uczestnicy mogą przeglądać to spotkanie”. Z powodu braku tej reguły, każdy uwierzytelniony użytkownik mógł wyliczać i pobierać każdą transkrypcję, niezależnie od statusu zaproszenia.

Dlaczego to ma znaczenie

Transkrypcje spotkań często zawierają debaty zarządu, mapy drogowe produktów, porady prawne i negocjacje handlowe. Gdy te słowa stają się publicznie dostępne, konkurenci mogą pozyskiwać strategiczne informacje, prawnicy mogą być zmuszeni do ponownego przeanalizowania zobowiązań do zachowania poufności, a pracownicy tracą zaufanie do narzędzi, na których polegają. Setki tysięcy rekordów sprawiają, że jest to awaria systemowa, która może dotknąć każdą organizację, która wdrożyła tl;dv bez dokładnego sprawdzenia modelu uprawnień.

Opóźnienie w reakcji

Chu zgłosił brakującą regułę zespołowi tl;dv w styczniu. Naprawa — polegająca na dodaniu odpowiedniego ograniczenia odczytu i ponownym wdrożeniu zestawu reguł — została wprowadzona dopiero w sierpniu. Sześciomiesięczne okno między wykryciem a naprawą jest niezwykle długie w przypadku luki, która zapewnia nieograniczony dostęp do odczytu wrażliwych danych. Opóźnienie to uwypukla luki w procesie zarządzania podatnościami w firmie, od triażu po wdrażanie poprawek.

Szersza lekcja dla agentów opartych na AI

Incydent ten jest często przedstawiany jako „ryzyko związane z AI”, jednak przyczyną źródłową jest tradycyjny błąd w kontroli dostępu. Agenci AI — niezależnie od tego, czy transkrybują spotkania, tworzą szkice e-maili czy podsumowują dokumenty — działają z uprawnieniami konta usługowego, które pozwalają im na dostęp do tych samych danych, co użytkownikowi-człowiekowi. Gdy uprawnienia te są zbyt szerokie, AI staje się kanałem wycieku danych równie łatwo, jak każda inna usługa backendowa.

Co organizacje mogą zrobić już dziś

  • Audytuj logikę autoryzacji – Zweryfikuj, czy każda kolekcja bazy danych, punkt końcowy API lub bucket pamięci masowej w chmurze używany przez narzędzie AI wymusza sprawdzanie zasady najniższych uprawnień. Szukaj brakujących lub zbyt szerokich reguł, takich jak ta, która umknęła w tl;dv.
  • Ogranicz zakres nagrywania – Skonfiguruj agenta do robienia notatek tak, aby rejestrował tylko te spotkania, na

Podsumowując: Narzędzia AI są tak bezpieczne, jak mechanizmy kontroli dostępu, które chronią dane, z którymi pracują. Jedna pominięta reguła Firestore zmieniła przydatnego asystenta do robienia notatek w potężny wyciek danych; regularnie testowane uprawnienia to jedyna niezawodna obrona.