The risk comes from policy expectations not matching execution behavior. A parent flow can invoke a child flow that uses a blocked non-business connector, while still starting from an allowed business context. That breaks the intended separation between trusted and untrusted data paths and can expose sensitive information to unauthorized recipients or external systems.
Why the Separation Breaks Down in Child Flow Execution
A child flow does not inherit the business or non-business intent of the parent in a way that preserves policy boundaries automatically. The parent can start from an approved business process, then pass data into a child flow that executes a connector with broader reach. Once that handoff happens, the original trust boundary is no longer the only one that matters.
The key issue is that data protection rules are often written for the visible flow, not for the full execution path. If the parent is allowed but the child can invoke a connector that the organisation would normally restrict, the effective control is weakened by composition. That is why mixed connector use can turn an ordinary automation pattern into a leakage path.
When that happens, the practical question is not whether the parent looked compliant at design time, but whether the combined execution path still respects data minimisation, approved destinations, and connector scope. In mixed environments, the child flow becomes the point where governance assumptions fail.
Where Leakage Usually Appears
Leakage risk is most often created when sensitive data is handed from a controlled business process into a less controlled connector path, then transformed, copied, or forwarded again. The risk is not limited to deliberate exfiltration. It also includes accidental exposure through logs, external API calls, message payloads, file writes, notifications, or downstream systems that were never meant to receive the original data.
This is especially problematic when the business connector and non-business connector combination encourages reuse. A team may build a legitimate approval or case-management flow, then reuse the same child flow for enrichment, storage, or delivery. That reuse can bypass the original review assumptions and create a hidden data-sharing channel.
- Data leaves the approved business context before the recipient has been revalidated.
- The child flow expands the number of systems that can observe the payload.
- Connector policy may permit execution, but not the specific data path the flow now creates.
For a deeper breach-oriented perspective on how credentialed automation and connected services can widen exposure, see The 52 NHI breaches Report and 52 NHI Breaches Analysis. For broader operational context, NHI Mgmt Group’s Ultimate Guide to Non-Human Identities notes that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage.
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 6 — Access Control Management | Mixed connectors need controlled access paths and approved data destinations. |
| Recommendation — Restrict connector access paths and revoke unapproved data-sharing routes. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The question centers on preventing unintended access paths through workflow composition. |
| Recommendation — Enforce access-control policies across parent and child flow execution paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Child flows can expose sensitive data when connectors carry credentials or tokens onward. |
| Recommendation — Limit where secrets and tokens can be used inside chained automations. | ||
Practitioner Guidance
What to verify: Review the full parent-to-child execution path, not just the parent flow. If the child can reach an external or lower-trust connector, confirm exactly which fields, attachments, and metadata cross that boundary.
Decision rule: If a child flow can transmit sensitive data to a connector that would be disallowed in the parent’s business context, treat the composition as a policy bypass until proven otherwise. Approve it only when the data path, destination, and logging behavior are explicitly bounded.
What good looks like: The design makes the child flow’s connector set, data fields, and recipient systems visible to review, and the flow cannot silently expand its exposure surface after approval.
Practitioner takeaway: The control problem is composition, not just connector choice, so evaluate the entire execution chain as one data-sharing decision.
