Piloting a Teams Meeting Policy to Block Third-Party AI Meeting Bots

Purpose

This article describes how to pilot-test a Microsoft Teams meeting policy change with a small group of users before rolling it out organization-wide. The example scenario is blocking third-party AI meeting assistants and note-takers (e.g. browser/bot-based meeting recorders) from joining Teams meetings, but the same pilot workflow applies to any Teams meeting policy change.

Background

Several third-party "AI meeting assistant" tools join Microsoft Teams meetings as anonymous guests in order to record, transcribe, or take notes. Because blocking these tools org-wide can have unintended side effects on legitimate external guests, it is best practice to validate the change against a small pilot group first, using a custom (non-Global) meeting policy.

Note: Microsoft has changed parts of the Teams admin center over time. The classic "Teams app permission policies" page has been retired and redirects to Manage apps, which only controls installed Teams-catalog apps and is not useful for blocking bots that join as anonymous guests. The controls relevant to this scenario live under Meeting policies instead.

Step 1: Create a custom Meeting policy

1. In the Teams admin center, go to Settings & policies > Meetings (or Meeting policies under Teams apps / Meetings in the classic nav).
2. Select Custom policies for users & groups, then open Meetings.
3. Click + Add.
4. Give the policy a clear name and description (avoid special characters such as parentheses or periods in the description field, the form will reject them).
5. Save the policy. At this point it inherits all Global default settings; nothing changes for any user yet.

Step 2: Scope pilot/test users into the policy

1. Open the newly created policy.
2. Go to the Assigned Users tab (or Assigned Groups if you prefer to scope by security group).
3. Click Add and select your pilot testers.
4. Confirm the users now show against the policy. Only these users will be affected by any settings changes made to this policy, everyone else continues to use the Global default policy.

Step 3: Apply the required changes to the custom policy

Available in the Teams admin center GUI

Under the policy's Edit Policy tab, Meeting join & lobby section:

• Manage external bots and their access to meetings - controls how detected meeting bots are handled. As of this writing the GUI only exposes two options: "Do not detect bots" and "When detected, require approval before joining." There is no hard "block" toggle in the GUI.
• Who can bypass the lobby - tightening this (e.g. to "People in my org" only) reduces the chance of an anonymous bot bypassing the lobby.
• Who can admit from the lobby - controls who can let waiting participants in.
• Anonymous users can join a meeting unverified - a blunt on/off switch for all anonymous join. Turning this off blocks legitimate anonymous guests too, not just bots, so use with caution.

PowerShell-only settings

Some settings are not exposed in the GUI at all and must be set via the Microsoft Teams PowerShell module (Connect-MicrosoftTeams):

# Set external bot access mode on the pilot policy only (not Global)
Set-CsTeamsMeetingPolicy -Identity "<PolicyName>" -ExternalBotAccessMode BlockDetectedBots

# Block anonymous join via Azure Communication Services (ACS)-based custom clients,
# which is the mechanism most third-party AI meeting bots use to join anonymously.
# Valid values are "ACS" and/or "Teams" (specifying both disables anonymous join entirely).
Set-CsTeamsMeetingPolicy -Identity "<PolicyName>" -BlockedAnonymousJoinClientTypes "ACS"

# Verify the values actually applied
Get-CsTeamsMeetingPolicy -Identity "<PolicyName>" | fl ExternalBotAccessMode,BlockedAnonymousJoinClientTypes

# Confirm a specific pilot user is scoped to the policy
Get-CsUserPolicyAssignment -Identity <user-upn> -PolicyType TeamsMeetingPolicy

# Alternative to the GUI, if you need to assign the policy via PowerShell
Grant-CsTeamsMeetingPolicy -Identity <user-upn> -PolicyName "<PolicyName>"

Important: always verify parameter names and accepted values against Get-Help -Parameter or the current Microsoft Learn documentation before running these in production, Teams PowerShell parameters and accepted values can change between module versions.

Step 4: Test the use case

With a pilot user (one who is scoped into the custom policy):

1. Schedule or start a Teams meeting as the pilot user.
2. Attempt to have a third-party bot (or a test anonymous/ACS-based client) join the meeting.
3. Confirm the bot is blocked or requires approval as expected, per the policy configuration.
4. Confirm normal, legitimate functionality still works for that user: joining via the Teams app, screen sharing, native recording/transcription, and any expected guest access.
5. Note Microsoft's own documentation caveat: blocking 100% of meeting bots is not guaranteed. Novel or obfuscated bots, or tools that intercept audio/video at the device level, cannot be fully prevented by these controls.

Step 5: Report the outcome

Document, at minimum:

• The name of the custom policy and which setting values were changed.
• Which users/groups were scoped into the pilot.
• What was tested and how (which bot/tool, which join method).
• Expected result vs. actual result.
• Any side effects observed (e.g., legitimate guests affected, features broken).
• A recommendation on whether to proceed with an org-wide (Global policy) rollout, adjust the approach, or continue piloting.

Key takeaways

• Always make changes on a custom policy scoped to a pilot group first; never edit the Global policy directly for an unvalidated change.
• Some bot/anonymous-join controls exist only in PowerShell, not the GUI, check both.
• Confirm the exact cmdlet parameter names and valid values before running them, since these can change over time and vary by tenant/module version.
• Blocking third-party meeting bots is a defense-in-depth control, not a guarantee, combine policy changes with organizational guidance for full effect.