Microsoft is developing a Microsoft Purview Data Loss Prevention control that will stop Microsoft 365 Copilot and Copilot Chat from processing emails sent from outside an organization, with preview targeted for June 2026 and general availability planned for January 2027. The move sounds narrow, almost administrative, but it lands directly on one of the hardest problems in enterprise AI: the inbox is both the richest workplace data source and the least trustworthy one. Microsoft is not merely adding another compliance switch. It is acknowledging that Copilot’s usefulness depends on deciding which corporate knowledge is safe to reason over in the first place.
For most of Copilot’s short enterprise life, Microsoft’s core reassurance has been that the assistant respects existing Microsoft 365 permissions. If a user cannot open a file or email, Copilot should not be able to summarize it, cite it, or use it as grounding material. That remains essential, but the new Purview DLP capability points to a different axis of control: not just who can access information, but where that information came from.
External email is a special case because it arrives with implied legitimacy and very little inherent trust. It may be from a supplier, a customer, a partner, a regulator, a mailing list, or an attacker impersonating any of the above. In the pre-AI workplace, users still had to read, copy, forward, and act on those messages manually. In the Copilot workplace, the system can summarize, extract, compare, and incorporate those messages into larger answers at machine speed.
That shift changes the risk model. An externally originated message is no longer just something a user might read; it can become a hidden ingredient in a generated answer, a meeting brief, a draft response, or an agentic workflow. Microsoft’s planned control effectively says that some organizations may want Copilot to treat outside email as untrusted input by default, even when the user has legitimate mailbox access.
The timing matters. The roadmap item was created in May 2026, updated on June 24, 2026, and is still marked as in development. That makes this less a finished compliance feature than a public marker of where Microsoft thinks AI governance is heading: toward real-time controls wrapped around model grounding, not just after-the-fact audit trails.
That is the uncomfortable reality behind this Purview expansion. An external email can contain a legitimate invoice, a hostile instruction, a confidential negotiation position forwarded from a partner, or cleverly formatted text designed to influence downstream summaries. The user may never ask Copilot to “trust” the email. They may simply ask for a recap of a thread, a list of action items, or a draft reply.
The distinction between reading and processing matters. Users can still read external mail; this roadmap item is about preventing Microsoft 365 Copilot and Copilot Chat from using that mail as material for AI responses. In other words, the control does not quarantine the message from Exchange. It limits whether the AI layer can reason over it.
That distinction will be important for administrators explaining the feature internally. This is not a spam filter, an anti-phishing control, or a transport rule replacement. It is a model-grounding restriction that treats external-origin content as a category of data risk.
That is why Microsoft has been steadily repositioning Purview as a control plane for Copilot. Earlier DLP controls focused on restricting Copilot responses when prompts contained sensitive information, limiting web searches when sensitive data appeared in user input, and preventing Copilot from processing sensitivity-labeled enterprise content. This external-email feature extends the same logic to sender provenance.
The practical result is a more granular definition of what Copilot is allowed to know at runtime. A human may be permitted to open a message from an outside sender, but the AI assistant may be prohibited from using that message as grounding data. That is an important architectural separation, and one that many organizations will likely come to see as necessary rather than optional.
It also shows how Microsoft is trying to avoid building a separate “AI security console” for every Copilot behavior. By routing these controls through Purview DLP, Redmond is telling compliance teams that Copilot governance belongs inside the same policy fabric they already use for email, files, endpoints, and cloud data.
Real-time enforcement suggests that Microsoft wants Purview to sit in the path between the user’s Copilot request and the content Copilot is allowed to process. If the policy detects external email as a prohibited source, Copilot should not use that material to answer. For security teams, that is the difference between observability and control.
The implementation details will matter enormously. Administrators will want to know whether the restriction applies to all external senders, whether trusted domains can be exempted, how forwarded messages are classified, and whether external-origin content inside long internal threads remains blocked. They will also want clarity on what Copilot tells the user when relevant external content exists but cannot be processed.
Those user-facing moments can make or break controls like this. If Copilot simply gives incomplete answers without explaining that DLP blocked certain sources, users may distrust the tool. If it reveals too much about policy logic, attackers may learn how to craft around it. Microsoft has to thread that needle carefully.
Recent reporting around Copilot and labeled emails has not helped Microsoft’s case. Bugs and advisory language around Copilot Chat processing confidential emails despite policies have reinforced the fear that AI assistants can turn small configuration assumptions into visible data exposure. Even when problems are fixed, the reputational lesson remains: enterprises will not accept “trust us, permissions are respected” as the final answer.
The external-email DLP control is therefore partly a risk-reduction feature and partly a confidence-restoration feature. It gives Microsoft something concrete to point to when customers ask how they can limit Copilot’s interaction with untrusted inputs. It also helps Microsoft preserve the broader Copilot adoption story by giving cautious organizations a way to say yes more selectively.
That is the strategic bargain Microsoft keeps making with Purview. The company wants Copilot to be ubiquitous, but ubiquity requires administrators to believe they can impose meaningful boundaries. Every new DLP condition, every label-aware restriction, and every policy-driven Copilot block is a small concession to the reality that enterprise AI cannot be governed by optimism.
Copilot forces a more subtle distinction. Internal data usually reflects some combination of corporate authorship, corporate permissions, and corporate governance. External email may reflect none of those things. It may be contractually important, legally discoverable, and operationally necessary, but it is not authored inside the same trust boundary.
That matters because large language models are not merely search boxes. They interpret instructions, infer intent, and transform source material into new text. An external email’s content can therefore influence not just what Copilot retrieves, but how Copilot frames the answer. A poisoned message does not need to hack Exchange to create risk; it only needs to be considered relevant at the wrong moment.
Blocking Copilot from processing external mail is a blunt response, but blunt controls are sometimes what regulated environments need. A bank, law firm, defense contractor, or healthcare provider may decide that no productivity gain justifies letting an AI assistant reason over untrusted inbound messages. Other organizations may apply the control only to certain users, departments, or high-risk workflows if Microsoft exposes that granularity.
Copilot Studio has become Microsoft’s bridge between general-purpose AI and organization-specific workflows. Companies can build agents to answer policy questions, triage requests, retrieve records, or guide employees through internal processes. Once those agents are published into Microsoft 365 Copilot, they participate in the same workplace fabric as chat, email, and documents.
That makes data-source restrictions more consequential. If an agent can use external email as grounding material, it might incorporate a vendor’s claim, a customer’s demand, or an attacker’s planted instruction into an answer that feels internal and authoritative. The user may see the output as “what the company knows,” not “what someone outside the company emailed us.”
Microsoft’s inclusion of Copilot Studio agents signals that the company understands this is not just a chat feature. It is an AI platform control. As Copilot evolves from assistant to action layer, controls over what the system may process become controls over what the business may automate.
For administrators, the first task will be deciding whether external email is truly untrusted across the board. Many organizations rely heavily on outside messages for sales, support, legal review, procurement, recruiting, and customer success. A blanket restriction could reduce Copilot’s usefulness in precisely the workflows where email summarization is most attractive.
The second task will be explaining the user experience. If employees are used to asking Copilot to summarize an inbox, draft replies, or pull together project context, they may notice missing pieces. The security team will need a clear internal narrative: Copilot is not broken; it is being prevented from using external-origin content because that content carries a different risk profile.
The third task will be testing edge cases. External messages become internal threads. Attachments are saved to SharePoint. Text is copied into Teams. Customer emails are forwarded by account managers. If Microsoft’s enforcement depends on message metadata, storage location, sensitivity labels, or content lineage, organizations will need to understand where the protection holds and where it fades.
The preview phase should not be treated as a checkbox. Administrators should test with real mailbox patterns, not artificial lab messages. That means long threads with mixed internal and external participants, delegated mailboxes, shared mailboxes, distribution lists, guest collaboration scenarios, and Copilot Studio agents that retrieve or summarize email-derived context.
Legal and compliance teams should also be in the room. External communications often carry contractual, regulatory, and litigation significance. Preventing Copilot from processing them may be desirable in some contexts and problematic in others, especially if employees expect AI assistance for discovery, customer support, or regulated response workflows.
Microsoft’s roadmap dates should be read as planning targets, not immutable promises. Roadmap items can slip, narrow, or change scope before release. But the June 24 update shows the feature remains active, and the January 2027 GA target gives enterprise tenants a concrete calendar around which to plan pilots.
Copilot still depends on identity hygiene, least privilege, SharePoint governance, Teams sprawl control, sensitivity labeling, retention policies, and user education. It still raises questions about auditability, explainability, and how employees should verify generated output. Blocking external email processing is useful, but it does not solve oversharing inside the tenant.
The feature also does not make external email harmless. Users can still open malicious links, download attachments, respond to spoofed requests, and copy external content into internal documents. If a user manually moves outside content into an internal location, organizations will need to know whether their other labels and DLP policies catch the risk downstream.
That is why the strongest interpretation of this roadmap item is not “Microsoft solved external-email risk.” It is “Microsoft is giving administrators one more lever to reduce Copilot’s exposure to untrusted content.” That lever belongs in a broader governance program, not on a shelf marked AI compliance magic.
That is a profound change. Administrators are no longer just managing access to documents; they are managing the conditions under which documents become model context. They are no longer just preventing data exfiltration; they are preventing unsafe synthesis. They are no longer just applying labels for humans; they are applying labels and policies that shape machine behavior.
Purview is where Microsoft is trying to locate that job. The company could have built Copilot-specific toggles scattered across Outlook, Teams, SharePoint, Copilot Studio, and the Microsoft 365 admin center. Instead, it is increasingly making Purview the policy vocabulary for AI-era data controls.
That consolidation is sensible, but it raises the stakes for Purview literacy. Organizations that ignored DLP because it seemed too complex or too compliance-centric may find that the same tooling now determines whether Copilot can be deployed safely. AI adoption will drag data governance out of the back office.
The best pilots will begin with a narrow group of users and a clear hypothesis. Security teams should measure what breaks, what improves, and which business processes genuinely require Copilot access to outside messages. Compliance teams should compare the new control with existing sensitivity-label and DLP strategies rather than treating it as a standalone feature.
Most importantly, IT should talk to users before enforcement becomes a surprise. Copilot restrictions are more likely to succeed when employees understand that the tool is being constrained because external email is a hostile and ambiguous data source, not because the organization distrusts productivity software. Good governance is partly technical and partly cultural.
Microsoft Moves the Copilot Boundary From Permissions to Provenance
For most of Copilot’s short enterprise life, Microsoft’s core reassurance has been that the assistant respects existing Microsoft 365 permissions. If a user cannot open a file or email, Copilot should not be able to summarize it, cite it, or use it as grounding material. That remains essential, but the new Purview DLP capability points to a different axis of control: not just who can access information, but where that information came from.External email is a special case because it arrives with implied legitimacy and very little inherent trust. It may be from a supplier, a customer, a partner, a regulator, a mailing list, or an attacker impersonating any of the above. In the pre-AI workplace, users still had to read, copy, forward, and act on those messages manually. In the Copilot workplace, the system can summarize, extract, compare, and incorporate those messages into larger answers at machine speed.
That shift changes the risk model. An externally originated message is no longer just something a user might read; it can become a hidden ingredient in a generated answer, a meeting brief, a draft response, or an agentic workflow. Microsoft’s planned control effectively says that some organizations may want Copilot to treat outside email as untrusted input by default, even when the user has legitimate mailbox access.
The timing matters. The roadmap item was created in May 2026, updated on June 24, 2026, and is still marked as in development. That makes this less a finished compliance feature than a public marker of where Microsoft thinks AI governance is heading: toward real-time controls wrapped around model grounding, not just after-the-fact audit trails.
The Inbox Is the Original Prompt-Injection Surface
Security teams have spent the past two years worrying about prompt injection in documents, websites, and SaaS connectors, but email may be the most familiar delivery mechanism of all. It is already where phishing, business email compromise, malicious links, poisoned attachments, and social engineering converge. Add Copilot, and the message body can also become a set of instructions that an AI system might ingest while trying to be helpful.That is the uncomfortable reality behind this Purview expansion. An external email can contain a legitimate invoice, a hostile instruction, a confidential negotiation position forwarded from a partner, or cleverly formatted text designed to influence downstream summaries. The user may never ask Copilot to “trust” the email. They may simply ask for a recap of a thread, a list of action items, or a draft reply.
The distinction between reading and processing matters. Users can still read external mail; this roadmap item is about preventing Microsoft 365 Copilot and Copilot Chat from using that mail as material for AI responses. In other words, the control does not quarantine the message from Exchange. It limits whether the AI layer can reason over it.
That distinction will be important for administrators explaining the feature internally. This is not a spam filter, an anti-phishing control, or a transport rule replacement. It is a model-grounding restriction that treats external-origin content as a category of data risk.
DLP Is Becoming the Policy Engine for AI Memory
Microsoft Purview DLP has traditionally been about preventing sensitive data from leaving approved boundaries. Credit card numbers, national identifiers, health data, source code, and labeled documents could trigger warnings, blocks, audits, or policy tips. Copilot changes the problem because data may “leave” in a less literal way: by being transformed into an answer, embedded into a summary, or combined with other enterprise context.That is why Microsoft has been steadily repositioning Purview as a control plane for Copilot. Earlier DLP controls focused on restricting Copilot responses when prompts contained sensitive information, limiting web searches when sensitive data appeared in user input, and preventing Copilot from processing sensitivity-labeled enterprise content. This external-email feature extends the same logic to sender provenance.
The practical result is a more granular definition of what Copilot is allowed to know at runtime. A human may be permitted to open a message from an outside sender, but the AI assistant may be prohibited from using that message as grounding data. That is an important architectural separation, and one that many organizations will likely come to see as necessary rather than optional.
It also shows how Microsoft is trying to avoid building a separate “AI security console” for every Copilot behavior. By routing these controls through Purview DLP, Redmond is telling compliance teams that Copilot governance belongs inside the same policy fabric they already use for email, files, endpoints, and cloud data.
Microsoft’s Real-Time Claim Is the Feature’s Most Important Word
The roadmap language calls this a real-time control, and that is not a throwaway adjective. In AI governance, timing is everything. A policy that logs risky Copilot behavior after the response has been generated may help investigators, but it does not protect the user from seeing sensitive or manipulated output in the moment.Real-time enforcement suggests that Microsoft wants Purview to sit in the path between the user’s Copilot request and the content Copilot is allowed to process. If the policy detects external email as a prohibited source, Copilot should not use that material to answer. For security teams, that is the difference between observability and control.
The implementation details will matter enormously. Administrators will want to know whether the restriction applies to all external senders, whether trusted domains can be exempted, how forwarded messages are classified, and whether external-origin content inside long internal threads remains blocked. They will also want clarity on what Copilot tells the user when relevant external content exists but cannot be processed.
Those user-facing moments can make or break controls like this. If Copilot simply gives incomplete answers without explaining that DLP blocked certain sources, users may distrust the tool. If it reveals too much about policy logic, attackers may learn how to craft around it. Microsoft has to thread that needle carefully.
The Feature Also Protects Microsoft From Copilot’s Own Success
Microsoft has pushed Copilot as a productivity layer that understands work across email, chat, meetings, files, and organizational context. That promise is commercially powerful precisely because the assistant can synthesize information employees would otherwise have to chase manually. But the same breadth creates an obvious governance challenge: the more Copilot can see, the more consequential every permission mistake and content-origin ambiguity becomes.Recent reporting around Copilot and labeled emails has not helped Microsoft’s case. Bugs and advisory language around Copilot Chat processing confidential emails despite policies have reinforced the fear that AI assistants can turn small configuration assumptions into visible data exposure. Even when problems are fixed, the reputational lesson remains: enterprises will not accept “trust us, permissions are respected” as the final answer.
The external-email DLP control is therefore partly a risk-reduction feature and partly a confidence-restoration feature. It gives Microsoft something concrete to point to when customers ask how they can limit Copilot’s interaction with untrusted inputs. It also helps Microsoft preserve the broader Copilot adoption story by giving cautious organizations a way to say yes more selectively.
That is the strategic bargain Microsoft keeps making with Purview. The company wants Copilot to be ubiquitous, but ubiquity requires administrators to believe they can impose meaningful boundaries. Every new DLP condition, every label-aware restriction, and every policy-driven Copilot block is a small concession to the reality that enterprise AI cannot be governed by optimism.
External Email Is Not Just Outside Data; It Is Outside Intent
The most interesting part of this roadmap item is that it treats external mail as categorically different from internal content. That sounds obvious, but many enterprise systems have historically blurred that line once a message enters a mailbox. If it is in Exchange Online and the user can access it, it becomes part of the user’s information universe.Copilot forces a more subtle distinction. Internal data usually reflects some combination of corporate authorship, corporate permissions, and corporate governance. External email may reflect none of those things. It may be contractually important, legally discoverable, and operationally necessary, but it is not authored inside the same trust boundary.
That matters because large language models are not merely search boxes. They interpret instructions, infer intent, and transform source material into new text. An external email’s content can therefore influence not just what Copilot retrieves, but how Copilot frames the answer. A poisoned message does not need to hack Exchange to create risk; it only needs to be considered relevant at the wrong moment.
Blocking Copilot from processing external mail is a blunt response, but blunt controls are sometimes what regulated environments need. A bank, law firm, defense contractor, or healthcare provider may decide that no productivity gain justifies letting an AI assistant reason over untrusted inbound messages. Other organizations may apply the control only to certain users, departments, or high-risk workflows if Microsoft exposes that granularity.
Agents Make the Boundary More Urgent
The roadmap item explicitly says the capability extends to Microsoft 365 Copilot and agents built in Copilot Studio that are published to Microsoft 365 Copilot. That clause deserves attention because agents are where today’s chat risks become tomorrow’s automation risks. A chatbot that summarizes an external email can mislead a user; an agent that acts on one can move the mistake into a business process.Copilot Studio has become Microsoft’s bridge between general-purpose AI and organization-specific workflows. Companies can build agents to answer policy questions, triage requests, retrieve records, or guide employees through internal processes. Once those agents are published into Microsoft 365 Copilot, they participate in the same workplace fabric as chat, email, and documents.
That makes data-source restrictions more consequential. If an agent can use external email as grounding material, it might incorporate a vendor’s claim, a customer’s demand, or an attacker’s planted instruction into an answer that feels internal and authoritative. The user may see the output as “what the company knows,” not “what someone outside the company emailed us.”
Microsoft’s inclusion of Copilot Studio agents signals that the company understands this is not just a chat feature. It is an AI platform control. As Copilot evolves from assistant to action layer, controls over what the system may process become controls over what the business may automate.
Admins Will Still Need to Do the Boring Work
This feature will not save organizations from poor data hygiene. If anything, it will expose how much of Copilot governance depends on classification, identity, mail flow, and policy design that many tenants have only partially implemented. A DLP switch is only as useful as the organization’s understanding of what it wants to block and why.For administrators, the first task will be deciding whether external email is truly untrusted across the board. Many organizations rely heavily on outside messages for sales, support, legal review, procurement, recruiting, and customer success. A blanket restriction could reduce Copilot’s usefulness in precisely the workflows where email summarization is most attractive.
The second task will be explaining the user experience. If employees are used to asking Copilot to summarize an inbox, draft replies, or pull together project context, they may notice missing pieces. The security team will need a clear internal narrative: Copilot is not broken; it is being prevented from using external-origin content because that content carries a different risk profile.
The third task will be testing edge cases. External messages become internal threads. Attachments are saved to SharePoint. Text is copied into Teams. Customer emails are forwarded by account managers. If Microsoft’s enforcement depends on message metadata, storage location, sensitivity labels, or content lineage, organizations will need to understand where the protection holds and where it fades.
The Preview-to-GA Gap Is a Warning to Pilot Carefully
Preview in June 2026 and general availability in January 2027 gives customers a useful but not generous runway. Six months is enough time to test policy behavior, gather user feedback, and revise governance documents. It is not enough time to fix a sprawling Microsoft 365 permissions estate if Copilot has already exposed how messy it is.The preview phase should not be treated as a checkbox. Administrators should test with real mailbox patterns, not artificial lab messages. That means long threads with mixed internal and external participants, delegated mailboxes, shared mailboxes, distribution lists, guest collaboration scenarios, and Copilot Studio agents that retrieve or summarize email-derived context.
Legal and compliance teams should also be in the room. External communications often carry contractual, regulatory, and litigation significance. Preventing Copilot from processing them may be desirable in some contexts and problematic in others, especially if employees expect AI assistance for discovery, customer support, or regulated response workflows.
Microsoft’s roadmap dates should be read as planning targets, not immutable promises. Roadmap items can slip, narrow, or change scope before release. But the June 24 update shows the feature remains active, and the January 2027 GA target gives enterprise tenants a concrete calendar around which to plan pilots.
This Is Not a Substitute for Securing Copilot
There is a temptation to treat every new Purview feature as another brick in an eventual wall that will make Copilot safe by construction. That is not how enterprise security works. DLP controls reduce specific risks; they do not erase the broader problem of giving AI systems broad access to business context.Copilot still depends on identity hygiene, least privilege, SharePoint governance, Teams sprawl control, sensitivity labeling, retention policies, and user education. It still raises questions about auditability, explainability, and how employees should verify generated output. Blocking external email processing is useful, but it does not solve oversharing inside the tenant.
The feature also does not make external email harmless. Users can still open malicious links, download attachments, respond to spoofed requests, and copy external content into internal documents. If a user manually moves outside content into an internal location, organizations will need to know whether their other labels and DLP policies catch the risk downstream.
That is why the strongest interpretation of this roadmap item is not “Microsoft solved external-email risk.” It is “Microsoft is giving administrators one more lever to reduce Copilot’s exposure to untrusted content.” That lever belongs in a broader governance program, not on a shelf marked AI compliance magic.
Redmond Is Quietly Defining the AI Admin Job
The Copilot era is creating a new kind of Microsoft 365 administrator. The old job was partly about mailboxes, licenses, groups, devices, and retention. The new job includes deciding what an AI assistant can infer, summarize, combine, and refuse to process.That is a profound change. Administrators are no longer just managing access to documents; they are managing the conditions under which documents become model context. They are no longer just preventing data exfiltration; they are preventing unsafe synthesis. They are no longer just applying labels for humans; they are applying labels and policies that shape machine behavior.
Purview is where Microsoft is trying to locate that job. The company could have built Copilot-specific toggles scattered across Outlook, Teams, SharePoint, Copilot Studio, and the Microsoft 365 admin center. Instead, it is increasingly making Purview the policy vocabulary for AI-era data controls.
That consolidation is sensible, but it raises the stakes for Purview literacy. Organizations that ignored DLP because it seemed too complex or too compliance-centric may find that the same tooling now determines whether Copilot can be deployed safely. AI adoption will drag data governance out of the back office.
The January 2027 Switch Will Reward Tenants That Prepare Early
The concrete lesson from this roadmap item is not that every organization should block Copilot from external email forever. It is that every organization should decide, explicitly, whether external-origin content belongs in AI grounding. Silence is a policy too, and in many tenants it currently means Copilot can operate wherever permissions and existing controls allow.The best pilots will begin with a narrow group of users and a clear hypothesis. Security teams should measure what breaks, what improves, and which business processes genuinely require Copilot access to outside messages. Compliance teams should compare the new control with existing sensitivity-label and DLP strategies rather than treating it as a standalone feature.
Most importantly, IT should talk to users before enforcement becomes a surprise. Copilot restrictions are more likely to succeed when employees understand that the tool is being constrained because external email is a hostile and ambiguous data source, not because the organization distrusts productivity software. Good governance is partly technical and partly cultural.
The Inbox Gets Its AI Seatbelt
Microsoft’s planned external-email restriction is a small roadmap item with a large architectural message, and the practical implications are already clear.- Organizations will be able to use Microsoft Purview DLP to stop Microsoft 365 Copilot and Copilot Chat from processing emails sent by external senders.
- The feature is currently planned for preview in June 2026 and general availability in January 2027 for worldwide standard multi-tenant cloud customers.
- The control applies not only to Microsoft 365 Copilot and Copilot Chat, but also to Copilot Studio agents published into Microsoft 365 Copilot.
- The feature is aimed at real-time prevention, which matters because post-event auditing cannot undo a generated response that already exposed or relied on risky content.
- Administrators should test mixed email threads, shared mailboxes, forwarded messages, and agent scenarios before assuming the policy behaves the way their risk model requires.
- The control should be treated as one layer in a broader Copilot governance program that includes permissions cleanup, sensitivity labeling, DLP tuning, and user education.
References
- Primary source: Microsoft 365 Roadmap
Published: 2026-06-24T23:15:55.6812517Z
Loading…
www.microsoft.com - Official source: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: blog-en.topedia.com
Loading…
blog-en.topedia.com - Related coverage: cyberpress.org
Loading…
cyberpress.org - Official source: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com - Related coverage: techradar.com
Microsoft admits an Office bug exposed confidential user emails to Copilot | TechRadar
Copilot was ignoring 'confidential' email flagswww.techradar.com
- Related coverage: windowscentral.com
Microsoft 365 Copilot Chat summarized confidential emails | Windows Central
Microsoft confirms a Copilot bug that exposed and summarized confidential emails, bypassing security policies.www.windowscentral.com - Related coverage: tomsguide.com
Microsoft confirms Copilot bug let its AI read sensitive and confidential emails | Tom's Guide
Microsoft confirmed a bug in Copilot was letting the AI assistant read and summarize confidential emails.www.tomsguide.com - Official source: cdn-dynmedia-1.microsoft.com
Slide 1: Microsoft Purview Data Governance Roadmap H1 CY2025
PDF documentcdn-dynmedia-1.microsoft.com
- Related coverage: itpro.com
Loading…
www.itpro.com
