[MTP Diagnostic Analysis] AzureFoundry hard-requires API keys and has no managed-identity auth path

[Evangelink]

Summary

Microsoft.Testing.Extensions.AzureFoundry only works when AZURE_OPENAI_API_KEY is present and always creates AzureOpenAIClient with ApiKeyCredential. There is no managed-identity / Entra / DefaultAzureCredential path, so the provider is not secure-by-default for Azure-hosted scenarios.

Evidence

• Q:\src\testfx\src\Platform\Microsoft.Testing.Extensions.AzureFoundry\OpenAIChatClientProvider.cs:21-24
  • public bool IsAvailable => ... AZURE_OPENAI_ENDPOINT ... AZURE_OPENAI_DEPLOYMENT_NAME ... AZURE_OPENAI_API_KEY
• Q:\src\testfx\src\Platform\Microsoft.Testing.Extensions.AzureFoundry\OpenAIChatClientProvider.cs:35-37
  • reads AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_DEPLOYMENT_NAME, and AZURE_OPENAI_API_KEY
• Q:\src\testfx\src\Platform\Microsoft.Testing.Extensions.AzureFoundry\OpenAIChatClientProvider.cs:49-56
  • missing API key causes throw new InvalidOperationException(...)
  • client construction is hard-coded to new ApiKeyCredential(apiKey)
• Q:\src\testfx\src\Platform\Microsoft.Testing.Extensions.AzureFoundry\PACKAGE.md:17-20
  • package presents itself as Azure AI Foundry integration and notes only environment-based configuration.

Why this is a real issue

Azure-hosted test infrastructure commonly uses managed identity instead of distributing API keys. The current implementation forces users to provision and inject a secret even when a safer Azure credential flow is available. That is a concrete completeness and security-default gap in the only built-in AI provider.

Suggested resolution

Support TokenCredential-based authentication (for example via DefaultAzureCredential) when endpoint + deployment are configured, with API key remaining as an explicit fallback. The availability logic and package documentation should reflect both supported authentication modes.

Related issues

• None found