An AI notetaker is software that many people never think about as a security surface. It joins a call, listens, writes down what was said, and files the transcript away. In early August 2026, reporting on the AI notetaker tl;dv turned that assumption into a case study, describing a tenant isolation gap that reportedly let any authenticated user browse meeting records belonging to other customers, including meetings tied to government bodies in 23 countries. This piece lays out what was reported, explains the underlying security concept in plain terms, and draws a vendor-neutral lesson for anyone evaluating AI tools that sit inside company meetings.
A note on framing before the details: this is an educational piece about a class of vulnerability, not a verdict on one company's intentions. The available reporting describes an exposure, not confirmed malicious exploitation, and that distinction is preserved throughout.
What was reported
According to Dark Reading, which published its account on August 4, 2026, and the independent researcher who goes by bobdahacker and first found the issue, tl;dv's backend had a Google Cloud Firestore database configured without a proper boundary between customers. In a well-isolated multi-tenant system, a logged-in user's queries are scoped so they can only ever touch their own organization's records. Here, that scoping was reportedly missing at the data layer itself, which meant the restriction that should have stopped one customer from reading another customer's data was not enforced where it needed to be.
The scale described in the reporting is large: roughly 181,874 meetings across about 84,312 users and 35,003 domains, including meeting records connected to government bodies in 23 different countries. The exposed data reportedly included meeting metadata and live conference IDs, the identifiers used to join an active call, which raises the additional possibility of unauthorized entry into an in-progress meeting rather than only after-the-fact record access. Separately, the reporting describes an internal employee directory that was reportedly reachable through an unauthenticated API, a distinct issue from the tenant boundary problem but one that points at the same underlying pattern of an access control gap.
Roughly six months from first report to public disclosure
Timeline as reported by Dark Reading (Aug 4, 2026) and the researcher who found the flaw. Dates mark reported milestones, not confirmed exploitation.
Independent researcher bobdahacker privately disclosed the missing tenant boundary to tl;dv.
The researcher says multiple follow-up messages were sent chasing a fix and a response.
Reporting describes follow-ups continuing through July with the issue still unresolved.
Dark Reading published the findings, stating the flaw remained unpatched at time of publication.
On the disclosure side, the timeline reported is straightforward to state and worth sitting with. The researcher says the flaw was first reported to tl;dv on January 28, 2026, with repeated follow-up attempts through July. Dark Reading's August 4 report states the vulnerability remained unpatched at the time of publication, roughly six months after the initial report. None of the sourced reporting claims to have confirmed active, malicious exploitation of the exposed data; what is documented is that the exposure existed and was reachable by any authenticated account.
What tenant isolation actually means
"Multi-tenant" describes any SaaS product where one shared set of servers and one shared database serve many separate customer organizations at once. It is the normal, efficient way to build software at scale, and it works well when the system enforces a hard rule: every read and every write is checked against which tenant the requesting user belongs to, on every single object, every single time. That rule is tenant isolation.
The failure mode described in the tl;dv reporting is a familiar one in application security, sometimes called broken object-level authorization: the application checks that a user is logged in, but does not separately check that the specific record they are asking for belongs to them. Document databases like Firestore make this mistake easy to introduce, because their security rules are configured separately from the application code, and a rule that is permissive by default, or scoped at the wrong level, can quietly grant read access across every tenant in the system while every other part of the product looks and behaves completely normally.
Tenant isolation has to be enforced at the data layer, on every object, every time. A login check is not the same thing, and a UI that hides other tenants' data is not the same thing either.
The core lesson from a document-database misconfiguration
Why AI notetakers concentrate the risk
Every SaaS category has a version of this risk, but AI meeting tools sit in an unusually sensitive spot. A notetaker does not just store one field of customer data; it aggregates full transcripts, recordings, calendar context, and the list of every participant across every meeting an organization holds, often for months at a time. Some products, as this case illustrates, also hold live conference identifiers that function as a key to an active call. A single tenant isolation gap in that category does not leak a name or an email address; it can expose the substance of what an organization actually discussed, at scale, across its entire meeting history. That is a meaningfully different blast radius than a typical account-data breach, and it is why the category deserves scrutiny beyond the usual "is my password safe" question. This is not specific to one vendor: any AI meeting tool, Metir included, has to treat tenant isolation as a foundational requirement rather than an assumed byproduct of building on a managed cloud database.
A vendor-neutral checklist
For anyone evaluating or building an AI meeting product, a few questions are worth asking directly rather than assuming the answer:
- Is authorization enforced at the data layer, per object, not just in the UI? A frontend that only shows a user their own meetings is not isolation if the backend API would happily return someone else's meeting to a direct request.
- Is access least-privilege by default? New database rules and new API endpoints should start locked down and be opened deliberately, not the reverse.
- Are live call credentials treated as secrets? A conference ID that lets anyone join an active meeting is functionally a password and should be handled with the same care.
- Is there transcript and access logging? Organizations should be able to ask "who accessed this meeting's data" and get a real answer.
- Is there a real coordinated-disclosure process? A published security contact and a track record of timely patching are cheap to verify and tell you a lot about how a vendor will behave under pressure.
The instructive part
Reasonable people can debate how the underlying flaw came about. What is documented and harder to dispute is the gap between report and fix: a vulnerability reported on January 28, 2026, followed by repeated outreach through July, still described as unpatched when Dark Reading published on August 4. That multi-month window, on its own, is the most concrete data point available here, and it is the part of this story that generalizes to any vendor: a fast, transparent response to a credible security report is not a nice-to-have, it is a core part of the product.
Sources:
- AI Notetaker Spy Government, Corporate Video Calls | Dark Reading
- tl;dv hack writeup | bobdahacker
- Inside the tl;dv Flaw That Exposed Live Government and Corporate Meetings | Netizen
Image credits
Header image: a screen displaying dozens of video-call participants during the 10th virtual Ukraine Defense Contact Group meeting at the Pentagon, March 15, 2023, used illustratively to depict a large multi-participant video conference and not as a depiction of the tl;dv incident. Photograph by the U.S. Secretary of Defense (Flickr / DoD), CC BY 2.0, via Wikimedia Commons. In-body image: server racks in a data center at The National Archives (UK), used illustratively to depict cloud backend infrastructure, CC BY 3.0, via Wikimedia Commons.