unable to share published copilot agent due to Power Automate workflows

There’s no supported way in Copilot Studio or Microsoft 365 Copilot today to let a broad audience use cloud flows that are secured only with the maker’s personal connections, without also giving them some level of access to those flows or re‑architecting how automation is done.

From the available information:

1. Sharing agents vs. sharing flows
   • Sharing a Copilot Studio/Agent Builder agent does not automatically share the underlying Power Automate flows.
   • To let others edit or add flows, flows must be shared directly in Power Automate by adding them as owners on the flow’s Owners list.
   • Users without access to flows in a shared agent can still run these flows only in the Test panel in Copilot Studio, not as end users of the deployed agent.
   • Therefore, for production use by the broader org, the flows must be accessible under a model that Copilot can execute on their behalf.
2. Agent flows vs. cloud flows
   • Copilot Studio now has agent flows, which are billed through Copilot Studio and explicitly cannot be copied, shared, have co‑owners, or give run-only permissions.
   • Cloud flows in Power Automate remain the general automation mechanism and support the usual sharing/co‑ownership model.
   • If the automation is implemented as agent flows, there is no mechanism to grant run-only access; the execution model is tied to Copilot Studio’s consumption and security model.
3. Maker-provided credentials pattern
   • For tools/actions that use connectors, some experiences allow choosing maker-provided credentials in the tool’s “Additional Details” → “credentials to use” setting so that the agent always uses the maker’s connection instead of prompting each user to create their own.
   • Where this option is available and supported for the connector in question, configuring the tool to use maker-provided credentials is the only documented way to have the agent run with the maker’s connection without requiring every user to have their own connection.
4. Practical implications for the scenario
   • If the automation is implemented as Power Automate cloud flows and surfaced as actions in the agent, and there is no maker‑provided credentials option for those actions, then:
     • Either the flows must be shared (co‑ownership or appropriate access) with the broader group, or
     • The design must be changed so that the agent uses a tool/connector configured with maker-provided credentials instead of directly exposing the flows.
   • If the automation is implemented as agent flows, there is no run-only sharing model; the flows are inherently tied to the agent and its billing model, and cannot be shared independently.

Given the constraints in the documentation, the only supported workaround pattern is:

• Where available, configure the agent’s tools/actions to use maker-provided credentials so that the agent runs with the maker’s connection and does not prompt each user.
• If that option is not available for the specific flow/action, the remaining supported path is to adjust the security/sharing model of the flows (for example, move to a service account–based connection and share/co‑own with the appropriate group) or reimplement the automation using tools that support maker-provided credentials.

There is no documented mechanism to keep flows fully private to the maker and still have a broadly shared agent reliably execute them for all users.

References:

• Share agents with other users
• Agent flows in Microsoft Copilot Studio FAQ
• How can I publish a CoPilot from Studio while having it reference my connector for the agent instead of asking users for their own? - Microsoft Q&A