Azure US Government: "The subscription could not be found" on foundry-api.listModels — extension queries commercial ARM

Summary

AI Foundry Toolkit v1.4.3 hardcodes the commercial ARM endpoint (https://management.azure.com) in its Foundry API client, so every management call (foundry-api.listModels, listKeys, project GET) fails with 404 SubscriptionNotFound for subscriptions that exist only in Azure US Government — even when microsoft-sovereign-cloud.environment is set to USGovernment and sign-in succeeds against the Gov cloud.

Environment

• Extension: AI Foundry Toolkit (ms-windows-ai-studio.windows-ai-studio) 1.4.3 (win32-x64)
• VS Code: 1.124.0, Windows 11 (10.0.26200, x64)
• Cloud: Azure US Government, region usgovvirginia
• Settings: "microsoft-sovereign-cloud.environment": "USGovernment", "foundry-toolkit.logLevel": "Debug"
• Azure resources: Foundry (Cognitive Services) account + project in a Gov-only subscription; az cloud set --name AzureUSGovernment && az login works and the same subscription/account/deployments resolve fine via Gov ARM (management.usgovcloudapi.net)

Reproduction Steps

1. "microsoft-sovereign-cloud.environment": "USGovernment" is set in VS Code settings.
2. The user signs in with an account whose subscription exists only in Azure US Government (az cloud set --name AzureUSGovernment, az login).
3. The Foundry Toolkit view is opened against a Gov Foundry project (or a model deployment/list is attempted in US Gov Virginia).
4. foundry-api.listModels (and the Models/Tools/keys panels) fail.

Consistency: 100% reproducible. The error re-fires on every tree-view refresh (observed at 15:15, 15:17, 15:29, 15:35 in a single session), so it surfaces continuously.

Expected Behavior

With the sovereign cloud environment set to USGovernment, the extension should target Gov ARM (https://management.usgovcloudapi.net) with the matching token audience, and list/deploy Foundry models in the US Gov (Virginia) subscription.

Actual Behavior

The extension authenticates (the bundled auth library honors microsoft-sovereign-cloud.environment), but then queries commercial ARM, which has no such subscription, and surfaces ARM's verbatim 404:

Action: foundry-api.listModels
Error type: SubscriptionNotFound
Error Message: The subscription '<subscription-id>' could not be found.

Version: 1.4.3
OS: win32
OS Arch: x64
OS Release: 10.0.26200
Product: Visual Studio Code
Product Version: 1.124.0
Language: en
UTC time: Fri, 12 Jun 2026 20:35:08 GMT

extension.js:2:3111839
extension.js:2:3112649

[error] Failed to load Models for project <project-name>: The subscription '<subscription-id>' could not be found.
[error] Failed to load Tools for project <project-name>: 404: The subscription '<subscription-id>' could not be found.
[warning] Failed to list keys for Cognitive account <account-name> in resource group <rg-name>: RestError: The subscription '<subscription-id>' could not be found.
[error] Error: Cognitive account <account-name> not found in resource group <rg-name>

Root Cause (from inspecting the shipped bundle)

In ms-windows-ai-studio.windows-ai-studio-1.4.3-win32-x64/dist/extension.js, the Foundry management client paths pin the commercial cloud in three places:

1. Project GET is a string literal to commercial ARM:

   url: `https://management.azure.com/subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/${account}/projects/${name}?api-version=2025-04-01-preview`
   

2. createCognitiveClient (behind listModels/listKeys) constructs the SDK client with no endpoint option, so the generated default applies — and also hardcodes the challenge-policy scope:

   const client = new CognitiveServicesManagementClient(credential, subscriptionId); // no { endpoint }
   configureAzureClient(client, await this.authService.getBearerChallengePolicy(subId, "https://management.azure.com/"));
   

   The bundled SDK default: this.$host = options.$host || "https://management.azure.com".

3. The sovereign-cloud setting is read by the bundled auth library (sign-in works; provider switches to microsoft-sovereign-cloud), but the Foundry management/data client code never consults it for endpoints. Corroborating counts in the bundle: 78 occurrences of management.azure.com vs 1 of management.usgovcloudapi.net — and that single occurrence sits in an unused environment-definition table that also carries the correct https://login.microsoftonline.us/ authority.

Net effect: a Gov-issued credential is used against commercial ARM; commercial ARM cannot see a Gov-only subscription and returns 404 SubscriptionNotFound, which is exactly the dialog text.

Impact

High — blocks all Foundry Toolkit functionality (model listing, model deployment, project tools/keys) for Azure US Government users. No extension setting can override the hardcoded URLs; the only workaround is bypassing the extension entirely (Azure CLI/REST against management.usgovcloudapi.net works for the same subscription and account).

Additional Context

• Sign-in itself succeeds via the microsoft-sovereign-cloud auth provider, which makes the failure look like a subscription/RBAC problem to users when it is an endpoint-selection bug.
• The same subscription, account, model deployment, and project are all retrievable via az (Gov cloud) and via the Gov Foundry data plane, confirming the resources exist and the account has access.
• Suggested fix: the extension should derive $host/request URLs and the bearer-challenge scope from the configured sovereign environment (the bundle already ships the AzureUSGovernment environment table with the correct resourceManagerEndpointUrl).