Makers wire SharePoint and premium connectors with their own accounts so the agent 'just works' for everyone. Security says that's privilege escalation by chatbot. Is there a real admin control, or only a warning at publish time?

Control maker credential options, end-user auth, autonomous-agent impact — Steady Security before convenient identity borrowing.

Should we block maker credentials on Copilot Studio agents?

That’s a genuine concern, and you’re not imagining the blast radius. When an agent runs tools with the maker’s stored credentials, every end user inherits the maker’s reach — mail they shouldn’t see, SharePoint they were never granted, actions their own account couldn’t perform.

Here’s what’s going on. Copilot Studio lets makers choose End-user credentials or Maker-provided credentials for connectors and flows. By default both options are enabled. Maker-provided credentials mean the agent authenticates as the maker at runtime; end-user credentials force each caller to sign in so actions stay inside their permissions. Admins can enforce this in the Power Platform admin centre under the environment (or environment group) Features → Copilot Studio agents → Control maker credential options. Turning off maker-provided credentials applies immediately to existing and new agents in that scope — conversations then prompt users to sign in for connected services. The automatic security scan already warns makers before publish if they pick maker credentials, no authentication, or org-wide sharing, but a warning is not a control. Roadmap item 566997 (block maker-provided credentials; GA planned August 2026) and 566873 (detect credential oversharing at share/publish; GA planned September 2026) show Microsoft treating this as a first-class governance gap, not a niche FAQ.

Caution for autonomous agents: if you force end-user credentials only, background or scheduled runs that need a live user sign-in will fail by design. Plan service principals or approved patterns for true autonomy — don’t silently re-enable maker credentials to “make the schedule work.”

Options that actually work:

End-user credentials only on managed agent environments. Pair with DLP and least-privilege connectors. Best Steady default for interactive agents in Teams / Copilot Chat.
Allow maker credentials in a locked sandbox only, with no production channels and a named exception list. Useful while you migrate brittle POCs.
Leave both on because demos look smoother. Every shared agent becomes a standing proxy for the maker’s identity. I’d avoid this outside a lab.

12 Panes action / comms: Pane 04 Security sets the environment-group rule; tell makers a week before you flip it so they can re-bind connections. Message to leadership: we’re not disabling agents — we’re stopping agents from borrowing VIP accounts. That frames the change as Third Law hygiene (historically attributed to Schofield): the easier it is for the bot to access data, the easier it is for everyone using the bot to access the same data.

Benefits / risks: End-user auth aligns audit and least privilege; maker credentials are convenient until the maker leaves, gets promoted, or holds Finance rights the helpdesk never should. Autonomous scenarios need an explicit identity design, not a hidden maker password.

I’d suggest enabling End-user credentials only on your agent production environment group this sprint, after a maker heads-up and a list of agents that will break. You’ll have peace of mind when useful agents still work — under each user’s own keys.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer