Revisit Azure.Identity dependency in Microsoft.Testing.Extensions.AzureFoundry before GA

[Evangelink]

Context

PR #9707 added managed-identity / Entra ID authentication to Microsoft.Testing.Extensions.AzureFoundry via DefaultAzureCredential, which introduces a direct dependency on Azure.Identity. This transitively pulls in a heavyweight graph (MSAL / Microsoft.Identity.Client, Azure.Core, Microsoft.IdentityModel.*, System.Memory, etc.) that becomes a transitive dependency for all consumers of the package.

The package is currently alpha / IsShipping=false, so this is acceptable for now.

Task

Before this package moves to shipping/GA status, revisit the dependency footprint. Options to weigh:

• Keep Azure.Identity as a direct dependency (simplest, secure-by-default).
• Abstract credential creation behind an injectable TokenCredential (or a factory) so consumers who only use API keys aren't forced to pull the full MSAL graph.
• Consider an optional/separate package for the managed-identity path.

Also re-verify that the pinned Azure.Identity version is current and supported at GA time (it was bumped to 1.21.0 in #9707).

References

• PR Support managed identity auth in AzureFoundry provider #9707
• Original issue [MTP Diagnostic Analysis] AzureFoundry hard-requires API keys and has no managed-identity auth path #8412

[github-actions]

Adding an energy-efficiency lens to the dependency decision.

Energy impact of the current Azure.Identity dependency

Every test run that uses Microsoft.Testing.Extensions.AzureFoundry (even with an API key) now loads the full Azure.Identity transitive graph. Rough breakdown of the per-run overhead:

Overhead	Source	Notes
Assembly load & JIT	Azure.Identity, Microsoft.Identity.Client, Azure.Core, Microsoft.IdentityModel.*	~15–25 extra assemblies; each must be loaded from disk and JIT-compiled on first use
Background threads	MSAL's token-cache eviction and refresh timers	Active even when no token is ever requested
Memory footprint	MSAL's internal state machines, HTTP client factory, token-cache dictionaries	Typically 8–20 MB resident; proportional to DRAM refresh energy

For a CI environment running hundreds of test processes per day, the aggregate overhead across the fleet is non-trivial — even if each individual process only holds the assemblies for a few seconds.

Recommended approach from an energy-proportionality perspective

The TokenCredential-injection option (option 2) is the most energy-proportional design:

// API-key users: no Azure.Identity dependency at all
var client = new AzureFoundryClient(endpoint, new ApiKeyCredential(key));

// Managed-identity users: they explicitly reference Azure.Identity and construct the credential
var client = new AzureFoundryClient(endpoint, new DefaultAzureCredential());

This way:

• Users who only use API keys pull zero MSAL assemblies
• The Azure.Identity package becomes an optional dependency, only loaded when the calling application explicitly adds it
• [Green Software Foundation — Energy Proportionality]((learn.greensoftware.foundation/redacted) resource usage scales with actual feature usage, not with the package's theoretical capability set

Concrete check

It's worth auditing whether DefaultAzureCredential is used for every authentication scenario in the current implementation, or whether it's only needed for the managed-identity/Entra path. If API-key paths currently call through DefaultAzureCredential unnecessarily (a common mistake), that alone is worth fixing even before the GA dependency decision.

🤖 Automated content by GitHub Copilot. Generated by the Efficiency Improver workflow. · 220.7 AIC · ⌖ 11.3 AIC · ⊞ 13.6K · [◷]( · ◷)

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/efficiency-improver.md@main