Microsoft Sentinel
Cloud and workloadsApplication card for Microsoft Sentinel SIEM
In brief
The documentation describes the SOAR playbook generator as an AI-assisted LLM feature in the Microsoft Defender portal. It clarifies that generated playbooks are code-based Python scripts running in a managed environment and specifies the permissions required to generate and deploy them.
What Defender admins need to know
Administrators can use the documented Microsoft Defender unified RBAC permissions to validate access for playbook generation, deployment, and automation-rule authoring.
Summaries are generated from the documentation change itself.
Documentation change
View on Microsoft LearnThe comparison below shows only the changed extract. Use the full-page view for complete context.
Application card: Microsoft Sentinel SIEM
| Term | Description |
|---|---|
| Behavior | A structured record of activity produced by the Microsoft Sentinel UEBA (User and Entity Behavior Analytics) behaviors layer. A behavior captures a series of related security events consolidated into a single narrative (for example, "User X accessed 25 resources in 10 minutes") with additional context like the involved entities and relevant MITRE ATT&CK tactic labels. |
| Playbook | An automated workflow in Microsoft Sentinel that performs a sequence of |
| Security orchestration | The coordination of multiple automated tasks and responses in security systems. In Microsoft Sentinel, orchestration refers to combining various actions (for example, sending an alert, quarantining a device, and notifying a team) into a coherent, automated playbook that can be triggered by security incidents or alerts. |
Key features or capabilities
| Feature | Description |
|---|---|
| UEBA behaviors layer | An AI-powered analytics layer that automatically aggregates and contextualizes security events. As logs are ingested, this feature groups related events from multiple sources into cohesive behavior entries. Each behavior provides an enriched summary of the activity—identifying the key actor(s) and target(s), labeling the relevant MITRE ATT&CK tactics, and describing in plain language what occurred. For example, instead of an analyst manually correlating dozens of logon attempts and file access events, the behaviors layer might output a single behavior like "User A attempted 10 logins from different IPs and accessed sensitive files in a short timeframe (Technique: Valid Accounts; Tactic: Credential Access)." By presenting many raw events as a single intelligible pattern, this capability reduces noise and helps analysts quickly focus on potentially unusual or noteworthy activities. For more information, see User and Entity Behavior Analytics (UEBA) behaviors layer. |
| SOAR playbook generator |
For more information, see Generate playbooks using AI in Microsoft Sentinel. |
Intended uses
- The model is guided through prompt engineering to focus on generating safe and relevant code. The team tested for undesirable outputs, and the system is more likely to respond with an error or request clarification than to produce something overtly dangerous if given a confusing or inappropriate request.
- The generator doesn't have the ability to run a playbook immediately on its own. Human review is mandatory—the playbook is saved but remains inactive until an authorized user enables it.
Additionally, theThe team also considered misuse—for example,whether someone could someone misuse the generator to create a playbook that intentionally exfiltrates data or causes disruption?disruption. The primary protections are access control and user oversight. Only users with specific roles (like Sentinel Contributorthe Automation: Automation Playbooks (Read and Automation/Detection Tuning roles)Write) permission can use the generator,generate and those individuals are typically trusted, trained personnel. And since the outputdeploy playbooks. The generated code is fully visible to these usersfor review before activation, any malicious intent would likely be caught during review. This layered approach - gatingactivation. Requiring the capability to appropriate rolespermission and requiringexplicit activation - mitigates the risk of feature abusehelps mitigate misuse by ensuringmaintaining an audit trail exists and requiring authorized personnel involvement.
No evidence of disparate impact or demographic bias is present for these features, as they operate on technical data and user-driven inputs, not on attributes of individuals. Behavior summaries and playbooks treat all inputs equally without preferential or prejudicial differences.
Transparency and explainability: Both features are built with transparency in mind. The behaviors layer's output includes clear descriptions and tags that explain each behavior and why certain events were grouped together. Analysts can click on a behavior to see the underlying events for verification. The playbook generator produces detailed documentation for each playbook, including a step-by-step explanation of the logic and a visual flowchart. This makes it easy for a security team to understand what an AI-generated playbook does, and adjust or augment it if needed. Transparency is crucial for trust—users should feel confident that they understand the AI's outputs before relying on them in their workflows.
Access and permissions: Access to AI features is controlled through existing
securitypermissions and roles.By requiring roles likeGenerating and deploying playbooks requires the Automation: Automation Playbooks (Read and Write) permission in Microsoft Defender unified RBAC. Authoring automation rules requires the Microsoft Sentinel Contributor role on the relevant workspaces orAutomation Contributor, Microsoft ensures that only qualified personnel can use the playbook generator. This reduces the risk of inexperienced users generating playbooks without proper oversight.resource groups. Similarly, the behaviors layer isautomaticallyavailable only tothoseusers who have access to the relevant logs and analyticsresults, meaning it's used by those who already handle sensitive security data.results.Data security and privacy: All processing for these features happens within the Microsoft Azure
environment,environment under the same compliance standards as the rest of Microsoft Sentinel. The behaviors layer processes dataentirelywithin the SIEM'sanalyticspipeline—itpipeline and doesn't send log data outside the service. For the playbook generator,the userAI processing occurs within Microsoft'spromptcloud environment, andcontext arecustomer data is handledby an Azure OpenAI instance tiedaccording to Microsoft's data-handling commitments. Data from user prompts and generated code isn't used to train the base model. Microsoft might collect usage telemetry and anonymized quality signals, depending on the customer'sSecurity Copilot tenant (which enforces data handling policies consistent with enterprise requirements). No long-term retention of prompt data occurs beyond what's needed to generate the output (unless the customer opts in to allow Microsoft to use it for product improvement under strict controls). These measures ensure that using these AI features doesn't expose or store sensitive customer data inappropriately.data-sharing settings.Testing and iteration support: Microsoft provides avenues within the tools themselves to help users adopt them safely. For example, the playbook generator interface allows users to run the new playbook on a sample alert (typically a sanitized incident) to see what actions it would take, verifying outcomes before deployment. The behaviors layer outputs can be compared against known sequences of events to confirm they align with expectations. Microsoft's documentation encourages such testing and outlines best practices for validating AI outputs (such as performing dry runs or starting in a lab environment). This approach helps organizations integrate the AI features gradually and with confidence.
Exercise caution when designing agentic AI in sensitive domains: Users should exercise caution when designing and/or deploying agentic AI applications in sensitive domains where agent actions are irreversible or highly consequential. Additional precautions should also be taken when creating autonomous agentic AI as described further in either the Microsoft Enterprise AI Services Code of Conduct (for organizations) or the Code of Conduct section in the Microsoft Services Agreement (for individuals).
Ensure relevant data and prerequisites: For the behaviors layer, connect the supported data
sources (suchsources, such as network logs or cloud auditlogs) so youlogs, to get the most out of the feature. More complete and high-quality data in Sentinel leads to more comprehensive behaviors. For the playbook generator,verifyonboard your Microsoft Sentinel workspace to the Defender portal and ensure you have the Automation: Automation Playbooks (Read and Write) permission in Microsoft Defender unified RBAC. The generator doesn've met all prerequisites (such as enablingt require a separate Microsoft Security Copilotin your tenant and having the appropriate user roles) before use.license or Security Compute Units. For all requirements, see Generate playbooks using AI in Microsoft Sentinel.Start with human oversight and small scope: Initially, treat AI outputs as suggestions or prototypes. For instance, use the playbook generator to create a new playbook and then walk through the code line by line with your team before trusting it on live incidents. You might deploy it in a monitoring-only mode (for example, logging actions but not taking irreversible steps) at first. Similarly, when you enable the behaviors layer, start by observing how it represents known benign vs. known malicious sequences in your logs to gauge its accuracy, and then gradually incorporate behaviors into detection rules or workflows.
@@ -1,7 +1,7 @@ --- title: Application card for Microsoft Sentinel SIEM titleSuffix: Microsoft Security-description: Details the AI-driven capabilities that support threat detection, investigation, response, and proactive hunting across multicloud environments.+description: Learn about the AI-driven Microsoft Sentinel capabilities that support threat detection, investigation, response, and proactive hunting in multicloud environments. f1.keywords: - NOCSH author: guywi-ms@@ -10,16 +10,16 @@ ms.localizationpriority: medium audience: ITPro ms.reviewer: mschechter ms.topic: concept-article-ms.date: 05/18/2026+ms.date: 08/24/2026 ms.service: microsoft-sentinel-ms.custom: responsible-ai-transparency+ms.custom: responsible-ai-transparency, msecd-doc-authoring-1015 ms.collection: - m365-security - tier1 - msec-ai-copilot ai-usage: ai-assisted -#customer intent: As a security analyst, I want to understand the responsible AI application card for Microsoft Sentinel SIEM+#customer intent: As a security analyst, I want to understand the responsible AI application card for Microsoft Sentinel SIEM so that I can evaluate and use its AI features responsibly. --- # Application card: Microsoft Sentinel SIEM@@ -45,7 +45,7 @@ The following table defines key terms relevant to Microsoft Sentinel's AI-enhanc |Term |Description | |---------|---------| |**Behavior**|A structured record of activity produced by the Microsoft Sentinel UEBA (User and Entity Behavior Analytics) behaviors layer. A behavior captures a series of related security events consolidated into a single narrative (for example, "User X accessed 25 resources in 10 minutes") with additional context like the involved entities and relevant MITRE ATT&CK tactic labels.|-|**Playbook**|An automated workflow in Microsoft Sentinel that performs a sequence of actions (such as alert triage or incident response tasks). Traditional Sentinel playbooks are built using Azure Logic Apps, whereas playbooks generated by the AI-assisted playbook generator (preview) are provided as code-based (Python) scripts running in a managed environment within Microsoft Sentinel.|+|**Playbook**|An automated workflow in Microsoft Sentinel that performs a sequence of actions, such as alert triage or incident response tasks. Traditional Sentinel playbooks use Azure Logic Apps. Playbooks from the AI-assisted playbook generator are code-based Python scripts that run in a managed environment within Microsoft Sentinel.| |**Security orchestration**|The coordination of multiple automated tasks and responses in security systems. In Microsoft Sentinel, orchestration refers to combining various actions (for example, sending an alert, quarantining a device, and notifying a team) into a coherent, automated playbook that can be triggered by security incidents or alerts.| ## Key features or capabilities@@ -55,7 +55,7 @@ The key features and capabilities in the following table describe what Microsoft |Feature |Description | |---------|---------| |**UEBA behaviors layer**|An AI-powered analytics layer that automatically aggregates and contextualizes security events. As logs are ingested, this feature groups related events from multiple sources into cohesive behavior entries. Each behavior provides an enriched summary of the activity—identifying the key actor(s) and target(s), labeling the relevant MITRE ATT&CK tactics, and describing in plain language what occurred. For example, instead of an analyst manually correlating dozens of logon attempts and file access events, the behaviors layer might output a single behavior like "User A attempted 10 logins from different IPs and accessed sensitive files in a short timeframe (Technique: Valid Accounts; Tactic: Credential Access)." By presenting many raw events as a single intelligible pattern, this capability reduces noise and helps analysts quickly focus on potentially unusual or noteworthy activities. <br/><br/> For more information, see [User and Entity Behavior Analytics (UEBA) behaviors layer](entity-behaviors-layer.md).|-|**SOAR playbook generator (preview)**|An AI-assisted playbook authoring feature that uses a large language model (LLM) to create automation workflows from natural-language descriptions. Security teams can interact with an embedded AI coding assistant in the Microsoft Defender portal, providing a plain English description of a security process they want to automate. The system then generates a Python-based Sentinel playbook implementing that workflow, complete with documentation and a visual flow diagram. For instance, an analyst might describe, "If an incident is high severity, gather host information and notify the on-call engineer," and the playbook generator produces a script to perform exactly those steps. The generated playbook is integrated into Sentinel's automation library, where it can be reviewed, tested on sample incidents, and then activated by the user to run on actual alerts or incidents. By enabling code-free automation development, this feature accelerates the creation of custom response playbooks and broadens the range of team members who can contribute to security automation. <br/><br/> For more information, see [Generate playbooks using AI in Microsoft Sentinel](automation/generate-playbook.md).|+|**SOAR playbook generator**|A generally available AI-assisted authoring feature that uses a large language model (LLM) to create automation workflows from natural-language descriptions. The generator is available to Microsoft Sentinel customers in the Microsoft Defender portal without a separate Microsoft Security Copilot license or Security Compute Units. Security teams describe a process to automate, and the generator creates an editable Python playbook with tests, documentation, and a visual flow diagram. Users can review and test the generated playbook before activating it for alerts or incidents. Access the generator from the **Playbooks** tab on the **Automation** page in the Defender portal. Generating and deploying playbooks requires the Automation: **Automation Playbooks (Read and Write)** permission in Microsoft Defender unified role-based access control (RBAC). <br/><br/> For more information, see [Generate playbooks using AI in Microsoft Sentinel](automation/generate-playbook.md).| ## Intended uses @@ -140,7 +140,7 @@ Microsoft examined potential risks and unintended behaviors of these AI features - The model is guided through prompt engineering to focus on generating safe and relevant code. The team tested for undesirable outputs, and the system is more likely to respond with an error or request clarification than to produce something overtly dangerous if given a confusing or inappropriate request. - The generator doesn't have the ability to run a playbook immediately on its own. Human review is mandatory—the playbook is saved but remains inactive until an authorized user enables it. -Additionally, the team considered misuse—for example, could someone misuse the generator to create a playbook that intentionally exfiltrates data or causes disruption? The primary protections are access control and user oversight. Only users with specific roles (like Sentinel Contributor and Automation/Detection Tuning roles) can use the generator, and those individuals are typically trusted, trained personnel. And since the output code is fully visible to these users before activation, any malicious intent would likely be caught during review. This layered approach - gating the capability to appropriate roles and requiring activation - mitigates the risk of feature abuse by ensuring an audit trail exists and requiring authorized personnel involvement.+The team also considered whether someone could misuse the generator to create a playbook that intentionally exfiltrates data or causes disruption. The primary protections are access control and user oversight. Only users with the Automation: **Automation Playbooks (Read and Write)** permission can generate and deploy playbooks. The generated code is visible for review before activation. Requiring the appropriate permission and explicit activation helps mitigate misuse by maintaining an audit trail and requiring authorized personnel involvement. No evidence of disparate impact or demographic bias is present for these features, as they operate on technical data and user-driven inputs, not on attributes of individuals. Behavior summaries and playbooks treat all inputs equally without preferential or prejudicial differences. @@ -160,9 +160,9 @@ Microsoft has implemented several measures to ensure these AI features remain sa - **Transparency and explainability:** Both features are built with transparency in mind. The behaviors layer's output includes clear descriptions and tags that explain each behavior and why certain events were grouped together. Analysts can click on a behavior to see the underlying events for verification. The playbook generator produces detailed documentation for each playbook, including a step-by-step explanation of the logic and a visual flowchart. This makes it easy for a security team to understand what an AI-generated playbook does, and adjust or augment it if needed. Transparency is crucial for trust—users should feel confident that they understand the AI's outputs before relying on them in their workflows. -- **Access and permissions:** Access to AI features is controlled through existing security roles. By requiring roles like Microsoft Sentinel Contributor or Automation Contributor, Microsoft ensures that only qualified personnel can use the playbook generator. This reduces the risk of inexperienced users generating playbooks without proper oversight. Similarly, the behaviors layer is automatically available only to those who have access to relevant logs and analytics results, meaning it's used by those who already handle sensitive security data.+- **Access and permissions:** Access to AI features is controlled through existing permissions and roles. Generating and deploying playbooks requires the Automation: **Automation Playbooks (Read and Write)** permission in Microsoft Defender unified RBAC. Authoring automation rules requires the **Microsoft Sentinel Contributor** role on the relevant workspaces or resource groups. Similarly, the behaviors layer is available only to users who have access to the relevant logs and analytics results. -- **Data security and privacy:** All processing for these features happens within the Microsoft Azure environment, under the same compliance standards as the rest of Microsoft Sentinel. The behaviors layer processes data entirely within the SIEM's analytics pipeline—it doesn't send log data outside the service. For the playbook generator, the user's prompt and context are handled by an Azure OpenAI instance tied to the customer's Security Copilot tenant (which enforces data handling policies consistent with enterprise requirements). No long-term retention of prompt data occurs beyond what's needed to generate the output (unless the customer opts in to allow Microsoft to use it for product improvement under strict controls). These measures ensure that using these AI features doesn't expose or store sensitive customer data inappropriately.+- **Data security and privacy:** All processing for these features happens within the Microsoft Azure environment under the same compliance standards as the rest of Microsoft Sentinel. The behaviors layer processes data within the SIEM analytics pipeline and doesn't send log data outside the service. For the playbook generator, AI processing occurs within Microsoft's cloud environment, and customer data is handled according to Microsoft's data-handling commitments. Data from user prompts and generated code isn't used to train the base model. Microsoft might collect usage telemetry and anonymized quality signals, depending on the customer's data-sharing settings. - **Testing and iteration support:** Microsoft provides avenues within the tools themselves to help users adopt them safely. For example, the playbook generator interface allows users to run the new playbook on a sample alert (typically a sanitized incident) to see what actions it would take, verifying outcomes before deployment. The behaviors layer outputs can be compared against known sequences of events to confirm they align with expectations. Microsoft's documentation encourages such testing and outlines best practices for validating AI outputs (such as performing dry runs or starting in a lab environment). This approach helps organizations integrate the AI features gradually and with confidence. @@ -184,7 +184,7 @@ End-users should: - **Exercise caution when designing agentic AI in sensitive domains:** Users should exercise caution when designing and/or deploying agentic AI applications in sensitive domains where agent actions are irreversible or highly consequential. Additional precautions should also be taken when creating autonomous agentic AI as described further in either the [Microsoft Enterprise AI Services Code of Conduct](https://www.microsoft.com/licensing/terms/productoffering/MicrosoftAzure) (for organizations) or the [Code of Conduct section in the Microsoft Services Agreement](https://www.microsoft.com/servicesagreement) (for individuals). -- **Ensure relevant data and prerequisites:** For the behaviors layer, connect the supported data sources (such as network logs or cloud audit logs) so you get the most out of the feature. More complete and high-quality data in Sentinel leads to more comprehensive behaviors. For the playbook generator, verify you've met all prerequisites (such as enabling Microsoft Security Copilot in your tenant and having the appropriate user roles) before use.+- **Ensure relevant data and prerequisites:** For the behaviors layer, connect the supported data sources, such as network logs or cloud audit logs, to get the most out of the feature. More complete and high-quality data in Sentinel leads to more comprehensive behaviors. For the playbook generator, onboard your Microsoft Sentinel workspace to the Defender portal and ensure you have the Automation: **Automation Playbooks (Read and Write)** permission in Microsoft Defender unified RBAC. The generator doesn't require a separate Microsoft Security Copilot license or Security Compute Units. For all requirements, see [Generate playbooks using AI in Microsoft Sentinel](automation/generate-playbook.md#prerequisites). - **Start with human oversight and small scope:** Initially, treat AI outputs as suggestions or prototypes. For instance, use the playbook generator to create a new playbook and then walk through the code line by line with your team before trusting it on live incidents. You might deploy it in a monitoring-only mode (for example, logging actions but not taking irreversible steps) at first. Similarly, when you enable the behaviors layer, start by observing how it represents known benign vs. known malicious sequences in your logs to gauge its accuracy, and then gradually incorporate behaviors into detection rules or workflows.