Lesson 10 — Security Copilot Best Practices

Learning objectives

• Prepare Security Copilot correctly.
• Use a repeatable prompt method.
• Inspect plugins, process logs and sources.
• Validate evidence across products.
• Control high-impact actions.
• Document accountability and uncertainty.
• Improve workflows continuously.

Begin with the investigation objective

Define the security question, intended audience and decision the output must support before opening a session.

Use Security Copilot for the right task

Use Copilot to accelerate analysis, explanation, correlation and drafting rather than replacing evidence collection or accountable decisions.

Confirm the active tenant

Check that the current tenant contains the security data required for the task.

Confirm the workspace

For Sentinel and other scoped products, verify that the correct workspace, subscription or environment is selected.

Check data health

Confirm connectors, sensors, retention, onboarding and product health before treating missing evidence as proof that nothing happened.

Apply least privilege

Assign only the Security Copilot and connected-product permissions needed for the analyst’s role.

Separate platform and product access

Access to Security Copilot does not automatically grant access to Defender, Sentinel, Entra, Intune, Purview or other product data.

Choose relevant plugins

Enable the plugins needed for the task and avoid unnecessary sources that can complicate selection or scope.

Review plugin settings

Check workspaces, tenants, filters, authentication and other plugin-specific configuration.

Start a clean session

Use a new session for a new incident or materially different investigation to avoid context drift.

Name sessions clearly

Use incident IDs, dates or investigation subjects so sessions can be found and reviewed later.

Protect session content

Treat prompts, responses, uploaded files, pinned items, exports and shared links as security records.

Use the four prompt elements

Build prompts around goal, context, source and expectations.

Use strong action verbs

Start with instructions such as summarise, compare, explain, investigate, correlate, generate or validate.

State the security context

Explain why the information is needed and how the result will be used.

Identify the source

Specify the incident, user, device, alert, file, workspace, time range or plugin that should ground the response.

Set output expectations

Define the format, audience, depth, evidence requirements and desired next steps.

Keep prompts neutral

Do not write compromise, malicious intent or guilt into the question before the evidence is reviewed.

Control the scope

Limit time range, entities, products and expected output to reduce noise.

Break complex work into stages

Use separate prompts for orientation, evidence collection, analysis, validation and reporting.

Use iterative prompting

Refine the result through focused follow-up questions rather than forcing every task into one prompt.

Ask for evidence

Require supporting alerts, entities, logs, source links or product records for major conclusions.

Ask for uncertainty

Request missing context, conflicting evidence, limitations and anything that cannot be verified.

Ask for alternatives

Compare malicious and legitimate explanations for suspicious behaviour.

Ask for confidence

Require an evidence-based confidence level rather than accepting a fluent conclusion.

Review the process log

Inspect the actions, selected capabilities, plugins, sources and processing time used for the response.

Open direct source links

Validate claims in the original Microsoft security product or approved external source.

Validate timestamps

Check time zones, sequence, gaps and whether events genuinely overlap.

Validate identities

Confirm users, service principals, administrators and authentication context.

Validate devices

Confirm device IDs, hostnames, owners, operating systems and endpoint timelines.

Validate network context

Check IP ownership, VPNs, proxies, domains, ports and expected network paths.

Validate email evidence

Confirm delivery, sender authentication, URLs, attachments, clicks and post-delivery actions.

Validate cloud evidence

Separate posture findings and attack paths from observed exploitation.

Validate data-security evidence

Confirm users, locations, labels, policies and document access before attributing risk.

Validate generated KQL

Check tables, fields, syntax, filters, joins, time windows, performance and returned rows.

Treat summaries as drafts

An incident summary is an orientation aid, not a final case conclusion.

Treat recommendations as proposals

Assess business impact, technical risk, reversibility and approval requirements.

Use human review gates

Require approval before consequential actions such as account disablement, device isolation or destructive remediation.

Use peer review for high-impact cases

A second analyst, incident commander or system owner should review critical findings.

Document fact, inference and unknowns

Keep confirmed evidence separate from likely interpretation and unresolved questions.

Record the role of Copilot

Investigation notes should identify where Copilot generated summaries, queries, explanations or recommendations.

Record decision ownership

Document who reviewed the evidence and who authorised the final response.

Protect sensitive information

Include only the personal, confidential or regulated data required for the task.

Review shared sessions

Shared links can expose the full session, so review all content before distribution.

Protect exports

Apply classification, retention, access and distribution controls to exported reports.

Use promptbooks for repeatable work

Standardise deterministic workflows while validating every intermediate response.

Use chat for exploration

Use ad-hoc sessions when the investigation direction is uncertain or changing.

Use agents with governance

Deploy agents only with clear scope, permissions, human oversight and approval controls.

Test promptbooks and agents

Use realistic, benign, malicious and failure scenarios before broad deployment.

Do not hide failures

Plugin errors, missing context and failed promptbook steps must remain visible.

Measure quality, not prompt volume

Evaluate time saved, investigation depth, consistency, accuracy and operational outcomes.

Capture corrected conclusions

When Copilot is wrong, record the correction and improve the prompt, promptbook or procedure.

Maintain a prompt library

Keep approved prompts for common incidents, reporting tasks and hunting scenarios.

Version operational workflows

Track changes to prompts, plugin dependencies, schemas, permissions and expected outputs.

Retire outdated content

Remove prompts and workflows that depend on deprecated portals, APIs, tables or product behaviour.

Train analysts on source products

Copilot users still need Defender, Sentinel, Entra, cloud, endpoint, email and KQL knowledge.

Avoid dependency

Analysts should be able to reproduce critical conclusions without relying solely on AI output.

Create an escalation path

Define what analysts should do when Copilot is unavailable, inconsistent or unable to access required data.

Review audit information

Use available auditing and governance records to understand platform activity and support oversight.

Optimise capacity responsibly

Remove redundant prompts and inefficient promptbooks while preserving investigation quality.

Close the session properly

Pin verified findings, document limitations, export only approved content and record the final human decision.

What Agent Foskett checked

• Tenant and workspace
• Plugin configuration
• User permissions
• Prompt structure
• Process log
• Email delivery
• User identity
• Device identity
• Timeline correlation
• Final approval

Best practices

• Prepare before prompting.
• Use focused neutral prompts.
• Request evidence and uncertainty.
• Review process logs.
• Open original records.
• Validate KQL and recommendations.
• Apply review gates.
• Protect sensitive data.
• Document decisions.
• Improve continuously.