Power Platform security group bypass exposes Dataverse access gaps

At a glance

What this is: Zenity shows that Power Platform Security Groups do not govern Application Users consistently, creating a Dataverse access control gap for Entra service principals.

Why it matters: This matters because IAM teams can misread group-based tenant governance as covering non-human identities, leaving sensitive data paths open through API access.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read Zenity's analysis of the Power Platform Security Group bypass and Dataverse exposure

Context

Power Platform security groups are meant to reduce exposure by controlling which identities can reach environments and data. The problem is that this control can be interpreted too broadly, especially when administrators assume a service principal behaves like a governed user account. In practice, that assumption breaks once an Application User can still call Dataverse APIs outside the expected group boundary.

This is an identity governance problem, not just a platform configuration issue. When Entra service principals are treated as if they inherit the same access model as human users, tenants can end up with a split between policy intent and enforcement. That gap is familiar in NHI governance: the identity exists, but the control plane does not always constrain it the way teams expect.

Zenity’s simulation shows why group membership alone is not enough to validate access boundaries for non-human identities in low-code and SaaS environments. The starting position is typical, not exceptional: many organisations rely on centralized identity structures that were designed for people first, then extended unevenly to service principals and application users.

Key questions

Q: What breaks when Security Groups do not govern Application Users in Power Platform?

A: The main failure is that administrators think a group boundary blocks access, while a service principal can still authenticate and query Dataverse through APIs. That creates a false sense of containment. The control appears to exist at the tenant layer, but the actual data path remains open, so governance evidence and runtime enforcement no longer match.

Q: Why do service principals create governance risk in low-code platforms?

A: Service principals are non-human identities, so they do not always follow the same policy inheritance that human accounts do. In low-code platforms, that can let API access bypass the restrictions teams assume are enforced by directory groups. The risk is not simply exposure, but misclassification of the actor type that is actually making the request.

Q: How can security teams verify that Dataverse access is really constrained?

A: They should test the API and data layers directly, not rely only on environment membership or UI restrictions. Validation should include excluded identities, row-level behaviour, and field-level exposure. If a blocked identity can still reach records through backend calls, the governance model is incomplete and the control boundary is not real.

Q: Who is accountable when a service principal bypasses a platform access policy?

A: Accountability usually sits with the team that defined the control boundary and assumed it applied to all identity types. Platform owners, IAM teams, and application administrators all need to verify whether the policy engine enforces the same rule for users and Application Users. If it does not, ownership of the gap must be explicit.

Technical breakdown

Why Security Groups fail to constrain App Users in Dataverse

Security Groups in Power Platform are designed to gate tenant and environment access, but they do not always apply uniformly to Application Users backed by Entra service principals. That creates a control mismatch between identity registration and runtime authorization. The service principal can authenticate with valid client credentials, then interact with Dataverse through REST APIs even when the identity is excluded from the intended group. The result is not a broken login flow, but a broken enforcement boundary.

Practical implication: validate whether your group-based governance actually applies to service principals before treating it as an access control boundary.

Dataverse row and field controls do not replace identity governance

Dataverse can still expose sensitive records when the platform’s identity and data layers are not aligned. RBAC alone does not guarantee that row-level or field-level exposure is blocked if backend enforcement is incomplete or misconfigured. In this case, the issue is not broad platform failure. It is the gap between who is supposed to be allowed in and what the API layer actually permits once an authenticated non-human identity is present.

Practical implication: test API-level access separately from UI permissions and review row and field exposure independently.

Why misaligned identity assumptions create zero-trust blind spots

Zero trust depends on continuous verification of identity, context, and authorization scope. When administrators assume a service principal is governed the same way as a user account, the model fails silently because the actor type is different. The identity may be authentic, but it is not subject to the same governance path. That makes this a classic assumption mismatch: the control exists, but it was built around the wrong subject model.

Practical implication: classify each identity type explicitly and verify that your control design reflects the actor actually making the request.

Threat narrative

Attacker objective: The objective is to reach Dataverse data through an identity path that governance teams believe is restricted.

1. entry via a valid Entra service principal with client credentials that could authenticate to the environment.
2. credentialed access was used to query Dataverse APIs even though the Application User was excluded from the Security Group.
3. impact was unauthorized data access through a control boundary that administrators expected to block the identity.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Security Group governance is not the same as non-human identity governance. This article shows a familiar control failure: tenant administrators assumed a platform group policy would govern every identity class equally. It did not. Service principals are not human users, and once that distinction matters at runtime, the governance model has to be explicit about which actor type a control actually constrains. The implication is that access policy cannot be validated by label alone.

App User bypass is a policy inheritance failure, not just a configuration miss. The deeper issue is that people often assume identity registration inside Entra means the downstream platform will inherit the same restrictions. That assumption fails when an Application User can authenticate successfully and still query Dataverse outside the intended group boundary. This is the kind of split enforcement that OWASP-NHI and NIST-CSF both warn about: authorization needs to be verified where the data is actually exposed.

Identity-aware access controls must be tested at the API layer, not only the admin layer. The article demonstrates that UI restrictions and environment scoping can give false confidence if Dataverse APIs remain reachable. That matters because NHI failures often happen at the boundary between central governance and application-specific enforcement. Practitioners should treat this as a control-plane mismatch, not a one-off exception.

Misaligned identity assumptions: this is the named failure mode the article exposes. The assumption that Security Groups govern all identities was designed for environments where the actor model is simpler and more uniform. That assumption fails when the actor is an Application User because the platform allows authenticated access paths that do not follow the expected human-style governance chain. The implication is that teams must rethink how they define authorization scope for non-human identities, not just add another rule.

Zero-trust only holds when identity type and enforcement path match. The article makes clear that a valid identity claim is not enough if the platform’s authorization layer treats actor classes differently. That is why NHI governance, IAM, and data security cannot be separated in low-code environments. Practitioners need to verify not only who can sign in, but also which identity type the policy engine truly governs.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• For a broader control baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how identity lifecycle and access governance should be aligned.

What this signals

Identity governance teams should expect more control gaps where SaaS platforms distinguish between users and application users. The lesson is not that Power Platform is unusual. It is that directory-level governance can overstate its reach once a platform applies different rules to non-human identities. Teams should validate the real enforcement boundary in each service rather than assuming directory membership is sufficient.

Misaligned identity assumptions are now a recurring NHI risk pattern. When a platform treats service principals differently from human users, the control plane must be evaluated as an actor-type problem, not just an access-control problem. That is why lifecycle review, access certification, and data-path testing belong together in the same programme.

The governance priority is moving from policy intent to runtime proof. If your team cannot demonstrate that an excluded non-human identity is blocked at the API layer, then the control boundary is descriptive rather than preventive. That is a programme design issue, not a documentation issue.

For practitioners

• Map every Application User to its actual enforcement path Document which Dataverse environments, APIs, and data surfaces are reachable by each service principal, then compare that mapping with the Security Group design you think is in force.
• Test API access independently of UI restrictions Run access checks against REST and backend interfaces for excluded identities, because a blocked console path does not prove the data plane is blocked.
• Separate human user governance from service principal governance Treat Entra users, Application Users, and other non-human identities as different actor types in policy design, review, and audit evidence.
• Add Dataverse-specific control validation to identity reviews Include row-level and field-level checks in recertification and privileged access reviews so governance teams can see whether the platform is enforcing what the directory intends.

Key takeaways

• The article exposes a control mismatch: Security Groups can fail to constrain Application Users even when administrators assume they do.
• The evidence is a runtime API access path through Dataverse, which means the gap sits in enforcement, not in identity creation.
• Teams need explicit validation for non-human identities at the data and API layers, or tenant governance will continue to overstate real access control.

Key terms

• Application User: A non-human identity used by an application or service to access platform resources. In Power Platform, the key issue is not whether the identity can authenticate, but whether platform governance controls constrain it the same way they constrain human users. Actor type determines enforcement.
• Service Principal: An Entra identity representing an application or workload rather than a person. It can hold credentials and obtain tokens for API access, which means it behaves like a machine identity with its own lifecycle, access scope, and audit requirements.
• Dataverse: Microsoft's data platform within Power Platform that stores and exposes application data through APIs and security controls. Its risk profile depends on how identity rules, row permissions, and backend authorization are enforced together, not just on the directory policy visible to administrators.
• Security Group: A directory-based control used to limit which identities can access a tenant, environment, or resource set. It only provides real security value when the downstream application actually enforces the restriction for the relevant actor type, including non-human identities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: When “Secure by Design” Isn’t Enough: A Blind Spot in Power Platform Security Access Controls. Read the original.