Use managed identity in Azure AI solutions

What managed identity does and does not solve

A managed identity gives a supported Azure workload an identity that can obtain Microsoft Entra tokens without storing an application secret in code or configuration. The target service still has to support the authentication path, and the identity still needs an appropriate role assignment.

It does not automatically grant access, make a public endpoint private, or remove the need to protect data and audit permissions. Treat identity, network access, and service authorization as separate controls.

Draw the caller-to-resource access graph

List every principal that connects to an Azure resource, the operation it performs, and the exact scope where access is granted. Distinguish the application identity from a service identity used by an indexer or other managed component; they may need different roles.

• Web app or function to model endpoint: identify the required inference role and supported auth mode
• Application to Azure AI Search: distinguish query access from index administration
• Search indexer to Storage: grant the Search service identity only the required data access
• Deployment pipeline to Azure: prefer workload identity federation and a separate deployment identity
• Human operator to resource: keep administrative permissions separate from runtime identities

Choose identity lifetime and scope

A system-assigned identity is tied to one Azure resource's lifecycle. A user-assigned identity is created independently and can be assigned to supported resources. Choose based on lifecycle, reuse, and ownership; do not reuse one broad identity merely to simplify setup.

Grant a built-in role at the narrowest practical resource scope. Review role definitions and target-service support before deployment, and document who can create or change role assignments. Role assignment requires privileged permissions and should be controlled separately from ordinary application deployment.

Separate authentication from network and service checks

When a request fails, follow a diagnostic sequence. Confirm the application is running with the intended identity; confirm token acquisition and audience; check that the target accepts the token; verify the principal has the correct data-plane role; then validate DNS, route, firewall, and private endpoint behavior. A 403 and a timeout point to different layers, though logs are needed to confirm the cause.

Test from the actual hosting resource and network path. A developer workstation's credentials can mask a missing workload role, while a correct token cannot bypass a firewall that blocks the application.

• Record the principal/object ID used by the request
• Verify role scope and propagation after assignment
• Check service diagnostics and activity logs without recording access tokens
• Test both expected access and denied access for a least-privilege review

Roll out safely

Start with a non-production workload and one resource connection. Verify the app still works after removing the old secret from its active configuration, then rotate or revoke that secret according to your policy. Keep a rollback plan that does not reintroduce a long-lived credential as a permanent workaround.

Review identities and assignments periodically. Remove stale principals, alert on unexpected role changes, and include identity setup in reproducible infrastructure rather than one-off portal steps.

Frequently asked questions