How to Disable Otter AI

A step-by-step guide for anyone who's noticed a bot silently transcribing their meeting and wants it gone, whether you're the host, a participant, or an IT admin trying to lock it out org-wide.

If you're searching for how to disable Otter AI, you probably saw it join a call you didn't invite it to. Maybe it appeared as "Otter.ai Notetaker" in your participant list, maybe a colleague's calendar integration pulled it in automatically, or maybe you got a follow-up email with a partial transcript of a conversation you thought was private. Whatever the trigger: you want it stopped. This guide covers the quick in-meeting kill, the account-level settings that prevent recurrence, the calendar disconnection most guides skip, and the org-wide blocks that IT teams are increasingly deploying. We also cover the legal context that makes all of this more urgent than it was six months ago.

Key Takeaways

• Any participant (even without an Otter account) can type stop otter in the meeting chat on Zoom, Google Meet, or Microsoft Teams to immediately eject the Notetaker bot.
• Removing the bot from one meeting does not prevent it from returning. You need to disable auto-join in account settings and, ideally, disconnect your calendar integration entirely.
• Revoking access does not delete transcripts already captured. Data that's been recorded and stored stays in the Otter account unless the account owner explicitly deletes it.
• A federal judge allowed core wiretapping and privacy claims against Otter.ai to proceed in August 2026, finding that nonconsensual recording, transcription, and retention of private conversations plausibly caused injury. The legal stakes for meeting hosts who invite these bots are real.
• IT teams blocking the domain alone often find the bot still gets in, because some notetakers join under the authenticated session of the user who connected the integration, not from a separate domain.

How Do I Remove Otter AI From a Live Meeting?

Type stop otter in the meeting chat. That's it. This works on Zoom, Google Meet, and Microsoft Teams, and you don't need an Otter account or host privileges to do it. Every Notetaker bot in that meeting session gets ejected immediately.

If you're the host or co-host, you also have the standard participant-management route: find the Otter.ai Notetaker in your participant list, click the three-dot menu (or equivalent), and remove it as you would any other participant. On Zoom, this means the host can also use "Remove" from the Participants panel. Google Meet and Teams have analogous controls for meeting organizers.

Both methods work. The chat command is faster and available to everyone. The host-removal path gives you slightly more control if multiple bots are present (not uncommon in larger organizations where different teams use different transcription tools).

One thing to understand: removal is instantaneous, but it's not retroactive. Whatever audio was captured before you typed the command is already processed. We'll come back to that.

Why Does Removing It Once Not Fix the Problem?

Because the bot's presence in your meeting is a symptom, not the root cause. The root cause is a calendar integration combined with an auto-join setting. Someone (possibly you, possibly a colleague who shares recurring calendar events) connected Otter to their Google or Outlook calendar and enabled automatic joining. The bot reads upcoming events, identifies meeting links, and joins at the scheduled time. It re-requests entry every occurrence of a recurring event, so removing it from today's standup means it shows up again tomorrow.

This is the part most quick-fix guides skip. Killing the bot in a live call is a five-second action. Preventing it from coming back requires changes at the account level, the calendar level, or the organization level, depending on your situation.

How Do I Disable Auto-Join in Otter's Settings?

Open Otter's settings (on the web or mobile app), navigate to Meeting settings, and switch the auto-join behavior from automatic to manual. On mobile specifically, the path is Account Settings → Meeting settings → auto-join toggle. This stops the bot from autonomously joining future meetings that appear on your connected calendar.

There is a catch. Previously scheduled events that already had auto-join toggled on retain their individual setting even after you change the default. So if you had a weekly all-hands with auto-join enabled three months ago, that specific calendar entry may still trigger the bot. Review your upcoming calendar events in Otter's dashboard after changing the global setting and manually disable any that still show auto-join active.

This is a design decision that works in Otter's favor, not yours. The default is sticky per-event, which means a single settings change doesn't propagate cleanly. You have to audit.

Should I Disconnect My Calendar Entirely?

If you want to be thorough, yes. Disabling auto-join stops the bot from joining automatically, but it does not sever calendar access. Otter still reads your calendar, still knows your meeting schedule, and still presents you with the option to manually send the bot. Disconnecting the calendar removes the integration entirely and clears all future event data from Otter's view.

To disconnect: go to your Otter account settings, find the calendar integration section (Google Calendar or Microsoft 365), and revoke the connection. You may also want to check the third-party app permissions on the calendar side. In Google, that's myaccount.google.com → Security → Third-party apps with account access. In Microsoft 365, it's your account's app permissions page. Remove Otter from both ends to be certain.

Does Revoking Access Delete My Existing Transcripts?

No. Revoking calendar and app permissions does not erase transcripts that are already stored in the Otter account. If the bot recorded three months of your team's standups, those transcripts persist until the account owner logs in and deletes them. If the account owner is a colleague who connected the integration on their own account, you have no direct ability to delete those transcripts. You'd need to ask them, or escalate to IT.

This is worth sitting with for a moment. The removal flow gives you control over future recordings. It gives you zero control over past ones. The data asymmetry is the core of the legal complaints now working through the federal court system.

What If I'm Not the One Who Connected Otter?

This is the most common scenario. You're in a meeting. You see the bot. You didn't install Otter. You don't have an Otter account. Someone else on the call, probably the organizer, has the integration enabled.

Your options in the moment: type stop otter in the chat. That works regardless of who invited the bot. After the meeting: talk to the person whose account is connected. If that doesn't resolve it, escalate to your IT team and ask them to implement org-wide blocks (covered below).

You cannot unilaterally prevent someone else's Otter account from targeting meetings you're invited to. You can only eject it in real time or ask administrators to block it at the platform level. This is, structurally, the same dynamic as someone bringing an uninvited guest to your house. You can ask them to leave, but you can't prevent the invitation from being sent in the first place unless you control the front door.

How Can IT Teams Block Otter AI Org-Wide?

There are several layers, and none of them is complete on its own.

Domain and DNS blocking

Some IT teams have blocked the otter.ai domain at the network level after repeated incidents. This prevents the Otter web app from loading on corporate networks and can interfere with the bot's ability to connect to meetings hosted on those networks. It's a blunt instrument. It doesn't help when employees are on home Wi-Fi or mobile data, and it doesn't stop the bot from joining meetings hosted on external infrastructure.

Meeting platform admin controls

Zoom, Teams, and Google Meet all have admin-level settings that can restrict who joins meetings. In Zoom, admins can require authentication for meeting participants, which blocks bots that don't authenticate as org members. In Microsoft Teams, admins can restrict external access and anonymous joins, which catches some notetaker bots. Stony Brook University's IT department recommends planning for the removal of AI summary participants from meetings in progress, acknowledging that domain blocking alone is insufficient.

The authentication gap

Here's the problem IT teams keep running into: some notetaker bots join using the meeting participant's own authenticated account rather than a separate bot identity. If an employee authorized Otter to act on their behalf, the bot may appear to the meeting platform as that employee, not as a third-party entity. Authentication requirements don't catch this. The bot is, from the platform's perspective, the user.

This is why a layered approach matters. Domain blocking plus meeting authentication plus a clear internal policy prohibiting unauthorized recording tools, enforced through employee agreements, covers more surface area than any single technical control. Some organizations are also lobbying meeting platforms for an explicit "block all third-party AI assistants" toggle at the tenant level, but as of mid-2026, that feature doesn't exist in a clean, universal form across all three major platforms.

What's the Legal Context Here?

It matters, and it's recent.

On August 13, 2026, a federal judge in San Jose allowed core privacy claims against Otter.ai to proceed, rejecting the company's motion to dismiss. The case is In re Otter.AI Privacy Litigation, N.D. Cal. Judge Eumi K. Lee found that plaintiffs plausibly alleged injury from nonconsensual recording, transcription, and retention of private conversations.

The surviving claims include violations of ECPA (the federal Electronic Communications Privacy Act), California's CIPA wiretapping provisions, Illinois's Biometric Information Privacy Act (BIPA, which covers voiceprints), and California's Unfair Competition Law. Unjust enrichment claims also survived.

The potential damages are significant. ECPA allows up to $10,000 per violation. CIPA allows $5,000. BIPA allows up to $5,000 per voiceprint. Across a large user base, the exposure is substantial.

One factual allegation in the complaint stands out: Otter allegedly sends follow-up emails containing partial transcripts and screenshots to all meeting invitees, regardless of whether they actually attended the meeting. If true, this means your voice could be transcribed, stored, and distributed to people who weren't even present for the conversation.

Why Does This Ruling Matter Beyond Otter Specifically?

Because the legal theories aren't vendor-specific. Legal analysis from ZwillGen frames this case as the first federal test of whether AI bots count as "third-party eavesdroppers" under decades-old wiretap statutes. The theories could apply to any consumer-facing product that collects meeting audio, transcribes it server-side, retains it, and uses it for model training.

The distinction that matters architecturally: tools that require cloud upload and server-side retention carry a categorically different legal risk profile than tools that process locally or don't retain data by design. The court didn't rule on the merits yet, but it found the architecture itself (record, upload, retain, distribute) sufficient to state a claim. That's a signal.

Who Bears Liability: The Vendor or the Person Who Invited the Bot?

Potentially both, and this is the angle that doesn't get enough attention.

Several legal analyses note that Otter's terms of service shift consent obligations to the user who enabled the integration. In practice, this means the individual employee or meeting host who turned on auto-join could bear personal legal exposure in all-party-consent states (California, Illinois, and roughly a dozen others require all parties to consent to recording).

If you're a manager who enabled Otter on your team's recurring standup and one of the participants is in Illinois, you may have a BIPA problem. Not Otter. You. The vendor structured it so the consent obligation flows downstream to the person who pressed the button.

For companies deciding what meeting tools to standardize on, this isn't a minor footnote. It's an HR and legal risk that sits with individual employees unless the organization explicitly authorizes and takes responsibility for the recording.

What Should I Do Right Now? A Checklist

Depending on your role, here's the practical sequence:

If you're a meeting participant who just wants the bot gone

1. Type stop otter in the meeting chat. Immediate effect.
2. After the meeting, ask the organizer to disable auto-join or disconnect the calendar integration.
3. If it recurs, escalate to IT.

If you're the person whose Otter account is connected

1. Open Otter → Account Settings → Meeting settings. Switch auto-join to manual.
2. Review all upcoming calendar events in Otter's dashboard. Disable auto-join on any individual events that retained the old setting.
3. If you want a clean break, disconnect your calendar integration entirely.
4. Revoke Otter's permissions on the calendar provider side (Google account settings or Microsoft 365 app permissions).
5. Remember: existing transcripts are not deleted by any of these steps. Log into Otter and manually delete any transcripts you don't want retained.

If you're an IT administrator

1. Block the otter.ai domain at DNS/firewall level as a first layer.
2. Configure meeting platform admin settings to require authentication and restrict anonymous/external participants.
3. Publish an internal policy on unauthorized recording tools, with clear consequences.
4. Educate employees that revoking app access doesn't delete existing data. Anyone who previously connected Otter needs to audit their account.
5. Monitor for bots joining under authenticated user sessions, since domain blocking alone won't catch those.
6. Consider the legal exposure: in all-party-consent jurisdictions, unauthorized recording by an employee's personal tool integration could create liability for the organization.

What Doesn't Work (or Doesn't Work Completely)?

A few things people try that fall short:

Blocking the domain alone. As noted above, bots that authenticate as the user bypass domain-level blocks. It's a useful layer, not a complete solution.

Disabling auto-join without reviewing existing events. Per-event settings survive the global change. You'll think you fixed it, then the bot will show up at next Tuesday's recurring sync.

Removing the bot from one instance of a recurring meeting. The bot rejoins based on calendar access, not meeting memory. Clearing one instance only clears that instance. The calendar entry still exists, and the next occurrence still triggers entry.

Assuming the meeting platform will handle it. Zoom, Teams, and Meet all provide admin controls, but none of them offer a single toggle that says "block all AI notetaker bots." The controls are fragmented across authentication settings, external access policies, and participant management. A determined integration can still find gaps.

The Bigger Picture: Removal Is Not Deletion

The core problem with AI notetaker bots isn't that they're hard to remove from a live meeting. That part is trivially easy. The core problem is the gap between removal and deletion.

Removing the bot stops future recording. It does not undo past recording. It does not delete stored transcripts. It does not revoke access to voiceprints that may have already been processed. It does not recall follow-up emails that may have already been sent. The "off switch" controls the future. The past is already on someone else's server.

This is exactly the theory the federal court found plausible in the Otter.ai privacy litigation: the alleged injury isn't just the recording, it's the retention and distribution. Stopping the recording is necessary but not sufficient.

For anyone who takes meeting privacy seriously, the lesson is architectural. Tools that never upload audio to a third-party server in the first place don't have a retention problem, because there's nothing to retain. Tools that process locally, or that give you cryptographic control over your own data, shift the power dynamic. The off switch works because there was never an on switch someone else controlled.

We built Selina around a different set of assumptions. Your data is encrypted at rest. Files and transfers through SelinaSEND are zero-knowledge encrypted. The account is protected, not just the content. And when you delete something, it's gone. Actually gone. That's not a feature. It's a constraint we designed around from day one.

If you want an AI assistant that remembers your context without making your conversations someone else's training data, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io