Building useful SOC automation has always sounded easier than it is. You start with a great idea — enrich a URL, disable a risky account, open a ticket, notify the right channel — and then the real work begins. Which trigger should you use? Which API permissions are required? Where do credentials live? How do you test the workflow without surprising the production SOC?
Microsoft Sentinel’s AI playbook generator is designed to make that first draft much faster. According to Microsoft Learn’s playbook generator documentation, the feature creates Python-based SOAR playbooks from a natural-language conversation in an embedded Visual Studio Code experience in the Microsoft Defender portal. Microsoft also lists the feature as generally available in the May 2026 Microsoft Sentinel What’s New notes, after introducing the generator in a Microsoft Tech Community post.
In this tutorial, you will walk through how the workflow fits together: prerequisites, Integration Profiles, playbook generation, validation against a real alert, and safe customization for tools such as ServiceNow or Jira.
Prerequisites
This walkthrough focuses on the process, but you will need a few items in place before you can follow it in your own tenant:
-
A Microsoft Sentinel workspace onboarded to the Microsoft Defender portal.
-
A tenant with Security Copilot enabled and SCUs available. Microsoft states that SCU availability is a technical requirement for this experience, even though the playbook generator does not bill those SCUs directly.
-
Microsoft Defender unified RBAC permissions for Detection tuning (manage) and Security Copilot (read) to use the generator.
-
Microsoft Sentinel Contributor permissions on the workspace or resource group where you will create automation rules.
-
Access to create Microsoft Entra app registrations and client secrets for API authentication.
-
A real alert ID you can use for testing.
Microsoft notes that permissions can take up to two hours to take effect after assignment. If the Playbook Generator button is missing, check permissions first before rebuilding the rest of your setup.
Understanding What the Generator Actually Creates
Before clicking Create, it helps to understand what is different about this feature.
Traditional Sentinel playbooks are Azure Logic Apps workflows. Those are still supported, and Microsoft’s playbook creation documentation describes how to create and manage them. The AI playbook generator, however, creates code-based Python playbooks through a conversational authoring flow. You describe the automation logic, review the generated plan, switch to Act mode, and then save a generated playbook with documentation and a visual flow diagram.
The generator is not magic glue for every application on the internet. It works from two major inputs:
-
The alert data passed into the generated playbook.
-
Integration Profiles that define how the playbook can authenticate to external APIs.
That second point is important. If you want to update ServiceNow, Jira, Microsoft Graph, VirusTotal, or another API-driven tool, the generator needs enough connection information to call the API safely.
Step 1: Create an Integration Profile
Integration Profiles are secure configurations used by generated playbooks to interact with external APIs. Microsoft defines each Integration Profile as including a base URL, authentication method, and required credentials.
Start with Microsoft Graph because many SOC workflows eventually need identity or user data.
-
Open the Azure portal and browse to Microsoft Entra ID → App registrations.
-
Select New registration.
-
Give the app a clear name, such as
Sentinel-Playbook-Graph-Automation. -
After registration, open the app’s Overview page.
-
Copy the Application (client) ID and Directory (tenant) ID.
-
Go to Certificates & secrets → Client secrets.
-
Select New client secret, set an expiration date that matches your credential rotation policy, and copy the secret value immediately.
Treat the client secret like a password. You cannot retrieve it again later, and you should not paste it into tickets, chat, or source control.
Next, create the profile in Defender:
-
Open the Microsoft Defender portal.
-
Browse to Microsoft Sentinel → Configuration → Automation.
-
Select the Integration Profiles tab.
-
Select Create.
-
Enter a descriptive integration name, such as
Microsoft Graph. -
Set the base API URL to
https://graph.microsoft.com. -
Choose OAuth2 as the authentication method.
-
Paste the application client ID and client secret.
-
Set the token endpoint to
https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token. -
Set the scope to
https://graph.microsoft.com/.default.
Microsoft’s documentation specifically calls out verifying that SecurityAlert.Read.All is granted under Microsoft Graph application permissions. Add any additional Graph permissions required by your workflow, grant admin consent, and keep the app registration as narrowly scoped as possible.
For a third-party platform, create a separate Integration Profile. For ServiceNow, that might point to your instance URL and use an authentication method your organization approves. For Jira, the same pattern applies: define the Jira base URL and the approved authentication method. Microsoft documents the supported authentication types as OAuth2 client credentials, API key, AWS Auth, username and password, bearer/JWT authentication, and Hawk.
Step 2: Start the Playbook Generator
With at least one Integration Profile ready, create the generated playbook.
-
In the Microsoft Defender portal, go to Microsoft Sentinel → Configuration → Automation.
-
Open the Playbooks tab.
-
Select Create → Playbook Generator.
-
Enter a playbook name.
-
Select Continue.
The portal opens an embedded Visual Studio Code environment with a conversational coding agent. Microsoft Learn identifies the agent as Cline. The generator begins in Plan mode, which is where you describe what you want the automation to do.
A weak prompt looks like this:
“`plain text
Handle phishing alerts.
A stronger prompt is much more specific: ```plain text When a high-severity phishing alert includes a sender address and a URL entity, extract the sender address and URL. Check Microsoft Graph to confirm whether the sender exists in our tenant. Add a comment to the related incident with the URL, sender, and Graph lookup result. If the sender exists, create a ServiceNow ticket assigned to the SOC queue and include the alert title, severity, incident link, and recommended next steps. Do not disable the account automatically.
Notice the difference. The second prompt defines the alert scope, the data to extract, the API lookup, the third-party action, and an explicit safety boundary.
Step 3: Review the Plan Before Generating Code
The generator should not be treated like a command prompt where you type once and trust the output. In Plan mode, expect it to ask clarifying questions, request permission to fetch API documentation, identify missing Integration Profiles, and propose a workflow plan.
Review the plan like you would review a pull request:
-
Does the plan use the correct alert fields?
-
Does it call the expected Integration Profiles?
-
Does it branch correctly for missing entities?
-
Does it avoid destructive actions unless you explicitly requested them?
-
Does it log enough information for an analyst to understand the action later?
-
Does it avoid exposing secrets in comments, incident notes, or generated documentation?
If the generator reports that an Integration Profile is missing, save your progress, exit the editor, create the missing profile from the Integration Profiles tab, and then return to the playbook.
When the plan is correct, follow the generator’s instructions to switch to Act mode. In Act mode, the generator creates the Python playbook, documentation, and a visual flow diagram. Microsoft says the generator can also ask for an Alert ID to test the playbook and will request approval before applying changes to the environment.
Step 4: Validate with a Real Alert
Testing against a real alert is one of the most useful parts of the experience. It forces the generated playbook to work with the payload shape your SOC actually receives instead of a perfect sample object.
Before you run the test, choose an alert that is safe for automation testing. For example, use a low-severity test alert or a lab workspace alert when possible. If the workflow creates tickets or posts messages, point it to a test queue or a clearly labeled test channel first.
When the generator requests an Alert ID:
-
Paste the test alert ID.
-
Read the summary of changes the playbook intends to apply.
-
Approve only if the changes match your expected test behavior.
-
Review the output and generated documentation.
-
Manually inspect the Python code before saving.
This manual review matters. Microsoft lists an important limitation: automatic code validation is not provided, and users must manually verify correctness. Treat the generated code as a strong first draft, not as production-approved automation.
Step 5: Save, Enable, and Trigger the Playbook
After you review the generated code and documentation, select Save in the editor. Microsoft states that the playbook is created in a disabled state.
To enable it:
-
Return to Automation.
-
Open the Active Playbooks tab.
-
Locate the newly created playbook.
-
Switch the status to Activate.
Next, create an enhanced alert trigger:
-
Open the Automation Rules tab.
-
Select Create.
-
Define conditions such as alert title, severity, provider, or other alert attributes.
-
Select the workspaces where the rule should apply.
-
Add an action to Run Playbook and choose your generated playbook.
-
Save the rule.
Enhanced alert triggers are tenant-level and can target alerts across Microsoft Sentinel, Microsoft Defender, and XDR platforms. That wider scope is powerful, but it also means you should start narrow. Begin with one provider, one severity, or one test workspace, then expand after the SOC has reviewed the results.
Step 6: Customize for ServiceNow, Jira, and Other Tools
The generator can help with third-party automation, but you should still own the API contract.
For ServiceNow, your prompt might request a ticket with fields such as short description, assignment group, severity, incident URL, alert provider, and recommended remediation. Microsoft’s Tech Community post includes a ServiceNow example in which the playbook extracts a user principal name, checks Entra ID, disables the account if present, creates a ServiceNow ticket, and posts to a security team channel.
For Jira, use the same structure, but be explicit about the project key, issue type, labels, summary format, and description body. Microsoft does not publish a Jira-specific example in the docs I reviewed, so validate Jira field names and authentication against your own Jira API documentation before approving generated code.
A good third-party prompt includes:
plain text
Use the Jira Integration Profile named Jira-SOC. Create an issue in project SEC
with issue type Task. Set the summary to "Sentinel alert: <alert title>". In the
description, include the alert severity, provider, incident URL, affected account,
entities, and remediation notes. If the Jira API returns an error, add a comment
to the Sentinel incident with the error status and do not retry more than once.
That prompt tells the generator what system to use, which profile to call, how to map fields, and what to do when the API fails.
Know the Current Limits
Microsoft documents several limits that should shape your rollout:
-
Generated playbooks support Python only.
-
Alerts are currently the only input type.
-
External libraries are not currently supported.
-
A tenant can have up to 100 generated playbooks.
-
Each playbook can contain up to 5,000 lines.
-
Each execution can run for up to 10 minutes.
-
A tenant can have up to 500 integrations.
-
Integration API URLs and authentication methods cannot be changed after creation.
-
Enhanced alert trigger run results are visible in the incident Activity tab, not in the Sentinel Health table.
-
Enhanced alert trigger rules do not support priority ordering or expiration dates.
These limits do not make the generator less useful. They define where it belongs: repeatable alert-driven automations with clear API calls and well-understood response logic.
Practical Rollout Tips
Start with enrichment and notification workflows before allowing remediation. Enriching an alert with VirusTotal results, adding Graph context, or opening a ticket is easier to review than disabling accounts or blocking users.
Use separate Integration Profiles for separate systems and environments. A test ServiceNow profile and a production ServiceNow profile are easier to reason about than one shared integration that everyone touches.
Keep generated playbooks under source review even if the first draft is created in the portal. Save the generated Python and documentation into your internal repository if your change-management process requires it.
Finally, teach analysts how to write prompts. The best prompts read like miniature runbooks: trigger, inputs, conditions, actions, failure handling, and safety boundaries.
Conclusion
Sentinel playbook generation is not a replacement for SOC engineering judgment. It is a faster way to get from an analyst’s runbook idea to a working Python automation draft inside the Defender portal.
The key is to treat the generator as a co-author. Give it clear requirements, configure Integration Profiles carefully, review the plan, inspect the code, test with a real alert, and enable automation gradually. Done that way, the feature can shorten the path from “we should automate this” to a repeatable workflow your SOC can trust.
