Are AI Meeting Notetakers Safe? What to Check

One missing access rule exposed 181,874 meetings. The vendor questions and internal controls that actually reduce your exposure.

Cecilia Iona
Cecilia Iona
Senior Editor, AI & Product
16 August 20261 min read

AI meeting notetakers are safe in the same way any multi-tenant SaaS is safe: entirely dependent on one boring implementation detail that you cannot see from the outside. The question is not whether the vendor encrypts data at rest, which they all do. It is whether every single database collection enforces tenant isolation, because missing it on exactly one is enough.

That is not a hypothetical. In August 2026, security researcher BobDaHacker published a disclosure about tl;dv, an AI notetaker for Zoom, Google Meet and Teams. One collection in the company's Firestore database had no tenant isolation rule. Any authenticated user could query meeting records belonging to every other customer.

What went wrong at tl;dv, precisely

The exposure covered 181,874 meeting records across 84,312 users and 35,003 email domains. The exposed fields included creator emails, meeting timestamps, and conference IDs, which are the joinable room identifiers for Google Meet and Teams calls. Roughly 1,000 meetings were in a recording state at any given moment, meaning their identifiers pointed at calls that were live.

The detail that matters most for anyone evaluating a vendor is this one, in the researcher's own words: tl;dv "already do it correctly for every other collection (users, chats, transcripts, clips, recordings, videos, notes, teams, organizations all return 403)." The meetings collection was the single exception.

So this was not a company that ignored security. It was a company that got it right nine times and wrong once, and once was enough to make a transcription service used by more than two million people into a searchable index of other organisations' calls. Affected domains reportedly included government meetings across 23 countries and universities including Berkeley and the University of Tokyo, according to Dark Reading's coverage.

The disclosure timeline is the other half of the lesson. The researcher reported it in January 2026 and followed up repeatedly. It was still reachable in July. tl;dv acknowledged the flaw publicly in early August.

The pre-install checklist this actually justifies

Generic vendor security advice tells you to check for SOC 2. tl;dv-shaped failures are invisible to that. Here is what to ask instead, derived from how this specific thing broke.

Question to ask

What a good answer looks like

Why it maps to this failure

Do you run automated tests for cross-tenant access on every collection or table?

Yes, in CI, and they fail the build

The bug was one unenforced rule among ten

What is your published disclosure process and median time to fix?

A security.txt or dedicated address, plus a stated SLA

Six months of unanswered follow-ups

Are meeting join identifiers treated as secrets?

Yes, never returned to unauthorised users

Conference IDs were in the exposed payload

Can we disable recording retention entirely?

Yes, configurable per workspace

Limits blast radius when isolation fails

Who inside your company can read customer transcripts?

A named, small, audited group

Insider access is the quieter version of the same risk

Controls that do not depend on trusting the vendor

The uncomfortable truth is that you cannot verify tenant isolation from outside. So put the weight on controls you own.

  • Set a retention limit and enforce it. A notetaker that keeps 90 days of calls has a smaller worst case than one that keeps three years. Most tools support this and most teams never touch the setting.

  • Keep the bot out of the meetings that matter. Legal, HR, security incidents, board conversations, anything under NDA with a third party. This is a calendar convention, not a technical control, and it works.

  • Announce the recorder every time. Two-party consent laws are real in several jurisdictions, and an AI notetaker that joins silently is a compliance problem before it is a security one.

  • Audit who is connected. Notetakers usually attach through a calendar OAuth grant. Review those grants quarterly and revoke the ones nobody remembers approving.

  • Assume transcripts are discoverable. If a conversation would be damaging in a subpoena, it should not be transcribed by anything.

The blunt version: treat every AI notetaker as though its contents will eventually be readable by someone you did not authorise, and decide what you are willing to put in it on that basis.

So are AI meeting notetakers safe enough to use?

For most internal meetings, yes. The productivity gain from automatic transcripts and action items is real, and the realistic risk for a routine standup is low. The failure mode is not "notetakers are dangerous," it is "teams install one, grant it calendar-wide access, never set retention, and forget it is in the room."

The gap between those two states is about twenty minutes of configuration.

FAQ

Was the tl;dv data actually stolen?

The researcher demonstrated that the records were queryable by any authenticated user. Public reporting documents the exposure and its scope. Whether an unauthorised party also accessed it is a separate question that only tl;dv's logs can answer.

Do AI notetakers train on my meeting transcripts?

It depends entirely on the vendor and the plan tier, and the answer changes. Check the specific data processing terms rather than the marketing page, and re-check after any ownership change.

It depends on jurisdiction. Several places require all-party consent. The safe practice is to announce the recorder at the start of every call and to let anyone object before it captures anything.

What is the single highest-value setting to change?

Retention. Shortening how long transcripts are stored reduces the size of every future incident, and it costs you nothing on a meeting you already read the notes for.

For more on the surrounding risks, see how to check if an AI tool trains on your data, a practical way to vet an AI vendor, what to do if an AI tool leaks your data, and the wider map of AI risks worth taking seriously.

How did this land?

About the author

Cecilia Iona
Cecilia Iona

Senior Editor, AI & Product

Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.