How to Stop AI Notetaker Bots from Joining Your Meetings: A Practical Guide for Zoom, Teams, and Meet

How to Stop AI Notetaker Bots from Joining Your Meetings? A Practical Guide for Zoom, Teams, and Meet

Ten minutes into a meeting, a name nobody recognizes suddenly appears in the participant list: Fireflies.ai Notetaker. Nobody invited it. The rhythm of the conversation breaks, and someone asks the question you've been dreading—who is this? And where is the recording going?

This isn't an isolated case. As AI meeting note tools proliferate, more and more Notetaker bots are joining meetings automatically without explicit permission. The good news: most of these bots can be blocked—but it takes a multi-layered strategy, not a single toggle.

Why a Single Blocking Method Doesn't Work

To understand how to stop AI notetaker bots, you first need to know how they get in. According to technical analysis of the source platforms, bots enter meetings through four main paths: calendar auto-join (automatically attempting entry when a scheduled event begins), invited addresses or links (someone added the bot's address to the invitation), marketplace integrations (connecting via official interfaces like the Zoom Meeting SDK), and web client automation (unofficial tools that drive the Zoom Web App).

Each path has a different interception point. Calendar auto-join needs to be turned off in the bot's own settings, invited addresses need domain-level control at the platform layer, marketplace integrations need admins to block specific apps in the backend, and web client automation is handled by built-in platform protections.

There's also a key limitation to state upfront: blocking bots is not the same as blocking recordings. Otter's desktop app and Chrome extension can record without a bot, and Fireflies, Fathom, and tl;dv also offer or promote bot-free modes. No meeting platform setting can detect these tools. For them, you need a recording policy, not a blocklist.

Meeting notetaker bot refers to a category of AI tools that automatically join video meetings as independent participants, transcribe in real time, and generate meeting summaries. Representative products include Otter.ai, Fireflies.ai, Fathom, tl;dv, and others. They typically begin by having the user authorize access to their calendar and email, then monitor schedules and automatically join a few minutes before a meeting starts under the name "Notetaker" or something similar, finally syncing transcripts, summaries, and action items back to the user's account or CRM. For enterprises, this convenience brings privacy and governance risks—a bot appearing in the participant list makes other attendees wary of "who is recording," and it may also trigger local recording-consent laws.

Host Settings: A Platform-by-Platform Walkthrough

Zoom: Waiting Room + Login Requirements

Zoom offers relatively rich controls. Hosts can enable the waiting room under Settings > Meeting > Security, then choose who needs to wait. The option "users not in your account and not part of whitelisted domains" lets people from known domains enter directly while blocking everyone else.

Additionally, Zoom supports requiring participants to sign in before joining, restricting participation by email domain, and managing which Marketplace apps can join meetings. When an unfamiliar name appears in the waiting room, simply deny it; if it's already inside, select "More" in the participant list and then remove it.

Microsoft Teams: Detect and Block

Teams handles external bots by automatically flagging them upon detection and holding them in the waiting room, "regardless of the meeting's waiting room configuration," requiring explicit approval from the organizer to join. This is the default behavior and requires no extra setup.

Microsoft recommends restricting who can admit people from the waiting room—only allowing organizers and co-organizers to do so, preventing presenters from accidentally admitting a bot. If a real guest is mistakenly flagged as a bot, approving them and selecting "This is not a bot" resolves it, but that action only applies to the current meeting.

Google Meet: Access Type Control

Meet doesn't have a dedicated bot filter, but it does offer access type settings. Set the access type to "Trusted" (people in the organization plus external guests invited via calendar links) or "Restricted" (only guests invited via calendar and people invited on the spot by the host), and uncheck "Anyone with the meeting link can request to join."

Enabling Host Management ensures only hosts and co-hosts can remove participants and approve knock requests, and also turn on "Hosts must join before others."

Webex and GoTo

Webex's waiting room feature groups waiting participants into internal, external, and unverified categories, allowing bulk operations. Admins can block external users by domain in Control Hub. Note that Webex's waiting room is not available in Meetings for Linux.

GoTo achieves a similar effect by locking the meeting—once locked, joiners go to the waiting room, and they connect automatically when it's unlocked. For suspicious participants already inside, the organizer can right-click and select "Dismiss" to remove them.

Waiting Room is an admission control mechanism offered by video conferencing platforms: once enabled, participants don't enter the main meeting directly but are first placed in a separate area, where the host or co-host approves or denies them one by one. It's the preferred method for blocking unknown bots because it shifts the default from "trust" to "verify"—even if a bot successfully initiates a join request via calendar or link, it must be manually admitted to get in. The waiting room's granularity can be configured by domain, login status, or internal/external grouping—for example, letting only organization members in directly, letting known partner domains in directly, and making everyone else wait. The trade-off is that the host must keep an eye on the waiting room, or external guests will be left standing outside.

Persistent Admin-Level Controls

The problem with host settings is this: once the host forgets, the defense disappears. Admin controls take that decision out of the host's hands.

Zoom allows admins to block specific Meeting SDK apps, and its bot blocking dashboard shows which apps are attempting to join or have been blocked. Waiting room defaults can be set at the account level.

Microsoft Teams's bot handling is a meeting policy-level setting, configured in the Teams admin center > Meeting policies > Meeting join and waiting room, corresponding to the ExternalBotAccessMode parameter in PowerShell. The default value RequireApprovalWhenDetected means a bot requires approval to join after being detected. Additionally, a policy in progress will automatically block recognized external bots, but the specific PowerShell parameters for that feature have not yet been confirmed in official documentation.

Webex offers a "Block external users from selected email domains" option in Control Hub under Services > Meeting > Settings, which requires also enabling "Require all sites to provide participant email addresses" to function properly. The documentation does not explain how bots without email addresses are handled.

Organization-Level Checklist

Based on the above analysis, a complete defense plan should include the following steps:

• Inventory connected tools: List the note-taking apps employees are using, as well as the calendar and OAuth apps authorized by your identity provider
• Move from blocklists to allowlists: Blocklists only cover names you already know. Zoom's Meeting SDK allowlist and Webex's approved email domains are better approaches
• Set defaults that don't depend on the host: Teams' detect-and-hold, Meet's host management, Zoom's login requirement
• Restrict calendar and OAuth authorization: Auto-join begins when users connect their calendars; restricting this authorization cuts off the source of the path
• Publish a brief internal policy: Clearly state approved tools, notification requirements, and the process for handling objections
• Review regularly: Check settings quarterly, since platforms continuously adjust related features

Why Bots Still Get In Despite Blocks

If you've configured the above settings but bots still appear, it's usually one of four situations:

The invitation never stopped. A bot following a calendar event will try again each time the event repeats. Removing it from a call only solves it for one meeting; the lasting fix requires turning off auto-join in the bot owner's settings.

The blocking method doesn't match how the bot joins. Domain rules can only see the joiner's email domain. If the bot joins from a domain you allow, or doesn't join as a bot at all, domain rules won't help.

Detection has blind spots. Microsoft explicitly states that some external bots won't be detected, and some real people will be misflagged. Zoom also acknowledges that legitimate users flagged by its Web App protection can still join by signing in.

The tool isn't a bot at all. Fireflies' desktop app has a "Take Notes" mode, Fathom claims it can "take notes with or without a bot," tl;dv says "no bot needed," and Otter's desktop app is the same. None of these go through the meeting platform, and no bot filter can reach them.

The False-Positive Problem: How to Block Bots Without Turning Away Real Guests

The strictest settings are often not the right choice. Blocking all external participants will certainly stop bots, but it will also turn away your clients, auditors, and candidates.

A practical default is to hold all external joiners in the waiting room—nobody gets in without manual confirmation, at the cost of the host monitoring the waiting room and approving by name. For internal team calls, you can allow only people inside the organization; for board, legal, or audit calls, you need to block all external parties except specifically invited guests.

A few habits that reduce friction: note in the invitation that "external guests will wait in the waiting room for host approval"; assign a co-host for large meetings specifically to admit people; and approve by name rather than by count—if the waiting room shows three names but four people are waiting, that's a signal worth questioning.

Recording Consent and Legal Risk

Blocking bots and approving bots both leave a legal question hanging: has everyone on the call consented to being recorded?

US federal law sets a one-party consent minimum, but states can be stricter. According to the Reporter's Committee for Freedom of the Press, 11 states require all-party consent, including California, Florida, Illinois, Maryland, and Massachusetts. For interstate calls, assume the stricter state law applies.

One ongoing case is worth watching: in a privacy lawsuit against Otter.AI, a federal court allowed claims under the federal wiretap law and California CIPA Section 631 to proceed. The plaintiffs argue that Otter's terms of service—which require the account holder to ensure necessary permission is obtained—cannot satisfy the requirements of all-party consent states. This was a ruling on a motion to dismiss, not a finding of liability.

For health, legal, and financial calls, there are additional compliance obligations. Before letting any note-taking tool near a regulated call, consult your legal or compliance lead first.

US states split into two categories for call recording consent: one-party consent and all-party consent. The federal Wiretap Act sets the former—only one party on the call needs to consent for recording; but state law can be stricter. California, Connecticut, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada, New Hampshire, Pennsylvania, and Washington are generally classified as jurisdictions requiring all-party consent (some states' rules have nuances in specific scenarios). For interstate calls, most compliance advice is to adopt the stricter standard. Additionally, CIPA (California's Invasion of Privacy Act, Section 631) is often used in lawsuits against third-party recording services, with plaintiffs arguing that the terms of service clause "the account holder must ensure permission is obtained" cannot substitute for the actual consent of every participant.

Comparing Bot-Free Options

People invite bots because they need notes. If you only block without offering alternatives, some will turn to desktop apps that platform settings can't see.

Built-in platform AI (like Zoom AI Companion or Google Meet's "Take notes for me") runs inside the platform, is started by the host, and shows a visible indicator. Otter's desktop app and Chrome extension offer a free tier of 300 minutes per month. CatchMeet provides device-level capture without a participant card, offering 120 free minutes per month.

Which to choose depends on your priorities: if you need real-time assistance during a call and document fact-checking, CatchMeet is more suitable; if you need automated searchable archives and CRM sync, Otter is the stronger choice. But either way, bot-free apps are still recording, and still require a consent process.

Bot-free notetaking tools are software that capture system audio, microphone, and screen content directly on the user's device rather than joining a call through the meeting platform's participant interface—for example, Otter's desktop app, Fireflies' desktop client, Fathom, tl;dv, and CatchMeet. Because they never appear as a participant in the meeting, waiting rooms, domain rules, Marketplace app blocking, and bot detection all become useless—the platform sees nothing unusual. The compliance burden for these tools thus falls entirely on the user: whether explicit consent was obtained from others on the call, whether all-party consent state requirements are met, and whether recordings are stored in a region compliant with corporate policy. Choosing a bot-free tool is often about reducing meeting interruptions and attendees' psychological discomfort, but it doesn't reduce legal obligations.

FAQ

Can you stop someone from running a notetaking tool on their own computer? No. A desktop app capturing system audio never joins the call, and no waiting room, domain rule, or bot filter can see it. This requires a written policy, device management, and a consent process at the start of the call.

Does blocking bots equal compliance? No. Blocking only removes one recorder; it doesn't tell you whether anyone else is recording, nor does it create a consent basis for your own recordings.

What about content a removed bot has already recorded? The account that owns the bot retains what was already captured. Fireflies says removing the bot stops transcription, but the owner still receives notes from the portion already recorded. You need to ask the owner to delete them.

Conclusion

Do three things in order: configure the platform to hold all external joiners and require login or domain approval; cut off auto-join at the source by restricting calendar and OAuth authorization; and publish a consent process and approved bot-free options.

To be upfront: the Zoom articles referenced in this piece about the Meeting SDK app blocklist and the bot blocking dashboard could not have their text content read when checked, so the admin section only describes their scope without giving specific menu paths. Teams' automatic blocking option depends on a message center announcement, and the official policy reference documentation currently lists only two parameter values. Help pages across platforms may vary by version.

One-line Summary

AI notetaker bots can enter meetings through four paths; a multi-layered blocking strategy plus a recording consent policy is required.

Paragraph Summary

The article analyzes the widespread phenomenon of AI meeting notetaker bots (such as Fireflies, Otter, and Fathom) joining meetings automatically without explicit permission. Bots mainly enter through four paths—calendar auto-join, invited addresses, marketplace integrations, and web client automation—each with a different interception point. At the host level, you can block them via Zoom waiting rooms, Teams detect-and-hold, Meet access types, Webex domain blocking, and GoTo meeting lock; at the admin level, use allowlists and detect-and-hold strategies for persistent control, avoiding reliance on host memory. But blocking bots is not the same as blocking recordings—desktop apps can capture system audio, and no platform setting can detect them. In addition, 11 US states require all-party consent for recording, and interstate calls should assume the stricter law applies. The recommended default is to hold all external joiners in the waiting room for manual approval, while providing approved bot-free options and publishing a consent process.