Flow security and connection references

Connections are stored credentials

When a maker creates a connection, they authenticate once and the platform stores a credential/token for that connector. The flow then acts as that connection on every run — with the full permissions of the account that authorised it. This is the security fact everything else follows from: the flow's power is the connection's power, not the caller's.

Connection references

A connection reference is a solution component that names a connection abstractly, so the flow points at 'the SharePoint connection' rather than a specific personal one. This is what makes ALM work — you can import a flow to production and bind it to a service-account connection there without editing the flow — and it is also the clean way to avoid personal-credential orphaning.

The exfiltration surface

A single flow that binds a business connector (read Dataverse/SharePoint) and a non-business connector (write to personal storage, POST via HTTP) is a data-exfiltration pipe. DLP's cross-group rule exists precisely to make that flow impossible — which is why DLP misclassification (a risky connector in the business group) directly reopens the hole. serv365 treats a DLP weakening as a dated drift alert for this reason.

Failure modes

• Sharing a flow lends your access. A co-owner or a flow triggered by an app can act through your connection — a privilege-escalation and exfil path that looks like ordinary collaboration.
• HTTP / custom connectors bypass intent. They can call arbitrary endpoints; in the business group they turn any flow into an outbound pipe.
• Over-privileged service accounts. A flow's service-account connection with broad rights becomes a high-value, standing credential.
• Secrets in flow definitions. Hard-coded keys or URLs in actions leak through export/inventory rather than being held as managed secrets.

What to watch (proofs)

• Connections and owners: Get-AdminPowerAppConnection — the stored-credential inventory and who holds each.
• Connector combinations per flow vs DLP: Get-AdminFlow details against Get-DlpPolicy — a flow spanning business + non-business (or a risky connector mis-grouped) is the exfil finding.
• Shared/high-reach flows: Get-AdminFlowOwnerRole and app-triggered flows — where one connection's access is lent widely.
• Connection-reference vs personal-connection usage in solutions — personal connections in production are both an orphan and an accountability risk.