Дослідник безпеки Френк Чу виявив, що tl;dv — сервіс для створення нотаток на зустрічах на базі ШІ, який інтегрується з Zoom та Teams — допустив витік 181 874 приватних транскриптів зустрічей через відсутність одного правила безпеки Firebase, що дозволило будь-якому авторизованому користувачу прочитати весь набір записів. Витік зачепив 84 312 користувачів у 35 003 доменах, нагадуючи про те, що незначна помилка в конфігурації може розкрити найконфіденційніші корпоративні розмови.

Як стався витік

tl;dv зберігає нотатки в базі даних Firestore від Google Firebase. У Firestore розробники пишуть правила безпеки, які визначають, хто може читати або записувати кожен документ. Більшість колекцій tl;dv були належним чином захищені, але в колекції meetings бракувало правила, яке перевіряє особу запитувача. Результат був простим: щойно користувач входив у додаток, API повертав список усіх документів зустрічей, що зберігаються в сервісі.

Тут не було складних експлойтів, шкідливого коду чи зламу самої моделі ШІ. Уразливість була класичною помилкою контролю доступу — відсутнім рядком коду, який мав би звучати так: «переглядати цю зустріч можуть лише власник або запрошені учасники». Через відсутність правила будь-який автентифікований користувач міг перелічити та завантажити кожен транскрипт, незалежно від статусу запрошення.

Чому це важливо

Транскрипти зустрічей часто містять обговорення в залах засідань, дорожні карти продуктів, юридичні поради та переговори щодо продажів. Коли ці слова стають доступними для публічного читання, конкуренти можуть збирати стратегічну інформацію, юристам, можливо, доведеться переглядати зобов'язання щодо конфіденційності, а працівники втрачають довіру до інструментів, якими користуються. Сотні тисяч записів роблять це системним збоєм, який може зачепити будь-яку організацію, що впровадила tl;dv без ретельного вивчення моделі дозволів.

Затримка у реагуванні

Чу повідомив про відсутнє правило команді tl;dv у січні. Виправлення — додавання належного обмеження на читання та повторне розгортання набору правил — було застосовано лише в серпні. Шестимісячний проміжок між виявленням та усуненням уразливості є незвично довгим для проблеми, яка надає необмежений доступ на читання до чутливих даних. Затримка підкреслює прогалини в процесі управління вразливостями компанії: від сортування до розгортання патчів.

Ширший урок для агентів на базі ШІ

Цей інцидент часто трактують як «ризик ШІ», проте першопричиною є традиційна помилка контролю доступу. ШІ-агенти — чи то транскрибують зустрічі, чи пишуть чернетки електронних листів, чи резюмують документи — працюють із привілеями сервісних облікових записів, що дозволяють їм мати доступ до тих самих даних, що й звичайний користувач. Коли ці привілеї є надто широкими, ШІ стає каналом для витоку даних так само легко, як і будь-який інший бекенд-сервіс.

Що організації можуть зробити вже сьогодні

  • Аудит логіки авторизації – переконайтеся, що кожна колекція бази даних, кінцева точка API або бакет хмарного сховища, що використовуються ШІ-інструментом, забезпечує перевірку за принципом найменших привілеїв. Шукайте відсутні або надто дозволяючі правила, подібні до того, що пропустили в tl;dv.
  • Обмеження сфери запису – налаштуйте агента для ведення нотаток так, щоб він фіксував лише ті зустрічі, які ви явно дозволили. Налаштування «запис за замовчуванням» розширює поверхню атаки; моделі з вибором користувача (opt-in) обмежують зону ризику.
  • Ставтеся до ШІ-агентів як до сервісних облікових записів – каталогізуйте кожну сторонню інтеграцію ШІ, призначайте їй окрему ідентифікацію та надавайте лише ті дозволи, які необхідні для виконання її функцій. Регулярно перевіряйте та анулюйте невикористовувані облікові записи.
  • Стрес-тестування правил безпеки – запускайте автоматизовані тести, які намагаються прочитати дані з колекцій без належних облікових даних. Включайте ці перевірки в конвеєри CI/CD, щоб виявити відсутнє правило ще до розгортання.
  • Прискорення реагування на інциденти – встановіть чіткі терміни для підтвердження, сортування та усунення виявлених вразливостей. Шестимісячний період усунення, як у цьому випадку, є провалом у процесах, що може посилити наслідки звичайної помилки.

На що звернути увагу далі

Підприємства, які покладаються на ШІ-асистентів для ведення нотаток на зустрічах, підбиття підсумків дзвінків або транскрипції в реальному часі, мають очікувати на подібні помилки конфігурації в інших хмарних сервісах. Оскільки ШІ-агенти стають дедалі глибше інтегрованими в щоденні робочі процеси, межа між «ризиком ШІ» та «традиційним ризиком безпеки» розмивається. Стежте за переглядом дозволів, вимагайте від постачальників прозорого аудиту правил безпеки та наполягайте на швидких циклах оновлень, щоб запобігти черговому інциденту з «одним відсутнім правилом», який призведе до витоку чергової купи конфіденційних розмов.

Підсумок: Безпека інструментів ШІ настільки ж висока, наскільки надійні засоби контролю доступу, що захищають дані, з якими вони взаємодіють. Одне пропущене правило Firestore перетворило корисного помічника для нотаток на масштабний витік даних; регулярно перевірені дозволи — це єдиний надійний захист.