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.
| Sharing mechanism | Whose credential runs | What the recipient can do | Main risk |
|---|---|---|---|
| Co-owner on a cloud flow | The connection creator's, for embedded connections | View run history, edit the definition, add owners, delete; cannot change another owner's connection credentials | Any co-owner can change what the flow does with someone else's access |
| Run-only user, connection "Provided by run-only user" | The invoker's own | Trigger an instant flow, not view or edit it | Low; exported as RuntimeSource invoker |
| Run-only user, embedded connection | The owner's | Trigger the flow with the owner's access | Privilege lent to everyone with run access |
| Connection shared with "Can use" | The connection owner's | Use it in apps or flows; OAuth connections can only be explicitly shared with a user representing a service principal | Credential reuse beyond its original purpose |
| Send a copy | None: the copy has no connections | Independent copy of the definition | Access cannot be revoked once sent; logic and endpoints leave your control |
| SharePoint list as co-owner | The connection creator's | Everyone with edit rights on the list can edit the flow | Flow control inherits sloppy list permissions |
- 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.
| Option | Use when | Trade-offs |
|---|---|---|
| Maker's own account | Personal productivity flows touching only the maker's data | Breaks on departure; access drifts with the person's role; MFA and Conditional Access changes interrupt it |
| Dedicated integration (service) account | Connectors that only support delegated user sign-in, in a governed environment | Needs a licence, an owner, Conditional Access design and credential custody; a shared password across makers is the failure mode to avoid |
| Service principal (Entra app registration) | Connectors that support it and solution flows owned by IT | Not supported by every connector; needs certificate or secret lifecycle; see the Azure Entra Client Secrets Security Guide |
| Run-only user provides connection | Instant flows where each user should act as themselves | Only for instant flows; every user needs their own rights to the target |
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.
| Control | What it restricts | Scope and limits (per Microsoft Learn) |
|---|---|---|
| Connector endpoint filtering (preview) | Which URLs, servers, storage accounts or SMTP hosts an allowed connector can reach | HTTP, HTTP with Microsoft Entra ID, HTTP Webhook, SQL Server, Azure Blob Storage, SMTP, Browser Automation, UI Automation and Dataverse. Rules evaluate in order; last rule must be * Allow or * Deny. Not enforced on environment variables, custom inputs or endpoints bound at runtime |
| Connector action control | Individual actions (and, by PowerShell only, triggers) within a connector | Blockable connectors only; not unblockable or custom connectors. Default connector action settings decide whether future actions are allowed |
| Tenant isolation | Connections to or from other Microsoft Entra tenants | Entra-authenticated connectors only; inbound, outbound or both; up to 500 rules; about an hour to apply. Not enforced for the Azure DevOps connector, which Microsoft says to restrict with data policies |
| Managed Environment sharing limits | Who solution-aware cloud flows and canvas apps can be shared with | solutionCloudFlows-limitSharingMode = disableSharing; limitSharingMode and maxLimitUserSharing for apps. Applies to new shares only; existing access stays |
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.
- List flows:
Get-AdminFlow | Export-Csv -Path '.\FlowExport.csv'gives every flow in the tenant with its environment and creator. - List connections per environment:
Get-AdminPowerAppEnvironment | Get-AdminPowerAppConnection. Record connector, created by and status for each. - List who can use each connection:
Get-AdminPowerAppConnectionRoleAssignment. Any connection shared beyond its creator, especially to large groups, goes to the review list. - 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.
- Check data policy coverage:
Get-DlpPolicyand confirm every environment, including new ones, falls under a tenant policy and that HTTP connectors are in Business or Blocked with endpoint rules. - Check the portal views: a connection's Apps using this connection and Flows using this connection tabs show blast radius before any change.
| Signal | Source | Why it matters |
|---|---|---|
| Created flow, Edited flow, Deleted flow | Microsoft Purview Audit, Power Platform activities | New or modified automation in production environments, especially edits by someone other than the owner |
| Edited permissions, Deleted permissions | Microsoft Purview Audit | Co-owners added, including guests, or access removed |
| Flow run status, duration, error codes | Dataverse cloud flow run records, Power Automate analytics, Application Insights (Managed Environments) | Purview does not log runs; spikes in HTTP actions or failures after a policy change show up here |
| Sign-ins by integration accounts and service principals | Microsoft Entra sign-in logs | Connection use from unexpected locations or after the account should be dormant |
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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- Contain:
Disable-AdminFlowon flows that send data externally or touch sensitive systems. Disruptive: business processes stop; agree with the owner's manager first unless compromise is confirmed. - 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.
- 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.
- Remove: delete orphaned connections and remove role assignments with
Remove-AdminPowerAppConnectionRoleAssignmentafter 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
| Framework | Reference | How this guide applies it |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 Account Management | Owner of record, departure handling and review of integration accounts behind connections |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege; AC-21 Information Sharing | Dedicated identities, run-only with invoker connections, sharing limits |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality; SC-7 Boundary Protection | Connector groups, action control, endpoint filtering, tenant isolation |
| NIST SP 800-53 Rev 5 | AU-2 Event Logging | Purview flow events plus run records |
| NIST CSF 2.0 | PR.AA-05; DE.CM-09 | Access permissions managed and reviewed; runtime monitored |
| MITRE ATT&CK v20 | T1078.004 Cloud Accounts; T1567 Exfiltration Over Web Service | Abuse of signed-in connections; HTTP actions to external endpoints |
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