tl;dv Security Breach: What It Means for Anyone Building or Using an AI Notetaker

A recently disclosed flaw in the AI meeting assistant tl;dv let any signed-in user access others' meeting records. It's worth investigating what went wrong, because the lesson applies to every tool in this category. As users, you must understand how to judge the tools you trust with your private calls.

If your company uses an AI notetaker, it sits in some of your most sensitive conversations: hiring calls, board updates, customer deals, and legal discussions.

That access is the entire value of the product. It's also the entire risk.

So when a security researcher demonstrates that one of these tools exposed meeting data across its whole user base, you must slow down to understand exactly what happened and why.

What was disclosed

In early August 2026, security researcher BobDaHacker (subsequently reported by Dark Reading) laid out critical flaws in the AI meeting assistant tl;dv. According to them, any authenticated tl;dv user could query a database collection containing meeting records belonging to other customers across the service.

By the researcher's own count, the exposed collection held 181,874 meeting records across 84,312 users and 35,003 domains. The exposed .gov domains alone pointed to meetings convened by governments of 23 different countries, including the United States, Japan, Brazil, Ukraine, Malaysia, Qatar, and Israel.

A few of the other meeting records originated from the University of Berkeley and the University of Tokyo, along with corporate domains like Mitsui-Soko, HubSpot, Confluent, and Mekari.

The exposed records were metadata rather than full transcripts, but the metadata was revealing on its own. Per the reporting, a meeting record could show:

• The meeting creator's email address
• Which conferencing provider hosted the call (Google Meet, Microsoft Teams, and so on)
• Timestamps and whether recording was active
• A conference identifier that could be used to enter Google Meet or Teams rooms

After identifying a call, the researcher was able to join meetings they were never invited to, including meetings hosted by the Malaysian Ministry of Education and students of a US university building a startup.

Roughly 1,000 records could be marked as actively recording at any given time, effectively turning the collection into a real-time directory of live calls.

On the timeline, the reporting is specific and unflattering. The issue was first reported to tl;dv in late January 2026, followed by repeated messages over the following months, and was still live when the story was published on August 4, 2026.

Why it happened

tl;dv is built on Google's Firebase/Cloud Firestore, an architecture where the user's browser can talk more or less directly to the database.

In that model, the thing standing between one customer's data and another's is a set of security rules; configurations that tell the database who is allowed to read what.

Get those rules right on a collection, and tenants are isolated. But miss them on a collection, and any authenticated user can read across everyone.

According to the reporting, that's exactly the shape of the failure.

Most of tl;dv's collections, including transcripts, recordings, chats, and user and team data, did enforce isolation correctly. The meetings collection was the exception. It was missing the rule that scoped reads to the requesting user's own organization.

Authentication still worked, since the system correctly checked that you had a valid account. It just didn't check whether the specific records you asked for were yours.

Security people have a name for this: broken object level authorization (BOLA). Knowing who someone is (authentication) is not the same as enforcing what they're allowed to see (authorization).

When the second check is missing, even on a single collection, a valid account becomes a key to everyone's meeting room.

The two things buyers should take away

1. Ask where authorization is enforced.

The uncomfortable property of the browser-talks-to-database model is that tenant isolation depends on configuration being correct on every collection, every time.

There's often no second layer catching a miss. One collection without the right rule, and the data is reachable.

So the question you should ask any vendor isn't "Are you secure?" because everyone says yes. Instead, ask:

• Where in your architecture is authorization enforced, and what happens if a developer forgets a check?
• If a researcher emails your security team right now, who responds, and by when?

The answers tell you whether their safety depends on never making a mistake, or on a design that catches mistakes.

2. Watch how they respond to disclosure.

A vulnerability is a moment in time. The response is a signal about the organization.

BobDaHacker’s responsible disclosure report went unanswered for months while the issue stayed open in production. It’s a statement about how security is prioritized.

When you're trusting a tool with your confidential meetings, that posture is as important as the code.

What this means for AI notetaker vendors

The tl;dv disclosure is a cheap lesson if you learn it on someone else's product. If you build in this category, here’s what it should prompt you to check before a researcher checks it for you.

1. Don't let tenant isolation depend on getting configuration right every single time.

If one missing rule on one collection can expose everyone, your security depends on never making a mistake. Pick an architecture where authorization is a mandatory step for every request, and make sure you update rules as your data grows or collection changes. This way, a forgotten check fails rather than silently opening a door.

2. Keep authentication and authorization separate in your code and in your thinking.

Confirming someone has a valid account does not confirm they may see the specific record they asked for. BOLA is one of the most common ways apps leak data because the two get conflated.

3. Audit every collection, endpoint, and object type, not only the obvious ones.

In the tl;dv case, most collections were isolated correctly, and a single one was not. The exception is what gets you. An attacker needs only one gap, so your coverage has to be exhaustive.

4. Stand up a disclosure process before you need it.

A monitored security inbox, a named owner, and a commitment to acknowledge reports quickly cost very little to set up and pay off enormously when a researcher reaches out. The most damaging part of this story was not only the bug but the months of silence while the issue remained active.

5. Treat metadata as sensitive.

Even without transcripts, knowing who is meeting whom, when, and whether a call is being recorded is a meaningful leak, especially for government and enterprise customers. Protect it accordingly.

How HappyScribe is built

Because we work in the same category, it's fair to ask how we approach the exact risk at the center of this story.

At HappyScribe, your browser never talks directly to our database. Every request goes through our backend, which decides what you're allowed to see before any data is returned. Authorization isn't a configuration file sitting next to the data. Rather, it's a step every request has to pass through.

Three properties are key here, and they're deliberately layered so that no single mistake removes the protection:

• Authorization is enforced at the framework level, deny-by-default. Access has to be explicitly granted per resource, per action, per role. The default answer is no.
• A forgotten check fails loudly. If a developer ships an action without an authorization check, the request is rejected rather than allowed through. A missing check is an error, not an open door.
• The same enforcement covers every path to your data. Web app, API, and the data our AI notetaker produces all run through the same authorization layer. No side door skips it.

No one should claim that a system can never have a bug. That's the kind of promise this whole story is a warning about.

What we can say is that our design goal is defense in depth, so that safety doesn't hinge on any one config file being perfect. It’s a different foundation than a single rule on a single collection separating tenants.

If you'd like to learn more about how HappyScribe protects your meetings, get in touch with us, and we’ll be happy to give you a walkthrough.

The takeaway

AI meeting tools are only as trustworthy as the boundaries between one customer's data and the next.

The tl;dv security breach is a clear, public example of what happens when that boundary depends on a single configuration being right, and of why response failure compounds the damage.

If you use any tool in this space, it's a good moment to ask it two questions: where is authorization enforced, and how do you handle a security report. The answers are more revealing than any feature list.

Sources:

• BobDaHacker's original security research, “tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open”
• Dark Reading, "AI Notetaker Lets Hackers Spy on Government, Corporate Video Calls"