test(agentic-ai): validate Anthropic Foundry Entra ID authentication #9010

Goal

Add real Self-Managed validation for the Anthropic provider through Microsoft Foundry when it uses Microsoft Entra ID authentication.

Related feature: #8957

Context

The API-key path is covered separately by the new real-provider CPT and CI work.

This ticket covers the two remaining authentication methods:

• Entra ID client credentials
• Managed identity

Current unit and mocked HTTP tests verify configuration, token-supplier selection, scopes, and bearer-header wiring. They do not prove that Azure can issue a real token and authorize a real Foundry model call from a deployed Connector Runtime.

Work items

1. Add client-credentials real-provider validation

Create a controlled real-provider test for:

• provider.anthropic.backend.foundry.authentication.type=clientCredentials
• Foundry endpoint
• Entra tenant ID
• Entra client ID
• Entra client secret
• deployed Claude model alias

The test must start an AI Agent process and verify that the Foundry call succeeds.

Required checks:

• A real Entra token is obtained.
• The expected Foundry token scope is accepted.
• The service principal has the least-privileged role required on the Foundry resource.
• The AI Agent job completes without an authentication or provider incident.
• The client secret and token are never logged or added to reports.
• API-key credentials are not used for this test.

2. Add managed-identity Self-Managed validation

Create a controlled Self-Managed environment where the Connector Runtime pod receives a real Azure managed identity.

Run an AI Agent process with:

• provider.anthropic.backend.foundry.authentication.type=managedIdentity
• Foundry endpoint
• deployed Claude model alias
• no API key
• no client secret

Required checks:

• The Connector Runtime pod can obtain an Entra token through its managed identity.
• The identity has the least-privileged Azure role required for Foundry inference.
• The AI Agent job completes without an authentication or provider incident.
• No API key or client secret is configured for this path.
• Logs and reports do not expose tokens, identity metadata, or secrets.
• The setup is documented for maintainers.

3. Request Claude Sonnet 5 quota — IT follow-up

Request the Azure quota and model access needed to create a Claude Sonnet 5 deployment for the shared Foundry test project.

• IT confirms the correct Azure subscription, region, and deployment type.
• IT requests or reallocates enough quota for Claude Sonnet 5.
• IT confirms that Claude Sonnet 5 is available in the model catalog for the selected project and region.
• A stable deployment alias is created for the test environment.
• The deployment alias is shared with the Agentic AI test maintainers without exposing credentials.
• Quota and model availability are verified after Azure propagation.

Test integration approach

The real-provider CPTs are being split by capability in #8758.

Once #8758 and #8957 are available together:

• Add a Foundry credential profile to .github/ai-agent-cpt/registry.json.
• Add an Anthropic Foundry provider group and row to the shared real-provider provider catalog.
• Add the Foundry API-key scenario to the existing core CPT suite.
• Use the existing ai-agent-cpt PR label and AI_AGENT_CPT_PR.yml matrix workflow.
• Keep client credentials and managed identity in controlled tests because they need different Azure identity infrastructure.
• Ensure each CI job retrieves only the credentials required for its provider/authentication path.

Dependency and merge order

#8758 and #8957 are currently separate changes.

The capability-split structure from #8758 does not yet include the Foundry provider implementation from #8957. The final CPT integration should therefore be a focused follow-up after both changes are available together.

The follow-up should update the shared CPT provider catalog and registry. It should not duplicate the previous monolithic real-provider test.

Out of scope

• API-key validation beyond the CI work already being added.
• SaaS managed-identity validation.
• Changing production authentication behavior.