Microsoft has closed a long-standing blind spot in Teams meetings. The company is rolling out new admin controls that require manual approval for any external AI bot attempting to join a video call—even when the meeting’s normal settings would otherwise let participants breeze past the lobby. The change, detailed in Microsoft’s Learn documentation and confirmed by enterprise early adopters, gives meeting organizers a decisive last chance to review automated note-takers, transcription services, and other third-party agents before they gain access to confidential conversations.

A detection system that puts organizers in control

The new policy, labeled “Manage external bots and their access to meetings” in the Teams admin center, introduces three distinct behaviors.

  • RequireApprovalWhenDetected: When Teams identifies a likely external bot, it routes the participant to the lobby and flags it for the organizer. Even if the meeting is set to let everyone skip the lobby, bot approval remains mandatory.
  • BlockDetectedBots: Suspected bots are automatically denied entry. Organizers don’t see a prompt; the bot simply cannot join.
  • AllowAllBots: All detected bots are admitted without manual intervention. Microsoft warns this is not a disable switch for detection—it’s an exception for approved, unattended workflows only.

Behind the scenes, Teams uses heuristics to spot join requests that originate from automated services. If the system’s confidence is high, the bot gets a distinct identity label in the lobby so the organizer knows exactly what they’re dealing with. Microsoft is also launching a Teams Bot Identification Program (timing not yet confirmed) that will let ISVs register their bots and embed a trust marker in join requests, making it easier for organizers to distinguish verified services from unknown ones.

What it means if you’re an everyday Teams user

If your organization has enabled the new control, you’ll start seeing unfamiliar prompts in the meeting lobby. Instead of a generic participant name, a suspected external bot will be clearly labeled. That gives you a moment to ask: Do I know who invited this service? What will it capture? Who has access to the recording or transcript afterwards?

Microsoft’s guidance is blunt: only admit a bot if you can answer those questions confidently. This isn’t just about privacy—it’s about compliance. In regulated industries or during sensitive discussions, an unvetted AI assistant recording proceedings could create serious legal exposure. The new policy puts the decision back in human hands.

For most calls—routine project syncs, customer check-ins, internal stand-ups—RequireApprovalWhenDetected offers a pragmatic balance. It doesn’t block legitimate tools; it forces an intentional “accept” click. And for meetings where confidentiality is non-negotiable (legal, HR, financial, M&A), admins can assign a BlockDetectedBots policy that eliminates the risk altogether.

What admins should do right now

According to WindowsForum’s detailed deployment analysis, the biggest mistake organizations make is treating all organizers identically. A finance VP hosting earnings reviews needs different protection than a project manager running daily scrums. Microsoft’s policy supports that segmentation.

Start with this three-tier model:

  • General organizers: Assign RequireApprovalWhenDetected. It allows known note-taking assistants while creating a deliberate checkpoint for everything else.
  • Sensitive-meeting organizers: Block bots outright. Legal, HR, security operations, executive leadership, and anyone handling regulated data should never have to decide on the fly whether an AI agent is welcome.
  • Approved automation workflows: Reserve AllowAllBots for the narrowest group possible—only after formal review confirms the bot’s data handling meets your organization’s standards and the workflow cannot function with manual approval.

Before you touch any policy, map out who falls into each tier. Identify teams that routinely discuss privileged information. Confirm that lobby admission is restricted to organizers and co-organizers; a detected bot should never be admitted by someone who lacks context about the meeting’s sensitivity. And run a pilot with real organizers and real bot services before deploying broadly.

Microsoft’s admin center path: Teams admin center > Meetings > Meeting policies > [select or create a policy] > Manage external bots and their access to meetings. Save and assign to the appropriate organizer population.

How we got here

The pandemic-era explosion of AI note-takers—Otter.ai, Fireflies.ai, Read.ai, and dozens more—filled a genuine need. But they also created a governance gap. A bot invited by one participant could silently join a meeting, record everything, and deposit a transcript into a cloud service outside the organization’s control. Even when a meeting’s lobby was set to admit only invited participants, many bots slipped through because they were technically invited by a human attendee.

Security researchers and enterprise compliance teams flagged this months ago. Microsoft’s response, first previewed in early 2025, is this detection-and-approval framework. It’s a sharp departure from the old model where bots were largely invisible to organizers and admins alike.

Detection is not an allowlist

One critical caveat: the system looks for “likely” external bots, not every possible automated join. An unreported service might still slip through. Conversely, a legitimate service that isn’t yet part of the Bot Identification Program could be flagged. Microsoft’s documentation stresses that organizers should not treat a “detected” label as proof of malicious intent—it’s simply a prompt to verify.

Similarly, marking a bot as “allowed” via the AllowAllBots policy doesn’t absolve the organization of normal vendor due diligence. Data governance, privacy reviews, and on-going access audits remain essential.

What’s next

The upcoming Bot Identification Program will give trusted ISVs a way to self-identify. When that happens, organizers will see additional context in the lobby—potentially a verified badge or provider name—making approval decisions faster and more informed. For now, the sharpest defense remains the simplest one: if you don’t know who sent the bot and what it’s doing, don’t let it in.