When people hear “Copilot Studio agent,” they picture a chatbot. That’s the wrong mental model. A modern agent is a reasoning layer sitting on top of three very different pipes: your business data in Dataverse, your organisational content in Microsoft Graph, and the wider universe of SaaS via Power Platform connectors.
Each pipe has its own auth story. And that’s where almost every SMB and MSP rollout I see comes unstuck.
That’s not a configuration problem. That’s an identity problem dressed up as a configuration problem.
Step-by-Step: wiring an agent to the three pipes
Set the agent’s authentication first
Before you add a single tool, go to Settings → Security → Authentication in your agent. Pick Authenticate with Microsoft. This uses Microsoft Entra ID to identify whoever is chatting — and it’s the prerequisite for almost everything that follows.
Skip this step and your agent runs as nobody. Which means it can’t read Dataverse on the user’s behalf, can’t honour SharePoint permissions, and can’t call a connector as the signed-in user. Get the front door right and the rest gets easier.
Add a Dataverse table as knowledge
Open Knowledge → Add knowledge → Dataverse. You can wire up to 15 tables per agent. Two things that catch people out:
- Dataverse search must be enabled on the environment first.
- Add synonyms and glossary terms for any column where your users speak a different dialect to the schema.
“Why doesn’t it find my open opportunities?”
Because your column is called statuscode and your users say “stage.” Synonyms fix that.
Add a Microsoft 365 Graph connector for content
Graph connectors are the other knowledge model — they index external content (Jira, ServiceNow, file shares, intranets) into the same semantic graph that Copilot already uses for Teams, SharePoint, and mail. Set them up in the Microsoft 365 admin center → Search & intelligence → Connectors. ACL-based permission trimming is preserved, so users only see what they’re allowed to see. Microsoft has a clear overview here.
Notice what’s missing? Dataverse is agent-scoped knowledge. Graph connectors are tenant-scoped knowledge. Different governance owners. Plan accordingly.
Add a connector as a tool
In your agent, Tools → Add a tool → Connector. Pick a standard, premium, or custom Power Platform connector. Now the agent can act — create a row, post to Teams, hit your line-of-business API.
Tool = action. Knowledge = retrieval. Don't confuse the two.Pick the right credentials mode
Every tool asks one question that quietly decides your security posture: Maker Credentials or End User Credentials?
- Maker Credentials: the connection runs as you, the builder. Easy demos. Terrible for anything user-specific.
- End User Credentials: each chatter authenticates with their own account. Slightly more clicks for users. The only sensible default for production. Details here.
My recommendation? Default to End User and only fall back to Maker when there’s a genuine service-account scenario — like reading a shared mailbox.
Why this actually changes behaviour
Here’s the real win. Once authentication is correctly threaded through the agent, the same prompt produces different, personally-relevant answers for every user — because it’s their identity flowing into Dataverse, their Graph results coming back, their connector permissions being honoured.
That’s not a chatbot. That’s a tenant-aware assistant.
The other thing I notice with clients: governance conversations get easier. “Who can see what?” becomes a question of existing Entra groups and Dataverse row security — not a brand-new permissions matrix you have to invent for the agent.
Get the auth pattern right once and every agent you build afterwards inherits it. Get it wrong and you’ll be unpicking the same mess for months.
Wire the pipes. Mind the credentials. Ship something your clients actually trust.
CIAOPS 