A Copilot Studio agent uses Entra ID authentication and accesses Dataverse tables to retrieve employee records. An HR manager reports that employees can chat with the agent but receive 'access denied' errors when the agent tries to look up their own records. Which configuration is most likely causing this error?

When Copilot Studio is configured to use Entra ID (end-user) authentication and calls Dataverse via the user's delegated token, Dataverse enforces the user's own security roles — not a service account.

Option B is correct. The agent authenticates to Dataverse using the signed-in employee's Entra ID token. Dataverse then checks whether that user's assigned security roles grant them read access to the Employee table. If no security role with read access to the Employee table is assigned to those users, Dataverse returns an access denied error regardless of the agent's configuration. The fix is to assign employees a Dataverse security role (such as a custom role with Read privilege on the Employee table) in the production environment.

Option A is incorrect. The agent itself does not hold a Dataverse security role in this architecture. When using user authentication, the query runs as the signed-in user, not as a service identity for the agent.

Option C is incorrect. Accessing Dataverse tables does not require a Power Apps license per se — access is controlled by security roles and licensing depends on the specific scenario. In this case, employees accessing Dataverse through an agent interaction is covered by the agent licensing, not Power Apps.

Option D is incorrect. The question states employees can chat with the agent successfully (the sign-in is working). The error occurs specifically when the agent queries Dataverse, indicating the authentication itself succeeded but the authorization (security role) check failed.