"Is it safe to paste this into Copilot?" is really five questions. Each one has a different owner and a different answer. Separating them shows you what Microsoft controls, what your administrator must confirm, and what remains your responsibility.
Five data objects in one interaction
A single Copilot exchange involves five distinct things, and a fact about one does not transfer to the others:
People often collapse all five objects into "my data" and apply one reassuring fact to everything. Microsoft's documented statement that Microsoft 365 Copilot data is not used to train large language models answers the training question only. It doesn't tell you whether the interaction is retained, saved as memory, copied into a document, or subject to another control.
Where does a prompt travel?
You don't need to trace every network packet. You need one checkpoint at each stage. An organizational interaction can be read as five steps, each with a question you can answer:
This model supports responsible use. It does not describe every tenant. An app, agent, connector, or memory feature may behave differently, and only an administrator can confirm your organization's configuration. You run the interaction-level checkpoints. Your administrator confirms the settings behind them.
Enterprise Data Protection has limits
Enterprise Data Protection (EDP) is Microsoft's protection architecture for organizational use of Microsoft 365 Copilot and Copilot Chat. It applies organizational identity, existing data-access controls, security, and compliance controls to the interaction. Those protections matter, but their scope is specific.
EDP does not give your identity access to a document it couldn't already open. It doesn't make every piece of organizational data appropriate for a prompt, guarantee an accurate answer, or remove your organization's retention obligations. A personal, consumer Copilot session isn't equivalent to a protected organizational session. The two are documented separately, so confirm the permissions, retention, and administrative controls for the session you're using.
Encryption is another necessary protection with a defined job. Microsoft documents that Microsoft 365 Copilot data is encrypted in transit and at rest. Encryption protects the data while it moves and while it's stored. It doesn't decide who should have access, remove unnecessary information from a prompt, or verify the answer. A protected service can still produce a bad result when it receives the wrong task or too much data.
Data minimization is your part of the control
Data minimization means using only the information the task needs. No setting, license, or architecture performs that judgment for you. If an account number wasn't needed for the task, a protected service still shouldn't receive it.
Before sending a prompt, remove names, case numbers, account numbers, passwords, API keys, and personal details the answer doesn't require. Use sanitized or fictional data when you're testing an approach. Point Copilot to the exact source, and ask it to write "Not provided" when information is missing. A short relevant excerpt is often enough. Also confirm that the account and surface you're using are approved for the task.
A good test is simple. The response shouldn't reproduce a name or number the task never needed. If it does, correct the source prompt as well as the output.
A worked example: sanitize, then summarize
An HR coordinator wants Copilot to summarize a draft leave policy for employees. The original document is stuffed with employee names, case numbers, and medical details, none of which a general policy summary needs. So before prompting, they delete all of it and keep only the policy mechanics: eligibility, request timing, the approval route, exceptions, and the fact that the draft never states a retention period.
Then they ask Copilot to summarize only that sanitized excerpt, in plain language, writing "Not specified in the excerpt" anywhere the source is silent. The result is useful: it preserves the real numbers, reports the missing retention period instead of inventing one, and can't reproduce the names or case numbers, because they were never in the prompt to begin with.
Two facts stay separate the entire time: the policy's missing retention period (a gap in the document) and the interaction's retention (a tenant setting your admin owns). Confusing those two is how a summary task turns into a privacy question no one meant to ask.
One more checkpoint before you paste anything nonpublic: confirm you're in the session you think you're in. Open your account control and check the address. Confirm it's your work or school account, and rule out a personal one. That confirms your identity. It does not prove the tenant's retention, memory, or regional settings, which still need your admin. If a personal address shows up where you expected a work one, stop before you type.
Keep each responsibility with its owner
Privacy questions become muddled when everyone assumes someone else handled them. Microsoft owns the architecture, including encryption in transit and at rest, the model-training exclusion, and the protections provided by Enterprise Data Protection. Your administrator owns tenant settings you can't see in the chat window, such as retention policy, memory, approved surfaces, and regional residency configuration.
You control the task you choose and the information you include. Settings managed by Microsoft or your administrator can't remove data that the prompt never needed. When you're unsure, ask the owner of the specific question: Microsoft documentation for architecture, your administrator for tenant settings, and yourself whether the prompt has been minimized.
