Repository navigation
Foundry Model Authentication
- A non-empty, whitespace-trimmed
FOUNDRY_PROJECT_ENDPOINTselects Foundry exclusively and requires a non-emptyAZURE_AI_MODEL_DEPLOYMENT_NAME. Configuration or authentication failure never switches to API-key authentication or GitHub inference.GITHUB_TOKENis an inference option only without a configured Foundry endpoint. - Foundry inference uses Microsoft Entra bearer tokens for
https://ai.azure.com/.default. The host lazily creates asyncDefaultAzureCredentialand Azure Identity's asyncget_bearer_token_provider; Azure Identity owns in-memory caching, early refresh, and concurrent acquisition. The Copilot SDK per-request callback is attached to both fresh and resumed sessions, including requests within long-running turns. Session configuration contains the callback, not a static bearer token or API key. -
_ensure_clientvalidates configuration and acquires a token before starting or returning the shared client. Foundry mode disables the Copilot runtime's logged-in GitHub identity. Expected credential failures produce sanitizedFoundryModelErrormessages rather than exposing underlying credential details. - Model-credential cleanup runs in
finallyafter the existing Responses shutdown handler, preserving protocol cleanup even when that handler fails. Cleanup clears the cached credential/provider references.
Sources: main.py. The existing dependency minima remain Copilot SDK 1.0.7 and Azure Identity 1.17.0; this PR changes no dependencies (requirements.txt).
AZURE_AI_MODEL_API_KEY is unsupported: a stale value cannot enable key authentication. Both hosted manifests omit it, and the host removes it from the Copilot child environment in either backend mode. The manifests also do not forward the deployment principal's Azure credential variables or GITHUB_TOKEN.
The repository's identity guidance distinguishes:
- Hosted agent runtime identity: the platform-provided identity used by the runtime credential flow. Preserve the platform-injected project endpoint and configure the model deployment name; do not substitute an account-level endpoint or inject the deployer's client ID.
- Project managed identity: the identity used to proxy project-endpoint inference to the account's model deployment. The documented requirement is Foundry User (formerly Azure AI User) on the Foundry account; it is not the runtime token principal.
- Deployment service principal: authenticates deployment automation, not runtime inference. Its role assignments do not establish access for either of the other identities.
Local execution can use existing Azure Identity environment/workload service-principal credentials or developer credentials. Keep credential values outside source control. The selected principal needs project-level model data-plane authorization, such as Foundry User or an approved narrower role; ARM Contributor alone is insufficient.
Remove obsolete model-key values from local configuration and secret stores only through the normal approved process. The code change neither deletes stored secrets nor updates a running deployment. For token-acquisition failure, check the runtime credential source first; for a service-side 403 after acquisition, check data-plane authorization, including project-to-account access. An administrator must verify actual principals and assignment scopes; this page does not establish live Azure permissions.
Sources: agent.yaml, azure.yaml, and the README guidance above.
Source: microsoft/IssueLens#42, merged to main at cf1d567d3b8564867011d9ded021b1182d8134b7.
Offline authentication regressions cover key/deployer-credential exclusion, callback registration and refresh for SDK create/resume, concurrent acquisition, sanitized failures, fail-closed behavior for both protocols, and credential cleanup after protocol shutdown. Test changes were inspected and their blob identity verified at the merged source revision; tests were not executed during wiki maintenance. This records merged implementation and repository guidance, not deployment, live inference, role-assignment, or secret-store verification. Separate deployment-workflow changes are outside this page's scope.