Lesson 2 — How Microsoft Security Copilot Works
Microsoft Security Copilot does more than send a question directly to a language model.
The prompt is processed, grounded with relevant security context, matched to available plugins and capabilities, evaluated through the permissions of the signed-in user and then used to generate a response.
Understanding this flow helps analysts write better prompts, recognise missing context, review the process log and validate where each conclusion came from.
What you will learn
This lesson explains the main components involved when Security Copilot processes a security prompt.
Security Copilot response flow
↓
Security Copilot interprets the requested task
↓
The prompt is preprocessed and grounded
↓
Relevant plugins and capabilities are selected
↓
Security data is requested using the signed-in user's permissions
↓
Authorised organisational context and threat intelligence are returned
↓
The language model reasons over the prompt and grounded context
↓
Security Copilot generates a response
↓
The process log records actions, sources, plugins and processing steps
↓
The analyst reviews the answer and validates the evidence
Core components
| Component | Purpose | Analyst question |
|---|---|---|
| Prompt | Defines the task, scope, context and expected response. | Did I ask a clear and answerable security question? |
| Grounding | Adds relevant security context and improves specificity. | What data and authoritative context were available? |
| Plugin | Extends Copilot with a supported security capability or data source. | Which plugin supplied the result? |
| Authentication | Accesses data on behalf of the signed-in user. | Do I have permission to access the required source? |
| Large language model | Generates and structures the natural-language response. | Is the output supported by the grounded evidence? |
| Process log | Shows actions, sources, selected capabilities and processing time. | Can I trace how the response was produced? |
| Analyst validation | Checks accuracy, context, confidence and appropriate action. | Does the evidence support the conclusion? |
Learning objectives
- Understand the Security Copilot processing flow.
- Explain prompt grounding.
- Understand the role of plugins.
- Recognise on-behalf-of authentication.
- Understand how permissions affect results.
- Use the process log for transparency.
- Validate responses against source evidence.
Start with the prompt
The prompt tells Security Copilot what the analyst wants to investigate, explain, summarise or produce.
Prompts are instructions
A prompt should define the goal, relevant context, scope and desired output rather than relying on a vague question.
Prompt quality matters
Clear and specific prompts generally produce more useful responses than broad or ambiguous requests.
Prompt context matters
Incident numbers, users, devices, time ranges, indicators and expected evidence help constrain the task.
Security Copilot interprets the task
Copilot identifies the likely intent of the prompt and determines which available capabilities may help answer it.
What is grounding?
Grounding enriches the prompt with relevant security-specific knowledge, organisational context and authoritative information.
Grounding improves specificity
Instead of relying only on general model knowledge, the response can use context connected to the analyst's actual security environment.
Grounding is not model training
Organisational data is supplied as context at response time rather than being used to retrain the underlying model for that prompt.
Available context affects the answer
If important data is missing, disconnected or outside the analyst's permissions, the response may be incomplete.
What is a plugin?
A plugin extends Security Copilot by connecting it to a security capability, product or supported data source.
Microsoft plugins
Microsoft plugins can connect Copilot with supported Microsoft security products and threat-intelligence capabilities.
Non-Microsoft plugins
Supported third-party plugins can add capabilities and data from other security platforms.
Custom plugins
Organisations can extend Security Copilot with approved custom plugins where governance and owner settings allow them.
Plugins expose capabilities
Each plugin provides defined capabilities that correspond to the types of prompts Security Copilot can perform.
Plugin selection
Security Copilot can select a relevant enabled capability based on the prompt and available sources.
Enabled does not mean authorised
A plugin may be available in the platform while the signed-in user still lacks permission to its underlying data.
On-behalf-of authentication
Security Copilot accesses supported security data on behalf of the signed-in user.
User permissions are preserved
Copilot should only retrieve information the user is already authorised to access through the connected product.
Least privilege still applies
Security Copilot is not a reason to give analysts broader permissions than their work requires.
Security Copilot roles
Platform roles control who can use and manage Security Copilot, while product permissions control access to connected data.
Two permission layers
An analyst may have permission to use Security Copilot but still lack access to a Defender, Sentinel, Intune or Purview data source.
Missing permissions change results
A response may omit important evidence when the user cannot access the required source.
The large language model
The model generates and organises the natural-language response using the prompt and grounded context.
The model predicts language
It can produce a convincing explanation without independently proving that every conclusion is correct.
Security-specific context improves relevance
Plugins and grounding help the model reason over security data instead of responding only from general knowledge.
Response generation
Security Copilot combines the requested task, available context and model output into a structured answer.
Responses can include uncertainty
Analysts should explicitly ask Copilot to identify missing evidence, assumptions and confidence.
What is the process log?
The process log shows the steps taken while Security Copilot forms a response.
Plugin visibility
The process log can show which plugin or capability was selected for the prompt.
Source visibility
The process log helps the analyst identify sources and actions involved in producing the response.
Processing time
The log can also show how long individual processing steps took.
Transparency supports validation
The process log does not prove the answer is correct, but it gives the analyst a path for checking it.
Sessions preserve context
Follow-up prompts in the same session can build on previous questions and responses.
Context can drift
Long sessions may accumulate assumptions, so analysts should restate scope when the investigation changes direction.
Promptbooks use multiple steps
Promptbooks run a sequence of prompts, with later steps building on earlier responses.
Files can provide context
Where supported, uploaded files can be referenced so Copilot can use their contents when responding.
Data quality matters
Incomplete alerts, unhealthy connectors, missing logs or incorrect asset ownership can weaken the response.
Product health matters
Security Copilot cannot recover evidence that the underlying security product never collected.
Permissions affect scope
Two analysts can ask the same question and receive different context because their access differs.
Plugins affect capability
The same prompt may behave differently when relevant plugins are disabled, unavailable or not configured.
Prompt wording affects output
A request for a summary produces a different result from a request for evidence, uncertainty and next steps.
Validation completes the flow
The response is only the beginning of the analyst's decision process, not the end.
Example prompt-processing walkthrough
Summarise incident 2147 and identify the likely initial access method.
Include supporting evidence and uncertainty.
Security Copilot interprets the task
↓
Incident 2147 becomes the investigation scope
↓
Relevant Defender XDR capabilities are selected
↓
Data is requested using the analyst's permissions
↓
Alerts, entities and available evidence are returned
↓
Grounded context is provided to the model
↓
A summary and likely initial-access hypothesis are generated
↓
The process log records plugins, actions and sources
↓
The analyst opens the original incident and confirms each claim
Agent Foskett investigation: “Why did Copilot miss the sign-in?”
↓
The response described endpoint and email activity
↓
But it did not mention the suspicious Entra sign-in
↓
The analyst first assumed Copilot had overlooked the evidence
↓
Agent Foskett opened the process log
↓
The selected capability had retrieved Defender XDR incident context
↓
The signed-in analyst did not have access to the required identity data
↓
The missing result was caused by missing authorised context
↓
The permissions and data source were reviewed
↓
The prompt was run again by an appropriately authorised analyst
↓
The identity evidence appeared in the response
↓
The answer changed because the available context changed
↓
Agent Foskett documented the permission dependency
↓
The response was not wrong because of one mysterious AI failure
↓
The processing chain explained what had happened
Response validation checklist
| Check | Question | Why it matters |
|---|---|---|
| Prompt | Was the request clear, scoped and specific? | Vague prompts produce vague or over-broad answers. |
| Plugin | Which capability answered the prompt? | The plugin determines which source and action were used. |
| Permission | Could the signed-in user access the required data? | Missing permissions can create incomplete context. |
| Grounding | What organisational and authoritative context was supplied? | The response quality depends on available evidence. |
| Process log | What steps, sources and processing actions were recorded? | The log provides transparency into response generation. |
| Source data | Do the original alerts and logs support the response? | AI output is not a substitute for source evidence. |
| Uncertainty | What could not be verified? | Missing evidence must remain visible to the analyst. |
| Business context | Could legitimate activity explain the result? | Copilot may not understand local operational intent. |
| Confidence | Is the conclusion confirmed, likely or speculative? | Confidence should match the strength of the evidence. |
| Action | Is the result strong enough to justify response? | Containment decisions remain accountable human actions. |
Key takeaways
- Security Copilot processes more than the visible words in the prompt.
- Grounding enriches the request with relevant security context and authoritative information.
- Plugins extend Security Copilot with supported products, data sources and capabilities.
- Security Copilot accesses plugin data on behalf of the signed-in user.
- Platform roles and connected-product permissions are separate access layers.
- Missing permissions, disabled plugins and incomplete telemetry can change the response.
- The large language model generates the response but does not independently prove its accuracy.
- The process log shows actions, selected capabilities, sources and processing time.
- Follow-up prompts can build on session context, but analysts should watch for scope drift.
- The analyst must validate the final response against the original evidence.
What Agent Foskett checked
- Prompt wording
- Requested scope
- Selected plugin
- Available capability
- User authentication
- Product permissions
- Grounded context
- Process log
- Original evidence
- Remaining uncertainty
Best practices
- Write specific prompts.
- Include the required scope.
- Enable only approved plugins.
- Apply least privilege.
- Check connector and data health.
- Review the process log.
- Inspect cited sources.
- Ask for uncertainty.
- Restart context when scope changes.
- Validate before acting.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How does Microsoft Security Copilot work?
Microsoft Security Copilot processes natural-language prompts through grounding, enabled plugins, authorised organisational context and large language models before producing a response that analysts validate through the process log and source evidence.
Microsoft Security Copilot grounding and plugins
Grounding adds security-specific context at response time, while plugins connect Security Copilot to supported Microsoft and third-party security capabilities and data sources.
Microsoft Security Copilot permissions
Security Copilot uses on-behalf-of authentication, so the signed-in user must have permission to access data exposed by the selected plugin or connected security product.
