A fire-district assistant must call Azure AI Search grounding indexes without embedding secrets in the app. Which identity pattern fits?

Using a user-assigned managed identity shared with Azure AI Search for grounding indexes is the correct secretless identity pattern for a fire-district assistant that must query Search without embedding keys in the app. Managed identities are issued by Azure AD/Entra and used by the Foundry-connected workload to obtain tokens for Azure AI Search role assignments such as Search Index Data Reader. A user-assigned identity is especially useful in municipal GenAIOps because the same identity can be shared deliberately across related resources, rotated via identity lifecycle rather than app secrets, and audited without placing long-lived keys in prompts, config files, or repos.

Pasting long-lived search admin keys into the assistant system prompt fails because prompts are not a secret store, keys become visible in logs and traces, and admin keys far exceed least privilege for grounding reads. Disabling authentication so any caller can query the grounding index fails because it opens fire-district knowledge to unauthorized retrieval. Storing personal developer PATs in a public GitHub gist fails because personal tokens are neither workload identities nor private, and public gists expose credentials immediately.

Exam caveat: managed identity plus RBAC on Azure AI Search is preferred over API keys when the stem stresses “without embedding secrets.” User-assigned is appropriate when the identity must be shared or pre-provisioned; system-assigned can also work for a single resource-bound app—pick the option that matches the stem’s shared-identity wording.

Operational check: assign the user-assigned managed identity to the assistant/Foundry-connected app, grant it least-privilege Search data-plane rights on the grounding index, remove embedded keys from prompts and configs, and verify token-based queries succeed while anonymous or keyless public access fails.