New Outlook + Copilot draft: Sensitivity label "General Document" gets auto-applied inconsistently depending on Insert path — bug or expected behavior?

Environment

Client: New Outlook for Windows

Tenant: Microsoft 365 with Microsoft Purview Information Protection enabled

Affected user: Single user (others in the same tenant do not experience this)

Feature: Copilot in Outlook ("Draft with Copilot")

Summary

When replying to an email in New Outlook using Copilot's "Draft with Copilot" feature, a sensitivity label ("General Document") is sometimes auto-applied and sometimes not, depending on which UI path the user takes to commit the Copilot draft into the message body. This behavior is reproducible on this user account, but I cannot trace it back to any published label policy.

Reproduction steps

Scenario A — Label IS auto-applied

Open a received email and click Reply.

Click "Draft with Copilot" (Alt+i).

Copilot generates a draft preview inside its inline panel.

Click on the generated draft preview → the helper panel closes and the draft text is inserted into the body.

✅ Sensitivity label "General Document" appears in the top-right of the compose window automatically.

Scenario B — Label is NOT auto-applied

Same steps 1–3 as above.

Instead of clicking the draft, click the "Keep" button in the Copilot panel.

The same draft text ends up in the body.

❌ No sensitivity label is applied.

The end state of the message body is identical in both scenarios, but the labeling outcome differs.

Initial behavior before draft is committed

Before any draft is inserted, the compose window shows no label (top-right is empty).

During Copilot generation ("Thinking..." / "Writing email...") state, also no label.

The label only appears at the moment focus returns to the body after the Insert action (Scenario A).

What I have already investigated

The label itself has no auto-labeling rules. The label is configured with Auto-labeling for files and emails = Off. So per-label client-side auto-labeling is not the trigger.General Document

No label policy in the tenant targets this user. I went through all 10 label policies in and checked each one's "Users and groups" assignment. The affected user is not listed in any policy, either directly or (as far as I can see) via group membership.Microsoft Purview → Information Protection → Label policies

Default label for emails is therefore unaccounted for. Since no policy targets this user, there should be no published labels, no default label, and no mandatory labeling enforced for them — yet is being applied.General Document

Audit log search returned no events. I searched for , , against this user's UPN over the time window of the test, with . Zero results. I am aware that Outlook only commits a labeling audit event on send / final save, and the user only saved as draft, so the absence is expected — but it does mean I cannot confirm from the log side.Search-UnifiedAuditLogSensitivityLabelAppliedSensitivityLabelUpdatedMIPLabelRecordType = AipSensitivityLabelActionActionSource

Only this one user is affected. Other users in the tenant performing the same Copilot-in-Outlook draft flow do not see this auto-labeling behavior.

My hypotheses (in descending order of likelihood)

(H1) Stale client-side label policy cache. The affected user may have been in scope of a policy with as the default email label at some point in the past and was later removed. The Office client cache may not have refreshed and is still applying the cached default.General Document

(H2) Hidden group membership. I may have missed a group entry in one of the policies' "Users and groups" assignment lists. Will re-check via PowerShell.

(H3) Bug in the New Outlook + Copilot + sensitivity label integration path. The fact that the Insert click path triggers labeling but the "Keep" button path does not is a strong indicator that the two paths are not invoking the same labeling pipeline, which seems like an implementation inconsistency.

Questions

Is the difference between the Click-to-insert path and the "Keep" button path in Copilot's draft commit a known issue? Are these two UI paths supposed to invoke the same MIP labeling evaluation?

Is there a way to inspect the currently cached client-side label policy on a specific user's machine (registry, file, or Office command) to verify H1?

Is there any tenant-level default label or legacy AIP setting (outside of the standard label policy UI) that could apply a default label to a user who is not in any published label policy?

Has anyone seen this "only one user is affected" pattern, and if so, what was the root cause?

For diagnostic purposes, which / / properties would you recommend to definitively prove or disprove H1 and H3?Get-LabelPolicyGet-LabelGet-OrganizationConfig

What I have for evidence

A 1m 50s screen recording of the full reproduction (both Scenario A and B).

Screenshots of the affected user's compose window in each state (before draft, during generation, after Insert with label, after Keep without label).

Screenshots of each label policy's overview panel (showing the user is not listed).

Confirmation that the "General Document" label itself has no auto-labeling configured.

Happy to share any of the above if helpful. Any pointers appreciated.

Environment

Client: New Outlook for Windows

Tenant: Microsoft 365 with Microsoft Purview Information Protection enabled

Affected user: Single user (others in the same tenant do not experience this)

Feature: Copilot in Outlook ("Draft with Copilot")

Summary

When replying to an email in New Outlook using Copilot's "Draft with Copilot" feature, a sensitivity label ("General Document") is sometimes auto-applied and sometimes not, depending on which UI path the user takes to commit the Copilot draft into the message body. This behavior is reproducible on this user account, but I cannot trace it back to any published label policy.

Reproduction steps

Scenario A — Label IS auto-applied

Open a received email and click Reply.

Click "Draft with Copilot" (Alt+i).

Copilot generates a draft preview inside its inline panel.

Click on the generated draft preview → the helper panel closes and the draft text is inserted into the body.

✅ Sensitivity label "General Document" appears in the top-right of the compose window automatically.

Scenario B — Label is NOT auto-applied

Same steps 1–3 as above.

Instead of clicking the draft, click the "Keep" button in the Copilot panel.

The same draft text ends up in the body.

❌ No sensitivity label is applied.

The end state of the message body is identical in both scenarios, but the labeling outcome differs.

Initial behavior before draft is committed

Before any draft is inserted, the compose window shows no label (top-right is empty).

During Copilot generation ("Thinking..." / "Writing email...") state, also no label.

The label only appears at the moment focus returns to the body after the Insert action (Scenario A).

What I have already investigated

The label itself has no auto-labeling rules. The label is configured with Auto-labeling for files and emails = Off. So per-label client-side auto-labeling is not the trigger.General Document

No label policy in the tenant targets this user. I went through all 10 label policies in and checked each one's "Users and groups" assignment. The affected user is not listed in any policy, either directly or (as far as I can see) via group membership.Microsoft Purview → Information Protection → Label policies

Default label for emails is therefore unaccounted for. Since no policy targets this user, there should be no published labels, no default label, and no mandatory labeling enforced for them — yet is being applied.General Document

Audit log search returned no events. I searched for , , against this user's UPN over the time window of the test, with . Zero results. I am aware that Outlook only commits a labeling audit event on send / final save, and the user only saved as draft, so the absence is expected — but it does mean I cannot confirm from the log side.Search-UnifiedAuditLogSensitivityLabelAppliedSensitivityLabelUpdatedMIPLabelRecordType = AipSensitivityLabelActionActionSource

Only this one user is affected. Other users in the tenant performing the same Copilot-in-Outlook draft flow do not see this auto-labeling behavior.

My hypotheses (in descending order of likelihood)

(H1) Stale client-side label policy cache. The affected user may have been in scope of a policy with as the default email label at some point in the past and was later removed. The Office client cache may not have refreshed and is still applying the cached default.General Document

(H2) Hidden group membership. I may have missed a group entry in one of the policies' "Users and groups" assignment lists. Will re-check via PowerShell.

(H3) Bug in the New Outlook + Copilot + sensitivity label integration path. The fact that the Insert click path triggers labeling but the "Keep" button path does not is a strong indicator that the two paths are not invoking the same labeling pipeline, which seems like an implementation inconsistency.

Questions

Is the difference between the Click-to-insert path and the "Keep" button path in Copilot's draft commit a known issue? Are these two UI paths supposed to invoke the same MIP labeling evaluation?

Is there a way to inspect the currently cached client-side label policy on a specific user's machine (registry, file, or Office command) to verify H1?

Is there any tenant-level default label or legacy AIP setting (outside of the standard label policy UI) that could apply a default label to a user who is not in any published label policy?

Has anyone seen this "only one user is affected" pattern, and if so, what was the root cause?

For diagnostic purposes, which / / properties would you recommend to definitively prove or disprove H1 and H3?Get-LabelPolicyGet-LabelGet-OrganizationConfig

What I have for evidence

A 1m 50s screen recording of the full reproduction (both Scenario A and B).

Screenshots of the affected user's compose window in each state (before draft, during generation, after Insert with label, after Keep without label).

Screenshots of each label policy's overview panel (showing the user is not listed).

Confirmation that the "General Document" label itself has no auto-labeling configured.

Happy to share any of the above if helpful. Any pointers appreciated.