AI meeting notetakers sell convenience. They also concentrate your calendar, attendees, and live room IDs in someone else's database. On August 4, 2026, security researcher bobdahacker published that tl;dv, the AI assistant for Zoom, Google Meet, and Microsoft Teams, left its Cloud Firestore `meetings` collection without tenant isolation. Any authenticated tl;dv user could query every meeting record on the platform. The researcher counted 181,874 meeting records across 84,312 users and 35,003 email domains. Fields included creator emails, conferencing provider, timestamps, recording status, and conference IDs that could open live rooms. Other collections such as transcripts and recordings returned authorization errors. The missing rule was the boring kind. That is why it is dangerous. More in our AI and security coverage.
What is a missing Firestore tenant isolation rule?
Tenant isolation is the rule that says a signed-in customer only reads their own org's rows. Firestore security rules exist specifically for that. According to bobdahacker, tl;dv exchanged a normal login for a Firebase token through `gw.tldv.io/v1/users/firebase/token`, then let that token query `projects/lmi-store/databases/(default)`. The `meetings` collection did not scope reads to the caller. Other collections did. That split is the whole story in miniature. Somewhere in the product's growth curve, transcripts and media blobs got the hard checks, while the scheduling index that pointed at live rooms did not.
That is not a glamorous zero-day. It is an authorization omission. Free-tier accounts counted. No privilege escalation chain was required. Once you could list meetings, you could read creator emails and conference IDs. The researcher estimated roughly 1,000 records carried a recording status at a given moment, which meant joinable live calls rather than only historical metadata. If you have ever treated a Meet or Zoom ID as a soft secret that lives in a calendar invite, you already understand why that number matters. Metadata is not "just metadata" when it is also a door.
Dark Reading and later secondary coverage corroborated the core claim that other customers' meeting data and call entry were reachable. tl;dv advertises SOC 2, GDPR, and related compliance badges. Badges do not write Firestore rules. Rules do. I keep seeing the same pattern across AI SaaS: the model layer gets the marketing spend, the datastore rules get whatever was copied from a tutorial six quarters ago, and the questionnaire still says "enterprise ready" because someone uploaded a PDF.
For operators evaluating AI notetakers, the technical ask is now blunt. Can another authenticated tenant enumerate meeting objects? Are conference IDs treated as secrets with the same discipline as OAuth tokens? Does your vendor's Firebase or Supabase project show collection-level tests in CI, or only a slide about "zero trust"? The Runtime Wire summary and Scott Armbruster's vendor-risk writeup both push the same uncomfortable conclusion. The failure mode is basic, and basic failures travel far when the product sits on every calendar.
There is also a product-design lesson buried in the numbers. 181,874 meeting records and 84,312 users are not abstract scale metrics. They are a map of who invited a bot into rooms that may have included counsel, security briefings, M&A chatter, or campus research. AI notetakers expand the attack surface sideways: one SaaS login becomes a lens onto many conference providers at once. That is convenient for sales decks. It is brutal when the index collection is wrong.
Government domains, universities, and the disclosure timeline
bobdahacker's sampling language and follow-on writeups noted .gov and university domains among the 35,003 email domains. The researcher described joining live sessions as proof of joinability, including government and campus-linked calls in the narrative. I am not repeating join steps here. The security lesson does not need a tutorial. What matters for risk owners is the blast radius class: public-sector calendars, research labs, and any org that assumed "we use a compliant AI note tool" equaled isolation.
The timeline is the second story. The researcher messaged co-founder Raphael Allstadt on January 28, 2026, emailed the CTO, and documented follow-ups into July. Public disclosure landed August 4. Company statements that later appeared in secondary coverage disputed parts of the timeline and emphasized user sharing settings for some public recordings. Readers should keep both accounts in view. The researcher's core technical claim is a missing isolation rule on one collection that other collections already had. That claim does not require you to settle every he-said-she-said about inbox responsiveness. It does require you to ask why a meetings index was still client-readable months after first contact.
Responsible disclosure fights always get muddy in public. Vendors talk about severity triage and scheduled fixes. Researchers talk about silence and still-open queries. Buyers should ignore the drama scoreboard and demand artifacts: rule diffs, notification scope, and a clear statement of whether conference IDs were rotated or invalidated where providers allow it. If the only response is a blog that thanks the researcher and restates compliance badges, treat that as incomplete.
For buyers of AI notetakers, the vendor questionnaire just got sharper. Ask whether meeting metadata is client-readable across tenants. Ask whether conference IDs are treated as secrets. Ask how long a responsible disclosure inbox actually responds. Compliance trophy walls are not the answer. If your legal team still equates SOC 2 with "no cross-tenant reads," this incident is your teaching case.
University IT and public-sector CISOs face an extra awkwardness: the tool may have been adopted bottom-up by a team that never filed a security review. Shadow SaaS is not new. Shadow SaaS that holds joinable live-call IDs is a sharper knife. Inventory bots by calendar OAuth grants, not by the official SaaS list your procurement team thinks is complete.
I reported this on January 28th, 2026. It is now July 2026. Six months later. The Firestore database is still wide open.
What operators should do this week
If your company used tl;dv during the exposure window, assume meeting metadata and live-room IDs were enumerable to other authenticated users. Rotate meeting links where your conferencing stack allows. Review whether sensitive government, legal, or HR calls ever sat on the tool. Treat the vendor as a high-risk dependency until you see a clear postmortem with rule diffs and customer notification details. Do not wait for a tidy CVE narrative. Authorization misses often never get one, and the operational risk does not care about catalog numbers.
Procurement and security architecture should move in parallel. Procurement renegotiates or exits if the postmortem is thin. Architecture inventorizes every bot that joins meetings on your behalf and asks the same Firestore-style question of each one. Otter, Fireflies, Grain, Gong-adjacent recorders, home-grown Zoom apps: different products, same class of datastore mistake waiting to happen. Zero-trust language without collection-level authorization is theater.
If you build a similar product, write tenant checks for every collection that holds joinable identifiers, not only for transcripts and media blobs. Add negative tests that prove a second tenant cannot list the first tenant's meetings. Put those tests in CI so a "temporary" rule for a demos environment cannot quietly become production. Metadata is enough to hijack a live call. The model summarizing your meeting is not the only risk. The database that schedules the bot can be worse.
One more practical cut for incident response: treat exposed conference IDs like exposed session tokens for the duration of live meetings, then like durable calendar secrets afterward. Waiting rooms, authenticated join, and rotating personal meeting IDs reduce the damage even when a third-party index leaks. Your conferencing provider's hygiene is part of the same story as the notetaker's Firestore rules.
I am filing this under AI product security with a privacy punchline. Follow Younes Bekrar in AI for more vendor-risk notes when the next notetaker's rules file gets the same kind of daylight.
Related reading on Skarvonix: our ai category, the authors directory, and more from Younes Bekrar.
Primary sources and further reading: bobdahacker tl;dv disclosure, Runtime Wire summary, Scott Armbruster vendor-risk writeup.
Frequently Asked Questions
What did bobdahacker disclose about tl;dv?
On August 4, 2026, the researcher reported that tl;dv's Firestore meetings collection lacked tenant isolation, exposing 181,874 meeting records across 84,312 users, including joinable conference IDs.
Were full transcripts and recordings exposed the same way?
According to the researcher, other collections such as transcripts, recordings, clips, and notes returned authorization errors. The core failure described was the meetings metadata collection.
When was the issue first reported?
bobdahacker says initial disclosure to tl;dv leadership began January 28, 2026, with follow-ups into July, before the August 4 public writeup.
Why do joinable conference IDs matter?
A conference ID can be a working door into a live Zoom, Meet, or Teams room. Exposed meeting metadata therefore creates real-time intrusion risk, not only a contact-list leak.
- LLMs
- Zero Trust
- Privacy
