Исследователь безопасности Фрэнк Чу обнаружил, что 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 превратила полезного помощника для ведения заметок в источник масштабной утечки данных; регулярная проверка прав доступа — единственная надежная защита.