Separate analyst permissions from Sentinel's incident-playbook authority

Source facts

Sentinel’s incident-playbook execution uses a service account as well as the analyst’s own permissions. That service account needs Microsoft Sentinel Automation Contributor on the playbook’s resource group; the grant permits execution of any playbook in that group. The Defender portal distinguishes Missing permissions for the operator’s Playbook Operator role from Grant permission for Sentinel’s missing service role. Microsoft Learn.

Granting Sentinel that access requires Owner or User Access Administrator authority on the resource group. The source also lists incident access and Logic App Contributor prerequisites; the visible status is not a complete role inventory. Microsoft Learn.

Applicability

Review Microsoft Sentinel incident playbooks run from the Microsoft Defender portal. Check the complete current prerequisites for the intended execution path; do not treat permissions for an alert or an entity as interchangeable with incident execution.

DSE recommendation

DSE recommends identifying the principal named by the failure before requesting a role change. Record the operator, Sentinel service account, playbook and containing resource group separately. Review the other playbooks in that group before approving service execution authority. Route permission changes to the authorized owner rather than granting the analyst broad administration simply to remove a disabled button.

Verification

Use an approved low-impact playbook against a test incident. Confirm the intended identities have their required scoped permissions, then inspect the resulting run in Logic Apps. Retain the role decision and run outcome without invoking unrelated response actions. A successful manual test should not be reported as verification of every automation rule or playbook in the group.

Official references

Microsoft Learn: Run Sentinel playbooks.