Copilot Studio Knowledge Sources forcing end-user credentials

(0) Share

Report

Posted on by AB-02031623-0

Hi everyone,

I’m running into like a design limitation with Knowledge Sources in Copilot Studio and would appreciate technical input from anyone who has solved this.

I’m connecting structured data sources as Knowledge (not Tools), such as: Azure SQL , Databricks, Dataverse (table).

When the copilot runs a query against the knowledge source:

It triggers a FederatedKnowledgeSearchOperation consent prompt.
It fails when the user clicks Allow.
The end user is asked to go to the Connector Manager to submit credentials.
In many cases, they don’t even see a connection to submit.
If the connector is visible (if I share it via Power Apps/Autumate), it fails with:

Unable to provision connection

I have tried:

Sharing the connection via Power Apps / Power Automate.
Configuring a Service Principal following guides like Matthew Devaney’s Azure SQL knowledge setup (https://www.matthewdevaney.com/copilot-studio-connect-an-azure-sql-database-as-knowledge/).

But still prompts for user credentials and still fails.

I know that if I implement the same data access as a Tool, maker credentials work fine, and if I use Azure AI Search, no user credential prompt appears.

But when using Knowledge Sources like Azure SQL , Databricks, and Dataverse, the connection is always executed in the end user’s context, regardless of service principal configuration.

Is there any supported way to:

Use maker-level authorization for these knowledge sources?
Force service principal authentication?
Avoid end-user credential prompts for structured connectors?

I specifically need table-level knowledge integration, not tool-based execution, because the functionality is not equivalent in my use case.

Any insights would be greatly appreciated!

Categories:

General topics

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

Beyond The Platforms 171 on at

Like (0)

Report
Copy link

Link copied!

Hi, this is indeed a current design limitation of Copilot Studio Knowledge Sources — structured connectors (Azure SQL, Databricks, Dataverse) always execute in the end-user's security context, and there is no supported way to override this with maker/service principal credentials at the Knowledge level today.

Here's a summary of your options:

✅ Workaround 1 – Use a Tool instead of Knowledge
You already know this works with maker credentials. If your use case can be adapted, wrapping the data access in a Power Automate flow (called as a Tool) lets you use a shared/service account connection. The trade-off is that you lose the native NL-to-query behavior of Knowledge, but you gain full control over auth.

✅ Workaround 2 – Azure AI Search as a Knowledge Source
As you noted, Azure AI Search does not trigger end-user credential prompts. You can index your Azure SQL or Databricks data into Azure AI Search and expose it as a Knowledge source. This adds sync complexity but solves the auth problem entirely.

✅ Workaround 3 – Custom connector with a fixed service account
Build a Custom Connector that internally uses a service account or managed identity, then expose it as a Tool or Knowledge plugin. This gives you control over the auth layer.

Hope this helps!
Paolo

✅ Did this solve your issue? → Accept as Solution
👍 Partially helpful? → Click "Yes" on "Was this reply helpful?" or drop a Like!

Want more tips on Power Platform & AI? Follow me here:

🔗 LinkedIn: https://www.linkedin.com/in/paoloasnaghi/
▶️ YouTube: https://www.youtube.com/@BeyondThePlatforms
📸 Instagram: https://www.instagram.com/beyond_the_platforms/
🌐 Website: https://www.beyondtheplatforms.com/

Was this reply helpful? Yes No
AB-02031623-0 4 on at

Like (0)

Report
Copy link

Link copied!
Thanks Paolo, really appreciate the clear breakdown.

You are right, using a Tool works from an authentication perspective. However, in my scenario I rely heavily on the native NL to query behavior of Knowledge Sources. If I move everything to a Tool, I lose that automatic query generation capability, which is core to my use case.

So I would like to better understand workaround 2 and 3.

Regarding Azure AI Search (Workaround 2)

My data is not unstructured text.
It is structured product specifications stored in tables.

Example user query:

Give me 10 products from category X where price is under 5 euro.

In my current setup, the idea is that the agent generates a query against structured data to retrieve exact matches.

If I index the table into Azure AI Search:

Would this still support structured filtering like price < 5 and category = X reliably?

Or would I effectively lose deterministic query behavior and move into semantic retrieval instead of structured querying?

In other words, can Azure AI Search fully replace NL to SQL style structured querying in this scenario, or is it mainly suited for text search + filters on indexed fields?

Regarding Custom Connector (Workaround 3)

If I build a custom connector that authenticates with a service account can this actually be used as a Knowledge Source? Or will it again only be usable as a Tool?

If it can only be exposed as a Tool, then we are back to losing Knowledge NL to query behavior.

Also, is there any supported way to redirect or bypass the FederatedKnowledgeSearchOperation consent flow and delegate authentication to a tool layer instead?

Thanks again for the guidance.

Was this reply helpful? Yes No
AB-02031623-0 4 on at

Like (0)

Report
Copy link

Link copied!

Adding to the questions I have left:

On the release plan page, I noticed the following item:

"Use single sign-on for non-Entra ID connections in Copilot Studio

Public preview Feb 2026

Business Value: With single sign-on (SSO) for connectors, agent users can experience a frictionless connection to external sources without the need for multiple clicks. This streamlined process significantly enhances productivity, as employees can access critical data and services instantly, without being interrupted by authentication barriers. For businesses, this translates into faster workflows, reduced support requests related to login issues, and a more secure and seamless experience for agent users.

Feature Details: The integration of SSO for connectors in Copilot Studio ensures that users of your agents are authenticated for the connectors used in the agent instantly. By handling authentication for connectors through SSO, your agent users don't need to manually enter login credentials or navigate through multiple screens whenever the agent tries to retrieve information through a connector to a secured service."

Is this related to our current problem? Would this solution work for knowledge sources as well?

Additionally, the official article mentions that some connections supporting SSO can use On-Behalf-Of (OBO) authentication. I noticed some parameters for SQL Server are sharable and attempted to share them, but it didn’t seem to have any effect. Could you clarify the intended functionality of this feature?

Was this reply helpful? Yes No