ACAT report creation fails with "Permission check failed" despite the account holding all documented required roles on the target subscription.

Question

ACAT report creation fails with "Permission check failed" despite the account holding all documented required roles on the target subscription.

Marney Edwards 20

Here's the ticket body — paste-ready:

Summary: ACAT report creation fails with "Permission check failed" despite the account holding all documented required roles on the target subscription.

Details:

Creating a compliance report in the App Compliance Automation Tool for Microsoft 365 (Azure portal) fails repeatedly with:

Error: Permission check failed, due to you miss below required permission(s). Missed permission: [{"SubscriptionId":"0fa51402-217b-4a30-8942-752ac7172417","MissedPermissions":["Microsoft.Authorization/policyAssignments/delete", ...]}] (Code: Forbidden)

Failed attempts (correlation IDs):

211f7f77-4471-49c3-9161-57de88c49ffb
78df00e6-0c65-4fd8-boc1-19b3f20a8874
59f48d0a-0f07-4d5a-a248-df2f4005890e

Account: [******@pansophyai.com] (Global Administrator of the tenant)

Role assignments on subscription 0fa51402-217b-4a30-8942-752ac7172417, verified via az role assignment list immediately before the third attempt:

Owner
App Compliance Automation Administrator
Resource Policy Contributor

The latter two were assigned per the remediation in the ACAT troubleshooting documentation (aka.ms/acat-troubleshooting). The third failure occurred more than 10 minutes after assignment, after signing out of the portal and back in, so token/RBAC propagation should not be a factor. Owner already includes all Microsoft.Authorization/policyAssignments/* actions the error lists as missing.

Report being created: offer pansophy-mcp-server (Second Opinion for Sales), publisher pansophyaiinc1775341545935.

Request: Please advise what ACAT's permission check is evaluating that these roles do not satisfy, or whether this is a known issue with the preview evaluator.

Marney Edwards 20 Reputation points

2026-06-12T13:11:16.84+00:00
Thank you, Suchitra. We've completed the verification steps and gone several beyond. The issue persists and the evidence now points away from permissions entirely.

Role verification (per your guidance):

On the target subscription <PII Removed>, IAM confirms Owner, App Compliance Automation Administrator, and Resource Policy Contributor — all at subscription scope (verified via az role assignment list --all; scopes are /subscriptions/-... exactly, not resource-group level).

To eliminate the multi-subscription theory, both ACAT roles were additionally granted on all four enabled subscriptions in the tenant. Error unchanged.

Minimal repro: Report creation with only two resources selected — one API Management instance, one Function App — neither under any deny assignment (deny assignments on the subscription were enumerated; all are platform-managed Container Apps/App Insights denies on unrelated managed resource groups). Failure: Microsoft.Authorization/policyAssignments/delete reported missing on 0fa51402, despite Owner and Resource Policy Contributor at subscription scope. Correlation ID: 74344638-6a8b-4814-8eba-d3e78287ad14.

Beyond the portal: Report creation was also attempted via direct ARM REST (PUT /providers/Microsoft.AppComplianceAutomation/reports/...) and via the official az acat CLI extension. Both fail with invalid_access_token — a different failure mode from the portal, from Microsoft's own tooling, in a session freshly authenticated with az login. Microsoft.AppComplianceAutomation is confirmed Registered on the subscription.

Summary: maximal roles at subscription scope on every subscription in the tenant, a two-resource repro untouched by deny assignments, RP registered, and three independent access paths (portal, ARM REST, official extension) all failing differently. We've exhausted client-side causes and request escalation to the ACAT product team. Prior correlation IDs from earlier attempts: 211f7f77-4471-49c3-9161-57de88c49ffb, 78df00e6-0c65-4fd8-b0c1-19b3f20a8874, 59f48d0a-0f07-4d5a-a248-df2f4005890e.

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello Marney Edwards

Thank you for posting your query on Microsoft Q&A platform.

Based on the ACAT troubleshooting guidance you referenced, ACAT performs permission checks in the subscription scope(s) relevant to the report creation. The documented minimum roles for administrator operations like creating reports are:

App Compliance Automation Administrator
Resource Policy Contributor

And the troubleshooting guide also calls out this general verification approach:

In the target subscription, check Access control (IAM) > View my access and confirm your role assignments include the required ACAT permissions for that subscription.

Why you might still see missing permissions:

From your error, ACAT is specifically complaining about missing Azure Policy assignment delete capability, e.g.:

Microsoft.Authorization/policyAssignments/delete

Even if your role assignments look correct (and Owner normally includes broad permissions), an ACAT-style permission check can still fail if:

the effective permissions at the exact scope/time of the operation don’t include what the ACAT workflow expects (for example due to policy/RBAC evaluation nuances), or
the operation is being evaluated across additional subscription scopes/resources beyond the one you checked (ACAT reports can rely on cloud resources that may span multiple subscriptions).

The ACAT docs explicitly mention that compliance report resources can span multiple subscriptions, and you need the appropriate roles for the corresponding subscriptions.

What to try next (practical checks):

Confirm access at the subscription scope(s) actually involved
- In the Azure portal, open the Subscriptions blade and go to the relevant subscription(s).
- For each subscription that could be involved in report creation, check IAM > View my access.
- Ensure you have App Compliance Automation Administrator and Resource Policy Contributor on every corresponding subscription involved (not just the one where you checked with az role assignment list).
Re-check the operation from the same account context
- Since you already tried waiting for propagation and re-signing, the remaining likely causes are scope coverage (additional subscriptions) or effective RBAC evaluation differences.
If you’re using preview tooling / evaluator
- With the info provided, we can’t confirm a known preview-evaluator issue from the documents you supplied, so it’s safest to treat this as a permissions/scope coverage evaluation until proven otherwise

Thanks,
Suchitra.