Why this exists: Copilot gave a confident wrong answer, or the tool “could not find” a row that is definitely there. Half the time the model is fine. Dataverse security is doing exactly what you asked it to do under the identity you actually used.
For you if: Your agent uses a tool that touches Dataverse directly or through a cloud flow and you need the result to match real user rights.
Ground rule: Dataverse lives in Microsoft’s cloud here. Row-level security, business units, and roles do not take a day off because an AI called something.
Should this action behave like the human using the agent, or like a shared system account?
There is no moral prize for picking the fancier option. Pick the one that matches your audit story and the sensitivity of the rows.
The tool or flow runs with the user who triggered things. Good when someone should only see their pipeline, their cases, or their region’s rows. If your testers use god-mode admin accounts and real users do not, you will ship a ghost bug.
A dedicated identity in Dataverse carries its own role bundle. Everyone gets the same slice of reality. Good for curated knowledge, reference tables, or guarded update operations your org signed off on. Bad surprise when someone expected private rows to stay private unless you designed for that.
This is the part nobody wants to do. It is cheaper than executive escalation.
Admins and security folks respond faster to a tight ask.
| Aspect | User-shaped runs | Shared automation account |
|---|---|---|
| Audit trail looks like | Individual people | One service identity |
| Row-level security | Usually what you want for human data | Only safe if the account is narrowed on purpose |
| Surprise factor | “Works for admin, fails for staff” | “Everyone sees the same slice” (sometimes intended, sometimes not) |
OAuth shape for the connector: Part 1. Pinning the tool in Studio: Part 2. If the tool is mostly a wrapper around Power Automate, go to Part 4. Auth garbage day: Part 5.