The Microsoft Sentinel SOAR playbook generator has mostly flown under the radar since it entered public preview, so let’s look at what it can do and whether it can replace Logic Apps with something more native. In SecOps conversations, I often hear the same view: Logic Apps are fine, but if you already script or code, they can feel like overhead rather than a productivity boost. Many MSSPs also rely on more flexible tooling such as Azure Functions or compiled code for incident automation.
The new Sentinel playbook generator feels more native for Defender XDR and Sentinel integration, and it adds AI on top. Let’s see whether that actually helps.
Playbook Generator in Action
You can find the playbook generator in the Unified Security Operations Platform (USOP) under the Sentinel automation blade, via the ‘Playbook Generator ✨’ option.
It opens a Visual Studio Code or GitHub Codespaces-style editor with Cline preinstalled for building Python playbooks.
Creating a playbook with natural language is straightforward. Cline uses a plan-and-act flow: you describe what you want, then it tests and builds the playbook.
For my initial tests, I used the following prompt: Create a playbook that triggers on all alerts and performs entity enrichment. Extract the entities and perform lookups based on the entity type in Entra ID, Microsoft Azure or the Virustotal API if it's a public IP address. Attach the entity information as comment.
You might wonder how it accesses APIs. The playbook generator uses integration profiles, and I added these three before creating the playbook:
These integrations are still immature: there is no managed identity support, and you have to use app registrations with client secrets.
Ignoring that for a moment, this is how Cline started working on the architecture:
It also generated a Mermaid diagram.
After a few iterations, Cline switched to act mode and tested the playbook with an alert ID from my Defender XDR environment. The generated playbook.py drove the whole flow, and the playbook worked:
It’s a neat way to build SOAR playbooks for Microsoft Sentinel. But the internals deserve a closer, more critical look.
Decoding the Sandbox
The VS Code environment is based on a Microsoft-built kernel from the Linux stable branch, which is also used for WSL:
Running whoami shows that we’re coder, and sudo whoami gets us to root. Network access is limited to sandbox-reachable URLs, and the command line has no direct internet access.
Boilerplate
The PlaybookInfrastructure class contains most of the wrappers, and main.py is pre-staged as soon as you create a new playbook.
Integrations
Within the playbook, the custom_api method handles integration access, and its signature only allows the HTTP verb, URI, and optional body:
def custom_api(method, url, body=None, timeout=120) -> Dict[str, Any]
Authentication happens in the backend through the unifiedActions/triggerAction API endpoint. That endpoint sits behind a proxy exposed through an environment variable and commsConfig.json, and the proxy is only reachable from inside the sandbox.
A closer look at the file system shows that the customerData folder contains:
the tenant configuration:
and the integrations, listed by API URL and authentication type:
Security Copilot Quota
While the preview does not bill SCUs, there is still a hidden capacity limit. I hit the following message while iterating through my playbook: 
If you do not have a dedicated Security Copilot workspace for AI-generated playbooks in the US or Europe, expect regional and quota-related limits during the preview.
Guardrails
Microsoft ships the playbook generator with fixed rules and guardrails:
LLM
Cline is configured to use GPT-5 through the Microsoft Security Copilot API: https://api.securitycopilot.microsoft.com:443/workspaces/SecurityCopilot_Workspace/openai/deployments/gpt5.
Stacktrace
On incidents and alerts, playbook interactions are visible through the SoarNL “Sentinel Playbook Generator” entity, which changed during the preview. The execution model still feels opaque. There are no run histories in the Defender XDR portal, aside from the API calls shown in incident Activities as RunPlaybook.
Triggers
Currently, you cannot trigger a playbook manually, and recurrence-based triggers are not available. A native SOAR playbook requires an “Enhanced” automation rule:
Human in the loop
You can edit the generated Python files, but Cline may overwrite your changes in the next act-mode iteration. Building the same playbook entirely on your own, for example in local Visual Studio Code with an SDK like Azure Functions, is also difficult because of the API proxying model.
Conclusion
I enjoyed the vibe-coding experience, but in my opinion, these capabilities are still missing:
- Modern secrets management through federated credentials or managed identity
- Clear run history, for example in the action center
- The ability to run a playbook on demand
- The option to manually develop and maintain a playbook in Python or another scripting language
- Content distribution support, especially if MSSPs are expected to adopt this model
- Local development and testing support, or an SDK similar to the Azure Functions SDK
Because you are rarely involved in the actual build process, troubleshooting could become difficult if the AI gets stuck in a loop. And for seasones SOC automation engineers, Python is there, but there is still no proper workflow for building and maintaining automations.