A suspicious PowerShell command triggers an alert at 09:14. Before you decide what it means, you need the incident, user, device, and evidence that shows whether the script ran. Security Copilot can assemble a first draft quickly. The trouble starts when that draft is read as a finding.
This lesson gives you the working model used throughout the module. You'll place the tool in the investigation, trace the boundaries around it, and write prompts that keep recorded evidence separate from interpretation.
Security Copilot supports investigations
Microsoft Security Copilot is an AI-assisted work surface for security operations. You can ask it to analyze a script, summarize an incident, or profile a threat actor. It uses the security information available through configured integrations and can propose further checks. The analyst still decides what the evidence establishes and whether any response action is appropriate. Security Copilot cannot decide that an account is compromised or authorize a device isolation.
A plugin connects Copilot to a security product's data or capabilities. Grounding means the answer is based on that connected data instead of the model's general knowledge. The distinction matters because a polished answer may still lack a relevant alert, identity record, or threat-intelligence source. Review it in two passes. First, find the evidence behind each material statement. Then check whether that evidence supports the wording of the claim. If either check fails, the statement isn't ready for a case record.
Every investigation crosses boundaries
An assisted investigation is a chain of separate boundaries, and knowing where you are on the chain explains most of what can go wrong. Access flows roughly like this: workspace access and settings, then available compute capacity, then your session and its bounded prompt, then the plugins and data you're permitted to use, then the generated timeline and recommendations, then your verification in the underlying product. Only then comes a documented conclusion or an approved action.
Each link is independent. Being able to open a session does not prove the incident you need is reachable. Having data permission does not guarantee capacity is available to process the request. And a generated recommendation to disable an account carries no authority to disable it. That last gap is the one people collapse under pressure: a technically supported action still has to clear your organization's approval process.
Capacity is the boundary most teams forget. Security Copilot runs on Security Compute Units (SCUs). Eligible Microsoft 365 E5 and E7 customers receive 400 SCUs per month for every 1,000 paid user licenses, capped at 10,000 SCUs per month. Extra capacity is either provisioned in advance at $4 per SCU per month or consumed as pay-as-you-go overage at $6 per consumed SCU. You rarely need to estimate a single investigation's cost. Before relying on the tool operationally, know whether usable capacity exists and who monitors it. Keep a calculated entitlement, an administrator's forecast, and the tenant's observed consumption separate. A forecast is never proof of what was used.
The inclusion formula, in one line
Included SCUs = 400 × (paid E5/E7 licenses ÷ 1,000), capped at 10,000 per month. So 7,500 licenses include 3,000 SCUs. For 30,000 licenses, the 10,000 cap applies, so the entitlement is not 12,000. This is a calculated entitlement. It neither forecasts nor reports the tenant's consumption.
Start standalone or inside the product
Security Copilot comes in two shapes, and picking the right one saves you from transferring identifiers by hand. A standalone experience is a dedicated surface where you open a session and investigate across whatever data your environment exposes. It's the right choice when you're starting from a broad question rather than a specific record. An embedded experience places Copilot inside another security product, so you begin from that product's context: an open incident in Defender XDR, a risky user in Entra, a DLP alert in Purview. Microsoft documents embedded experiences across Defender XDR, Sentinel, Entra, Intune, Purview, and more.
The rule of thumb: start standalone when you have a question and no record open. Start embedded when the record is already in front of you and its native context matters. Either way, the entry point changes the context you get for free. It never changes your responsibility to verify the evidence and to route any operational action through approval. The next lesson, Embedded in Defender, Sentinel, Entra, and Purview, lives entirely in that second shape.
Write prompts with evidence boundaries
A weak security prompt ("look into this alert") invites a fluent guess. A strong one bounds what Copilot may use and what it must return. Microsoft's prompting guidance uses the same four elements you met in Prompting 101, tuned for investigations: Goal (the action and the deliverable), Context (the decision, audience, and time window), Source (the exact evidence it may use), and Expectations (the format, the uncertainty handling, and the next steps). If you internalized the four-element model in The Anatomy of a Great Prompt, you already have the core method. Security work raises the cost of a blurred source.
The new discipline here is labeling uncertainty. Ask Copilot to classify every statement as OBSERVED (directly supported by a record), INFERRED (an unconfirmed interpretation), UNKNOWN (needed but unavailable), or RECOMMENDED (a proposed next check that does not show anything happened). Those four labels stop a plausible interpretation from being copied into a case record as a fact. Pair them with an explicit missing-data rule: "if a requested value is absent from the source, write Not provided." The gaps then stay visible instead of being filled with an estimate.
Sessions, promptbooks, and agents
These three words describe increasing levels of repeatability, and mixing them up sends you to the wrong tool.
Security Copilot ships seven built-in promptbooks: Check impact of an external threat article, Incident investigation, Microsoft User analysis, Suspicious script analysis, Threat actor profile, Threat Intelligence 360 report based on an MDTI article, and Vulnerability impact assessment.
Choose one by matching both its required input and its intended output. Don't reach for Incident investigation just because you have an alert. Its documented purpose starts from a Sentinel or Defender XDR incident and produces a nontechnical executive report.
You can also build a custom promptbook from prompts you've already run. Name it, add placeholders like <script> or <incident>, and keep it shared with Just me until you've tested it against a second input and confirmed no old data leaks through.
