Microsoft has quietly rolled out a long-awaited security control for Teams meetings, giving administrators the power to automatically route detected external meeting bots into the lobby. Even if a meeting’s default lobby settings would normally let participants in unhindered, any external account flagged as a bot will now require explicit organizer approval before joining. The change tackles a growing headache for corporate Teams users: uninvited or hard-to-identify automated agents slipping into sensitive meetings.
How the Bot Detection Policy Works
The new capability appears inside the Teams admin center under Meeting policies. When an admin enables it, Teams applies an additional layer of scrutiny to every external participant joining a meeting. If Microsoft’s backend signals identify the joining user as a bot—such as accounts registered as bots in Azure AD, service accounts with automated access patterns, or participants using third-party calling-platform integration—the system overrides the meeting’s standard lobby bypass rule. Instead of joining directly, the bot is placed in the lobby, where the meeting organizer can admit or block it.
Crucially, the override is policy-based and tenant-wide. That means it works across all meetings scheduled by users in that tenant, regardless of the individual meeting options the organizer selected. For example, a meeting set to “Everyone” bypasses the lobby would still intercept a detected external bot and hold it for review. The only way to override this behavior is to disable the policy entirely or to add the specific bot’s domain to an allowlist—though Microsoft’s documentation suggests that allowlisting for this scenario is still maturing.
Admin Controls in the Teams Admin Center
To turn on the feature, IT staff navigate to Meetings → Meeting policies in the admin center, choose an existing policy or create a new one, and scroll to the Meeting join & lobby section. There, a new toggle—likely labeled something akin to “External participants detected as bots will wait in the lobby”—sits alongside the familiar lobby-bypass dropdown. By flipping it on, admins can immediately start filtering bot traffic without touching any other lobby configuration.
Microsoft has integrated the detection with its broader identity and threat signals, so no additional agents or connectors are required. The feature works in tandem with the External access and Guest access settings already in place: external participants who are not bots continue to follow the standard lobby rules, while bots are forcibly held. This nuanced approach avoids disrupting legitimate external users—partners, clients, or contractors—while clamping down on unauthorized automation.
For organizations that rely heavily on approved bots—such as transcription services, compliance recording systems, or in-meeting assistants—Microsoft provides a path to exempt them. Admins can add the bot’s domain or app ID to a custom list, effectively telling Teams to treat that bot as a trusted participant. This list is still separate from the standard lobby-bypass allowlist, underscoring the targeted nature of the control.
Why Organizations Asked for This
Over the past two years, as hybrid work made Teams meetings the default watercooler, security teams reported a surge in unwanted automated attendees. Uninvited bots could join meetings that happened to be set with open lobby policies, harvesting conversation transcripts, contact lists, or even injecting themselves into the chat. While most of these incidents were annoying rather than destructive, the risk of data leakage was real. Finance, healthcare, and legal firms, in particular, raised concerns that a misconfigured lobby could allow a competitor’s AI agent or a malicious scraper to sit in on confidential discussions undetected.
The classic defense—restricting lobby bypass to “People in my organization”—is effective but rigid. It blocks all external humans, not just bots, forcing meeting organizers to manually admit every outside participant. That friction led many teams to reluctantly open their lobbies, trading security for convenience. The new policy closes that gap by applying an intelligent filter: humans pass, bots get flagged. No compromise on usability is required.
User Experience and Meeting Flow
From the meeting organizer’s perspective, the experience is seamless. When an external bot tries to join, the organizer receives a lobby notification identical to the one shown for any anonymous or unauthenticated user. The notification card in the meeting window identifies the participant as a bot—likely with a small bot icon or a “Detected bot” label—so the organizer can make an informed decision. Accepting the bot brings it into the meeting; rejecting or ignoring the notification keeps it out.
Attendees inside the meeting see no interruption unless the organizer admits the bot, at which point the bot appears in the participant list like any other user. For meetings that use Together Mode or Large Gallery, bots are placed in their own tile or seat, though Microsoft has not yet indicated whether they will be visually distinguished within those views.
Critically, the policy does not affect bots that originate inside the tenant. An internal compliance-recording bot, for instance, will continue to join automatically based on the meeting’s normal settings. The filter applies only to tenants other than the organizer’s home tenant, ensuring that internal automation remains unhampered.
Part of a Broader Security Push
The bot lobby override is the latest in a series of Teams security enhancements aimed at giving IT granular control over meeting access. Over the last twelve months Microsoft has introduced end-to-end encryption option for meetings, watermarking for confidential sessions, harder mute controls, and improved lobby audit logs. The bot-detection feature dovetails with these by leveraging Microsoft’s cloud-scale intelligence to identify and isolate untrusted automated traffic.
It also hints at a future where AI-driven threat protection becomes a standard layer inside collaboration apps. Microsoft’s security graph already collects signals across Azure AD, Microsoft Defender, and Office 365. Tapping that graph to classify participants in real time opens the door to other dynamic access decisions—for example, applying conditional-access-style policies to meeting join actions, or blocking participants whose behavior patterns match known attack signatures.
Potential Limitations and What’s Next
The current iteration relies on Microsoft’s ability to accurately detect bots at join time, which is not foolproof. Some sophisticated bots may use standard user accounts and mimic human behavior, evading detection. Admins have asked for a reporting dashboard where they can review how many bots were intercepted and manually flag false positives, but such a dashboard is not yet available.
Additionally, the allowlist mechanism for trusted bots is still in its early stages. Early adopter feedback suggests that managing allowlists at scale across hundreds of meetings will require an API or PowerShell cmdlets, neither of which appeared in the initial rollout. Microsoft’s roadmap may address this in a future wave, along with tenant-wide reporting and more granular policy assignment to specific groups.
For now, the feature represents a pragmatic step forward. It arms IT departments with a low-overhead tool to cut off a tangible risk—one that had been met with growing frustration as bot activity increased. Organizations that have been holding back from liberalizing lobby settings for fear of automation now have a clear path to do so safely.
How to Enable It Today
If your tenant is on the public cloud and you have Teams administrator permissions, you can enable the policy immediately:
- Sign into the Teams admin center (https://admin.teams.microsoft.com).
- Navigate to Meetings > Meeting policies.
- Select an existing policy or click Add to create a new one.
- Under Meeting join & lobby, locate the new bot-detection toggle.
- Turn the toggle On and save the policy.
- Assign the policy to users, groups, or the entire tenant.
Once applied, the setting takes effect for all future meetings scheduled by those users. Existing meetings already in progress are not affected until they end and are rescheduled.
Because the feature is policy-based, testing is straightforward: create a separate test policy, assign it to a pilot group, and schedule meetings with and without a known external bot to observe the lobby behavior. Microsoft’s message center post for this update likely includes additional rollout details, so checking the message center for an official post is recommended.
The Bottom Line
For organizations weary of unwanted bots crashing their Teams meetings, this new policy is a welcome addition. It restores control without forcing a return to the all-or-nothing lobby configurations that hamper collaboration. By intelligently distinguishing between external humans and automated agents, Microsoft has delivered a practical security lever that should become a default setting for security-conscious tenants. As the line between human and bot participants continues to blur, features like this one will define how trust is negotiated in the modern meeting experience.