Fabric Data agent integration with Static web app

Hi Nirav_Synapx​,

Yes, this is possible, and there are now two different patterns depending on how you want authentication and permissions to work.

You do not necessarily need Microsoft Foundry just to expose a Fabric Data Agent through a Static Web App.

Microsoft now supports calling a published Fabric Data Agent from a custom application using a Service Principal. The current capability is documented here in the Fabric Data Agent Service Principal guidance.

A practical architecture would be:

Azure Static Web App
-> backend API
-> Microsoft Entra token
-> published Fabric Data Agent
-> Fabric data sources

I would not call the Fabric Data Agent directly from browser JavaScript using a client secret.

Azure Static Web Apps supports backend APIs through Azure Functions and other Azure services, so the frontend can send the user's question to a server-side API and that API can acquire the Fabric token and call the Data Agent.

Microsoft documents the Static Web Apps API pattern here in the Azure Static Web Apps API documentation.

For the Service Principal approach, Microsoft currently requires the Service Principal to have access to the workspace containing the Data Agent and read access to the underlying data sources used by the agent. The Fabric tenant setting allowing Service Principals to use Fabric APIs must also be enabled.

There are two important current limitations with this route.

Service Principal authentication for Fabric Data Agent is currently Preview.

Managed Identity is not currently supported for Fabric Data Agent authentication, so the application needs to use a Service Principal. Microsoft also currently documents a limitation for Service Principal authentication when the Data Agent uses a KQL database.

The alternative is the Foundry architecture you mentioned.

Microsoft now supports adding a published Fabric Data Agent to a Microsoft Foundry agent through Fabric IQ.

That flow would look more like:

Azure Static Web App
-> backend API
-> Microsoft Foundry Agent
-> Fabric Data Agent
-> Fabric data

One important difference is identity.

The current Foundry integration uses delegated user authentication. The Fabric Data Agent query runs using the signed-in user's identity, so each user must already have access to the Fabric Data Agent and the underlying data that they are allowed to query.

That is useful if you need the chatbot to respect different Fabric permissions for different users.

So I would choose between the two based on the security requirement.

If all application users should query Fabric through one controlled application identity, I would consider the direct Service Principal pattern.

If each user's existing Fabric permissions should be enforced individually, I would look at the Foundry + Fabric Data Agent identity-passthrough pattern.

Also, Azure Static Web Apps would only host the web/chat interface. Microsoft Foundry itself remains a backend service; you would not host Foundry inside the Static Web App.

If I were building a first proof of concept, I would start with:

Static Web App
-> Azure Function API
-> Fabric Data Agent using Service Principal

and only introduce Foundry if I needed multi-agent orchestration, additional tools/knowledge sources, or per-user identity passthrough.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.