Fabric ML Model Endpoint returns 401 from application but works in Postman with the same token
Hi , Now, I'm currently integrating the Fabric ML Model endpoint with a .NET application and encountering a 401 Unauthorized error when calling the scoring API. The endpoint is activated and working as expected when tested directly through Postman. However, when the application calls the same Fabric scoring API, it returns HTTP 401. As far as we've verified, the same Bearer token and authentication details are being used. Endpoint pattern: POST /v1/workspaces/{workspaceId}/mlmodels/{modelId}/endpoint/score Error response: { "errorCode": "RequestFailed", "message": "Unable to process the request", "isRetriable": false } Additional details from the application logs: HTTP status: 401 Unauthorized Authorization header present on final request: True WWW-Authenticate header: Empty Postman request: Successful Application request: Fails with 401 The error response doesn't provide any additional information to identify the exact cause. I'm trying to understand whether there are any specific authentication, authorization, endpoint configuration, or HTTP client requirements when calling Fabric ML Model endpoints from an external application. Has anyone encountered a similar issue where the same token works in Postman but fails when used in the application? Are there any additional headers, permissions, redirect behaviors, or diagnostic steps that we should check to identify the cause? Any suggestions? Thanks!
Implement Fabric capacity Pause and Resume operation using Azure Automation Runbook - Part 1
Introduction Microsoft Fabric allows pausing an F SKU capacity when it is not needed and resume it when work should continue. While pausing Fabric capacities will reduce operational cost, it will make Fabric content within these capacities unavailable. When a paused Fabric capacity is resumed, billing resumes and assigned content becomes available again. Pausing Fabric capacity can provide significant operational discounting as the capacity compute charges stop once the capacity is Paused. Hence this approach could be a significant price optimization technique if the capacity does not have to be online 24 hours a day. This blog will help you implement automated control plane operation with Azure Automation. A system-assigned managed identity authenticates the runbook, a custom Azure role grants only the Fabric capacity suspend and resume operations, and two schedules pass either Pause or Resume to the same runbook. What will you need to build and enable as part of this process? Create a custom RBAC role that permits PAUSE and RESUME operations on Fabric capacities within a subscription Configure an Azure Automation runbook to undertake PAUSE and RESUME operations through a scheduled operation Following pre-requisites are needed prior to commencing the process described in this Blog. An existing Microsoft Fabric F SKU capacity. Pause and resume apply to the Azure Fabric capacity resource (not tenant). Permission to create a custom role and role assignment. Microsoft documents User Access Administrator or equivalent role-definition and role-assignment permissions for these tasks. An Azure Automation account, or permission to create one. This guide uses its system-assigned managed identity. [2] [11] PowerShell in Azure Cloud Shell for the one-time RBAC setup Step 1 - Record deployment values Before commencing the process, its important to document the necessary values as they will be needed multiple times during the process. Value Example Where to find it Subscription ID 00000000-0000-0000-0000-000000000000 Subscriptions > target subscription Fabric Resource Group rg-fabric-prod Fabric Capacity > Overview Fabric Capacity Name fab-prod-uswest2 Microsoft Fabric -> Capacity Resource Azure Automation Resource Group rg-automation-prod Azure Automation Account > Resource Group Name Automation Account Name aa-fabric-operations Automation Account -> Account Name Time zone Australia/Melbourne Azure Portal Step 2 - Create Azure automation account and enable account identity If an Azure Automation account does not already exist, create one from Automation Accounts > Create and complete the subscription, resource group, name, region, and review steps documented in the Azure Automation quickstart. Open the Automation account in the Azure portal. Under Account Settings, select Identity. On the System assigned tab, set Status to On, select Save, and confirm the change. Copy the displayed Object (principal) ID for validation. The PowerShell assignment step below also retrieves it directly. The system-assigned identity is registered in Microsoft Entra ID and is represented by an object ID. The runbook later uses Connect-AzAccount -Identity, so no stored username, password, certificate, or Automation Run As account is required. Step 3 - Prepare Azure Automation Powershell runtime From the Automation account Overview, switch to the Runtime Environment experience if it is not already enabled. Under Process Automation, select Runtime Environments > Create. Choose PowerShell and runtime version 7.4. Give the environment a descriptive name such as ps74-fabric-operations. On Packages, retain the default Az PowerShell package and add Az.Fabric from the gallery. Verify that Az.Accounts is available because the script uses Connect-AzAccount, Disable-AzContextAutosave, and Set-AzContext. Create the runtime environment and wait until its packages are available. Microsoft documents that PowerShell runtime environments include the Az package by default and can accept additional packages from the gallery. In the older Automation experience, modules are managed under Shared Resources > Modules instead. Step 4 - Create a new custom RBAC role Following four Azure RBAC actions are required for Fabric capacity pause and resume operations. Existing built-in privileged (pre-defined) roles do not contain these permissions, hence a custom role is needed. RBAC Action Purpose Microsoft.Fabric/capacities/read Read the target Fabric capacity Microsoft.Fabric/capacities/write Write to the target Fabric capacity Microsoft.Fabric/capacities/suspend/action Initiate a pause/suspend action for Fabric capacity Microsoft.Fabric/capacities/resume/action Initiate a resume action for Fabric capacity There are 2 ways to create the custom role - Using a definition file (in JSON format) Defining the permissions inline as part of a command issued within a Powershell session. As part of this blog, I'll show you both ways to create the role. Following examples shows you a functional JSON file that could be leveraged to create the custom role through command line or Azure portal. In the text below, replace SUBSCRIPTION_ID placeholder with actual subscription ID. The role definition is available at the subscription level, while the role assignment in the next step is narrowed to one capacity resource. If its desirable to create this role at resource group level, that can be done by updating the assignableScopes node to the resource group. JSON { "properties": { "roleName": "Fabric capacity Pause Operator", "description": "", "assignableScopes": [ "/subscriptions/<SUBSCRIPTION_ID>" ], "permissions": [ { "actions": [ "Microsoft.Fabric/capacities/read", "Microsoft.Fabric/capacities/write", "Microsoft.Fabric/capacities/suspend/action", "Microsoft.Fabric/capacities/resume/action" ], "notActions": [], "dataActions": [], "notDataActions": [] }] } } Now we will use the second method to configure new RBAC custom role. In Azure Cloud Shell (PowerShell), create and inspect the role. Open a new Cloud Shell Powershell session Replace the SUBSCRIPTION_ID below with the SubscriptionID in the following commandlet. Copy and paste each command into the Cloud shell session one at a time and execute. Azure custom roles use Actions for control-plane permissions and AssignableScopes to specify where the role definition is available. Microsoft recommends listing actions explicitly rather than using wildcards Powershell Set-AzContext -SubscriptionId "<SUBSCRIPTION_ID>" $role = New-Object -TypeName Microsoft.Azure.Commands.Resources.Models.Authorization.PSRoleDefinition $role.Name = 'Fabric Capacity Pause Resume Operator' $role.Description = 'Pause and Resume Fabric Capacities” $role.IsCustom = $true $role.AssignableScopes = @("/subscriptions/<SUBSCRIPTION_ID>") $permission = New-Object -TypeName Microsoft.Azure.Commands.Resources.Models.Authorization.PSPermission $permission.Actions = @( "Microsoft.Fabric/capacities/read" "Microsoft.Fabric/capacities/write" "Microsoft.Fabric/capacities/suspend/action" "Microsoft.Fabric/capacities/resume/action" ) $role.Permissions = @($permission) New-AzRoleDefinition -Role $role This blog series continues in the next post. Part 2 can be found here: Implement Fabric capacity Pause and Resume operation using Azure Automation Runbook - Part 2Fabric Core MCP: Centrally restricting destructive operations
Hi, Does Fabric provide, or plan to provide, a central governance mechanism to restrict specific REST API operations or Fabric Core MCP tools? Our goal is to allow API/MCP-based administration and automation, while centrally blocking destructive operations such as delete workspace or delete item. The key requirement is that this restriction is enforced by the Fabric platform rather than relying on the configuration of individual MCP clients. I haven't seen anything in this direction at FabCon EU. Other AI platforms already provide controls to restrict specific tools or destructive operations. Is something similar available or planned for Fabric? Best Florian
Fabric Capacity Metrics app vs Chargeback app
Hi, using Fabric Capacity Metrics app and Chargeback app I've noticed that they seem to overlap about the exposed data, even if their goal is different: the Capacity Metrics is useful for operational and performance monitoring, while the Chargeback app is useful for attribution/allocation of capacity consumption. I think it's very difficult not to use them together in a Fabric solution: why not have a single app? They should share the same data that feeds the two semantic models. What do you think? ThanksBest practices for integrating the Fabric ML Model endpoint with an application (preferably .NET)?
Hi, I'm working on a ML use case in Microsoft Fabric where we train models using Fabric notebooks, track experiments through MLflow, and register models for real-time predictions. We have already registered a model and activated its real-time inference endpoint in Fabric. We're now planning to integrate this endpoint with an application (preferably .NET). I'd appreciate some guidance on the recommended integration approach, particularly around authentication, permissions, and API invocation. A few questions: Authentication: What is the recommended way for the backend (.NET) to authenticate with a Fabric ML Model endpoint? Does it support OAuth 2.0 Client Credentials using a Microsoft Entra service principal, and is Managed Identity also supported? Permissions: What Fabric workspace or ML Model permissions are required for a service principal to invoke an activated endpoint? Are any additional tenant-level settings required? API integration: What is the recommended approach for calling the endpoint from .NET application, including the request payload format, response handling, and access-token management? Endpoint behavior: Are there any considerations around synchronous/asynchronous responses, latency, timeouts, or concurrent requests when integrating the endpoint with an application? Model versioning: If we train and register an updated model version later, can we activate a new endpoint while keeping the existing version available? What is the recommended approach for switching between versions without affecting the application? If anyone has implemented a similar integration, I'd appreciate any recommended architecture, documentation, or working. Also would like to understand whether there is a secure Fabric-native approach that would be more appropriate. Thanks in advance!
Best practice for managing OAuth Client Secrets in Fabric Pipelines without Azure Key Vault
Hi, I am currently building a Microsoft Fabric Pipeline that retrieves data from the Marketo REST API using OAuth authentication. Since OAuth authentication requires a Client ID and Client Secret, I am looking for the recommended and secure way to manage the Client Secret in Microsoft Fabric. I understand that one common approach is to store the Client Secret in Azure Key Vault (AKV) and retrieve it during the Pipeline execution. However, before introducing AKV, I would like to understand whether Microsoft Fabric provides a native way to securely manage credentials or secrets for this type of scenario. Specifically: Is there a recommended way to securely store and use an OAuth Client Secret within Fabric, for example through Connections, Credentials, Workspace settings, or another Fabric feature, without using Azure Key Vault? For a Fabric Pipeline calling an external REST API such as Marketo, is Azure Key Vault considered the recommended or best-practice approach for managing the Client Secret? If both approaches are possible, what are the main security and operational differences between using Fabric-native credential management and Azure Key Vault? Are there any Microsoft documentation or reference architectures that describe the recommended approach for this scenario? I would like to understand whether introducing Azure Key Vault is necessary for this use case, or whether there is a secure Fabric-native approach that would be more appropriate. Any advice or examples from similar implementations would be greatly appreciated. Thank you!
Controlled "Semantic Model Execute Queries" REST API Access for Fabric Users
We want to enable the executeQueries endpoint for a large audience of users so that an application can execute DAX queries against a directlake model (with SSO enabled) on their behalf. Enabling this endpoint poses a security risk because it allows users to access Fabric via unapproved tools. (Some are safe and helpful, but this can't be guaranteed.) The relevant tenant setting ("Semantic Model Execute Queries REST API") can be scoped to security groups, but it cannot limit incoming traffic to a specific source (our trusted application). Fabric provides controls to limit inbound traffic - IP allow-lists, private links at the workspace level, conditional entra access policies, etc. We have reviewed the options on this page: About inbound access protection in Fabric - Microsoft Fabric | Microsoft Learn. Semantic models are not supported for most of these solutions (private links, for example), and even if they were, they seem like they would treat API access and portal access the same. Any setting that sufficiently restricts traffic to the API endpoint would also lock users out of the Fabric portal itself (or unnecessarily restrict data in the portal). Have we missed anything? Is there a way to conditionally allow API access from specific sources for security groups without negatively impacting users by applying those same restrictions to standard portal access?Copilot Studio, Foundry, Fabric Data Agent or Operations Agent? Which one to pick
Most confusion comes from the word "agent" being used for all four. The fastest way to choose is to ask two questions: who builds it (maker or developer) and what triggers it (a person asking, or data changing). Meet the four Copilot Studio is Microsoft's low-code agent builder on Power Platform. You describe the agent in plain language, add knowledge (SharePoint, Dataverse, websites), plug in 1,000+ connectors and Power Automate flows, then publish to Teams, Microsoft 365 Copilot or a website. It is also the easiest place to orchestrate other agents, including Foundry and Fabric agents. Microsoft Foundry (formerly Azure AI Foundry) is the pro-code platform for engineers. You pick from a large model catalog, write orchestration in code, run evaluations, trace every call and deploy behind private networking. Use it when the agent is a product component, not just a chat window. Fabric data agent is a read-only, conversational analyst over your Fabric data. It turns a question into SQL, DAX or KQL against up to five sources (lakehouse, warehouse, Power BI semantic model, KQL database, ontology) and respects each user's permissions. It is generally available. Fabric operations agent lives in Real-Time Intelligence. You give it an Eventhouse, a business goal and allowed actions. It writes its own monitoring rules, wakes up when a condition hits, reasons over the data, and messages people in Teams or runs a Power Automate action. It reached general availability in mid-2026. Which one should I pick? Ask the questions in order and stop at the first "yes". A "yes" does not rule the others out: a data agent or Foundry agent is often published through Copilot Studio. Side by side Copilot Studio Foundry Fabric data agent Fabric operations agent Core job Converse and automate Build custom AI apps and agents Answer questions over data Monitor live data and act Triggered by A person (or event/flow) Your code A person or another agent A data condition Builder Maker, IT, business AI engineer, developer Data/BI team Ops and RTI team Skill level Low-code Pro-code Low-code + good data modelling Low-code, chat-based setup Data it reaches Connectors, SharePoint, Dataverse, other agents Anything you wire up Lakehouse, warehouse, semantic model, KQL, ontology Eventhouse (KQL) streams Writes or acts? Yes, via flows and tools Yes, whatever you code No, read-only Yes, Teams messages and Power Automate actions Where users meet it Teams, M365 Copilot, web, other channels Your app, API, Teams Fabric, Copilot Studio, Foundry, M365 Copilot, MCP Teams chat or channel Billing Copilot Credits Azure consumption Fabric capacity (CU) Fabric capacity (CU) Pick it when You need speed and M365 reach You need model choice, evals, isolation People Real-world scenarios These are the patterns that come up most often in the community. Each names the tool that fits and why. HR policy helper in Teams → Copilot Studio. A 3,000-person company wants staff to ask "How many leave days do I have?" and "Book Thursday off." Knowledge sits in SharePoint, leave balances in an HR system with a connector. A maker builds it in days and publishes to Teams. No developer needed. Insurance claims triage inside a customer app → Foundry. An insurer reads uploaded photos and PDFs, extracts fields, scores fraud risk and returns a decision to its claims system through an API. It needs a vision model, evaluation datasets, tracing and a private network. That is a product feature, so it belongs in Foundry. Sales leaders asking about pipeline → Fabric data agent. "Which regions missed Q3 target, and by how much?" The data agent sits on the sales semantic model, writes the DAX, and only shows rows each person may see. Publish it into Microsoft 365 Copilot or Copilot Studio so leaders never open Fabric. Cold-chain monitoring for a food distributor → Fabric operations agent. Truck temperature sensors stream into an Eventhouse. The goal: "Keep chilled loads between 2 and 5 °C." When a truck drifts, the agent posts in the fleet Teams channel with the truck, route and trend, and can trigger a Power Automate flow to reroute or open a ticket. Retail "what should I do?" assistant → all four together. Microsoft's Zava reference demo shows this: an operations agent spots a stock risk, a Fabric data agent pulls the numbers, Foundry agents for sales and product reason over them, and Copilot Studio is the front door in Teams where the manager approves a reallocation. Better together The strongest designs use more than one. Copilot Studio meets people where they work, Foundry adds custom reasoning, and the two Fabric agents keep answers and actions grounded in governed data. The operations agent is the only one that starts on its own: it reads live events and reaches people in Teams without anyone asking first. Status as of October 2026, and gotchas Fabric data agent is GA, and its Copilot Studio integration went GA at FabCon Barcelona (October 2026). Data agents in Microsoft Copilot Chat were only a sneak peek there. The data agent inside Copilot in Power BI was retired on 26 August 2026. Use the data agent directly, or through Foundry, Copilot Studio, Microsoft 365 Copilot or its MCP endpoint. Operations agent is GA (June to July 2026). Newer abilities, such as root-cause investigations and pre-approved actions, are still in public preview. Operations agents need a paid Fabric capacity. Trial capacity is not supported, and an admin must turn on the Copilot/AI and operations agent tenant settings. A data agent is only as good as the model under it. Clear table names, descriptions, relationships and agent instructions matter more than prompt tricks. An operations agent automates your mistakes too. Start with "recommend" actions that a person approves, then move to automatic actions. Don't pick Foundry just for governance. Both Copilot Studio and Foundry agents now show up in the same Microsoft governance and security tooling. Pick on build style, model needs and network needs. Rule of thumb: prototype in Copilot Studio for a week. If you hit a wall (model choice, evals, isolation, scale), that wall is your Foundry requirement. Sources Operations agent (Generally Available), Fabric Updates Blog Improving operational efficiency with operations agents, Fabric Updates Blog Build, deploy, and govern Fabric at scale (FabCon 2026), Fabric Community FabCon Barcelona 2026 announcements, James Serra Retirement of data agent in Copilot in Power BI, Fabric Community What are Fabric data agents: GA status and limits, Atlan Fabric data agent vs operations agent, Daymark One agent, many channels: querying Fabric data agents, Data Science at Microsoft Copilot Studio vs Microsoft Foundry, Nasstar Zava Real-Time Intelligence demo, Microsoft CDX
