How to block AI notetakers in Zoom, Google Meet and Teams — and why it keeps not working

Nine minutes into a client call, a new participant appears. It is called something like "Dana's AI Notetaker." Dana is on the call and looks as surprised as you are. Nobody clicked anything. The client's legal counsel is in the room, deal terms are on screen, and a transcript is now being written into a third-party account neither of you controls.

Then your phone buzzes. It's the account manager asking whether that's allowed.

Here is what you do next, per platform. Some of it works. A meaningful piece of it does not, and one platform quietly fixed most of the problem in June while the other two did not. Every control below reflects its state this week.

Why your app blocklist didn't catch it

The mental model most admins start with is wrong in a specific way that costs a week.

You assume the notetaker is an app. Apps request OAuth scopes and appear in an admin console where you can block them. So you go block it there.

The bot doesn't arrive as an app. It arrives as a person. It reads a user's calendar, finds the join link on the event, and dials in as an ordinary external participant — sometimes labelled with your own employee's name. On r/sysadmin's 408-point thread on blocking AI notetakers, which ran to 126 comments, the top diagnosis is the plain one:

The biggest problem with these apps as they join as an attendee and it's really hard to keep those out unless you lock down the lobby

The calendar is the attack surface. That's also why it spreads. The 757-point r/sysadmin thread on Read.ai describes the mechanism with more feeling than a vendor doc ever will:

It attaches to you like a barnacle, launching itself on your own calls going forward

One person on your side accepts an invite from someone whose calendar is wired to Read.ai. Now the bot has your recurring events too. An MSP thread put it in four words: "It works exactly like a worm."

Often the user never asked for it. One Google Meet customer reported that

an automated participant labeled '[My Name]'s AI Notetaker' began joining my meetings automatically. I never signed up for this, I never opted in

This is not a hypothetical compliance worry. A class action filed in August 2025 alleges Otter.ai recorded private conversations "deceptively and surreptitiously" to train its models; NPR's write-up quotes the complaint on this exact vector, saying an Otter Notetaker "may join the meeting without obtaining the affirmative consent from any meeting participant."

Zoom

Start with what exists. Zoom ships a per-app allow or block list for SDK apps that join as participants, documented in KB0083775. Find it under Settings > General > Security, as "Manage which Zoom apps can join as a participant in meetings and webinars in your organization." Pick apps from the Marketplace list, decide whether that list allows or blocks, save.

Now the bad news. It is per app. There is no category, no "block all AI notetakers" switch, and Zoom's own documentation for the feature describes nothing of the kind. You are hand-maintaining a list against a market that adds an entrant every month.

Admins have been asking. A Zoom community thread on disabling AI notetakers has drawn more than 9,900 views since June 2025, and the answers there are a tour of partial fixes: Admin App Management, unchecking app requests under Permissions, telling users to detach the notetaker from their own calendar. That thread also names why domain blocking underperforms — the bots frequently ride in on a participant's authenticated account rather than their own domain.

Cornell IT's guide is the most honest institutional writeup I've found, partly because Cornell blocks Read.ai and Fireflies.ai at the instance level and still publishes a list of extra steps. Their warning about domain blocking is the one to internalise: vendors use multiple domains, so blocking the obvious one may not be sufficient.

What actually moves the needle on Zoom:

Waiting room, on, always. The only control that catches an unknown participant regardless of how it got the link.
Require authentication to join, under Settings > Meeting, restricted to your own domain where the meeting allows it.
Block vendor domains under Settings > Meeting > Security, accepting that it's partial.
Turn off automatic approval for local recording under Settings > Recording.

There is also the in-meeting toggle people ask about. Under Host tools, "Share realtime meeting content with apps" governs Zoom's Realtime Media Streams. Per Zoom's RTMS documentation, admins can control whether RTMS is available at account, group and user level and whether RTMS apps auto-start, with the host making the final call inside the meeting. What the docs don't describe is what else stops working when a host flips it off mid-call, so test it on an internal meeting before telling 400 people it's the fix.

As of this month Zoom still has no blanket bot control. A feature request filed on 7 August 2026 asks for exactly that, and the requester reports being told by support that it doesn't exist. It sat at zero replies.

Google Meet

Google's own article, External apps are recording Meet meetings, lists five things: block the app's domains through Chrome Enterprise, restrict third-party extensions in Chrome and ChromeOS, block third-party app access to APIs, ask the app owner to block your organisation, and set meeting access so that "anyone who hasn't been invited must ask to join" — then make that the default for every meeting you host. Google does not present the API control as sufficient on its own.

There's a reason, and admins found it first. From r/gsuite, on blocking Fireflies org-wide:

I put a block in via API controls and Fireflies is still trying to join meetings.

App access control governs what an app does with your data through Google's APIs. It does not govern who opens a meet.google.com link. If the bot sits on the calendar event as a guest, it is an invited guest — and invited guests aren't the ones knocking.

Google did harden the lobby in early 2026 with the safeguarded guest admit flow, which splits join requests into two queues and defaults the suspicious one to deny, reaching Rapid Release domains on 24 March 2026. Read it closely and you'll notice it never mentions bots, notetakers or calendar invites. It hardens knocking. The calendar path is untouched.

So removal is manual, in three parts, all of which you need:

Revoke the app's access in the Admin console and mark it Blocked so it can't re-authorise.
Delete or suspend any account the notetaker was provisioned in your directory, and clear the OAuth grant on every affected user.
Open each already-scheduled event and remove the bot's guest entry by hand.

Existing invitations survive steps one and two. Step three is the one people skip, and it's why the bot is back on Monday. End users hit the same wall from the other side, in a long-running Meet forum thread about getting Otter out of their meetings and notes.

Microsoft Teams

This section changed, and it changed in your favour.

Teams now detects external bots and holds them in the lobby by default. The policy is documented at Manage external bots and their access to meetings, lives under Meeting policies > Meeting join and lobby, and applies per user or group:

Set-CsTeamsMeetingPolicy -Identity <policy name> -ExternalBotAccessMode RequireApprovalWhenDetected

Two documented values. AllowBots turns detection off and lets bots appear as ordinary external participants. RequireApprovalWhenDetected is the default: detected bots are marked in the lobby and held there until admitted. The detail worth knowing, from BleepingComputer's coverage of the 30 June 2026 announcement, is that this holds "even in meetings where organizers allow participants to bypass the lobby." Tony Redmond tracked the rollout from targeted release in mid-May 2026 to general availability in early-to-mid June.

Microsoft is candid about the limits, and so should you be:

Some external bots may not be detected. We're constantly improving our detection mechanism and filling in any gaps that are observed.

The docs also warn that detection "may occasionally misclassify human participants as bots," which is why organisers get a "This is not a bot" correction. A mode that blocks detected bots outright rather than lobbying them is reported to be rolling out this month under roadmap item 566201. Check your message center rather than taking my word for it.

One thing that does not work, and admins keep trying it: deleting the vendor's app registration in Entra ID. That stops new consent. It does not evict a bot already attached to a user's calendar and joining as a participant, because that path doesn't need your tenant's consent at join time.

Platform	What exists today	What it still won't do
Zoom	Per-app SDK allow/block list (KB0083775), waiting room, domain blocking, auth requirements	No blanket bot block; domain lists go stale; still an open feature request
Google Meet	App access control, Chrome domain and extension blocking, restricted meeting access (Google's list)	API blocks don't stop a bot invited on the calendar; per-event cleanup is manual
Teams	`ExternalBotAccessMode` detection with lobby hold, on by default	Detection is imperfect by Microsoft's own admission, and false positives happen

The part nobody puts in the guide

Everything above assumes the transcriber shows up as a participant. A growing share of them don't.

A browser extension sitting in someone's Chrome profile can read the tab's audio and captions without ever joining the meeting. No participant entry. No lobby event. No SDK app to blocklist. Your waiting room never sees it, Teams bot detection never fires, and your audit log records a completely normal meeting. Zoom users have been asking how to block third-party transcription extensions, and the 27-comment answer is essentially: not from inside Zoom.

The only lever that reaches this is device management — an extension allowlist pushed through Chrome Enterprise or Intune, which is why Google lists extension restriction alongside the meeting settings. Manage the endpoint and you have a shot. If the person running the extension works at the client, you have a conversation, not a control.

Which is the honest summary of this whole guide. You can make your meetings hard to record. You cannot make them impossible to record, and any vendor telling you otherwise is selling something.

Where Team Meet comes out differently

We build Team Meet, and we took the opposite position: instead of detecting programs that sneak in, give them a front door and make it loud.

An agent joins a Team Meet room through an open protocol using a key. It appears in the member list as itself, and its arrival is written into the meeting chat where everyone can see it. Any person in the room can remove it — not only the host or the organiser, but anyone in the conversation being recorded. The host has one switch that turns agents off for the room entirely and disconnects the ones already connected. No policy object, no PowerShell, no list to maintain by hand.

The limit is real and I won't dress it up. This applies only to meetings held on Team Meet. It does nothing about Otter in someone else's Zoom, nothing about a Chrome extension on a laptop you don't manage, and it will not retroactively fix this morning's call. Anyone claiming their product blocks notetakers on platforms they don't run is lying to you. What it does mean is that on calls you host, "who is recording this" has a visible answer at all times, enforceable by anyone in the room rather than by whoever happens to be organiser. The protocol is documented at teammeet.io/developers.

In the meantime: waiting rooms on, ExternalBotAccessMode left at its default, and a calendar audit for the barnacles already attached.