AI meeting assistants are becoming normal participants in business calls, government briefings, customer meetings, interviews, and internal strategy sessions. They join calls, record audio and video, generate transcripts, summarize decisions, and store searchable meeting history.
That convenience comes with a serious risk: if the notetaker’s backend authorization fails, the tool can become a directory of private conversations.
A recent disclosure involving tl;dv, an AI meeting assistant, shows exactly how dangerous that can be. According to Dark Reading, a Google Firebase misconfiguration allowed authenticated tl;dv users to query meeting information belonging to other users and potentially join calls they were never invited to.
What Happened
Security researcher BobDaHacker found that tl;dv users were assigned a session ID that allowed unusually broad access to the app’s backend Google Firebase / Cloud Firestore environment. Most sensitive collections, such as transcripts and recordings, reportedly had tenant isolation in place. The weakness was in the meetings collection, where authorization rules did not properly restrict users to their own organization’s records.
That meant a valid tl;dv account could query meeting records across the service.
The exposed records did not automatically contain every transcript or recording. But they could reveal highly sensitive metadata, including meeting creator email addresses, conference provider, timestamps, recording status, and conference identifiers that could be used to locate live or past meetings.
This is a classic authorization failure: the system checked that the user was logged in, but failed to enforce which records that user was allowed to read.
Why This Is So Serious
Meeting metadata is not harmless.
A conference ID, host email, timestamp, and recording status can reveal who is meeting, when they are meeting, which platform they are using, and whether a call is active. In sensitive environments, that can be enough to support espionage, social engineering, meeting intrusion, or targeted phishing.
According to Dark Reading, the researcher was able to identify live calls and join some meetings by appearing as an AI notetaker. Some meetings were publicly open, while private meetings often accepted the bot-like participant when it requested entry.
That is the uncomfortable reality of AI notetakers: people often stop questioning them.
When a bot joins a meeting, participants may assume someone else invited it.
Government and Corporate Calls Were Exposed
The scale of the exposure was significant.
A separate analysis summarizing BobDaHacker’s findings reported 181,874 meeting records across 84,312 users and 35,003 domains. The exposed government domains reportedly included meetings from governments in 23 countries, including the United States, Japan, Brazil, Ukraine, Malaysia, Qatar, and Israel.
Dark Reading also reported that records included meetings tied to large corporations and universities, including HubSpot, Mitsui Fudosan, UC Berkeley, and the University of Tokyo.
In a smaller sample of more than 27,000 meeting IDs, the researcher found that more than 1,000 exposed invitee emails and call transcripts were on the open Internet.
That turns the issue from a backend configuration mistake into a real confidentiality problem.
The Root Cause: Broken Object-Level Authorization
The vulnerability was not caused by a complex exploit.
It was caused by missing tenant isolation on one backend collection.
In Firebase and Cloud Firestore-based applications, security rules are critical because client applications can interact directly with backend data. If rules are correctly scoped, users can only access records belonging to their own account or organization. If one collection is missed, that collection can become globally readable to every authenticated user.
Security teams often call this class of issue Broken Object-Level Authorization, or BOLA.
In simple terms: knowing who the user is does not automatically mean they should see every object they request.
Authentication answers: “Who are you?”
Authorization answers: “Are you allowed to access this specific record?”
The second check is what failed.
Why AI Notetakers Are High-Risk Tools
AI notetakers are not ordinary SaaS apps.
They sit inside conversations where people discuss sales pipelines, government projects, hiring decisions, legal strategy, customer contracts, product plans, security incidents, and financial information.
Many notetakers also connect to calendars, contacts, conferencing platforms, transcripts, recordings, and internal search. Dark Reading notes that these bots can become silent participants with deep access to an organization’s communication layer.
That means the security bar should be high.
A failure in an AI notetaker does not only leak app data. It can leak the context of an organization’s private decisions.
The Human Factor: Bot Blindness
This incident also highlights a social problem.
People have become used to seeing AI bots in meetings. A participant list with multiple notetakers no longer feels unusual. Sometimes bots join on behalf of absent users. Sometimes users forget they enabled automatic recording. Sometimes organizations allow external bots without a clear approval process.
That creates “bot blindness.”
Attackers can abuse this by joining meetings with names or avatars that look like common AI notetakers. If participants do not challenge the bot, a stranger may be able to listen silently.
The technical vulnerability exposed the meeting directory, but the human tendency to accept unknown bots increased the practical risk.
What Organizations Should Do
Organizations using AI notetakers should treat them as sensitive third-party systems, not convenience tools.
Important actions include:
- review which AI notetakers are allowed in company meetings
- disable automatic bot joining unless needed
- require explicit approval before bots can record
- restrict external AI notetakers in sensitive meetings
- make meeting lobbies mandatory for external participants
- train employees to challenge unknown bots
- default recordings and transcripts to private
- review sharing settings for transcripts and recordings
- ask vendors where tenant authorization is enforced
- ask vendors how security reports are handled
- audit integrations with calendars, contacts, and conferencing tools
The safest default is simple: sensitive meetings should not allow unexpected AI bots.
What AI Notetaker Vendors Must Learn
Tenant isolation must be enforced consistently across every backend collection, API, and sharing path. One missed Firestore rule can expose the entire customer base.
AI notetaker vendors should implement:
- strict tenant-scoped authorization rules
- automated tests for every database collection
- backend-side authorization checks, not only client assumptions
- logging for cross-tenant query attempts
- rate limits on meeting-record lookups
- security review of public and internal APIs
- rapid vulnerability intake and response
- clear customer notification processes
- default-private meeting data
- stronger controls for public transcript sharing
Security cannot depend on users setting the right privacy option after the fact.
Final Thoughts
The tl;dv case is a warning about the hidden risk of AI meeting assistants.
These tools are useful because they sit close to sensitive conversations. That is also why they are dangerous when authorization fails.
A single backend misconfiguration allowed meeting records across governments, companies, universities, and organizations to become queryable by authenticated users. In some cases, that information could be used to join live calls or find exposed transcripts.
AI notetakers are now part of the security boundary. Organizations should manage them like privileged communication tools, and vendors must prove that every meeting, transcript, recording, and metadata record is isolated by design.
