Power Automate connections security: shared credentials, flows and DLP controls explained

Every Power Automate connection is a stored credential, and most organisations have thousands of them signed in as ordinary staff, attached to flows nobody owns any more. A flow that runs on a schedule acts with the identity of whoever created its connections, so a maker's mailbox, SharePoint rights or SQL login quietly becomes a non-human identity. This guide covers how connections, connection references and sharing actually behave, the data policy features that constrain them (connector groups, endpoint filtering, action control, tenant isolation), how to inventory and monitor them, and what to do when a connection owner leaves or is compromised. It is written for Power Platform administrators, Microsoft 365 security teams and identity teams who own the risk of automation built outside IT.

Key takeaways

• A connection is a credential, not a setting. Microsoft describes connections as stored authentication credentials for a connector, so treat them with the same inventory, ownership and review you apply to service account passwords.
• Flows run as the connection owner. Co-owners can use a connection in a flow but cannot change its credentials, and when the creator leaves, actions bound to their connections start failing or, worse, keep working on a dormant account.
• Data policies are the main preventive control. Business, Non-business and Blocked groups stop risky combinations, and endpoint filtering and connector action control narrow what an allowed connector can reach or do.
• Audit logs show changes, not runs. Microsoft Purview records flow creation, edits, deletion and permission changes; per-run activity needs Dataverse run records, analytics or Application Insights.
• Move business-critical flows into solutions. Connection references, dedicated integration accounts or service principals and Managed Environment sharing limits turn personal automation into something you can own, deploy and recover.

How connections, connection references and sharing work

Three objects matter. A connector wraps an API. A connection is the stored authentication for that connector, for example the OAuth sign-in a maker completes for Office 365 Outlook or the username and password typed into SQL Server Authentication. A connection reference is a solution component that points to a connection, so a solution flow binds to the reference and the reference binds to whichever connection the environment supplies at import.

• Turning a flow on: the user must own, or hold Can use on, every connection the flow uses; ConnectionAuthorizationFailed means one is missing. Use it as a checkpoint for whose credentials a production flow carries.
• Default environment: Microsoft Entra users get the EnvironmentMaker role automatically in the default environment, which is why personal flows with personal connections accumulate there.
• Owner departure: if an active owner remains, the flow keeps running but actions using the departed user's connections may fail until credentials are updated. If no active owner remains, Microsoft's route is to copy the flow and rebuild it under the new owner. Non-solution flows cannot change ownership in place.

The platform-wide view (environments, Dataverse application users, admin roles) is in the Microsoft Dynamics 365 and Power Platform Security Guide; this page stays on connections and flows.

Choosing the identity behind a production flow

For each important flow, decide whose access the automation should carry.

Small organisations can manage with one governed environment and a few integration accounts. Large tenants need separate development, test and production environments, Managed Environments for production and an owner of record for every production connection.

Data policies: groups, endpoints, actions and tenants

Data policies (formerly DLP policies) are created at tenant level by a Power Platform Administrator, or at environment level by an environment admin. Environment policies cannot override tenant-wide ones, and environment admins cannot edit or delete tenant policies.

• Connector groups: each connector sits in exactly one of Business, Non-business (the default group) or Blocked. A flow cannot combine Business and Non-business connectors, and Blocked connectors cannot be used at all. Unblockable connectors, SharePoint among them, always fall into Non-business unless you move them to Business.
• Default group for new connectors: set with Set default group. Microsoft recommends Non-business. Choosing Blocked sends new blockable connectors to Blocked, which is stricter but generates maker friction each time Microsoft adds a connector.
• Enforcement: violating flows are suspended and connections for blocked connectors disabled. Microsoft states enforcement usually completes within an hour and can take up to 24 hours. Start-DLPEnforcementOnConnectionsInTenant and the per-environment variant run enforcement against existing connections.

Endpoint filtering is the control that stops an HTTP action posting data to an arbitrary internet address, which maps to ATT&CK T1567 Exfiltration Over Web Service. Because dynamic endpoints are not evaluated, pair it with a review that rejects flows building URLs from variables. Wider DLP design is in the Data Loss Prevention (DLP) Guide.

Inventory and monitoring

All of the steps below are read-only. Install Microsoft.PowerApps.Administration.PowerShell (it needs Windows PowerShell 5.x) and run as a Power Platform Administrator.

1. List flows: Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv' gives every flow in the tenant with its environment and creator.
2. List connections per environment: Get-AdminPowerAppEnvironment | Get-AdminPowerAppConnection. Record connector, created by and status for each.
3. List who can use each connection: Get-AdminPowerAppConnectionRoleAssignment. Any connection shared beyond its creator, especially to large groups, goes to the review list.
4. Join with Entra ID: match connection creators against disabled, deleted or departed accounts and against privileged role holders. A disabled creator with active connections is your first remediation queue.
5. Check data policy coverage: Get-DlpPolicy and confirm every environment, including new ones, falls under a tenant policy and that HTTP connectors are in Business or Blocked with endpoint rules.
6. Check the portal views: a connection's Apps using this connection and Flows using this connection tabs show blast radius before any change.

Turn on auditing per production environment and grant analysts the Purview Audit Logs or View-Only Audit Logs role. On retention, see the SaaS Audit Log Retention and Licensing Guide.

Metrics that show the controls work:

• Percentage of production flows in solutions using connection references.
• Number of active connections whose creator is disabled or has left (target zero).
• Connections shared with Can use beyond their creator, trended monthly.
• Environments not covered by a tenant data policy (target zero).
• HTTP connector flows with endpoint rules ending in * Deny, as a share of all HTTP flows.
• Median days from owner departure to connection reassignment.

Rolling out connection governance

1. Baseline (read-only): run the inventory above and export the current data policies. Identify flows using HTTP, SQL Server, SMTP and custom connectors, and connections owned by privileged or departed accounts.
2. Tenant data policy in a test environment: build the policy scoped to a test environment first, with HTTP connectors in Business plus endpoint rules ending in * Deny. Microsoft notes excluded test environments have no policy applied, which is useful for comparison.
3. Pilot ring: apply to one production environment with known owners. Watch for suspended flows and ConnectionAuthorizationFailed errors for two weeks. Rollback is editing the policy scope or moving the connector back to its previous group; allow up to 24 hours for enforcement to settle either way.
4. Tenant-wide policy: scope to all environments, with exclusions documented and time-limited. Destructive impact: violating flows are suspended and connections for blocked connectors are disabled across the tenant, so communicate first.
5. Tenant isolation: turn on Restrict cross-tenant connections only after adding a temporary * rule in both directions, reviewing the cross-tenant isolation reports, then replacing * with named partner tenants.
6. Production hygiene: move business-critical flows into solutions with connection references bound to integration accounts or service principals, enable Managed Environments and set solutionCloudFlows-limitSharingMode for production.
7. Ongoing review: Microsoft suggests reviewing flow ownership and sharing monthly or quarterly; fold it into identity access reviews.

Responding to a departed or compromised connection owner

1. Scope (read-only): list every connection created by the account and every flow using them, from the inventory and the Flows using this connection tab. Check Purview for Edited flow and Edited permissions events in the window of concern.
2. Contain: Disable-AdminFlow on flows that send data externally or touch sensitive systems. Disruptive: business processes stop; agree with the owner's manager first unless compromise is confirmed.
3. Revoke: disable the user account and revoke its sessions in Entra ID, then confirm the OAuth-based connections it created now fail. Rotate any password or key typed into non-OAuth connections (SQL Server Authentication, SMTP, custom connector API keys) at the target system, because disabling the Entra account does not change them.
4. Rebuild: re-create connections under an integration account or service principal, rebind connection references, and transfer solution flow ownership. For non-solution flows, use Save as or export and import.
5. Remove: delete orphaned connections and remove role assignments with Remove-AdminPowerAppConnectionRoleAssignment after confirming no flow uses them. Destructive: a deleted connection cannot be restored and must be signed in again.

For token-based compromise more broadly, see the OAuth Token Theft Incident Playbook.

Common failure patterns

• Admins build flows with admin accounts: a privileged identity signs in to connectors, and every co-owner can point that access at new actions.
• Run-only flows with embedded connections: an instant flow shared to a large group runs with the owner's rights, lending them to everyone who can press the button.
• Default group left as Business: new connectors join the Business group automatically and can be combined with sensitive data the day they appear.
• HTTP allowed without endpoint rules: the HTTP connector in the Business group with no * Deny rule gives every maker a general-purpose exfiltration path; endpoint rules that rely on variables are not enforced.
• Departures handled by HR only: the account is disabled, flows fail at quarter end, and someone reconnects with their own account, recreating the problem.
• Non-OAuth secrets forgotten: SQL logins and API keys inside connections outlive the person who typed them, and are not rotated when that person leaves.

Where identity fits

Connections are the non-human identity layer of Power Platform: long-lived, delegated and rarely reviewed. Put integration accounts and service principals used by flows into your NHI inventory with an owner, purpose and review date. The governance model for maker-built automation is covered in the Citizen Developer and Internal AI App Governance Guide and the Low-Code and No-Code Application Security Guide.

Framework mapping

Practitioner checklist

• Export all flows, connections and connection role assignments, and join creators against Entra ID account status.
• Reassign or remove every active connection whose creator is disabled or departed.
• Confirm a tenant data policy covers all environments and the default group is Non-business or Blocked.
• Put HTTP connectors under endpoint filtering with a final * Deny rule and reject flows that build endpoints from variables.
• Use connector action control to block high-risk actions on connectors you must allow.
• Enable tenant isolation with named partner tenants, and restrict the Azure DevOps connector with data policies.
• Move production flows into solutions with connection references bound to integration accounts or service principals.
• Turn on Purview auditing per production environment and alert on Edited permissions involving guests.
• Rotate non-OAuth secrets held in connections when the person who entered them leaves.

Standards and references

• Microsoft Learn: Manage data policies
• Microsoft Learn: Connector endpoint filtering
• Microsoft Learn: Connector action control
• Microsoft Learn: Share a cloud flow
• Microsoft Learn: Use a connection reference in a solution
• Microsoft Learn: Restrict cross-tenant inbound and outbound access
• Microsoft Learn: Power Automate activity logging
• Microsoft Learn: PowerShell support for Power Apps and Power Automate

Related NHI Mgmt Group resources: Microsoft Dynamics 365 and Power Platform Security Guide · Low-Code and No-Code Application Security Guide · SaaS and OAuth App Governance Guide · Azure Entra Client Secrets Security Guide