AI Notetaker tl;dv Left 181,000 Business Meetings Exposed

30-Second Summary

Independent security researcher bobdahacker disclosed that tl;dv, one of the most widely used AI meeting notetakers for Zoom, Google Meet, and Microsoft Teams, left 181,874 meeting records accessible to any authenticated user on its platform. The cause was a missing security rule in the platform's cloud database that allowed any logged-in user to list and read meetings from every other organisation on the service. The researcher reported the flaw to tl;dv in January 2026. After more than six months of follow-ups with no fix applied, the researcher published the findings publicly in August 2026. During testing, the researcher joined live business and government meetings uninvited by impersonating an AI notetaker bot, succeeding in roughly 80 percent of attempts.

At a Glance

• Topic: AI Security
• Company: tl;dv
• Date: Publicly disclosed August 2026
• Announcement: Security researcher published findings after six months of ignored responsible disclosure
• What Changed: tl;dv's Firestore database had no tenant isolation on its meetings collection, exposing all records to any signed-in user
• Why It Matters: AI meeting tools attend sensitive business conversations. A breach of this type puts confidential client, legal, and strategy sessions at risk across tens of thousands of organisations.
• Who Should Care: Any business using AI meeting notetakers for Zoom, Google Meet, or Microsoft Teams

Key Facts

• Company: tl;dv
• Vulnerability Disclosed to Vendor: January 28, 2026
• Publicly Disclosed: August 2026
• What Changed: Firestore meetings collection lacked tenant isolation, making all records readable by any authenticated user
• Scale of Exposure: 181,874 meetings from 84,312 users across 35,003 domains
• Who It Affects: Any organisation whose meetings were recorded by tl;dv during the exposure period
• Primary Source: bobdahacker (independent security researcher), corroborated by Dark Reading and Hacker News

What Happened

Security researcher bobdahacker discovered that tl;dv's cloud database contained a critical misconfiguration. When a user authenticated to tl;dv, the platform issued a Firebase token that granted read access to the meetings collection across all tenants on the service, not just the user's own organisation. Most collections in the database enforced correct account boundaries. The meetings collection was the exception.

The researcher first reported the issue to tl;dv on January 28, 2026, through standard responsible disclosure. After repeated follow-ups over six months with no fix applied, the researcher published the findings publicly in August 2026.

The exposure went beyond archived transcripts. The researcher was able to identify active sessions and join live meetings uninvited by requesting access as an AI notetaker bot. This approach succeeded in approximately 80 percent of tested cases. Live sessions entered during testing included a government education institute meeting with more than 150 participants and a corporate session in which product development work was being shared on screen.

The technical cause was a single missing configuration rule in Firestore. The fix required no architectural change, only a security rule that scoped collection access to the authenticated user's tenant. The six-month delay between disclosure and public reporting meant businesses across 35,003 domains were exposed without any notification or opportunity to respond.

Why It Matters

• AI meeting notetakers are now present in the most sensitive conversations most businesses have. They attend client negotiations, legal briefings, HR discussions, and strategy sessions where no written record would otherwise exist.
• The tl;dv flaw required no hacking skill to exploit. Any paying subscriber could have accessed meeting records from any other organisation on the platform using normal authentication.
• A six-month gap between responsible disclosure and public reporting signals that many AI SaaS vendors have not built security operations practices commensurate with their growth or the sensitivity of the data they hold.
• The researcher accessed live government and corporate meetings in real time, not just stored archives. This means conversations were observable as they happened.
• Businesses across 35,003 domains were affected. This is mainstream SMB adoption territory, not a niche user base.
• The flaw was a single missing configuration line, which makes the extended exposure period difficult to justify and raises questions about the maturity of the vendor's security review processes.

The David and Goliath View

Most business operators assume that signing up for a reputable AI SaaS tool means their data is protected by default. The tl;dv breach is a direct challenge to that assumption. The platform had users across more than 35,000 domains, was integrated into three of the most widely used video conferencing platforms in the world, and was trusted with some of the most sensitive conversations those businesses had. A single missing database rule made all of it readable to any other subscriber.

For operators running organisations of 10 to 200 people, the exposure is asymmetric. A large enterprise typically has a security team that reviews vendor contracts, assesses data handling architectures, and monitors breach disclosures. A smaller business usually relies on the vendor's reputation and assumes the product is safe. That assumption is now a documented liability.

The practical shift is to treat AI tool procurement the same way you would treat hiring a new team member with access to everything. Ask where data is stored, how it is isolated from other customers, what the vendor's incident response process looks like, and whether they operate a formal responsible disclosure programme. If a vendor cannot answer those questions clearly in writing, that difficulty is itself the answer. Start this review with your meeting notetaker, then extend it to every other AI tool with access to your calendar, email, or internal communications.

Where This Fits in the AI Stack

Secure AI Brain: The tl;dv breach illustrates exactly what happens when AI tool adoption outpaces data governance. A Secure AI Brain approach means verifying, rather than assuming, that vendors enforce tenant isolation, maintaining a register of which AI tools have access to which systems, and establishing clear procurement criteria before any tool is connected to sensitive business conversations.

Questions Operators Are Asking

Is my business affected if we use tl;dv? If your organisation used tl;dv at any point during the exposure period, your meeting recordings may have been accessible to other authenticated users. Contact tl;dv directly and ask for written confirmation of when the flaw was introduced, when it was resolved, and whether any unauthorised access to your account's data has been detected. Until you receive a satisfactory response, treat recordings stored on the platform as potentially compromised.

How do I know if any of my meetings were accessed? Access logs for cloud databases are typically not available to end users, which means individual organisations are unlikely to be able to determine whether their meetings were viewed. This is precisely why transparent vendor disclosure and audit logging matter. Ask tl;dv specifically for an incident report covering the January to August 2026 period.

Does this affect other AI meeting tools? This specific misconfiguration is unique to tl;dv, but the underlying category of risk applies across the AI notetaker market. Tools such as Otter.ai, Fireflies, and others should be subject to the same scrutiny. Ask each vendor to explain their tenant data isolation architecture and whether they have undergone independent security testing.

Should I stop using AI meeting tools entirely? Not necessarily. These tools offer genuine productivity benefits, particularly for capturing decisions and reducing meeting administration. The answer is to use them selectively, restrict access to the most sensitive sessions, and vet vendors before connecting them to your business systems. The risk is not inherent to the category; it is a function of poor security practices at specific vendors.

What should I do in the next 48 hours? List every AI tool that currently has access to your calendar. Review which meetings your notetaker attended in the past 90 days and identify any sessions involving client confidentiality, legal matters, or competitive strategy. Contact your vendor and ask for written confirmation that your data is isolated from other tenants. Document the response and set a review date in 30 days to follow up if the answer is unsatisfactory.

Citable Summary

What happened: Security researcher bobdahacker publicly disclosed that tl;dv's Firestore database had no tenant isolation on its meetings collection, exposing 181,874 meetings from 84,312 users across 35,003 domains to any authenticated user, including live calls that the researcher was able to join uninvited.

Why it matters: AI meeting notetakers hold some of the most sensitive conversations in any business, and most operators have no visibility into how that data is stored or who can access it, making inadequate vendor security a direct and unmanaged business risk.

David and Goliath view: Smaller organisations that rely on vendor reputation rather than independent security verification are most exposed to this category of risk. Treating AI tool procurement as a governance decision, not a software subscription, is now an operational necessity.

Offer relevance:

• Secure AI Brain: Directly relevant. This breach illustrates why structured AI tool governance, verified tenant data isolation, and clear vendor security criteria are foundational requirements before any AI tool is connected to sensitive business systems.