A chat interface in Fabric proves that a Data Agent can answer a question. It does not prove that a customer portal, internal application, scheduled service, or multi-step automation can call the agent reliably under a non-human identity. A production integration needs an explicit application contract: which identity asks, which sources that identity can read, how requests enter the runtime, how answers are validated, and what happens when authentication, capacity, source access, or generated queries fail.
Microsoft now documents service principal authentication for published Fabric Data Agents in custom applications, background services, automation, and CI/CD pipelines. The capability is in preview. That creates a practical machine-to-machine path, but it also changes the security model. Every user of a shared application can otherwise inherit the same fixed service-principal data boundary, so authorization at the application layer must be designed rather than assumed.
What decision will the application make easier, and whose data boundary should govern each request? Resolve those two questions before selecting credentials or writing the first MCP client call.
Separate management plane, published state, and runtime
Fabric exposes different surfaces for different jobs. The Fabric REST API and the preview Fabric Data Agent Python SDK manage the artifact lifecycle: create the item, configure instructions and sources, update the public definition, publish a staged version, and inspect item properties. Microsoft explicitly describes the SDK as management plane rather than the runtime question API.
After publication, the Data Agent runtime is exposed through its MCP endpoint. A client discovers the published agent's tool, sends a natural-language question, and receives the generated answer. The endpoint follows the workspace and Data Agent artifact IDs and requires a valid Fabric bearer token. Keep this runtime connection separate from deployment automation. The identity allowed to update an agent definition should not automatically be the identity used by a production application to ask questions.
| Plane | Purpose | Production control | Failure to avoid |
|---|---|---|---|
| Definition and lifecycle | Create, configure, version, update, and publish the Data Agent through Fabric REST APIs, Git, deployment pipelines, or the Python SDK. | Deployment identity, versioned configuration, approval, environment binding, and rollback evidence. | Allowing the runtime application to modify its own instructions, sources, or published definition. |
| Published artifact | Provide the approved instructions, examples, source bindings, description, and consumption endpoint. | Named owner, known-good version, evaluation baseline, source inventory, and publication record. | Calling an unpublished draft or changing production sources without regression testing. |
| Runtime MCP endpoint | Accept a question from a tool, application, or agent and return the Data Agent answer. | Dedicated runtime identity, token handling, request policy, timeout, retry, telemetry, and answer checks. | Treating a successful HTTP response as proof that the answer is authorized or correct. |
| Application experience | Authenticate users, collect intent, apply business authorization, display evidence, and route follow-up or escalation. | User-to-data policy, approved prompt templates, citations, disclaimers, feedback, and human review. | Exposing one broad service-principal data boundary to every application user. |
Design the service principal as a fixed data persona
A service principal is a non-interactive Microsoft Entra identity. Microsoft requires the tenant setting that permits service principals to use Fabric APIs, workspace access for the published Data Agent, and explicit read access to every attached data source. Sharing the Data Agent item alone does not grant source access. The agent reads schemas and runs read-only queries under the calling identity's effective permissions.
Treat the service principal as a fixed data persona. Define the business domain it may answer, the application that may use it, approved sources, workspace role, row-level and column-level rules, Purview policies, credential owner, expiration, and emergency revocation path. Prefer a dedicated identity per application and data boundary over one tenant-wide integration identity. A secret that is easy to deploy but grants broad source access is an operational liability.
Microsoft documents client-credentials authentication using the Fabric resource scope https://analysis.windows.net/powerbi/api/.default. Store credentials in an approved secret manager, rotate them, alert before expiration, and prevent tokens or secrets from entering logs. Where organizational policy permits, use a certificate or federated credential instead of a long-lived client secret. Confirm the currently supported credential and identity options during implementation because the Data Agent service-principal capability remains preview.
Two limitations require an early design decision. Microsoft's current Data Agent runtime documentation says managed identities are not supported for this authentication path, and service principal authentication is not yet supported for Data Agents connected to KQL databases. Do not design a launch around either assumption. If the source mix includes KQL or the hosting standard mandates managed identity, retain an interactive identity path, change the integration boundary, or wait for verified support.
Build a resilient MCP runtime adapter
Do not spread token acquisition and MCP protocol logic through the application. Put them behind a small runtime adapter that accepts an approved question envelope and returns a normalized result. The envelope should include application user, tenant or customer context, business purpose, correlation ID, question, conversation policy, timeout, and expected response class. The adapter should acquire and cache tokens safely, connect to the published endpoint, discover the supported tool, invoke it, normalize errors, and emit structured telemetry.
Define retry behavior by failure type. Retry token or transient capacity failures with bounded exponential backoff and honor server guidance where available. Do not blindly replay ambiguous requests or retry authorization failures. Cap total latency, apply concurrency limits, isolate queues by customer or workload, and stop cascading requests when Fabric capacity or a source is unhealthy. Natural-language questions are not idempotent business actions, and the Data Agent remains read-only, but repeated calls can still consume capacity and produce confusing duplicate answers.
The application must enforce its own authorization before the shared service principal asks a question. Map each signed-in application user to approved domains, question types, customers, regions, and output handling. Reject attempts to expand scope through prompts. If distinct customers require distinct data boundaries, use separate source models, RLS identities that are proven for the runtime path, separate Data Agents, or separate service principals. Never rely on the model to infer tenant isolation from the wording of a question.
| Test family | What to exercise | Required evidence |
|---|---|---|
| Identity | Valid, expired, revoked, wrong-tenant, wrong-scope, rotated, and missing credentials. | Fail-closed behavior, no secret leakage, actionable alert, and successful rotation without application downtime. |
| Authorization | Workspace denied, one source denied, restricted row or column, cross-customer request, and unsupported KQL path. | The application blocks invalid scope and Fabric enforces the service principal's effective permissions. |
| Question quality | Approved, ambiguous, unsupported, adversarial, stale-context, multi-source, and high-cardinality questions. | Ground-truth comparison for source selection, generated query, result, explanation, and uncertainty. |
| Runtime reliability | Token delay, MCP disconnect, timeout, throttling, source outage, capacity pressure, malformed response, and partial result. | Bounded retries, clear user state, correlation, circuit breaking, no request storm, and recoverable queue behavior. |
| Operations | Agent republish, source schema change, credential rotation, permission recertification, incident, and rollback. | Version attribution, regression detection, owner notification, known-good recovery, and retained audit evidence. |
Evaluate the answer as application output
A custom application can make a generated answer look authoritative. Preserve the distinction between source evidence, generated query, computed result, and natural-language explanation. Where the runtime exposes diagnostics or source detail, capture the minimum necessary evidence without leaking sensitive data. Display the data freshness, business scope, and limitations that a user needs to judge the answer. Route high-impact or ambiguous results to a human rather than allowing the application to turn a read-only answer into an automatic business action.
Build a versioned evaluation set from real questions. Cover expected metrics, filters, time windows, joins, synonyms, source selection, empty results, restricted data, and questions the agent should decline. Score factual correctness, query correctness, permission behavior, completeness, unsupported claims, latency, and consumption. Run the set against the exact published version and service-principal identity used by production. A Data Agent that passes under a developer account may fail or answer differently under the application identity.
Operate the integration with correlated telemetry across the application request, token acquisition, MCP call, Data Agent version, source, latency, capacity, answer evaluation, user feedback, and escalation. Avoid logging raw prompts and answers by default when they may contain confidential data. Establish retention, access, redaction, and incident rules. Watch for increases in authorization errors, timeouts, unsupported questions, low-confidence answers, repeated retries, consumption per answer, and negative feedback.
Run a three-to-five-week custom application pilot
- Select one application workflow, one governed domain, one published Data Agent, one service-principal data persona, and one accountable business owner.
- Map the management plane, published artifact, runtime endpoint, application authorization, sources, users, trust boundaries, secrets, and operational owners.
- Enable the scoped tenant setting, register the Entra application, choose the credential method, grant least-privilege workspace and source access, and document unsupported paths.
- Implement the runtime adapter with token caching, MCP connection, request envelope, timeout, bounded retry, correlation, structured errors, and secure telemetry.
- Build ground-truth, permission, adversarial, failure, capacity, credential rotation, republish, and rollback tests for the production identity.
- Run the pilot with a controlled cohort, measure answer quality and business value, remediate the correct layer, and repeat the full regression suite.
- Deliver the architecture, permission matrix, evaluation scorecard, deployment and rotation runbooks, dashboards, support model, and go, limit, or stop recommendation.
Frequently asked questions
Can a custom application call a Microsoft Fabric Data Agent without a signed-in user?
Yes. Microsoft documents service principal authentication for published Fabric Data Agents in automation, background services, custom applications, and CI/CD pipelines. The service principal must be enabled for Fabric APIs, have access to the workspace, and have explicit read access to every attached source used by the Data Agent.
Is the Fabric Data Agent Python SDK the runtime API for asking questions?
No. Microsoft describes the Python SDK as a management-plane tool for creating, configuring, updating, and publishing Data Agents. A published Data Agent is queried at runtime through its MCP endpoint. Production architecture should keep management credentials and runtime credentials separate.
Does sharing the Data Agent with a service principal grant access to its data sources?
No. The service principal needs workspace access and explicit read access to every attached source. Sharing only the Data Agent item is insufficient. The Data Agent reads schemas and executes read-only queries within the calling identity's effective permissions.
Can Fabric Data Agent service principal authentication use a managed identity?
Not currently for the Data Agent runtime. Microsoft's preview documentation says managed identities are not supported and a service principal is required. It also states that service principal authentication is not yet supported for Data Agents connected to a KQL database.
How long does a Fabric Data Agent custom application integration pilot take?
A focused pilot commonly takes three to five weeks for one application, one published Data Agent, one service principal, and a controlled question set. The pilot should prove identity, source permissions, runtime behavior, answer quality, failure handling, capacity, observability, and operational ownership before production rollout.
Official implementation references
- Service principal authentication with Fabric Data Agent
- Fabric Data Agent Python SDK and runtime separation
- Fabric Data Agent item-management REST APIs
- Fabric Data Agent public definition format
- Fabric Data Agent MCP runtime
- Fabric Data Agent architecture, governance, and limitations
Start with one application and one deliberately narrow data persona. Datrick can implement the service-principal path, prove the runtime under production permissions, and deliver an evidence-backed rollout decision.