A Copilot Studio agent is connected to a Dataverse environment and uses a service principal (application user) to read and write Customer records on behalf of employees. Employees should only be able to read and update Customer records they personally own. After deployment, the help desk reports that employees can view all Customer records in the organization, not just their own. The security role assigned to the application user grants Read access at the Organization level. What is the most targeted change that resolves the data visibility issue without breaking the agent's operational write capability?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Dataverse security is like a set of nested Russian dolls — Organization level means 'see everything in the org,' User level means 'see only records you own.' The application user's security role had the Read doll at the wrong size. Dialing it down to User level AND telling Dataverse to apply the filter against the real employee's identity (via impersonation) locks each person to their own customers.
Full explanation below image
Full Explanation
Dataverse row-level security is enforced through a combination of security roles (which define privilege levels: None, User, Business Unit, Parent Business Unit, Organization) and record ownership. When an agent uses a service principal (application user) without impersonation, Dataverse evaluates all privilege levels against the service principal's identity — and if that service principal's Read is set to Organization, it can see all records.
Option C is correct because it addresses both parts of the problem. First, changing the Read permission from Organization to User level means the security role itself restricts reads to records where Owner = the identity being evaluated. Second, enabling caller impersonation (passing the CallerObjectId header in the Dataverse API request with the employee's Entra ID object ID) tells Dataverse to evaluate that User-level Read permission against the employee's identity rather than the service principal's. The service principal still performs the actual API call, but the data filter is applied as if the employee were making the request. This preserves the agent's operational capability (the service principal still has the necessary privileges to execute the call) while enforcing the correct data scope.
Option A is incorrect. Removing all security roles from the application user would break all agent interactions with Dataverse — the service principal would have no permissions at all. Copilot Studio agent connection settings do not independently define fine-grained table-level permissions in Dataverse.
Option B is similar to C but less precise. 'Replace the security role' implies a completely different role with User-level Read and Write, which is correct for the privilege level change. However, the description of 'passing the end user's Entra ID identity through the connection' is vague and does not specify the technical mechanism (CallerObjectId header), making it a less targeted and actionable answer than C. Option C is more specific and technically accurate.
Option D is incorrect. Field-level security restricts visibility of specific column values within records, not which records are returned by queries. Even with field-level security on individual columns, an employee would still see the list of all Customer records (with sensitive fields masked) — the over-exposure of record rows is not addressed. Field-level security is a complementary control, not a substitute for row-level security.
Exam tip: On AB-620, know the five Dataverse access levels in order from most to least permissive: Organization > Parent Business Unit > Business Unit > User > None. For agent scenarios with service principals, impersonation via CallerObjectId is the standard pattern for applying user-specific row-level security. Know that Write operations can remain at a higher level while Read is restricted to User level.