Tag: Microsoft Defender XDR

Cloud computing, Cybersecurity, Microsoft Certification, SC-500 October 10, 2026October 10, 2026

Query Microsoft Purview Audit in Defender XDR (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage and monitor security posture (20–25%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Query Microsoft Purview Audit in Defender XDR

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Security investigations often require more than security alerts and endpoint telemetry. Investigators also need to know what users and administrators actually did across Microsoft 365 and Microsoft security services.

For example:

Who changed a Microsoft Defender security setting?
Who created or modified a custom detection rule?
Who isolated a device?
Who changed a data-retention setting?
Who modified security roles?
Who assigned a user to an incident?
What actions were performed by an administrator before or during a security incident?

Microsoft Purview Audit provides the auditing infrastructure used to record supported user and administrator activities across Microsoft 365. Microsoft Defender XDR uses this auditing capability, and the audit records can be searched from the Microsoft Defender portal.

For the SC-500 exam, the important skill is understanding how to query the Microsoft Purview unified audit log from Microsoft Defender XDR, what information can be searched, what permissions are required, and how audit-log retention affects an investigation.

1. What Is Microsoft Purview Audit?

Microsoft Purview Audit records supported user and administrator activities throughout the Microsoft 365 environment.

The resulting audit records can be used for:

Security investigations
Forensic investigations
Compliance investigations
IT investigations
Legal investigations
Insider-risk investigations
Tracking administrative changes

Microsoft describes Audit (Standard) as a solution for logging and searching audited activities across Microsoft services. It includes thousands of searchable audit events.

A useful conceptual model is:

			
Users / Administrators
        |
        v
Audited activities
        |
        v
Microsoft Purview Unified Audit Log
        |
        +-----------------------+
        |                       |
        v                       v
Microsoft Defender XDR     Microsoft Purview
        |                       |
        +-----------+-----------+
                    |
                    v
             Investigation

		

The important point is that the audit information is not simply a Defender-specific log.

Microsoft Defender XDR uses Microsoft Purview auditing.

2. Why Query the Audit Log During a Security Investigation?

Security telemetry can tell you that something happened.

The audit log can help answer:

Who performed the action, what action occurred, and when did it occur?

Consider an investigation into a compromised security administrator account.

An investigator might discover that:

The account signed in.
A Defender security configuration was changed.
A device was isolated.
A security role was modified.
A custom detection rule was created.

Security alerts alone might not provide the complete administrative activity trail.

The audit log can provide evidence of supported administrative and user activities.

Microsoft specifically identifies Defender activities such as changes to data-retention settings, changes to advanced features, creation of indicators of compromise, device isolation, security-role changes, custom detection-rule changes, and incident assignments as audited activities.

3. Microsoft Defender XDR and the Unified Audit Log

Microsoft Defender XDR activities are integrated with the Microsoft Purview auditing solution.

This means that an investigator can use the Audit page in the Microsoft Defender portal to search for supported activities.

Microsoft states that the Defender portal audit search is identical to the audit-log search experience available through Microsoft Purview.

Conceptually:

			
Microsoft Defender XDR
        |
        | audited activity
        v
Microsoft Purview auditing
        |
        v
Unified Audit Log
        |
        v
Defender portal → Audit

		

This is particularly useful because security personnel can investigate Defender activity without having to switch to an entirely separate audit system.

4. What Can You Search For?

The audit search allows investigators to filter activities using several criteria.

Important search criteria include:

Date and time range
Activities
Users

The available activities depend on the services and workloads being audited.

Microsoft Defender XDR audit records can include activities associated with Microsoft Defender XDR and Microsoft Defender for Endpoint.

Examples include:

Activity type	Example investigation question
Data-retention changes	Who changed a retention setting?
Advanced-feature changes	Who changed a Defender configuration?
Indicator changes	Who created an indicator of compromise?
Device isolation	Who isolated a device?
Security-role changes	Who added, edited, or removed a security role?
Custom detections	Who created or modified a custom detection rule?
Incident assignment	Who assigned a user to an incident?

These examples illustrate an important distinction:

The audit log records administrative and user actions, not simply security alerts.

5. Accessing Audit Search in Microsoft Defender

The current Microsoft Defender portal provides an Audit page for searching audit records.

The general process is:

Sign in to the Microsoft Defender portal.
Open Audit.
Configure the search criteria.
Select Search.
Review the returned audit records.
Export results if required.

Microsoft documents the Defender portal Audit page as the starting point for audit-log searches.

The same audit-search capability can also be accessed from Microsoft Purview.

6. Search Criteria

A typical audit search begins by narrowing the investigation.

Date and Time

Specify the period in which the activity occurred.

For example:

			
Start: September 20, 2026 00:00 UTC
End:   September 25, 2026 23:59 UTC

Be careful with time zones.

Microsoft’s audit search uses a date/time range, and audit activities are represented using UTC-based timing.

Exam Tip

If an exam question asks you to investigate activity during a specific period, date/time is one of the primary search filters.

Activities

The Activities filter lets you search for specific audited operations.

For example, an investigator could search for a Defender activity involving:

Device isolation
Security-role changes
Custom detection rules
Indicators
Retention settings

The exact activity names available depend on the workload and audit records being searched.

Users

The Users filter allows an investigator to narrow results to activities performed by particular users.

For example:

“Determine whether the compromised administrator account changed any Defender settings during the incident.”

The investigator can specify that account in the Users filter.

Leaving the Users field empty allows the search to include activities from all users within the search scope.

7. Example Investigation

Suppose a security team discovers that a critical endpoint was isolated unexpectedly.

The team wants to determine:

Who initiated the isolation and when?

A reasonable audit investigation would be:

			
Audit
  |
  +-- Date/time
  |     |
  |     +-- Incident timeframe
  |
  +-- Activity
  |     |
  |     +-- Device isolation-related activity
  |
  +-- User
        |
        +-- Leave blank initially

		

The investigator reviews the resulting audit records to determine which account performed the action.

If a particular account is identified, a second search can narrow the investigation to that user and the surrounding time period.

This illustrates an important investigation technique:

Start broad enough to discover the activity, then narrow the search as evidence identifies relevant users, activities, or time periods.

8. Audit Records vs. Microsoft Sentinel Logs

This distinction is important for SC-500.

Microsoft Purview Audit is not simply another Microsoft Sentinel table.

The audit log is a Microsoft 365 auditing system.

Microsoft Sentinel can collect and analyze many different data sources, while Microsoft Purview Audit provides auditing of supported Microsoft 365 activities.

Therefore:

Microsoft Purview Audit	Microsoft Sentinel
Focuses on audited user/admin activities	Security information and event management
Unified Microsoft 365 audit log	Centralized security data platform
Search through Audit	Query using KQL and Sentinel capabilities
Used heavily for compliance and administrative investigations	Used for detection, investigation, hunting, and response
Records supported audited activities	Collects many security and operational data sources

The two systems can complement one another.

For example:

			
Defender alert
      |
      v
Sentinel investigation
      |
      +---- Endpoint telemetry
      |
      +---- Identity logs
      |
      +---- Microsoft 365 activity
      |
      v
Purview Audit
      |
      v
Administrative action

		

An investigator may use both security telemetry and audit records to reconstruct an incident.

9. Microsoft Defender XDR Audit vs. Defender Alerts

Another important distinction is:

Alert

An alert generally indicates that a security-related condition or detection occurred.

Audit record

An audit record documents a supported user or administrator activity.

For example:

Alert:

Suspicious activity detected on a device.

Audit record:

Administrator isolated the device.

These are different types of information.

During an investigation, both can be valuable.

10. Required Permissions

Access to the audit log is controlled through permissions.

Microsoft currently documents that users need the Audit Logs or View-Only Audit Logs permissions/roles to search audit records. In the Defender/XDR context, these permissions are associated with Exchange Online role groups such as Compliance Management and Organization Management by default.

Microsoft also emphasizes least privilege.

A Global Administrator can have the necessary access, but Microsoft recommends using lower-privilege roles when they are sufficient.

Exam Tip

If a question asks:

“What permissions are required to search the audit log?”

Think:

Audit Logs or View-Only Audit Logs.

Do not automatically choose Global Administrator simply because that role can perform the task.

11. Audit Logs vs. View-Only Audit Logs

These permissions provide access to audit information.

The principle is:

Give investigators the minimum permissions required to perform their responsibilities.

For an investigator who only needs to search and review audit records, a read-oriented audit role is preferable to granting broad administrative permissions.

This aligns with the principle of least privilege emphasized throughout Microsoft security solutions.

12. Audit Must Be Available

Before investigating audit activity, auditing must be available for the organization.

Microsoft Defender XDR uses Microsoft Purview auditing, and Microsoft states that auditing needs to be turned on in Microsoft Purview before audit data can be viewed in the Defender portal.

This creates an important troubleshooting sequence:

			
Can't find audit records?
        |
        +--> Is auditing enabled?
        |
        +--> Does the user have audit permissions?
        |
        +--> Is the activity actually audited?
        |
        +--> Is the activity within the retention period?
        |
        +--> Are the search filters correct?

		

A missing audit record does not automatically mean the activity never occurred.

The activity may:

Not be audited
Fall outside the retention period
Require different search criteria
Belong to a different workload
Have been performed outside the period being searched

13. Audit Retention

Retention is especially important when investigating historical incidents.

The default Audit (Standard) retention period is currently 180 days for audit logs generated on or after October 17, 2023. Older Audit (Standard) records generated before that date followed the previous 90-day default.

Therefore, an investigator should not assume that an audit record from several years ago is automatically available.

Audit retention depends on the organization’s Microsoft Purview audit configuration and licensing.

14. Audit (Premium) and Longer Retention

Microsoft Purview Audit (Premium) provides additional audit capabilities, including configurable audit-log retention policies.

Audit retention policies can retain audit records for:

More than the standard retention period
Up to one year for appropriately licensed users
Up to 10 years when the required licensing and 10-year audit retention add-on are in place

Microsoft currently documents support for audit-log retention policies of up to 10 years.

Important Licensing Concept

Longer retention is not simply a matter of changing a setting.

Microsoft documents licensing requirements for longer retention. For example, retaining audit logs beyond 180 days and up to one year requires appropriate E5-level licensing for the users whose activities generate the audit records; 10-year retention requires an additional 10-year audit-log retention license.

Exam Tip

When a question combines:

Long-term audit retention
Compliance
Microsoft Purview Audit

look for Audit retention policies and the appropriate licensing, rather than assuming Microsoft Sentinel table retention controls the audit records.

15. Audit Retention Policies

Microsoft Purview Audit (Premium) supports audit log retention policies.

Policies can specify how long audit records should be retained.

They can be configured according to criteria such as the audited workload, record type, and other supported conditions.

An organization can have up to 50 audit-log retention policies.

The important exam concept is:

Microsoft Purview Audit retention is managed through Purview audit-retention capabilities, not through Microsoft Sentinel table-retention settings.

16. Searching With PowerShell

The audit log can also be queried programmatically.

Microsoft provides the Search-UnifiedAuditLog PowerShell cmdlet for searching audit events.

This can be useful when:

Searches need to be automated
Investigators need repeatable queries
Results need to be processed programmatically
An investigation involves many searches
Security teams want to integrate audit searching into operational workflows

The portal and PowerShell access the same underlying audit-log capability.

17. Microsoft Graph Audit Search API

Microsoft also provides the Audit Search Graph API.

This allows applications to programmatically access audit-search data through Microsoft Graph.

This is useful for organizations building:

Automated investigations
Compliance workflows
Security dashboards
Custom reporting
Integration with security operations tooling

For the SC-500 exam, recognize the relationship:

			
Audit Search
     |
     +---- Defender portal
     |
     +---- Purview portal
     |
     +---- PowerShell
     |
     +---- Microsoft Graph Audit Search API

		

18. Exporting Audit Results

Audit-search results can be exported.

The Microsoft Purview audit search experience supports exporting results to a CSV file.

The exported data includes an AuditData column containing additional event information formatted as JSON.

That JSON can be transformed in tools such as Excel’s Power Query Editor to make individual properties easier to analyze.

This can be useful for:

Compliance reports
Investigation evidence
Sorting and filtering
Offline analysis
Sharing investigation results with authorized personnel

19. Understanding the AuditData Property

An audit record contains multiple properties describing the event.

When audit results are exported, the AuditData field contains additional event information as JSON.

For example, an exported record can conceptually look like:

			
CreationTime
UserId
Operation
Workload
RecordType
AuditData

		

The AuditData field may contain additional properties that provide more context about the operation.

This is particularly useful when the standard columns do not provide all the information required for an investigation.

20. Investigating Microsoft Defender XDR Activities

Microsoft Defender XDR provides a specific collection of audited activities.

Examples include:

Data-retention changes

An investigator can determine whether an administrator changed a security data-retention setting.

Device isolation

An investigator can investigate which user or administrator performed an isolation action.

Security-role changes

An investigator can determine whether security permissions or roles were changed.

Custom detection changes

An investigator can determine who created or modified custom detection rules.

Incident assignments

An investigator can determine who assigned a user to an incident.

These activities can provide important evidence during an investigation into unauthorized administrative behavior.

21. Example: Investigating an Unauthorized Defender Change

Suppose a security team discovers that an organization’s Defender configuration changed unexpectedly.

The investigation could proceed as follows:

Step 1 — Identify the approximate timeframe

Determine when the configuration change was discovered.

Step 2 — Search the Audit page

Open the Audit page in Microsoft Defender.

Step 3 — Filter by activity

Select the relevant Defender activity.

Step 4 — Review users

Identify which account performed the activity.

Step 5 — Correlate with other telemetry

Compare the audit event with:

Sign-in activity
Device activity
Security alerts
Incident timelines
Other administrative changes

Step 6 — Export if required

Export the results for additional investigation or reporting.

This provides a more complete picture than examining a security alert alone.

22. Audit Log Search Is Not the Same as KQL

A common SC-500 exam trap is assuming that every Microsoft security data source is queried with KQL.

Microsoft Purview Audit provides its own search experience.

The standard Audit search uses filters such as:

Date/time
Activities
Users

It can also be accessed programmatically through PowerShell and Microsoft Graph.

By contrast, Microsoft Sentinel uses KQL extensively for querying data stored in its Log Analytics environment.

Therefore:

Task	Primary mechanism
Search Microsoft Purview audit activities	Audit search
Search Defender audit activity	Defender Audit
Programmatically search unified audit log	Search-UnifiedAuditLog / Graph API
Query Sentinel log tables	KQL
Build Sentinel analytics rules	KQL-based queries

23. Common Troubleshooting Scenario

Suppose an administrator says:

“I know a user changed a Defender setting yesterday, but I cannot find the event.”

Work through the following checklist.

1. Check permissions

Does the investigator have:

Audit Logs
View-Only Audit Logs

or equivalent access?

2. Check auditing

Is Microsoft Purview auditing enabled?

3. Check the date/time

Is the correct UTC range being searched?

4. Check the activity

Is the specific operation actually audited?

5. Check the user

Was the correct account selected?

6. Check retention

Is the event still within the organization’s audit-log retention period?

7. Check the workload

Could the activity have been generated by another Microsoft workload?

This systematic approach is more reliable than simply expanding the search indefinitely.

24. Audit Data and Incident Reconstruction

One of the most valuable uses of audit information is reconstructing a timeline.

For example:

			
09:12  User signs in
   |
09:17  Defender configuration changed
   |
09:19  Indicator created
   |
09:23  Device isolated
   |
09:31  Incident assigned
   |
09:45  SOC begins investigation

		

The audit log can provide evidence for supported administrative actions within this timeline.

Other security data sources can then provide additional context.

This is particularly useful for determining:

What happened?
When did it happen?
Who performed the action?
Which security controls were changed?
What happened immediately before or after the change?

25. Best Practices

Use least privilege

Do not give investigators Global Administrator privileges merely because that role can search audit logs.

Use the appropriate Audit Logs or View-Only Audit Logs permissions.

Search narrowly before expanding

Start with:

Known timeframe
Known user
Known activity

Then expand the search when necessary.

Correlate audit records with security telemetry

Audit records provide administrative context. Combine them with Defender, Microsoft Entra, endpoint, and Sentinel data for a more complete investigation.

Understand retention before an incident occurs

Organizations should establish audit retention policies before they need historical evidence.

Consider licensing requirements

Longer audit retention may require specific Microsoft licensing and the appropriate retention policy configuration.

Export important results

Export relevant audit results when investigation or compliance procedures require a durable copy for analysis or reporting.

26. Common Exam Mistakes

Mistake 1: Confusing Purview Audit with Sentinel data retention

Purview audit records are governed by Microsoft Purview audit retention, not Microsoft Sentinel table-retention settings.

Mistake 2: Assuming Defender audit data is separate from Purview

Microsoft Defender XDR uses Microsoft Purview auditing.

Mistake 3: Choosing Global Administrator unnecessarily

Audit Logs or View-Only Audit Logs permissions are the more relevant concept for audit searches.

Mistake 4: Assuming every Defender action is audited

Only supported activities generate audit records.

Mistake 5: Forgetting retention

If an event is older than the organization’s applicable audit retention period, it may no longer be available.

Mistake 6: Confusing alerts with audit records

An alert identifies a security condition; an audit record documents a supported user or administrator action.

Mistake 7: Assuming audit search requires KQL

The Microsoft Purview/Defender Audit search experience is not the same as querying Sentinel tables with KQL.

27. SC-500 Exam-Focused Summary

Concept	What to remember
Microsoft Purview Audit	Records supported user/admin activities
Unified Audit Log	Central audit repository for supported Microsoft 365 activities
Defender XDR auditing	Uses Microsoft Purview auditing
Defender Audit page	Used to search audit activity
Main search filters	Date/time, activities, users
Audit Logs role	Provides audit-log access
View-Only Audit Logs	Read-oriented audit access
Global Administrator	Should not be selected unnecessarily
Audit (Standard)	Default retention is currently 180 days for newer audit records
Audit (Premium)	Provides enhanced audit capabilities and retention policies
Long-term retention	Requires appropriate licensing/configuration
Maximum documented retention	Up to 10 years with required licensing
PowerShell	`Search-UnifiedAuditLog`
Microsoft Graph	Audit Search Graph API
Export	CSV
AuditData	JSON containing additional event properties
Sentinel KQL	Different from Purview Audit search
Retention settings	Purview audit retention, not Sentinel table retention

28. Key Takeaways

The most important points for the SC-500 exam are:

Microsoft Defender XDR uses Microsoft Purview auditing.
The Audit page in Microsoft Defender can be used to search supported audit activities.
Searches can be narrowed by date/time, activities, and users.
Defender audit activities include operations such as device isolation, security-role changes, custom detection changes, indicator creation, and data-retention changes.
Audit searches require appropriate Audit Logs or View-Only Audit Logs permissions.
Microsoft recommends least privilege rather than automatically assigning Global Administrator.
Audit retention is controlled by Microsoft Purview audit-retention capabilities.
The current default Audit (Standard) retention period is 180 days for applicable newer audit records.
Audit (Premium) supports retention policies and can provide retention of up to 10 years when the required licensing is in place.
Audit searches can be performed through the portal and programmatically through PowerShell or Microsoft Graph.
Audit results can be exported to CSV, with additional event information available in the AuditData JSON property.
Purview Audit searches are different from KQL queries against Microsoft Sentinel data.
A missing audit event may be caused by permissions, incorrect filters, unsupported activity, or retention expiration.

Practice Exam Questions

Question 1

A security analyst needs to determine who isolated a device in Microsoft Defender XDR yesterday.

Where should the analyst begin the investigation?

A. Microsoft Defender portal Audit

B. Azure Policy

C. Microsoft Sentinel Data Lake

D. Azure Resource Graph

Answer: A

Explanation: Microsoft Defender XDR activities are audited through Microsoft Purview, and the Defender portal provides an Audit page where supported Defender activities can be searched.

Question 2

An investigator needs to search the Microsoft Purview audit log for activity performed by a specific administrator during a particular time period.

Which combination of search criteria is most appropriate?

A. KQL table, workspace, and analytic rule

B. Subscription, resource group, and Azure region

C. Date/time range, activities, and user

D. Device group, vulnerability, and exposure score

Answer: C

Explanation: Audit searches can be filtered using criteria such as the date/time range, activities, and users. These are the core filters an investigator uses to narrow audit activity.

Question 3

A security analyst needs to search Microsoft Defender XDR audit records but should not receive broad administrative privileges.

Which permission is most directly relevant?

A. Contributor

B. View-Only Audit Logs

C. Security Administrator

D. Global Administrator

Answer: B

Explanation: View-Only Audit Logs provides read-oriented access to audit information. The important SC-500 principle is to use the minimum permissions required rather than assigning Global Administrator unnecessarily.

Question 4

An organization needs to determine whether an administrator changed a Microsoft Defender data-retention setting.

Which Microsoft Defender/Purview capability should be used?

A. Microsoft Defender Vulnerability Management

B. Microsoft Sentinel analytics rules

C. Microsoft Purview Audit

D. Azure Resource Locks

Answer: C

Explanation: Changes to data-retention settings are among the types of Microsoft Defender activities that can be audited. The audit record can be searched through the Defender Audit experience.

Question 5

An investigator wants to search the unified audit log programmatically rather than through the Microsoft Defender portal.

Which PowerShell cmdlet is specifically designed for this purpose?

A. Get-MgUser

B. Get-AzActivityLog

C. Get-MgAuditLogDirectoryAudit

D. Search-UnifiedAuditLog

Answer: D

Explanation: Search-UnifiedAuditLog is the Exchange Online PowerShell cmdlet used to search Microsoft Purview unified audit-log events.

Question 6

A security team discovers that an administrative action occurred 14 months ago. The organization has not configured extended audit retention and is using the standard audit-retention period.

What should the investigator consider first?

A. The audit record may no longer be available because it is outside the applicable retention period.

B. Microsoft Sentinel automatically retrieves the missing audit event.

C. Defender XDR automatically converts the event into an alert.

D. The event must be available indefinitely because it is an administrative action.

Answer: A

Explanation: The current default Audit (Standard) retention period for applicable newer audit records is 180 days. Historical availability depends on the organization’s retention configuration and licensing.

Question 7

An organization has a compliance requirement to retain applicable audit records for several years.

Which capability should the organization investigate?

A. Azure resource locks

B. Microsoft Purview audit-log retention policies with appropriate licensing

C. Microsoft Sentinel automation rules

D. Microsoft Defender Vulnerability Management

Answer: B

Explanation: Microsoft Purview Audit (Premium) supports audit-log retention policies, including long-term retention. Longer retention periods require appropriate licensing.

Question 8

A security analyst searches Microsoft Defender XDR Audit and cannot find an expected event.

Which of the following is a valid reason the event might not appear?

A. Microsoft Defender audit records are never retained.

B. Audit records can only be queried with KQL.

C. The activity may not be a supported audited activity.

D. Audit records are stored only in Azure Resource Manager.

Answer: C

Explanation: Not every action performed in a Microsoft service is necessarily an audited activity. Investigators should verify that the activity is supported, as well as checking permissions, time range, user filters, and retention.

Question 9

A security engineer exports Microsoft Purview audit search results to CSV and wants to examine additional event properties contained within each record.

Which exported field contains additional event information formatted as JSON?

A. AuditData

B. ResourceGroup

C. IncidentData

D. SecurityData

Answer: A

Explanation: The exported audit results include an AuditData column containing additional event information in JSON format. The JSON can be transformed for easier analysis.

Question 10

An investigator is trying to determine whether a user changed a Defender security role immediately before a security incident.

Which approach provides the most appropriate combination of evidence?

A. Search Azure Policy compliance results only.

B. Review the Azure Activity Log only.

C. Search Microsoft Purview Audit for the relevant Defender activity and correlate the result with other security telemetry.

D. Query Azure Resource Graph for the user’s mailbox activity.

Answer: C

Explanation: Defender administrative actions are audited through Microsoft Purview. Searching the relevant audit activity can identify the administrative action and user, while correlating it with Defender, identity, endpoint, or Sentinel telemetry can help reconstruct the incident timeline.

Final Exam Reminder

When an SC-500 question asks you to investigate who performed an administrative or user action in Microsoft Defender XDR or Microsoft 365, think:

			
Microsoft Defender XDR activity
             |
             v
    Microsoft Purview Audit
             |
             v
       Audit search
             |
      +------+------+
      |      |      |
    Time  Activity  User
             |
             v
       Audit record
             |
             v
      Correlate with
     security telemetry

		

The central concept to remember is:

Microsoft Defender XDR uses Microsoft Purview auditing to record supported user and administrator activities, and those activities can be searched from the Defender portal’s Audit experience.

For the exam, keep the following distinctions especially clear:

Purview Audit → audited activities

Microsoft Sentinel → security data and KQL-based analysis

Defender XDR Audit → Defender activities recorded through Purview auditing

Audit retention → governed by Microsoft Purview audit-retention capabilities

Long-term audit retention → requires the appropriate Purview licensing and retention configuration

Go to the SC-500 Exam Prep Hub main page

azure, Azure AI, Microsoft Certification, SC-500, security October 10, 2026

Enable and configure real-time protection for Microsoft Copilot Studio agents (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Enable and configure real-time protection for Microsoft Copilot Studio agents

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

This topic covers how to use Microsoft Defender for Cloud Apps and Microsoft Defender XDR to provide runtime protection for agents created with Microsoft Copilot Studio.

You should understand how to:

Describe the security risks associated with AI agents.
Enable real-time protection for Copilot Studio agents.
Coordinate configuration between Microsoft Defender and Power Platform.
Configure the required Microsoft Entra application ID.
Understand how suspicious agent actions are detected and blocked.
Review agent inventory, alerts, incidents, and Advanced Hunting data.
Distinguish runtime protection from post-event investigation and governance.

Why Copilot Studio agents require runtime protection

AI agents can do more than generate text. Depending on their configuration, they may:

Retrieve information from enterprise data sources.
Invoke connectors and tools.
Call APIs.
Execute workflows.
Send messages.
Create or update records.
Perform actions on behalf of users.
Make decisions based on natural-language instructions.

This introduces risks that are different from those associated with a traditional application. An attacker or malicious user may attempt to manipulate an agent into performing an unsafe action, accessing information it should not use, or disclosing sensitive data.

Examples include:

Prompt injection.
Cross-prompt injection attacks.
Malicious or unexpected tool invocation.
Attempts to access protected information.
Data exfiltration.
Use of an agent to perform unauthorized actions.
Abuse of excessive agent permissions.

Real-time protection helps reduce these risks by evaluating agent activity during runtime and blocking suspicious actions before they execute. Microsoft Defender for Cloud Apps provides this protection for supported Copilot Studio agent scenarios.

What is real-time protection?

Real-time protection is a security capability that evaluates an AI agent’s activity while the agent is operating.

For Copilot Studio agents, protection evaluates tool invocations before the tools execute. If Microsoft Defender identifies suspicious behavior or a supported attack pattern, the proposed action can be blocked.

The protection process can be summarized as follows:

A user sends a prompt to an agent.
The agent interprets the request.
The agent considers invoking a tool, connector, or action.
Microsoft Defender evaluates the proposed invocation.
If the action is considered safe, the agent continues.
If the action is considered risky, the invocation is blocked.
Depending on the configuration and integration status, an alert or incident may be created in Microsoft Defender XDR.

This approach is designed to prevent unsafe actions rather than merely report them after they occur.

Microsoft Defender for Cloud Apps and Copilot Studio

The SC-500 learning objective identifies Microsoft Defender for Cloud Apps as the service used to provide runtime protection for Copilot Studio agents.

Microsoft Defender for Cloud Apps supplies the security integration, while Copilot Studio and Power Platform provide the agent runtime and configuration.

The integration requires coordination between:

A Microsoft Defender administrator.
A Power Platform administrator.
The Microsoft Entra application used by the agent integration.

The Defender administrator enables protection and provides configuration information. The Power Platform administrator completes the required onboarding steps in Power Platform. The application ID used during the process must match the application ID associated with the Microsoft Entra application.

Prerequisites

Before enabling protection, verify the following:

Microsoft Defender administration

The administrator should be familiar with:

The Microsoft Defender portal.
Microsoft Defender for Cloud Apps.
Microsoft Defender XDR.
Security for AI settings.
Alerts and incidents.
Advanced Hunting.

Copilot Studio and Power Platform

The organization should have:

Copilot Studio agents that require protection.
A Power Platform administrator available to complete onboarding.
The required agent configuration and application information.

Microsoft Entra application

The integration uses an application ID associated with a Microsoft Entra application. The application ID configured in Power Platform must match the application ID entered in the Defender portal.

Microsoft 365 app connector

The Microsoft 365 app connector should be connected when the organization wants protection outputs, such as alerts and incidents, to appear in Microsoft Defender. If the connector is not connected, runtime blocking may continue, but related alerts and incidents may not appear in the Defender portal.

Enabling real-time protection

The exact navigation may change as Microsoft updates the Defender portal, but the configuration process generally follows these steps.

Step 1: Open Microsoft Defender

Step 2: Open Security for AI settings

Navigate to the Defender portal’s AI security settings. Depending on the current portal experience, this may appear under:

Settings
Security for AI
Copilot Studio
Real-time protection

Microsoft documentation has used different navigation labels as the feature has evolved. The important exam concept is that the configuration is performed in the Microsoft Defender portal, not exclusively in Copilot Studio.

Step 3: Check the Microsoft 365 app connector

Verify that the Microsoft 365 app connector is connected.

If it is not connected, enable or configure it according to the organization’s requirements.

The connector is important for Defender visibility, including alerts and incidents associated with protected agent activity. Runtime protection may still block suspicious actions even when the connector is not connected, but the corresponding security outputs may not be available in the Defender portal.

Step 4: Enable real-time protection

Turn on the real-time protection setting for Copilot Studio agents.

This enables Defender to inspect supported agent tool invocations during runtime.

Step 5: Provide the Power Platform integration URL

The Defender portal provides a URL or configuration value that must be shared with the Power Platform administrator.

The Power Platform administrator uses this information to complete the external threat detection and protection configuration for the Copilot Studio agents.

Step 6: Configure the integration in Power Platform

The Power Platform administrator completes the required onboarding steps in Power Platform.

This establishes the connection between the Copilot Studio agent environment and the external protection service.

Step 7: Confirm the application ID

The Power Platform administrator provides the application ID used by the integration.

The Defender administrator enters that value in the appropriate App ID field in the Defender portal.

The application ID must match the App ID used by the Microsoft Entra application. A mismatch can cause validation errors or prevent the integration from becoming connected.

Step 8: Save and verify the connection

Save the configuration and verify that the integration displays a connected status.

If the application ID was recently changed, the update may take a short time to propagate. Microsoft documentation indicates that propagation can take approximately one minute in some cases.

How runtime protection works

The runtime protection process is designed to evaluate agent activity before a potentially dangerous action occurs.

For example, an agent might receive a prompt such as:

“Find the customer records for this account and send them to an external address.”

The agent may attempt to invoke a connector or API. Before the tool invocation executes, Defender evaluates the proposed action.

If the action is permitted:

The tool invocation proceeds.
The agent continues processing.
The user generally does not see an interruption.

If the action is blocked:

The tool invocation does not execute.
The agent stops or interrupts the relevant processing.
The user is notified that the request or action was blocked.
An alert or incident may be generated, depending on the configuration and connector status.

This is an important distinction: protection occurs at the point where the agent is about to perform an action, rather than only after the action has completed.

Threats that runtime protection can address

Runtime protection is intended to help detect and block supported threats involving agent activity.

Prompt injection

A prompt injection attack attempts to manipulate the agent into ignoring its intended instructions or security boundaries.

For example, a user may attempt to instruct an agent to:

Ignore its system instructions.
Reveal hidden configuration.
Disclose protected data.
Invoke a tool for an unauthorized purpose.
Treat untrusted content as a trusted instruction.

Cross-prompt injection

Cross-prompt injection can occur when malicious instructions are introduced through content that the agent retrieves or processes.

For example, a document, web page, or data source may contain instructions designed to manipulate the agent when it reads the content.

Unsafe tool invocation

An agent may attempt to invoke a connector, API, or action in a way that creates a security risk.

Examples include:

Sending sensitive information to an unauthorized destination.
Modifying records without sufficient authorization.
Calling an unexpected external service.
Accessing information outside the intended business purpose.

Data exfiltration

Data exfiltration occurs when an agent is manipulated into transferring sensitive information to an unauthorized person, application, or destination.

Runtime protection can help prevent certain exfiltration attempts by blocking the tool invocation responsible for the transfer.

However, runtime protection should not be treated as the only security control. Organizations should also use least-privilege access, data policies, DLP, sensitivity labels, authentication controls, and appropriate agent design.

Reviewing protection outputs

After enabling protection, administrators should verify that the expected security information is available in Microsoft Defender XDR.

Important outputs include:

AI agent inventory

The AI agent inventory helps administrators discover and review agents operating in the environment.

Depending on the available experience, inventory information may include:

Agent name.
Agent type.
Agent owner.
Agent environment.
Security posture.
Protection status.
Related recommendations.

Alerts and incidents

When suspicious activity is detected, Defender may generate alerts or incidents.

These can help administrators investigate:

The affected agent.
The user or activity involved.
The type of detected threat.
The action that was blocked.
The related evidence.
The recommended response.

Advanced Hunting

Advanced Hunting can be used to search and analyze security telemetry associated with AI agents.

This supports activities such as:

Identifying repeated attacks.
Finding agents that frequently trigger detections.
Detecting patterns across users or environments.
Correlating agent activity with other security events.
Creating custom detections and investigations.

The SC-500 objective specifically expects administrators to verify that agent inventory, alerts, and Advanced Hunting data appear in Microsoft Defender XDR.

Runtime protection versus agent governance

Runtime protection is only one layer of AI security.

Runtime protection

Runtime protection focuses on what an agent is attempting to do while it is operating.

It can help:

Inspect tool invocations.
Detect suspicious behavior.
Block risky actions.
Generate security alerts.

Agent governance

Agent governance focuses on how agents are created, configured, published, owned, and managed.

Governance activities include:

Reviewing agent ownership.
Controlling who can create agents.
Reviewing agent permissions.
Applying data policies.
Managing environments.
Reviewing authentication.
Monitoring agent lifecycle.
Removing unused agents.

Data protection

Data protection focuses on the information that agents can access or process.

Relevant controls include:

Microsoft Purview sensitivity labels.
Data Loss Prevention.
Microsoft Purview auditing.
Insider Risk Management.
SharePoint permissions.
Microsoft Entra Conditional Access.
Least-privilege permissions.
Data classification.

A secure agent deployment requires all three layers:

Secure agent design and governance.
Protected data and controlled access.
Runtime detection and blocking.

Copilot Studio built-in protection versus Defender protection

Copilot Studio includes built-in protections against certain threats, including prompt-injection-related attacks. External threat detection provides an additional layer of runtime monitoring and enforcement.

The external protection service evaluates proposed tool invocations and can return an allow or block decision.

The distinction is important:

Copilot Studio built-in protections are part of the agent platform.
Microsoft Defender protection provides an additional security and monitoring integration.
Microsoft Purview focuses on data security, compliance, classification, auditing, and information protection.
Microsoft Entra controls identity and access.
Microsoft Defender XDR provides centralized detection, investigation, and hunting experiences.

Protection status in Copilot Studio

Copilot Studio can display an agent-level protection status for published agents.

Possible statuses include:

Protected
Needs review
Unknown

The protection status can summarize categories such as:

Authentication.
Policies.
Content moderation.

A status of Needs review may indicate that the agent violates a policy or has an authentication issue. A status of Unknown means that the protection state cannot be confidently determined.

This status helps makers identify potential issues, but it does not replace centralized security monitoring in Microsoft Defender.

Operational best practices

Use least privilege

Give agents only the permissions and tools required for their intended business purpose.

Avoid granting broad access to:

SharePoint sites.
Dataverse tables.
Customer records.
Financial systems.
Administrative APIs.
External communication services.

Limit tool access

An agent should not have access to every connector or action available in its environment.

Use narrowly scoped tools and actions, and review them periodically.

Require appropriate authentication

Ensure that the agent’s authentication configuration is appropriate for the sensitivity of the data and actions involved.

Review agent ownership

Every production agent should have:

A business owner.
A technical owner.
A support contact.
A defined purpose.
A review schedule.

Monitor alerts and incidents

Do not enable protection and then ignore the resulting alerts. Repeated detections may indicate:

A malicious user.
A poorly designed agent.
An overly permissive connector.
A compromised account.
A legitimate workflow that requires adjustment.

Test before production deployment

Test agents with:

Normal business prompts.
Unexpected prompts.
Prompt injection attempts.
Requests for sensitive information.
Unauthorized tool requests.
Attempts to send information externally.

Keep protection enabled

Disabling runtime protection removes an important security layer. If protection must be disabled for troubleshooting, document the reason and re-enable it as soon as possible.

Troubleshooting considerations

The integration does not show Connected

Check:

Whether the Power Platform onboarding steps were completed.
Whether the correct App ID was entered.
Whether the App ID matches the Microsoft Entra application.
Whether the configuration has had enough time to propagate.
Whether the required administrators completed their respective tasks.

Alerts are not appearing

Check:

Whether the Microsoft 365 app connector is connected.
Whether the activity generated an alertable detection.
Whether the administrator has the required permissions.
Whether the agent is within the supported protection scope.
Whether the alert is available in the relevant Defender experience.

Runtime blocking may still occur even if alerts and incidents are not visible because the connector is not connected.

A legitimate action is blocked

Investigate:

The detection type.
The tool being invoked.
The data being accessed.
The user’s request.
The agent’s instructions.
The agent’s permissions.
Whether the workflow can be redesigned more safely.

Do not simply disable protection without understanding the cause.

Protection is not available for an agent

Verify:

The agent type is supported.
The agent is configured for the relevant runtime.
The required integration is enabled.
The tenant has the required licensing.
The agent is not a classic agent outside the supported external threat-detection scope.

Microsoft documentation states that the external threat detection integration applies to generative agents using generative orchestration and is skipped for classic agents.

Important exam distinctions

Defender for Cloud Apps versus Defender for Cloud

For this topic, runtime protection for Copilot Studio agents is associated with Microsoft Defender for Cloud Apps.

Do not confuse it with Microsoft Defender for Cloud capabilities used to protect Azure resources, AI services, containers, virtual machines, and cloud workloads.

Runtime protection versus investigation

Runtime protection attempts to block unsafe actions before execution.

Advanced Hunting and alert investigation are used to analyze activity and investigate threats.

Power Platform configuration versus Defender configuration

The integration requires work in both environments:

Defender enables and configures protection.
Power Platform completes the agent-side onboarding.
The Microsoft Entra App ID must match across the configuration.

Blocking versus auditing

A security system may be configured to observe or audit activity, or it may be configured to block specific detected actions.

Auditing provides visibility. Blocking provides preventive enforcement.

Protection versus data classification

Runtime protection evaluates agent behavior and tool invocations.

Data classification identifies sensitive information. The two capabilities address different parts of the security problem and should be used together.

Summary

To enable and configure real-time protection for Microsoft Copilot Studio agents:

Open the Microsoft Defender portal.
Navigate to the Security for AI settings.
Verify the Microsoft 365 app connector.
Enable real-time protection for Copilot Studio agents.
Share the provided integration URL with the Power Platform administrator.
Have the Power Platform administrator complete the onboarding process.
Obtain the correct Microsoft Entra application ID.
Enter the matching App ID in Defender.
Save the configuration.
Confirm the integration shows a connected status.
Verify agent inventory, alerts, incidents, and Advanced Hunting data.
Investigate and remediate blocked or suspicious activity.

The central exam concept is that Microsoft Defender for Cloud Apps can inspect supported Copilot Studio agent tool invocations during runtime and block suspicious actions before they execute.

Practice Exam Questions

Question 1

Which Microsoft service provides runtime protection for supported Microsoft Copilot Studio agents?

A. Microsoft Defender for Cloud Apps
B. Azure Backup
C. Microsoft Defender for Containers
D. Microsoft Purview Records Management

Answer: A

Explanation: Microsoft Defender for Cloud Apps provides the runtime protection integration for supported Copilot Studio agents. It evaluates agent activity and can block suspicious tool invocations.

Question 2

An administrator enables real-time protection in Microsoft Defender but does not complete the Power Platform configuration. What is the most likely result?

A. All Copilot Studio agents are automatically deleted.
B. The integration may not become connected or provide the expected protection outputs.
C. Microsoft Entra ID is disabled for the tenant.
D. All SharePoint permissions are removed.

Answer: B

Explanation: The onboarding process requires coordination between Defender and Power Platform. Enabling the Defender setting alone does not complete the integration.

Question 3

What must match between the Power Platform configuration and the Defender configuration?

A. The Azure subscription name
B. The SharePoint site URL
C. The Microsoft Entra application ID
D. The Microsoft Sentinel workspace name

Answer: C

Explanation: The App ID used by the Power Platform integration must match the App ID associated with the Microsoft Entra application and entered in the Defender portal.

Question 4

What does runtime protection primarily evaluate for Copilot Studio agents?

A. Azure virtual machine disk encryption
B. SharePoint retention labels
C. Tool invocations during agent execution
D. Microsoft Entra password expiration settings

Answer: C

Explanation: Runtime protection evaluates proposed agent tool invocations before they execute, helping detect and block suspicious actions.

Question 5

What happens when Defender identifies a suspicious tool invocation covered by a blocking protection rule?

A. The tool invocation is blocked before it executes.
B. The tool invocation always executes and is reviewed later.
C. The agent is permanently deleted.
D. The user is automatically assigned the Global Administrator role.

Answer: A

Explanation: The purpose of runtime protection is preventive enforcement. A suspicious action can be blocked before the tool executes.

Question 6

Which Microsoft Defender capability is useful for investigating patterns in AI agent security telemetry?

A. Azure Cost Management
B. Advanced Hunting
C. Azure Resource Locks
D. Microsoft Purview Data Lifecycle Management

Answer: B

Explanation: Advanced Hunting allows security teams to query and analyze security telemetry, identify repeated activity patterns, and investigate AI agent behavior.

Question 7

An organization wants alerts and incidents associated with protected Copilot Studio agent activity to appear in Microsoft Defender. Which component should the administrator verify?

A. Azure Bastion
B. Microsoft 365 app connector
C. Azure VPN Gateway
D. Microsoft Defender for Storage

Answer: B

Explanation: The Microsoft 365 app connector is important for Defender visibility. If it is not connected, runtime blocking may continue, but related alerts and incidents may not appear in the Defender portal.

Question 8

Which scenario is an example of prompt injection against an AI agent?

A. A user changes their Microsoft Entra password.
B. An administrator enables a resource lock.
C. A user attempts to manipulate the agent into ignoring its instructions and revealing protected information.
D. A security analyst exports an alert to a CSV file.

Answer: C

Explanation: Prompt injection attempts to manipulate an AI agent’s behavior by introducing instructions that conflict with its intended system instructions or security boundaries.

Question 9

Which statement best describes the relationship between runtime protection and Microsoft Purview?

A. Runtime protection and Microsoft Purview are identical services.
B. Runtime protection evaluates agent behavior, while Purview provides data security and compliance capabilities.
C. Microsoft Purview replaces all agent authentication controls.
D. Runtime protection is used only for Azure virtual machines.

Answer: B

Explanation: Runtime protection focuses on agent actions and tool invocations. Microsoft Purview supports data classification, sensitivity labels, DLP, auditing, Insider Risk Management, and other data-security and compliance capabilities.

Question 10

A Copilot Studio agent is configured as a classic agent rather than a generative agent using generative orchestration. What should the administrator understand about the external threat-detection integration?

A. It automatically converts the agent into a generative agent.
B. It applies only after the agent is deleted and recreated.
C. It is skipped for classic agents.
D. It requires Azure Bastion to be installed.

Answer: C

Explanation: Microsoft documentation states that the external threat-detection integration is called for generative agents using generative orchestration and is skipped for classic agents.

Go to the SC-500 Exam Prep Hub main page

AI Governance, AI Security, azure, Microsoft Certification, SC-500, security October 10, 2026

Analyze blast radius for security risks related to Entra Agent ID by using Defender XDR (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Analyze blast radius for security risks related to Entra Agent ID by using Defender XDR

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

AI agents can access data, invoke tools, call APIs, and perform actions across an organization. If an agent identity is compromised, the impact may extend far beyond the agent itself.

For example, an agent might have permission to:

Read confidential documents.
Access a customer database.
Modify records in a business application.
Call privileged APIs.
Access other identities or resources.
Use knowledge sources containing sensitive information.

The blast radius of an agent represents the potential impact of compromising that agent identity. It helps security teams understand what an attacker might be able to reach or control by abusing the agent’s permissions, connected resources, and relationships.

Microsoft Defender XDR provides an AI agent inventory, posture-risk information, and attack-path analysis to help security teams discover agents and assess the consequences of a compromised agent identity.

What Is Microsoft Entra Agent ID?

Microsoft Entra Agent ID provides identity capabilities for AI agents. Instead of treating every agent as an unidentified application process, an organization can represent an agent with a distinct identity that can be:

Authenticated.
Assigned permissions.
Governed.
Monitored.
Investigated.
Disabled or remediated when risky.

An agent identity should be treated as a security principal with a defined owner, purpose, permission set, and lifecycle.

This is important because an AI agent may have more effective access than its name or user interface suggests. The agent’s actual risk depends on what it can access and what actions it can perform—not merely on what the agent was designed to do.

What Is Blast Radius?

The blast radius is the set of resources, identities, applications, data, and systems that could potentially be affected if an agent identity were compromised.

A blast-radius assessment asks questions such as:

What permissions does the agent have?
Which applications and APIs can it access?
Which data sources are available to it?
Can it read or modify sensitive data?
Can it invoke tools that perform destructive actions?
Can it access privileged business systems?
Can it reach other identities or resources through existing relationships?
Are there attack paths from the agent to critical assets?

Example

Suppose an AI agent has:

Read access to a document repository.
Write access to a purchasing application.
Permission to call an external API.
Access to a knowledge source containing confidential business information.

If the agent is compromised, the attacker might be able to:

Read confidential documents.
Extract sensitive information.
Submit unauthorized purchasing requests.
Use the external API to transfer data.
Reach additional resources through the agent’s permissions.

The agent’s blast radius is therefore larger than the agent itself.

Why AI Agents Create Unique Blast-Radius Risks

AI agents introduce additional risk because they can dynamically determine which tools to use and which actions to perform.

Traditional applications often follow fixed workflows. Agents may instead:

Interpret natural-language instructions.
Retrieve information from multiple sources.
Select tools dynamically.
Chain several actions together.
Act autonomously.
Use permissions inherited from a user or application.
Operate without continuous human approval.

A compromised or manipulated agent may therefore use legitimate permissions in unintended ways.

Important AI-related risks include:

Over-privileged agent identities.
Excessive access to sensitive data.
Unrestricted tool invocation.
Indirect prompt injection.
Weak or missing authentication.
Agents that can operate without human approval.
Privileged access to business systems.
Active threats or alerts associated with the agent.

Microsoft Defender assesses agent posture using risk indicators derived from configuration, permissions, tools, runtime activity, settings, and associated security alerts.

Microsoft Defender XDR AI Agent Inventory

Microsoft Defender XDR provides a centralized inventory of AI agents in the organization.

Depending on the available integrations and supported platforms, the inventory can include agents built with:

Microsoft Copilot Studio.
Microsoft Foundry.
Microsoft 365.
Supported non-Microsoft platforms.
Local AI agents discovered on endpoint devices.

The inventory can provide information about:

Agent identity.
Agent type.
Agent configuration.
Connected tools.
Knowledge sources.
Risk level.
Risk indicators.
Security recommendations.
Related alerts.
Security context.

To review agents in the Microsoft Defender portal, navigate to:

Assets → AI agents → Agents

The exact portal experience may change as Microsoft’s AI security capabilities evolve.

Agent Risk Level Versus Blast Radius

These concepts are related but are not identical.

Agent risk level

The risk level represents the overall security risk associated with an agent. Microsoft Defender combines active risk indicators to determine an overall risk level.

Possible risk levels include:

High
Medium
Low
No known risk
Not evaluated

Risk indicators may include:

Weak instructions.
Indirect prompt-injection exposure.
Privileged business-system access.
High usage.
Active threats.
Lack of human approval.
Access to sensitive data.

The risk level is influenced by both the severity and combination of active indicators.

Blast radius

Blast radius focuses on the potential impact if the agent is compromised.

An agent could have a high blast radius even if no active threat has been detected. For example, an agent may be operating as designed but have broad permissions to critical systems.

Conversely, an agent may have a low blast radius but still be actively compromised.

Therefore:

Risk level describes the likelihood and seriousness of the agent’s security exposure. Blast radius describes what could be affected if the agent were compromised.

Security teams should evaluate both.

Key Risk Indicators

Microsoft Defender uses risk indicators to provide context about an agent’s exposure.

Privileged business-system access

This indicates that an agent has write access to important business systems.

Examples include:

Creating or modifying financial transactions.
Changing customer records.
Updating inventory.
Modifying business-critical configurations.
Accessing administrative APIs.

An agent with write access generally has a greater blast radius than an agent with read-only access.

Indirect prompt-injection exposure

An agent may retrieve content containing hidden instructions from:

Email.
Documents.
Web pages.
Knowledge bases.
External data sources.

The content may attempt to manipulate the agent into performing unintended actions.

This risk is especially important when the agent can access sensitive data or invoke powerful tools.

Weak instructions

Weak or incomplete instructions may fail to establish safe operating boundaries for the agent.

For example, an agent may not be clearly instructed to:

Refuse unauthorized requests.
Avoid exposing secrets.
Request approval before destructive actions.
Validate tool parameters.
Restrict access to approved resources.

High-usage agent

An agent used by many people may be important to business operations. A compromise could affect a large number of users or business processes.

High usage does not necessarily mean the agent is insecure, but it increases the importance of careful review.

Active threat

An active threat indicator means that security alerts are associated with the agent.

An agent with both an active threat and privileged access should receive immediate attention because the likelihood and potential impact of compromise may both be significant.

Understanding Attack Paths

An attack path is a possible sequence of relationships or permissions that could allow an attacker to move from a compromised entity to a target resource.

For an agent, an attack path might look like:

Compromised agent identity → application permission → sensitive database → confidential data

Another example could be:

Compromised agent → privileged API → business application → administrative action

Attack-path analysis helps identify indirect exposure that may not be obvious when reviewing the agent’s permissions individually.

A single permission may appear harmless, but a sequence of permissions and relationships may create a significant route to a critical asset.

Microsoft Defender graphs use nodes and edges to represent entities and relationships. Attack-path analysis can show potential routes between a source entity and a target asset.

How to Analyze an Agent’s Blast Radius

Step 1: Discover the agent

Open the Microsoft Defender portal and review the AI agent inventory.

Identify:

The agent name.
The agent type.
Its associated identity.
Its owner.
Its environment.
Its connected tools.
Its knowledge sources.
Its risk level.

The inventory is the starting point for understanding which agents exist and which require further investigation.

Step 2: Review the agent’s configuration

Examine how the agent is configured.

Important questions include:

Is the agent autonomous?
Does it act on behalf of a user?
Can it operate without human approval?
Which tools can it invoke?
Which applications can it access?
Does it have write or administrative capabilities?
Does it use external services?
Does it retrieve content from untrusted sources?

Configuration weaknesses can increase the likelihood that an agent will be manipulated or misused.

Step 3: Review permissions and identities

Determine the permissions assigned to the agent identity.

Review:

Microsoft Entra roles.
Application permissions.
Delegated permissions.
API scopes.
Resource access.
Group memberships.
Access packages.
Privileged assignments.
Permissions inherited through applications or users.

The goal is to determine what the agent can actually do, not merely what it is intended to do.

Step 4: Review knowledge sources

Knowledge sources can significantly increase an agent’s blast radius.

Review whether the agent can access:

Confidential documents.
Customer information.
Financial data.
Internal policies.
Credentials or secrets.
Sensitive databases.
External content.
Data belonging to multiple departments.

An agent with read access to a broad knowledge source may expose more information than expected, even if it cannot modify the underlying data.

Step 5: Review connected tools

Tools determine what actions the agent can perform.

Examples include tools that:

Query databases.
Send email.
Create support tickets.
Modify records.
Call external APIs.
Execute workflows.
Access storage.
Provision resources.

A tool with write, delete, or administrative capability can substantially increase the agent’s potential impact.

Step 6: Review blueprint configuration

Agent identity blueprints can provide a consistent way to create and manage agent identities.

Review blueprint configuration to determine whether it establishes:

Appropriate identity settings.
Required governance.
Permission boundaries.
Consistent security controls.
Appropriate ownership.
Secure defaults.

A poorly configured blueprint may create multiple agents with the same excessive permissions or weak security settings.

Step 7: Review risk indicators and recommendations

Review the agent’s active risk indicators and any available security recommendations.

Risk indicators describe the agent’s exposure. Recommendations identify actionable changes that may reduce that exposure.

A high-risk agent may not always have an available recommendation, and a lower-risk agent may still have a recommendation that should be implemented. Therefore, review the risk level and recommendations together.

Step 8: Analyze attack paths

Use the available Defender graph and attack-path capabilities to investigate possible routes from the agent to sensitive resources.

Look for paths involving:

Privileged identities.
Sensitive applications.
Critical databases.
Storage accounts.
Administrative roles.
High-value business systems.
External access.
Lateral movement.

The objective is to identify not only direct access but also indirect routes that could lead to compromise of critical assets.

Step 9: Prioritize remediation

Prioritize agents that combine several high-impact characteristics, such as:

High risk.
Privileged access.
Access to sensitive data.
Autonomous operation.
External exposure.
Active security alerts.
Write access to critical systems.
Multiple attack paths to important assets.

Defender Blast-Radius Graphs

Microsoft Defender can display graph-based views of entities and potential attack paths.

A graph generally contains:

Nodes, representing entities or assets.
Edges, representing relationships or connections.
Paths, representing possible routes between entities.

For an incident, investigators can select an entity and choose View blast radius when the capability is available. The graph can show highly rated attack paths and a list of reachable targets. Investigators can select a target to inspect the potential path leading to it.

What the graph can help identify

The graph may reveal:

A compromised identity’s reachable resources.
Indirect paths to critical assets.
Relationships between identities and applications.
Potential lateral movement.
Privilege-escalation routes.
Access to sensitive data.
Connections between an agent and other entities.

Important limitations

Blast-radius graphs are an approximation of possible attack reach.

They may be limited by:

The number of hops analyzed.
Data freshness.
The attack techniques modeled.
The viewer’s RBAC scope.
Missing or incomplete relationships.
Changes in the environment that have not yet been reflected.

The graph shows possible paths. It does not guarantee that an attacker will use every path shown.

Interpreting the Blast Radius Correctly

A blast-radius graph should not be interpreted as proof that a compromise has occurred.

Instead, it answers:

“If this identity were compromised, what resources might be reachable through known relationships and permissions?”

The graph is useful for:

Prioritizing remediation.
Identifying excessive permissions.
Understanding lateral movement.
Finding critical assets exposed through an agent.
Supporting incident investigation.
Designing Conditional Access policies.
Improving agent architecture.

It should be combined with:

Actual sign-in and activity logs.
Security alerts.
Agent configuration.
Permission reviews.
Data classification.
Business criticality.
Incident-response procedures.

Example Scenario

A company deploys an autonomous finance agent.

The agent can:

Read invoices.
Query a financial database.
Submit payment requests.
Access a shared document repository.
Call a payment-processing API.

Defender identifies the following risk indicators:

Privileged business-system access.
Indirect prompt-injection exposure.
Ability to operate without human approval.
Access to sensitive financial data.

An attack-path analysis shows:

Agent identity → payment API → financial system

It also shows:

Agent identity → shared repository → confidential financial documents

The security team should consider:

Removing unnecessary write permissions.
Requiring human approval for payment actions.
Restricting the agent to approved APIs.
Limiting access to financial documents.
Reviewing prompt-injection protections.
Applying Conditional Access to high-risk agent identities.
Monitoring related alerts and activity.
Reassessing the blast radius after remediation.

Relationship to Conditional Access

Conditional Access and blast-radius analysis work together.

Blast-radius analysis helps answer:

Which agents are high impact?
Which agents have privileged access?
Which resources should be protected?
Which agents should be restricted or blocked?

Conditional Access can then enforce policies such as:

Block high-risk agent identities.
Restrict selected agents from sensitive applications.
Separate development and production agents.
Apply policies based on agent attributes.
Restrict access to selected resources.

Microsoft Entra ID Protection can detect risky agent behavior. When an agent is confirmed as compromised, its risk can be set to High, allowing a Conditional Access policy configured to block high agent risk to prevent access to resources.

Relationship to Microsoft Defender for Cloud and Microsoft Purview

Blast-radius analysis is not the same as every other security capability.

Microsoft Defender XDR

Used for:

AI agent inventory.
Agent risk assessment.
Identity investigation.
Attack-path analysis.
Security alerts.
Incident investigation.

Microsoft Defender for Cloud

Used more broadly for:

Cloud security posture management.
Workload protection.
Security recommendations.
Cloud resource security.
AI workload protection.

Microsoft Purview

Used for:

Data classification.
Sensitivity labels.
Data security posture management.
Data-loss prevention.
Compliance and information protection.

Microsoft Entra Conditional Access

Used for:

Evaluating access conditions.
Blocking risky agent identities.
Restricting access to selected resources.
Enforcing identity-based access policies.

These capabilities complement one another. No single control provides complete protection for AI agents.

Best Practices

Use dedicated agent identities

Avoid sharing a broad identity across unrelated agents. Separate identities improve accountability and reduce the impact of a single compromise.

Apply least privilege

Grant only the permissions required for the agent’s purpose.

Minimize write and administrative permissions

Read-only access generally creates a smaller blast radius than the ability to modify or delete data.

Restrict tools

Every connected tool expands the agent’s potential attack surface. Remove tools that are not required.

Use approval gates

Require human approval for:

Financial transactions.
Data deletion.
Permission changes.
External communications.
Production changes.
Other high-impact actions.

Protect knowledge sources

Limit the data available to the agent and ensure that sensitive sources are properly secured.

Separate environments

Development and test agents should not automatically have access to production resources.

Review blueprints

Ensure that agent identity blueprints do not create agents with excessive or inconsistent permissions.

Monitor active threats

An agent with active alerts and privileged access should be investigated immediately.

Reassess after changes

Recalculate or review the agent’s exposure after changing:

Permissions.
Tools.
Knowledge sources.
Identity configuration.
Resource access.
Blueprint settings.

Treat graphs as possible paths

Do not assume that every path shown is an active attack or that every possible path is displayed.

Common Exam Traps

Blast radius is not the same as risk level

Risk level describes the agent’s overall security exposure. Blast radius describes the potential impact of compromise.

An agent does not need to be compromised to have a large blast radius

An agent may be configured with excessive permissions even when no threat has been detected.

Read access and write access are different

Write access to critical business systems generally creates a greater potential impact than read-only access.

Attack paths show possibilities

A graph shows possible routes based on known relationships and data. It does not prove that an attacker has used the route.

Conditional Access does not remove permissions

Conditional Access controls whether access is allowed under specified conditions. It does not replace least-privilege authorization.

Risk indicators and recommendations are different

Risk indicators contribute to the agent’s risk assessment. Recommendations identify available actions that may improve security posture.

A high-risk agent may not have a recommendation

Risk level and available recommendations are calculated separately.

Missing graph paths do not prove that no risk exists

Graphs have scope, freshness, and modeling limitations.

Practice Exam Questions

Question 1

What does the blast radius of a Microsoft Entra agent identity primarily describe?

A. The number of users who have interacted with the agent
B. The amount of compute capacity assigned to the agent
C. The potential resources and systems affected if the agent identity is compromised
D. The number of prompts processed by the agent

Correct answer: C

Explanation: Blast radius describes the potential impact of compromising the agent, including reachable data, applications, identities, and systems.

Question 2

Which Microsoft Defender capability provides a centralized view of AI agents and their security context?

A. Azure Cost Management
B. Azure Resource Graph only
C. Microsoft Purview retention management
D. AI agent inventory

Correct answer: D

Explanation: The AI agent inventory in Microsoft Defender provides visibility into agents, configuration, identities, risk indicators, tools, and related security information.

Question 3

An agent has no active security alerts but can modify a critical financial system. What should the security team conclude?

A. The agent has no security risk
B. The agent has a potentially large blast radius even though no compromise has been detected
C. The agent must be deleted immediately
D. The agent cannot be protected by Conditional Access

Correct answer: B

Explanation: Blast radius is based on potential impact. Privileged access can create significant exposure even when no active threat has been detected.

Question 4

Which risk indicator most directly suggests that an agent can affect important business operations?

A. High usage
B. Weak instructions
C. Indirect prompt-injection exposure
D. Privileged business-system access

Correct answer: D

Explanation: Privileged business-system access indicates that the agent can write to or otherwise affect important business systems.

Question 5

What is the purpose of analyzing attack paths for an agent identity?

A. To determine the model’s response quality
B. To identify possible routes from the agent to other resources or critical assets
C. To calculate the agent’s monthly operating cost
D. To configure the agent’s natural-language instructions

Correct answer: B

Explanation: Attack-path analysis identifies possible relationships and permission chains that could allow access to additional resources or critical assets.

Question 6

Which statement best distinguishes an agent’s risk level from its blast radius?

A. Risk level measures potential impact only, while blast radius measures prompt quality
B. Risk level applies only to human users, while blast radius applies only to applications
C. Risk level reflects overall security exposure, while blast radius reflects potential impact if compromised
D. They are two names for exactly the same measurement

Correct answer: C

Explanation: Risk level combines active risk indicators. Blast radius focuses on what could be affected if the agent identity were compromised.

Question 7

A Defender blast-radius graph displays a path from an agent to a sensitive database. What does this mean?

A. The agent has definitely been compromised
B. The database has already been accessed
C. The graph identifies a possible route based on known relationships and permissions
D. The agent must be assigned a database administrator role

Correct answer: C

Explanation: A blast-radius graph shows possible attack paths. It does not prove that compromise or access has occurred.

Question 8

Which change would most directly reduce an agent’s blast radius?

A. Remove unnecessary write permissions and restrict the agent to required resources
B. Increase the agent’s model size
C. Add more knowledge sources
D. Allow the agent to use additional administrative APIs

Correct answer: A

Explanation: Reducing permissions and limiting resource access directly reduces what the agent could affect if compromised.

Question 9

Why should security teams review an agent’s knowledge sources during blast-radius analysis?

A. Knowledge sources determine the agent’s compute pricing
B. Knowledge sources may expose confidential or sensitive information to the agent
C. Knowledge sources automatically grant Global Administrator access
D. Knowledge sources eliminate the need for identity protection

Correct answer: B

Explanation: Knowledge sources may contain sensitive information. The agent’s access to those sources can significantly increase the impact of compromise or misuse.

Question 10

Which statement about Microsoft Defender blast-radius graphs is accurate?

A. They show every possible attack path with complete certainty
B. They prove that all displayed paths have been exploited
C. They replace permission reviews and incident investigation
D. They show possible paths and may be limited by data freshness, scope, and modeled attack techniques

Correct answer: D

Explanation: Blast-radius graphs are useful approximations, but they have limitations involving data freshness, RBAC scope, hop limits, and known attack vectors.

Go to the SC-500 Exam Prep Hub main page