What happens when Power Platform DLP policies cannot block run a child flow actions?

When the platform cannot block a child flow action, administrators lose a key enforcement point. Users may still move data from business sources into non-business channels through indirect execution, even when connector groupings look compliant on paper. The practical result is reduced trust in DLP as a standalone control and increased exposure to leakage.

Why the policy gap matters operationally

When a power platform dlp policy cannot stop a child flow action, the control boundary is weaker than the policy language suggests. The key issue is not connector labelling, but execution path: an apparently compliant flow can still hand data off indirectly and bypass the intended business to non-business restriction.

That changes how administrators should read DLP outcomes. Policy coverage becomes a statement about what the platform can natively inspect and block, not a guarantee that every data movement path is prevented. In practice, this can create a false sense of containment if teams assume that a blocked connector group means the whole workflow is safe.

Where the leakage path comes from

Child flows create an indirection layer. A parent flow may pass validation, then invoke another flow that performs the sensitive transfer or transformation, so the policy decision no longer lines up neatly with the actual data movement. The result is a control gap between what is configured and what is operationally reachable.

This is why indirect execution matters more than the connector catalog alone. In a low-friction automation platform, users often optimise for reuse and speed, which makes shared child flows attractive. That same reuse can also concentrate risky logic in one place, so a single weak control point can affect many business processes at once.

Review whether the sensitive step is executed directly or delegated through another flow.
Check whether the business and non-business separation still holds after the child flow is invoked.
Validate the actual execution chain, not only the visible connector grouping in the parent flow.

What practitioners should do next

Use DLP as one layer, not the whole containment strategy. If child flows can evade a policy boundary, then design review, environment separation, and maker governance become part of the control set. That is especially important where automation handles data that would be unacceptable to expose through a non-business connector path.

If you need a broader identity and access lens for this problem, NHIMG’s Ultimate Guide to Non-Human Identities is useful for thinking about lifecycle, visibility, and privilege around the automation that executes these paths. For attack-path context, GitHub Action tj-actions Supply Chain Attack illustrates how indirect execution can expose sensitive material at scale.

Practitioner takeaway: If the platform cannot block the child flow, treat the policy as advisory for that path and compensate with architectural segregation and explicit review of the delegated execution chain.

Risk and Threat Considerations

The main risk is silent data movement through a permitted-looking parent flow. That can weaken governance, expose regulated or business-sensitive data, and make policy attestation unreliable because the control no longer fully represents real runtime behaviour.

Failure mechanism: A parent flow passes DLP checks, then calls a child flow that performs the restricted action, so the enforcement point is bypassed without breaking the visible policy posture.

Impact: Sensitive data can traverse into non-business channels, and security teams may only discover the gap after reviewing logs, incidents, or downstream leakage evidence.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	DLP gaps here stem from misapplied platform configuration and enforcement boundaries.
Recommendation — Harden flow and environment settings so delegated actions cannot bypass approved data paths.
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations	The issue is an authorization boundary failure where delegated execution exceeds intended data access.
	GV.PO-1 — Cybersecurity Policy	DLP policy expectations must reflect what the platform can actually enforce at runtime.
Recommendation — Enforce least-privilege permissions across parent and child flow execution paths. Align policy language with the platform’s real enforcement capabilities and exceptions.
OWASP Non-Human Identity Top 10	NHI-01 — Secret Exposure	Indirect automation paths can move sensitive material into channels that should not receive it.
	NHI-04 — Overprivileged Non-Human Identities	Child flows often concentrate delegated authority, increasing blast radius if permissions are too broad.
Recommendation — Track and restrict any automation path that can expose sensitive data outside approved business flows. Reduce delegated permissions so child flows cannot perform broader actions than necessary.

Practitioner Guidance

What to verify: Confirm whether the child flow inherits the same enforcement expectations as the parent, and test an end-to-end path with representative business data before trusting the DLP result.

Decision rule: If a restricted transfer depends on delegation, treat the delegated step as the control boundary and assess whether the platform can actually enforce the intended separation there.

Practitioner takeaway: The control failure is architectural, not cosmetic, so the most useful response is to test runtime paths and adjust governance around the delegation model rather than relying on policy labels alone.