A solution architect is planning authentication for a Copilot Studio agent that needs to call an Azure Function. The team wants to avoid storing credentials or rotating secrets manually. Which authentication approach best meets this requirement?
Select an answer to reveal the explanation.
Short Explanation
Managed identities kill the secret rotation headache. For Power Platform calling Azure, you put the system-assigned managed identity on the environment so Copilot Studio connectors can authenticate without stored credentials. The Azure Function just grants that identity access.
Full Explanation
Managed identities provide automatic credential management for Azure-hosted services. When the Power Platform environment has a system-assigned managed identity, the platform can authenticate to Azure resources (like Azure Functions, Azure Key Vault, or Azure AI Search) using the identity directly — no client secrets, no certificate files, no rotation schedules. The system-assigned managed identity tied to the Power Platform environment is correct because connectors and flows can call Azure resources authenticated as that identity. The Azure resource, in this case the Azure Function, is configured to grant the managed identity access via Azure RBAC. There are no credentials to store, no expiry dates to track, and no secrets to rotate. The service principal approach with a client secret stored in an environment variable is incorrect. While it works technically, it introduces a credentials management burden. Secrets expire, and when they do, the agent breaks. Storing secrets in environment variables also means they appear in plain text in the Power Platform admin center. The managed identity assigned to the Azure Function's hosting resource so the function authenticates to downstream Azure resources is incorrect as stated. That identity allows the function to call other Azure resources; it does not help the Copilot Studio agent authenticate to the Azure Function. The identity needs to be on the calling side, Power Platform, not the called side. The anonymous requests approach with network-level firewall rules restricting access to Power Platform IP ranges is incorrect. Making an Azure Function anonymous and relying on IP allowlisting is a weak security posture. Power Platform uses dynamic, shared IP ranges that are not practical for strict allowlisting, and anonymous endpoints have no authentication layer if the IP control fails.