0.7 Sentinel Automation Architecture

The two-layer model

Sentinel's automation architecture separates orchestration from execution. Automation rules are the orchestration layer. They evaluate conditions and decide what happens: change a property, trigger a playbook, close an incident. Playbooks are the execution layer. They perform the work: call APIs, run conditional logic, query external services, wait for human approval.

This separation exists because most automation decisions are simple. Changing an incident's severity from Medium to High requires no code, no API call, and no Logic App. An automation rule handles it in a single action. Enriching an incident with IP reputation data from three threat intelligence feeds requires conditional logic, parallel API calls, error handling, and data transformation. A playbook handles that.

The separation also means that a playbook does nothing on its own. A Logic App with a Sentinel incident trigger sits idle until an automation rule invokes it. This is the mistake Tom made. The playbook is the capability. The automation rule is the trigger. You need both.

Automation rules: what they can and cannot do

An automation rule triggers on one of three events: incident created, incident updated, or alert created (the Enhanced Alert Trigger, which extends coverage to alerts from Defender XDR and other Microsoft security products). Each rule evaluates conditions against the incident or alert properties and executes one or more actions.

The condition engine evaluates incident properties (severity, status, title, analytics rule name, incident provider) and entity properties (account UPN, IP address, host name). You can combine conditions with AND/OR operators and use Contains, Equals, and other string operators. For NE's AiTM severity override, the condition is straightforward: analytics rule name contains "AiTM" and severity equals Medium. The action changes severity to High.

Automation rules support these actions: change severity, change status (New, Active, Closed), assign an owner, add tags, run a playbook, and add an incident task. You can stack multiple actions in a single rule. NE's AiTM handling uses one rule with two actions: change severity to High, then run the enrichment playbook. One rule, two actions, one trigger. This is cleaner than splitting them into separate rules because the actions share the same trigger condition.

Rules execute in order number sequence. If Rule 1 (order 1) changes severity to High and Rule 2 (order 11) triggers a playbook only when severity equals High, Rule 2 sees the updated severity because Rule 1 already executed. This ordering lets you structure automation in layers: triage rules first, enrichment triggers second, response triggers third.

Automation rules can also be exported as ARM template JSON files. This export is workspace-independent, meaning you can import the same rule into a different workspace or tenant. For organizations managing multiple Sentinel workspaces, this is how you standardize automation across environments without rebuilding each rule manually.

{
  "type": "Microsoft.SecurityInsights/automationRules",
  "properties": {
    "displayName": "AiTM: Severity Override + Enrichment",
    "order": 1,
    "triggeringLogic": {
      "isEnabled": true,
      "triggersOn": "Incidents",
      "triggersWhen": "Created",
      "conditions": [
        {
          "conditionType": "Property",
          "conditionProperties": {
            "propertyName": "IncidentSeverity",
            "operator": "Equals",
            "propertyValues": ["Medium"]
          }
        },
        {
          "conditionType": "Property",
          "conditionProperties": {
            "propertyName": "IncidentTitle",
            "operator": "Contains",
            "propertyValues": ["AiTM"]
          }
        }
      ]
    },
    "actions": [
      {
        "order": 1,
        "actionType": "ModifyProperties",
        "actionConfiguration": {
          "severity": "High"
        }
      },
      {
        "order": 2,
        "actionType": "RunPlaybook",
        "actionConfiguration": {
          "logicAppResourceId": "/subscriptions/.../playbook-enrich-aitm",
          "tenantId": "..."
        }
      }
    ]
  }
}

This is the exported ARM template for NE's AiTM automation rule. Two conditions (severity equals Medium AND title contains "AiTM") and two actions (change severity to High, then run the enrichment playbook). The order field at the rule level (1) determines when this rule fires relative to other rules. The order fields inside actions determine the action execution sequence within this rule.

Playbooks: Logic Apps as the execution engine

Playbooks are Azure Logic Apps with a Sentinel connector trigger. The Sentinel connector provides three trigger types. The incident trigger fires when an automation rule invokes the playbook on an incident. The alert trigger fires on individual alerts. The entity trigger fires on specific entities from an investigation context, used for manual on-demand execution during threat hunting.

The incident trigger is what you use for almost everything. It receives the full incident object: severity, title, description, the list of correlated alerts, and the entity array containing all mapped entities (accounts, IPs, hosts, URLs, files, mailboxes). Your playbook logic operates on this object. An enrichment playbook iterates over the IP entities and queries each one against threat intelligence feeds. A containment playbook extracts the account entity and calls the Graph API to revoke sessions.

The alert trigger has a narrower use case. It fires on individual alerts before incident grouping occurs, so it doesn't have access to the incident's correlated alerts or the entity mapping that grouping provides. Alert-triggered playbooks that were attached directly to analytics rules were deprecated in March 2026. You can no longer add playbooks to analytics rules this way. Existing alert-trigger playbooks continue to run, but Microsoft recommends migrating them to automation rules with the Enhanced Alert Trigger, which provides broader coverage across Sentinel, Defender, and XDR alerts at the tenant level.

Logic Apps come in two hosting models. Consumption (multi-tenant, pay-per-execution) is what most Sentinel playbooks use. Standard (single-tenant, fixed monthly pricing) provides network isolation, CI/CD pipeline support, and predictable costs for high-volume workloads. For NE's automation program, Consumption is the right starting point. Enrichment playbooks will execute roughly 500 times per day (once per incident). At Consumption pricing, that is a few dollars per month. Standard becomes relevant when playbook volume exceeds thousands of executions per day or when network isolation requirements demand single-tenant deployment.

Entity extraction is the first challenge every playbook builder encounters. An incident trigger provides entities as a JSON array, but that array structure varies by alert type. Some alerts map a single Account entity. Some map an Account and an IP. Some map nothing, because the analytics rule's entity mapping was never configured. Your playbook must handle all cases: extract the entity if it exists, skip gracefully if it does not. A playbook that assumes every incident contains an IP entity will fail on identity-only alerts. A playbook that assumes every incident contains exactly one Account entity will miss multi-user incidents. SA1 covers entity extraction patterns in detail, including the Parse JSON action pattern that handles variable entity arrays reliably.

The service account and permissions model

Sentinel uses a dedicated service account to execute playbooks on incidents. When an automation rule triggers a playbook, the Sentinel service account invokes the Logic App. This service account requires the Microsoft Sentinel Automation Contributor role on the resource group containing the playbook. Without this role, the automation rule appears to work (it evaluates conditions and selects actions correctly) but the playbook never fires.

This is a common deployment failure. The automation rule is configured, the playbook is built, the Logic App has a managed identity with the correct Graph API permissions, but the Sentinel service account doesn't have Automation Contributor on the playbook's resource group. The automation rule logs show "playbook triggered" but the Logic App run history shows no executions. The fix is a single role assignment, but diagnosing it requires understanding that Sentinel uses its own identity to invoke playbooks, separate from the playbook's managed identity.

The playbook's managed identity is the second permission layer. This identity is what the playbook uses to call external APIs. For enrichment playbooks, it needs read permissions: User.Read.All and AuditLog.Read.All for identity data, SecurityEvents.Read.All for alert data, and the Sentinel Reader role for workspace access. For containment playbooks, it needs write permissions: User.RevokeSessions for session revocation, Policy.ReadWrite.ConditionalAccess for CA policy changes, and the Sentinel Responder role for incident updates.

The permission model is two-layered by design. Sentinel Automation Contributor lets Sentinel invoke the playbook. The managed identity permissions let the playbook invoke APIs. Separating the two means you can grant Sentinel the ability to run a playbook without granting that playbook broad permissions. Each playbook's managed identity carries only the permissions its specific workflow requires.

Monitoring automation health

Building automation without monitoring it recreates the dead playbook problem from Section 0.6. Sentinel provides two tables for automation observability. SentinelHealth captures whether each automation rule evaluated successfully and whether each playbook was launched. AzureDiagnostics captures the internal execution of each Logic App workflow, including individual action success/failure, execution duration, and error messages.

Enabling health monitoring requires two steps. First, enable SentinelHealth data collection in the Sentinel workspace settings under Auditing and health monitoring. Second, configure diagnostic settings on each Logic App to send AzureDiagnostics data to the same workspace. Without both, you see only half the picture: SentinelHealth tells you the playbook launched, but AzureDiagnostics tells you whether the API call inside it succeeded.

NE's dead VirusTotal playbook would have been caught within hours if both tables were active. SentinelHealth would show the playbook launching successfully on every incident. AzureDiagnostics would show the HTTP action returning 429 (Too Many Requests) on every execution. A simple KQL alert on AzureDiagnostics filtering for status codes above 399 would have notified the team the same day the rate limit changed.

The decision framework

Every automation requirement maps to one of three patterns. The choice depends on two questions: does the automation need multi-step logic, and does it need incident-level context?

Simple triage actions that modify incident properties (change severity, assign owner, add tag, close incident) use automation rules alone. No playbook required. These deploy in minutes, require no code, and handle the highest-volume automation scenarios. NE's severity override, assignment routing, and false positive suppression are all automation rules.

Complex workflows that call APIs, evaluate conditional logic, or integrate with external systems use playbooks triggered by automation rules. The automation rule fires on incident creation with the appropriate conditions. The playbook receives the full incident object and executes the workflow. This is the pattern for enrichment, evidence collection, notification, and containment.

Time-critical alert-level actions that need to execute before incident grouping use the Enhanced Alert Trigger on an automation rule. The rule fires on alert creation and triggers a lightweight playbook that captures volatile data. The incident trigger handles everything else. In practice, fewer than five percent of automation requirements need the alert trigger. Session status capture for AiTM alerts is one of the few legitimate use cases.