Microsoft is strengthening security and privacy controls in Teams with a new meeting protection policy that will allow administrators to automatically prevent detected external bots from entering meetings.
The forthcoming control expands Microsoft’s existing bot-detection capabilities, which currently identify suspected third-party meeting assistants, label them as bots and hold them in the lobby until an authorized participant approves their admission.
Under the stricter policy, detected external bots will be blocked automatically. Meeting organizers will no longer need to review or reject each attempted bot admission manually, reducing the risk that an automated assistant could enter a sensitive discussion because of human error, confusion or an overly permissive lobby configuration.
The change is particularly relevant to organizations whose employees routinely participate in meetings involving confidential business strategy, customer information, regulated data, legal discussions, intellectual property or security incidents.
Microsoft announced the policy through Microsoft 365 Message Center advisory MC1459141. According to the rollout information, targeted release deployment is expected to continue through the end of August 2026, with worldwide general availability scheduled for completion by late September.
New policy removes the organizer approval step
Microsoft Teams already has a control designed to identify external meeting assistants through signals collected while a participant attempts to join a meeting. These assistants can include AI transcription services, automated note takers, meeting summarization platforms and other third-party tools that appear in the participant list as bots.
With the current default configuration, Teams places a detected bot in the meeting lobby regardless of the meeting’s ordinary lobby settings. The bot must then be explicitly admitted before it can access the conversation.
Microsoft says its detection system uses a combination of infrastructure and behavioural signals observed during the joining process. Once Teams classifies a participant as a bot, the platform labels it and applies the action specified by the organization’s meeting policy.
The existing policy provides a layer of visibility, but it still leaves the final decision to an organizer, co-organizer or, depending on the meeting configuration, another presenter. That creates an opportunity for accidental admission, particularly during large or fast-moving meetings where participants may approve lobby requests without closely examining them.
The new blocking option changes that workflow. Instead of placing a detected bot in the lobby and waiting for a decision, Teams will prevent it from joining meetings covered by the policy.
Microsoft’s announcement says the control will be disabled by default. Administrators will therefore need to evaluate the effect on their organization, enable it and assign the relevant meeting policy to selected users or groups.
This opt-in approach reflects a balance between security and productivity. Many organizations legitimately use external transcription and meeting-intelligence services, so universally enabling the block without preparation could disrupt approved workflows.
How administrators will deploy the protection
The control will appear within the “Manage bots” or external-bot section of the Teams meeting protection settings in the Teams admin center. Administrators will be able to apply it through the organization-wide meeting policy or create targeted policies for particular users and groups.
Targeted deployment could be useful for organizations that want stronger restrictions around specific roles or departments. Senior executives, legal teams, security personnel, research and development groups, finance employees, healthcare workers and staff handling government information may require a stricter policy than users involved in less sensitive collaboration.
Microsoft’s current documentation identifies the PowerShell property responsible for bot handling as ExternalBotAccessMode. The documented options include allowing bots to be treated like ordinary participants and requiring detected bots to remain in the lobby until approved. Microsoft is expected to update its public technical documentation as the new automatic-blocking option becomes broadly available. Microsoft’s external-bot administration guidance explains the existing detection and approval model, while the Set-CsTeamsMeetingPolicy documentation describes the corresponding policy property.
Organizations should avoid enabling the control across every account without first identifying business processes that depend on outside meeting assistants. A staged deployment can help administrators determine whether approved transcription, note-taking or accessibility tools are mistakenly blocked.
The safest approach is likely to begin with a limited pilot involving security, compliance, legal and collaboration-platform teams. Administrators can then compare detected-bot activity with approved services before extending the policy to high-risk departments and, eventually, the wider organization.
Why external meeting bots create security and privacy concerns
Third-party meeting assistants can deliver genuine productivity benefits. They can generate searchable transcripts, summarize decisions, extract action items and help employees revisit discussions without manually taking notes.
Those capabilities also require access to information that may be highly sensitive.
A bot admitted to a meeting may be able to hear participants, process shared screens, capture presentation material, create a transcript and transfer the resulting information to an external service. Depending on the product and its configuration, the data may be retained in infrastructure that sits outside the organization’s Microsoft 365 environment and established compliance controls.
Microsoft identifies several risks associated with external meeting assistants. A bot could record or transcribe a discussion without every participant appreciating that automated capture is taking place. It could also store meeting information in a third-party system beyond the organization’s normal data-governance boundary, introducing privacy, regulatory and data-leakage concerns.
This is not limited to intentionally malicious tools. A legitimate service introduced by an employee, contractor, customer or business partner can still create compliance problems if it has not been reviewed by the organization.
A meeting could involve personal information protected by privacy legislation, health records, payment data, litigation strategy or material corporate information. An unapproved transcript may create a new copy of that material, with different retention periods, access controls, encryption arrangements and geographic storage locations.
Microsoft therefore recommends maintaining bot detection and exercising caution before admitting automated participants. It also advises organizations to restrict lobby admission authority to organizers and co-organizers, limiting the number of people who can approve a detected bot. Microsoft’s guidance also acknowledges that bot detection is not infallible: some bots may evade identification, while a human participant may occasionally be classified incorrectly.
Detection is not a complete security boundary
The automatic-blocking option will improve control over recognized meeting bots, but it should not be treated as a guarantee that every automated participant will be stopped.
Microsoft says its detection mechanisms provide broad coverage, but it acknowledges that some external bots may not be identified. Detection may also occasionally classify a genuine attendee as an automated assistant.
This means the effectiveness of the new policy will depend partly on the accuracy of Microsoft’s classification technology. An automated service that joins using an ordinary external identity or changes its behaviour to avoid known detection signals may not necessarily be treated as a bot.
Organizations should combine the policy with broader meeting controls, including authenticated participation, restrictive lobby configurations, carefully assigned presenter permissions and limitations on anonymous access.
Microsoft’s Teams hardening guidance recommends preventing dial-in participants from bypassing the lobby, disabling anonymous meeting access where business requirements permit and restricting the presenter role to organizers and co-organizers. It also recommends limiting external collaboration to approved domains for environments that do not require unrestricted communication. Microsoft’s Teams attack-surface guidance provides additional configuration recommendations.
These controls involve trade-offs. Disabling anonymous participation may prevent customers, applicants, temporary partners or other legitimate users from joining. Restricting external domains can reduce exposure but create administrative overhead for organizations that regularly collaborate with a large and changing network of third parties.
Teams has become a growing target for social engineering
The bot policy arrives as attackers increasingly turn to collaboration platforms to reach enterprise users outside the traditional email channel.
Microsoft reported that Teams-based phishing increased through the second quarter of 2026. Detected attack volumes rose by an average of 19% between March and April, remained broadly stable in May and climbed by another 10% in June.
Voice phishing conducted through Teams grew even faster. Microsoft observed average weekly malicious call attempts increasing by 31% from April to May and by a further 27% in June. By the end of the quarter, weekly vishing attempts were approximately 80% higher than at the beginning of 2026 and nearly ten times the level observed in mid-2025. Microsoft’s Q2 2026 threat analysis found that technical-support impersonation remained the dominant lure.
In a separate investigation, Microsoft described attackers using cross-tenant Teams communications to pose as corporate IT or helpdesk personnel. Victims were persuaded to launch Quick Assist or another legitimate remote-support tool and grant interactive access to their computers.
Once connected, attackers used legitimate software and native administrative protocols to execute malicious code, move laterally and reach high-value systems. Microsoft observed activity involving Windows Remote Management, commercial remote-management software and Rclone, which can be used to stage or transfer data to external storage.
Microsoft emphasized that the campaign did not depend on a vulnerability in Teams. Instead, attackers exploited legitimate external-collaboration features and convinced users to override warnings and approve subsequent actions. Microsoft’s investigation of the intrusion chain shows why collaboration security cannot rely solely on technical access controls.
The new external-bot policy addresses a different risk from helpdesk impersonation. It will not prevent an attacker operating an ordinary external account from contacting employees, nor will it stop users from granting remote access during a convincing social-engineering call. However, it forms part of a wider effort to give security teams greater control over external identities, automated participants and cross-tenant activity.
Microsoft expands centralized blocking for Teams
Microsoft has also extended Teams blocking into the Microsoft Defender portal. Administrators can use the Tenant Allow/Block List to block external domains and individual sender addresses.
Once configured, these entries prevent new Teams communications from the blocked organization or sender, including chats, calls, channels and meeting interactions. Microsoft currently supports as many as 4,000 domain entries and 200 individual user entries. The blocks do not expire automatically and may take up to 24 hours to become active. Microsoft’s Defender documentation outlines the prerequisites and management process.
The domain and sender controls are complementary to bot management. A domain-level restriction can prevent communication from a known malicious or unwanted organization, while the external-bot policy focuses specifically on participants Teams identifies as automated meeting assistants.
Enterprises with strict security requirements may combine both with allow-list-based external access, permitting collaboration only with approved partner domains. Less restrictive organizations can maintain broader external connectivity while blocking identified malicious senders and applying the automatic bot restriction to meetings hosted by sensitive users.
Auditability and approved-bot lists remain important
Automatic blocking solves the immediate problem of preventing detected bots from joining, but enterprises will also need mechanisms for making exceptions.
Microsoft previously outlined plans for approved-bot lists, reporting and audit capabilities, and more granular controls designed for organizations with different risk requirements. Allow lists would be especially important where an enterprise has formally reviewed a meeting assistant, established contractual data protections and approved it for specific departments.
Audit records can help security and compliance teams answer several important questions: which bots attempted to enter meetings, which users or meetings were targeted, whether a bot was admitted, and whether repeated attempts indicate an unauthorized application or compromised workflow.
Without adequate visibility, an organization may block a service without understanding why employees adopted it. That can lead users to seek less visible workarounds, such as recording meetings locally or uploading audio to unsanctioned AI services after a call.
A mature governance program should therefore combine technical enforcement with a clear process for requesting and approving meeting tools. Employees need to know which services are permitted, what information they may process and how to request an exception when a legitimate business need arises.
What security teams should do now
Before the policy reaches general availability, Microsoft 365 administrators should inventory external meeting assistants currently used across the organization and identify which have received formal security, legal and privacy approval.
They should also review existing meeting policies to determine which users can admit participants from the lobby, whether anonymous users are permitted and whether presenters have more privileges than necessary.
High-risk groups can be selected for an initial deployment. During the pilot, security teams should monitor blocked joins and investigate false positives, while collaboration administrators ensure that approved accessibility and productivity services continue to function.
Organizations should also communicate the change to employees. Users need to understand that a blocked bot may represent an intentional policy decision rather than a Teams malfunction. They should also be warned that not every bot will necessarily be detected and that the absence of a bot label does not prove that a participant is human or trustworthy.
The new policy represents a meaningful improvement because it transfers the final decision from busy meeting organizers to centrally managed security policy. Its effectiveness, however, will depend on careful deployment, reliable detection and integration with broader controls governing external access, anonymous participation, app approval and data handling.
As AI meeting assistants become more common, the central security question is no longer simply whether they are useful. Enterprises must also determine who authorized them, what they can capture, where that information is stored and whether their presence is compatible with the organization’s legal and security obligations.