When an Azure SDK call authenticates as the wrong identity, the cause is almost always the DefaultAzureCredential chain order, not a bug in your code.
The chain (verified against the current azure-identity docs, same order in Python, JS, Go, .NET, Java):
1. Environment - AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET (or certificate). Used first whenever all three are set. This is why a stray env var on your laptop can make local runs authenticate as a service principal instead of your az login.
2. Workload Identity - when running on Azure with workload identity enabled.
3. Managed Identity - when running on an Azure host with a managed identity.
4. Shared token cache (Windows only) - Visual Studio login.
5. Visual Studio Code - the Azure Resources extension account.
6. Azure CLI - whatever `az login` last authenticated.
7. Azure PowerShell - Connect-AzAccount.
8. Azure Developer CLI - azd auth login.
9. Interactive browser - only if you explicitly enable it (off by default).
10. Broker - OS brokered auth, if the broker package is installed.
Practical rules:
- Local dev: if you want your `az login` identity, make sure AZURE_CLIENT_ID / AZURE_TENANT_ID / AZURE_CLIENT_SECRET are NOT set in your shell. One forgotten export flips step 1 on.
- In production: prefer narrowing the chain. In Python: `DefaultAzureCredential(exclude_cli_credential=True)` and friends. Every language has exclude_* options; use them to cut the chain down to exactly what the environment provides.
- Managed identity is only attempted when the code actually runs on Azure (IMDS endpoint reachable). Locally it is skipped fast; in a locked-down VNet where IMDS is blocked it can hang, so set a short timeout or exclude it.
- Interactive browser auth never fires unless you opt in, so a headless job will not pop a browser. It will just fail with a clear "no credential in the chain worked" error.
Debug move: run with AZURE_LOG_LEVEL=debug (Python) or the equivalent logging in your SDK. The log shows each credential tried and why it was skipped. That log is the fastest way to see which step actually produced the token.