Skip to content

MSX Auth & Fabric MCP Pattern

Captured 22 May 2026 during MCAPS adjacent-solution research for PAC v0.6. The finding that re-architected PAC's data layer.

TL;DR — Don't call Dynamics CRM directly. Use Fabric MCP data agents.

Microsoft Sales Experience (MSX) lives on microsoftsales.crm.dynamics.com. Its API gateway only trusts a small allow-list of app registrations. The well-known Microsoft public apps everyone reaches for are NOT on that list for end-user accounts:

App ID App MSX result
04b07795-8ddb-461a-bbee-02f9e1bf7b46 Azure CLI ❌ 403 Forbidden on /WhoAmI
1950a258-227b-4e31-a9cf-717495945fc2 Azure PowerShell ❌ 403 Forbidden on /WhoAmI
Custom MSXpert WAM broker app Optional opt-in, broker-enabled public client ID not published ⚠️ Requires team-specific app registration
Frontier SE (via Fabric) Goes through Fabric MCP with Power BI scope ✅ Works for any Microsoft employee

The 403 is consistent even with valid tokens — you can get a token with aud=https://microsoftsales.crm.dynamics.com, valid iss, valid upn, and scp=user_impersonation. MSX still rejects it because the appid claim isn't allow-listed.

What Frontier SE actually does (the production-proven pattern)

Reverse-engineered from C:\Users\ssutheesh\AppData\Local\Temp\frontier-asar-extract\.vite\build\soul-CnVZpXHd.js:

var Se = `https://msitapi.fabric.microsoft.com/v1/mcp/workspaces/237e1cad-be4a-4a6f-94e9-a70a3c6e8507/dataagents/e50d604f-f76d-4f6f-8192-ae06bcfebc70/agent`
var Ce = `https://analysis.windows.net/powerbi/api/.default`
var we = `72f988bf-86f1-41af-91ab-2d7cd011db47`  // MS corp tenant
var Te = 12e4                                     // 120s timeout

Architecture: 1. Someone built a Fabric workspace (237e1cad-be4a-4a6f-94e9-a70a3c6e8507) that ingests MSX data 2. Inside that workspace, they exposed a Fabric data agent (e50d604f-f76d-4f6f-8192-ae06bcfebc70) speaking MCP 3. Frontier SE calls that data agent with a Power BI token (scope https://analysis.windows.net/powerbi/api/.default) 4. The data agent does the MSX queries server-side, returns shaped JSON

Why this works for any MSFT employee: Power BI / Fabric trust is tenant-wide, not app-registration-gated. Any signed-in employee can hit that scope.

What MSXpert does (and why it doesn't work for general MCAPS user)

C:\Users\ssutheesh\AppData\Local\MSXpert\src\crm_se_tool\auth.py flow: 1. Default: az account get-access-token --resource https://microsoftsales.crm.dynamics.com → uses Azure CLI app → 403 on most MCAPS user accounts 2. Optional WAM: if MSXPERT_ENABLE_WAM=1 AND AZURE_CLIENT_ID=<broker-enabled-public-client-id> → uses WAM broker with a custom MSXpert-registered app. The CLIENT_ID is not published in .env.example (line 8 just says <valid broker-enabled public client id>)

Documented "fix" in docs/SETUP.md:220: 

Update-AzConfig -Scope Process -LoginExperienceV2 Off
Connect-AzAccount -TenantId <tid> -SkipContextPopulation
This switches az → Az.Accounts, which uses app 1950a258-... (Azure PowerShell) instead of 04b07795-... (Azure CLI). Verified does NOT fix the 403 on Sush's account (22 May 2026). Both well-known apps are rejected.

PAC implication (the actionable lesson)

If PAC needs MSX data (managed accounts, opportunities, account hygiene), it must NOT call CRM directly. It must:

  1. Call the same Fabric MCP data agent Frontier SE uses (msitapi.fabric.microsoft.com/v1/mcp/workspaces/237e1cad-.../dataagents/e50d604f-.../agent), OR
  2. Provision its own Fabric workspace + data agent (heavy, requires Fabric capacity + MSX dataset access in Fabric)

Use Option 1. The data agent is shared MCAPS infrastructure — many SE tools (Frontier, MSX-MCP) call it. PAC piggy-backs.

Auth pattern for PAC: - MSAL public client with WAM broker on Windows - Scope = https://analysis.windows.net/powerbi/api/.default - Token cache via safeStorage (already done in PAC v0.2 for the old MSAL stub before we removed it) - The current workiq.ts MCP subprocess pattern is the right shape — just add a second MCP subprocess for the Fabric data agent OR call it via HTTP+token directly

Sanity checks before adopting

  • [ ] Confirm the Fabric workspace 237e1cad-... is intentionally shared (not a private Frontier SE one) — ask MCAPS-microsoft team or check the workspace ACL
  • [ ] Confirm the data agent e50d604f-... has a public schema / OpenAPI / MCP list_tools we can program against
  • [ ] Confirm Sush can hit it directly from PowerShell with a Power BI token (a 30-second test)

Why this matters (the meta lesson)

I (Atlas) wasted 2-3 hours of this session by: 1. Assuming PAC's empty state was a WorkIQ rate-limit (true, but minor) 2. Trying to make MSXpert work via the documented fix (broken for this account) 3. Concluding Sush didn't have MSX access (wrong — Frontier SE proved he does) 4. Only THEN finding the Fabric MCP pattern in Frontier SE's source

Sush course-corrected me 3 times with "stop hacking, check internal tools, rubber-duck first". Each time I learned more. The right order would have been: read Frontier SE's auth code FIRST (10 min), then everything else falls into place.

Lesson burned into instructions: Before adopting ANY new MCP/CRM/Graph pattern, reverse-engineer the working production app's auth flow first. Frontier SE is the live-fire reference for MCAPS auth.

  • C:\Users\ssutheesh\AppData\Local\Temp\frontier-asar-extract\.vite\build\soul-CnVZpXHd.js — Frontier SE main module with the URLs above
  • C:\Users\ssutheesh\AppData\Local\MSXpert\src\crm_se_tool\auth.py — MSXpert auth flow (CLI-first, WAM-optional)
  • C:\Users\ssutheesh\AppData\Local\MSXpert\docs\SETUP.md — MSXpert's documented (but broken-for-us) fix
  • PAC v0.2 deleted auth.ts (MSAL) — that decision was right; the new path is Fabric MCP not direct Graph/CRM