On July 2, 2026, Microsoft quietly added a governance control to its Microsoft 365 roadmap that could prevent a whole class of identity nightmares in Copilot Studio. The feature—numbered 566997 on the roadmap—lets administrators block AI agents from authenticating to tools using the personal credentials of the person who built them. Preview is expected in September 2025, with general availability in August 2026. The real story here isn’t the date wonkiness; it’s that Microsoft is finally tackling the messy reality of agent identity sprawl at scale.

What Exactly Is Microsoft Adding?

The control is a simple but powerful toggle. According to Microsoft’s own documentation, it stops Copilot Studio agents from using "maker authentication"—the practice of wiring an agent to a data source or connector using the builder’s own login. When enabled, agents must instead rely on end-user credentials (the person chatting with the agent) or a managed service identity such as an Entra ID application or managed identity.

The roadmap item describes it as a way to "prevent unauthorized access, align with regulatory obligations, enforce identity policies, and increase trust in agents at scale." It will be available in the Power Platform admin center or Copilot Studio settings, where admins can enforce the restriction at the environment or tenant level.

Why This Matters for Your Organization

The impact depends on your role.

For IT administrators and security teams: This is a direct answer to the growing risk of overprivileged agents. When an agent runs under a maker’s identity, it can silently inherit access to sensitive data or business processes that the end user shouldn’t have. Blocking this pattern removes a major audit and compliance headache. You’ll be able to enforce least privilege more effectively and answer auditor questions about who accessed what with a straight face.

For citizen developers and makers: The convenience trade-off is real. Until now, you could quickly hook up a connector using your own credentials and see immediate results. With this control on, you’ll need to design agents with delegated authentication or service identities from the start. That means more upfront work, but it also means your agents won’t break when you change roles or leave the company.

For business users interacting with agents: You may never see the toggle, but you’ll benefit from agents that only access what you’re authorized to see. No more awkward discoveries that a chatbot gave you data way above your pay grade because it was running on someone else’s access.

For compliance officers and auditors: Cleaner logs and clearer accountability. When an agent acts under a documented service principal or a user’s delegated identity, the audit trail is far easier to parse than trying to untangle shared maker credentials.

The Hidden Danger of Maker Credentials in Agentic Systems

Low-code platforms have always loved quick authentication shortcuts. In Copilot Studio, the temptation to use your own login is strong because it instantly proves the agent works. But the moment that agent is shared with colleagues or published more broadly, it becomes a standing proxy for your permissions.

Consider a real-world example: A sales manager builds an agent that pulls quarterly pipeline data from a CRM. The manager connects the agent using their own credentials, which include access to executive-level revenue forecasts. When a junior sales rep chats with the agent, they suddenly see data they’d normally never reach. The agent doesn’t care about role-based access controls; it looks like the manager is making the request.

This isn’t a hypothetical edge case. Microsoft’s own security guidance warns that maker-mode authentication can lead to unintended data exposure. The new control closes that gap by forcing a deliberate choice: either the end user provides the authority, or a governed workload identity does.

How Did We Get Here? The Slow March Toward Agent Governance

Copilot Studio emerged from Microsoft’s Power Virtual Agents, riding the wave of citizen development. Early adoption focused on ease of use and rapid prototyping. Security was often an afterthought—or worse, delegated entirely to the maker’s judgement. As organizations started deploying agents in production, the wrinkles showed: over‑permissioned agents, shared environments with no lifecycle management, and a growing sense that AI automation was outpacing traditional identity controls.

Microsoft has been adding governance bits and pieces. Managed environments, sharing policies, connector action controls, and now this maker credential block. The roadmap item’s language explicitly calls out GDPR and HIPAA, signaling that Copilot Studio is being positioned for regulated industries. The odd timeline—a preview date before the roadmap item was even created—suggests the feature may have been tested privately or backfilled, but the GA commitment is what matters. It tells admins: this isn’t a beta toggle that might disappear; it’s a permanent piece of the governance puzzle.

Your Action Plan for Copilot Studio Identity Governance

Don’t wait for general availability. Start preparing now.

  1. Inventory existing agents. Use the Copilot Studio overview in the Power Platform admin center to list every agent and their authentication configuration. Flag any that use maker-provided connections—especially those shared beyond the original team.

  2. Assess the blast radius. For each flagged agent, determine what data and systems the maker can access. If the maker is a power user with broad privileges, assume the agent has the same. That’s your priority list.

  3. Test the control in a sandbox environment. As soon as the preview toggle appears in your tenant, enable it in a non‑production environment and rebuild a few sample agents using end‑user or service principal auth. Document the pitfalls and prepare guidance for makers.

  4. Create reusable authentication patterns. Instead of leaving every maker to figure out Entra ID app registrations alone, provide templates: user‑delegated OAuth for personal productivity agents, service principals with tightly scoped permissions for business‑wide automations, and API gateways for high‑sensitivity systems.

  5. Update your governance policy. Amend your Power Platform governance document to require the new control be enabled in all production environments. Define a sunset period for existing maker‑credential agents and a process for exceptions.

  6. Communicate with makers. Explain why the change is happening, the risk it mitigates, and where to find resources. Frame it as an upgrade to enterprise readiness, not a punishment. Offer office hours or quick‑start guides.

  7. Monitor and audit continuously. Even after the toggle is on, keep an eye on agent usage, connector permissions, and audit logs. The control is one piece; true governance includes data loss prevention policies, consent management, and regular access reviews.

What’s Next for AI Agent Security

This roadmap item is a signal flare. As Microsoft pours billions into Copilot and agentic AI, identity governance will become the backbone of trust. We can expect more granular controls: per‑connector authentication policies, integration with Entra ID Privileged Identity Management, and perhaps a future where new Copilot Studio tenants ship with maker credentials blocked by default.

The bigger shift is cultural. Organisations are slowly realising that an AI agent is not a magic answer bot; it’s a new kind of application, and like any application, it needs a rigorously defined security model. Microsoft’s toggle may look like a small switch, but it draws a bright line between the era of experimenting with AI and the era of betting on it for serious work.