ACS Call Automation Play and Recognize return 401/8565 with managed identity and Azure AI network ACL

We are testing Azure Communication Services Call Automation in a protected, synthetic, no-PHI environment using the Node.js Call Automation SDK. Production calling is disabled.

The inbound call path now reaches ACS successfully:

• answerCall succeeds.
• startRecognizing is accepted asynchronously (202), followed by a RecognizeFailed callback with result code 401 and subcode 8565.
• A fail-safe playToAll request is also accepted asynchronously (202), followed by a PlayFailed callback with the same 401/8565 result.
• Microsoft documentation describes 401/8565 as an Azure AI Services authentication error.

Configuration already verified:

• The ACS resource has a system-assigned managed identity.
• That identity has the Cognitive Services User role at the exact Azure AI resource scope.
• The configured Azure AI endpoint matches that resource.
• Local/key authentication is disabled on the Azure AI resource.
• Public network access is enabled, but the network ACL uses default deny with the Azure-services bypass enabled.
• No connection string or access key is used for this test.

Questions:

1. Which identity does ACS Call Automation use when Play or Recognize accesses the linked Azure AI resource: the ACS system-assigned managed identity, the calling application's managed identity, or another Microsoft service principal?
2. Does the Azure-services firewall bypass cover the ACS Call Automation media path, or must the Azure AI resource use default allow?
3. Is there a supported private endpoint, VNet, service tag, or firewall configuration for this integration that keeps the Azure AI resource fail-closed?
4. Besides Cognitive Services User, is another role, resource link, trusted-service setting, or regional pairing required?
5. Which Azure diagnostic log can identify the denied principal or network request without exposing call content?
6. Is disableLocalAuth=true supported for the ACS Call Automation Play and Recognize integration?

We are considering one tightly bounded, maximum 15-minute synthetic diagnostic that would temporarily change only the Azure AI firewall default action to allow, place one no-PHI test call, capture metadata-only result codes, and immediately restore default deny with read-back verification. Is it the appropriate next isolation step?

Please do not request or post phone numbers, tenant/subscription identifiers, resource names, endpoints, call identifiers, prompts, recordings, or credentials in the public thread. We can provide sanitized metadata only.

References:

https://learn.microsoft.com/en-us/azure/communication-services/concepts/call-automation/call-automation

https://learn.microsoft.com/en-us/azure/communication-services/how-tos/call-automation/play-action

https://learn.microsoft.com/en-us/azure/communication-services/how-tos/call-automation/recognize-action