Lesson 29 — Validating AI Investigation Results
Security Copilot can summarise incidents, generate queries, explain scripts, enrich indicators and recommend next actions—but every material claim still needs to be checked against the correct source and original evidence.
A response can be inaccurate, incomplete or overstated. It can also be perfectly accurate for the wrong incident, workspace, device or time period.
This lesson explains how to validate sources, entities, timelines, KQL, indicators, ATT&CK mappings, malware findings and response recommendations before they become operational decisions.
What you will learn
This lesson develops a complete source-to-decision AI validation workflow.
AI-result validation workflow
↓
Confirm the incident, entity, tenant, workspace and time range
↓
Review the process log, plugins and source references
↓
Open the original alert, event, entity page or raw rows
↓
Separate direct observations from inference
↓
Check alternative explanations and contradictory evidence
↓
Validate scope, timeline, KQL and intelligence context
↓
Assign confidence to each claim
↓
Check whether the claim justifies the proposed action
↓
Record revisions, uncertainty and peer review
↓
Approve the final human-owned investigation result
AI validation model
| Layer | Evidence | Validation question |
|---|---|---|
| Source | Prompt context, plugin, incident, table, entity and original record. | Did Copilot use the correct evidence? |
| Claim | Observation, inference, confidence and supporting events. | Does the evidence support the statement? |
| Scope | Users, devices, mailboxes, resources, time and environment. | Who and what are actually affected? |
| Alternative | Benign activity, shared infrastructure, duplicates and missing data. | What else could explain the result? |
| Decision | Escalation, containment, blocking, monitoring or closure. | Does the evidence justify the action? |
| Record | Sources, queries, revisions, uncertainty and approvals. | Can another analyst reproduce the conclusion? |
Learning objectives
- Validate Copilot sources and process logs.
- Confirm incidents, entities and environments.
- Check timelines, KQL and raw evidence.
- Validate IOC, ATT&CK and malware claims.
- Identify unsupported conclusions and alternatives.
- Document confidence and uncertainty.
- Approve defensible operational decisions.
What is AI-result validation?
AI-result validation is the process of checking Copilot claims against the correct source, original evidence, environment and operational context.
Validation is not distrust
Validation turns a useful AI response into a defensible analyst conclusion.
Three validation layers
Confirm the correct source, confirm that the source supports the claim and confirm that the claim justifies the proposed action.
Correct answer, wrong source
A response can be accurate but belong to the wrong incident, user, device, tenant, workspace or time period.
Correct source, weak claim
The correct incident can still contain insufficient evidence for the conclusion.
Correct claim, wrong action
A supported observation does not automatically justify containment, blocking or escalation.
Hallucination
A hallucination is generated content that is unsupported or fabricated rather than grounded in available evidence.
Omission
Copilot can omit relevant events, entities, limitations or contradictory evidence.
Overstatement
A response can transform possible activity into confirmed compromise.
Understatement
A response can miss business impact, persistence or wider scope.
Stale context
Old intelligence, expired indicators or outdated incidents can distort current conclusions.
Wrong environment
Tenant, subscription, workspace, device group and product context must be confirmed.
Wrong identity
Users with similar names, aliases or renamed accounts can be confused.
Wrong device
Hostnames can be reused, renamed or reimaged, so DeviceId must be checked.
Wrong incident
Similar alerts and repeated campaigns can lead analysts to validate the wrong incident.
Wrong time range
A valid event outside the investigation window may be unrelated.
Start with the question
Write down the exact claim that needs validation.
Break claims apart
Separate statements about identity, device, execution, impact, persistence, scope and attribution.
Classify each claim
Mark claims as confirmed, probable, possible, unsupported or disproven.
Use direct evidence first
Prioritise original events, portal records, raw rows and immutable identifiers.
Use supporting evidence second
Use summaries, threat intelligence and related analytics to add context.
Use inference carefully
Inference should be labelled and supported by multiple facts.
Review the process log
Security Copilot exposes intermediate steps and sources so analysts can review how a response was produced.
Review source citations
Open the referenced incidents, alerts, entities, reports, tables and pages.
Verify plugin selection
Confirm which plugin or product supplied each major statement.
Verify prompt context
Check incident IDs, entity names, uploaded content and prior-session context.
Verify session context
A long Copilot session can contain information from earlier prompts that no longer applies.
Start a clean session when needed
Use a new session when previous context could contaminate the investigation.
Verify the incident ID
Confirm that every summary and action relates to the correct incident.
Verify alert IDs
Compare alert identifiers, services, timestamps and associated entities.
Verify entity IDs
Use DeviceId, AccountObjectId, NetworkMessageId, AlertId and resource ID.
Verify display names separately
Readable names should support—not replace—immutable identifiers.
Verify the tenant
Confirm that the user, application, workspace and resource belong to the intended tenant.
Verify subscription and workspace
Cloud and Sentinel evidence can be correct but come from another environment.
Verify timestamps
Compare event time, ingestion time, detection time and summary time.
Verify time zone
Normalise times and preserve the original source time zone when required.
Verify first observed
Identify the earliest confirmed event, not merely the first alert.
Verify latest activity
Check whether the attacker or suspicious process remained active after the summary ended.
Verify sequence
Ensure the proposed order is technically and chronologically possible.
Verify gaps
Mark periods where logs, sensors or connectors are unavailable.
Verify duplicates
Repeated alerts can inflate incident size and confidence.
Verify users
Check object ID, UPN, account type, roles, aliases and authentication context.
Verify devices
Check DeviceId, hostname, OS, ownership, onboarding, reimage and risk state.
Verify IP addresses
Check NAT, proxy, VPN, shared hosting, ownership and incident timing.
Verify domains
Check the full domain, subdomain, DNS history, ownership and current relevance.
Verify URLs
Preserve scheme, host, path, parameters, redirects and final destination.
Verify hashes
Confirm algorithm, exact value, file prevalence, path, source and execution.
Verify email
Check Network Message ID, sender, recipient, delivery, URLs, attachments and clicks.
Verify cloud resources
Check full resource ID, subscription, identity, region and activity logs.
Verify applications
Check application ID, service principal ID, publisher, consent and permissions.
Validate incident summaries
Compare the Copilot narrative with the incident timeline, alerts and evidence entities.
Validate attack stories
Ensure every transition has supporting events and identifiers.
Validate affected scope
Separate confirmed, suspected and unrelated users, devices, mailboxes and resources.
Validate business impact
Do not infer data loss, downtime, financial loss or regulatory impact without evidence.
Validate current status
Confirm whether the incident is active, contained, recovering or unresolved.
Validate completed actions
Check that isolation, token revocation, quarantine and blocking actually succeeded.
Validate residual risk
Identify unresolved sessions, persistence, exposure, missing logs and monitoring needs.
Validate KQL syntax
Run the query and resolve recognition, syntax and function errors.
Validate KQL schema
Confirm the tables, columns and data types exist in the intended environment.
Validate KQL scope
Review workspace, tenant, device, user and time filters.
Validate KQL joins
Check stable identifiers, join type and row multiplication.
Validate KQL results
Inspect representative raw rows rather than accepting the summary.
Validate empty results
No result can mean no activity, wrong table, stale data, bad scope or missing telemetry.
Validate excessive results
Broad filters can make normal activity look like widespread compromise.
Validate IOC freshness
Review first seen, last seen, expiration, ownership and source date.
Validate IOC relevance
Search for internal sightings and surrounding behaviour.
Validate reputation
A malicious reputation label does not prove malicious use in this incident.
Validate shared infrastructure
CDNs, proxies, VPNs and cloud hosts create common false relationships.
Validate ATT&CK mappings
Compare the behaviour with the current MITRE definition and most precise sub-technique.
Validate dual-use tools
PowerShell, PsExec, certutil and other tools need user, parent, command and network context.
Validate malware claims
Separate malicious artefact, internal delivery, execution and successful compromise.
Validate sandbox findings
Compare cloud-sandbox behaviour with internal endpoint evidence and execution conditions.
Validate threat-actor claims
Attribution requires more than one hash, domain, IP or tool.
Validate recommendations
Check whether the proposed response matches evidence, permissions and business impact.
Validate blocking
Assess shared services, prevalence, dependencies and false-positive consequences.
Validate containment
Confirm scope and preserve evidence before isolating or disabling where required.
Validate escalation
Ensure the evidence meets documented severity and specialist-engagement criteria.
Ask what supports the claim
Request the exact source, event, entity and timestamp behind a conclusion.
Ask what contradicts the claim
Require evidence that weakens the leading theory.
Ask what is missing
Identify absent tables, events, products, entities and time periods.
Ask what else could explain it
Request legitimate administrative, deployment, testing and user explanations.
Ask how confident the claim is
Require confidence for each conclusion rather than one score for the entire incident.
Ask what would change the conclusion
Define the evidence that would raise or lower confidence.
Avoid asking only “Are you sure?”
A general reassurance prompt is weaker than a source-specific validation request.
Use independent queries
Create separate KQL or portal checks instead of asking Copilot to validate itself.
Use a second analyst
Peer review helps identify context errors, assumptions and missed evidence.
Use different data sources
Corroborate material claims across independent logs where possible.
Document negative findings
Record scope, sources and limitations when no supporting evidence is found.
Document uncertainty
Unknowns should remain visible in investigation notes and reports.
Document revisions
Record when an AI-generated conclusion was changed and why.
Document Copilot contribution
Record which prompts, sessions, agents or promptbooks assisted the investigation.
Audit AI activity
Security Copilot activity can be reviewed through Microsoft audit capabilities and organisational logging.
Preserve the evidence trail
Another analyst should be able to reproduce the final conclusion.
Final analyst judgement
Security Copilot can accelerate reasoning, but the authorised analyst remains accountable for the final investigation result.
Example AI-result validation prompt
Include:
1. The exact incident, alert, user and device identifiers used
2. The plugins, products and source records supporting each claim
3. Direct observations separated from inference
4. A verified chronological timeline
5. KQL queries and representative raw rows
6. Evidence supporting account compromise
7. Evidence supporting lateral movement
8. Legitimate alternative explanations and contradictory evidence
9. Missing telemetry, uncertainty and confidence for each conclusion
10. Whether escalation and containment are justified
Do not reuse conclusions from earlier session context unless they are independently verified against incident 2147.
Agent Foskett investigation: “Copilot was right… for the wrong incident”
↓
The IP address was malicious
↓
The device process tree showed malware execution
↓
The timeline included persistence and lateral movement
↓
The ATT&CK mappings were well supported
↓
The confidence was high
↓
Agent Foskett checked the source references
↓
The active case was incident 2194
↓
The summary described incident 2149 from the previous day
↓
Both incidents involved the same malware family
↓
Both contained similar alert titles
↓
The AI response was accurate
↓
The investigation context was wrong
↓
A clean session was opened with the correct incident ID
↓
Incident 2194 contained only blocked email delivery
↓
No endpoint compromise or lateral movement existed
↓
The error was not a hallucination
↓
It was a source-selection failure
AI-result validation checklist
| Area | Question | Validation action |
|---|---|---|
| Context | Is the correct incident, session and environment selected? | Confirm IDs, tenant, workspace and time. |
| Process log | Which plugins and sources produced the result? | Open intermediate steps and references. |
| Entities | Are users, devices and resources correctly identified? | Use immutable identifiers. |
| Timeline | Are timestamps and sequence supported? | Compare original event records. |
| KQL | Do queries use valid schema and logic? | Run independently and inspect raw rows. |
| Claim | Is the conclusion observed or inferred? | Separate facts, probability and uncertainty. |
| Alternative | Could benign activity explain the evidence? | Review change, deployment and user context. |
| Coverage | Which logs or products are missing? | Document retention and visibility gaps. |
| Action | Does the evidence justify escalation or containment? | Apply approved decision criteria. |
| Record | Can the conclusion be reproduced? | Preserve prompts, sources, queries and approvals. |
Key takeaways
- Security Copilot responses should be validated against the correct source and original evidence.
- The process log exposes intermediate steps and sources that help analysts double-check a response.
- An accurate response can still be wrong for the active investigation if the context or incident is incorrect.
- Direct observations, inference, confidence and uncertainty should remain separate.
- Immutable identifiers are essential for user, device, message and resource validation.
- Generated KQL should be run independently and checked against raw rows.
- IOC, ATT&CK and malware claims require timing, context and supporting evidence.
- Operational actions require a higher evidence threshold than narrative summaries.
- Prompts, responses and Copilot activity can be governed and audited through Microsoft security and compliance capabilities.
- The authorised analyst remains accountable for the final investigation decision.
What Agent Foskett checked
- Incident ID
- Session context
- Source references
- Alert identifiers
- User object ID
- Device ID
- Timeline
- KQL results
- Compromise evidence
- Final incident scope
Best practices
- Validate the context.
- Review the process log.
- Open original evidence.
- Use immutable IDs.
- Run queries independently.
- Seek contradictions.
- Document missing data.
- Assign claim-level confidence.
- Use peer review.
- Keep judgement human.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you validate Microsoft Security Copilot investigation results?
Analysts should review the Security Copilot process log, source references, original incidents, entity identifiers, timelines, KQL results and raw Microsoft security evidence before accepting a generated conclusion.
Security Copilot process log and sources
Security Copilot displays intermediate steps and sources in a process log so users can review how a response was produced and double-check the result.
Responsible AI investigation validation
AI-assisted investigation output should preserve human accountability, confidence, uncertainty, alternative explanations and independent verification before operational action.
