What your Copilot agent can actually see
Nobody worried much about oversharing in CRM, because advanced find was tedious and nobody went looking. An agent removes that. Everything a user technically has access to is now one plain-English question away.
Your security model didn't change. What changed is that it's finally being exercised.
Identity is the whole design
Two options, and they behave completely differently.
User authentication. The signed-in user's identity flows through to Dataverse, which applies your security roles and record-level permissions as normal. The same prompt returns different answers for different people, which is exactly right.
Agent author authentication. A fixed credential does the work regardless of who asked. Microsoft scopes this to implicit or low-risk access — a weather lookup, a public phone number. If you reach for it to make something work, you've just built a bypass around your own security model.
Default to user auth. Fall back only for a genuine service-account case, like reading a shared mailbox.
Cumulative permissions get expensive
Dataverse adds up every grant from every role and every team, then checks. There's no deny.
That was survivable when access was theoretical. Now an agent will happily aggregate across everything the user can reach and summarise it in one answer. The stray owner team somebody created three years ago to solve a visibility request stops being clutter and starts being a disclosure.
Before you switch anything on: pull the role and team membership for a sample of users and check what they can actually see, not what they're supposed to see.
What the model can't protect
- Column security profiles — salary, ID numbers, bank details. If the field is readable, the agent can read it and put it in a sentence.
- Record sharing — invisible at design time, unauditable in bulk, and it grants exactly the access the agent will use.
- Notes and attachments — usually wide open, frequently containing things people would never put in a proper field.
The paths that aren't in the security model at all
This is where agent projects leak. Most failures aren't a misconfigured table privilege:
- Which connection the agent's actions run under, and whose permissions that carries
- Whether a flow behind the agent runs as a service account with more rights than the user
- App sharing and DLP policy governing which connectors the agent can reach
- Any autonomous agent, which has no signed-in user at all — that identity is the ceiling on everything it can do
Give service identities a purpose-built role scoped to the specific tables they need. Not System Administrator because it was faster.
Treat retrieved content as untrusted
Records and documents are input, and input can carry instructions. A case description written by an external customer is not a safe place to take direction from.
The design rule: retrieved content informs an answer, it never authorises an action. Anything privileged runs on validated parameters through a flow or plugin, where the rules are enforced server-side and a model can't talk its way past them.
Where to start
- Confirm every action is using user authentication unless there's a written reason not to
- Audit team memberships and delete the ones nobody can explain
- Column-secure the fields that would be a problem in a chat window
- Check which identity your flows and connections actually run as
- Test the agent as three different users, not as yourself
None of this is AI work. It's the security model you already had, finally being read out loud.
Related: Copilot in Dynamics 365 — what it actually does
Thanks for reading this article. Hope this Article will help you. Cheers!!!
#Dynamics365 #PowerPlatform #MicrosoftCopilot #DynamicsCRM #CopilotStudio #Dataverse #AIDeveloper #DynamicsAIEngineer #HireAIEngineer #AIEngineer #D365Consultant #CRMDeveloper #AIAgents #MSDyn365
