Embedded in Defender, Sentinel, Entra, and Purview

Entra flags a risky sign-in. Intune holds the device record. Eight minutes later, Purview raises a data-loss alert for the same user. The records may be related, but three nearby events don't establish one incident.

Embedded Security Copilot starts inside the product record you already have open. Your job is to begin with the product that owns the evidence, carry identifiers carefully between records, and stop a neat account from becoming stronger than the underlying data.

Which surface owns the evidence?

When you begin from a record, the product that holds that record should anchor your reasoning. Defender XDR and Sentinel both summarize incidents, but they diverge past that point, and Entra, Intune, and Purview each own a different slice of the picture. Route by asking what owns the evidence you need:

Reliability here comes down to two things. First, treat the incident or product record as the authoritative source for identifiers, timestamps, and entities. Don't treat Copilot's prose that way. Second, don't assume a capability that exists in one surface exists in the other: Defender XDR analyzes files and scripts and offers guided response, while Sentinel's documented strengths are incident summaries and natural-language-to-KQL. Misrouting costs more than time: ask a surface a question it doesn't own and you may get a confident answer built on the wrong evidence, or a thin one built on almost none. Choose the surface that owns the evidence, and match the returned incident identifier to your own notes before you trust anything else in the response.

Three finding states

Embedded investigations use three labels that work well across products. Mark each material statement Confirmed when an identified record directly supports it, Plausible when it is a reasonable interpretation that still needs checking, or Unknown when the available records don't establish it. These are analyst-applied labels. Copilot doesn't return them as a built-in field, and precise wording isn't evidence.

A documented capability also doesn't guarantee that a particular record contains every requested field. An Intune device record may omit compliance state. A Purview DLP alert may identify a user while leaving out the device or destination. Ask for those fields, but tell Copilot what to do when they are absent: "Use only fields available in the selected record. For each requested field that is absent, return Not available, and do not infer a value."

Classification matters after the first review because statements move. A Confirmed line may be copied into a case record or used by an analyst who never opened the source alert. If a Plausible interpretation is promoted to Confirmed, the later decision rests on evidence that wasn't present. Keep the weaker label until another record closes the gap.

Generated KQL starts as draft

Ask Copilot to turn a hunting question into a Kusto Query Language (KQL) query and you'll get syntactically valid text in seconds. Syntactically valid text can still be wrong. Generated KQL does not establish that the proposed tables hold the data, that the fields exist in your environment, that the time filter matches the incident, that entity values use the right format, or that the returned rows support your hypothesis.

Run it through a short validation loop before you interpret a single row. Confirm the full date, time boundary, and time zone: "between 09:00 and 10:00" with no calendar date is ambiguous and unsafe. Check the proposed tables and fields against your available schema. Decide whether the logic needs both entities in one record (AND) or either entity (OR), because that changes the meaning entirely. Then run the query in the authorized query experience, compare the returned records against the incident timeline, and revise only the condition that proved defective.

Sentinel's natural-language-to-KQL is documented as Preview. That status doesn't mean the output is unusable, but you still need to check the schema, the logic, and the result before you rely on it.

Correlation across products needs proof

Separate embedded sessions don't automatically share prior findings. Use a manual worksheet for correlation, with one row per source and columns for the product, exact record ID, user, device, timestamp, confirmed evidence, interpretation, missing evidence, and correlation status. Move identifiers and findings into it deliberately.

A cross-product relationship is defensible when the identifiers and relevant times align and the records support the link. Suppose Entra and Purview both identify [email protected], while Entra and Intune both identify device WIN-ENG-042, with events minutes apart. The shared user and device are Confirmed. If the Purview alert has no device field, you still can't place the DLP activity on that machine. That link remains Unknown, and a single common compromise remains Plausible until another record supports it. Nearby timestamps support a hypothesis. They don't establish causation.

Recommendation is not authorization

Defender XDR's guided response suggests steps for an analyst to consider. It doesn't approve them. A recommendation such as "isolate the device" may read like an instruction, but the tool doesn't know your change process and has no authority to carry out the action. Before changing a user, device, file, or policy, verify the target, preserve the supporting evidence, understand the expected effect and blast radius, and obtain the required approval.

Record proposed actions as "awaiting approval." Mark one complete only after the action occurred and an authorized person signed off. A later reviewer should be able to distinguish what the evidence established, what the analyst recommended, and what the organization approved.