There is a section on the Power Platform identity and access management page on Microsoft Learn that deserves more attention than its placement suggests. It is called Authentication for agents, it is in preview, and it sits about two thirds of the way down a page most admins reach only when they are looking for something else.
What it does is straightforward. It lets an administrator require authentication for all agent interactions in an environment, which means a maker can no longer publish an agent that anyone with a link can talk to.
What makes it worth writing about is not the capability. It is where the capability used to live, what happens while both places are active, and the fact that the new admin center screen can show you a setting that is not the setting being enforced.
The maker default is fine. It is still a maker default.
Start with what a maker sees. When someone creates a new agent in Copilot Studio, the Authenticate with Microsoft option is on by default. The agent uses Microsoft Entra ID authentication with no manual setup, and it can be used in Microsoft Teams, SharePoint, Power Apps, or Microsoft 365 Copilot.
That is a good default. Microsoft picked correctly.
The maker can also select No authentication, at which point anyone holding the link can chat with the agent. Microsoft’s own documentation says this plainly. There is no approval step in that flow, no second confirmation from an admin, and no tenant signal that it happened unless you have gone looking.
A default that a maker can change is a convenience, not a control. The distinction matters more for agents than it did for apps, because an agent published without authentication is not just an open front door. It is an open front door with a conversational interface attached to whatever knowledge sources and actions the maker wired up.
Where the guardrail lived until now
The way to actually stop this has existed for years. You block a virtual connector called Chat without Microsoft Entra ID authentication in Copilot Studio through a data policy in the Power Platform admin center. Microsoft Learn has a dedicated walkthrough for it.
The mechanism works. The placement is the problem, for three reasons.
First, it is a connector, and it is not a connector. Nothing connects to anything. It is an authentication requirement modeled as a connector because DLP policies were the enforcement surface available at the time. An admin scanning a connector list for data exfiltration risk is not primed to read that entry as an identity control.
Second, the default state is genuinely uncertain in any given tenant. Microsoft’s guidance notes that connectors introduced after 2019, including this one, are likely to be in the default Non-business group, and that in many organizations Non-business connectors are automatically blocked. Likely and many are doing real work in that sentence. Whether anonymous agents are currently possible in your tenant depends on how your data policies were built and whether they were scoped to the environments where agents are actually being made.
Third, DLP policies are tenant or environment scoped in a way that resists nuance. Blocking the connector broadly is easy. Allowing anonymous access for one legitimately customer-facing agent while blocking it everywhere else means policy exceptions, and policy exceptions are where governance programs accumulate the entries nobody can explain two years later.
What Authentication for agents changes
The new feature sits in the Security area of the Power Platform admin center. Microsoft describes it as a modernized framework of the existing virtual connector, and says it helps you scale through environment-level configurations and rules.
The options are the two you would expect. Authenticate with Microsoft or Authenticate Manually forces authentication through Entra ID or a manual configuration, and Microsoft states directly that this option helps prevent makers from creating or using agents with no authentication. No authentication allows anonymous access.
The improvement is not the toggle. It is the phrase groups and rules. An identity requirement expressed as an environment-level rule can follow your environment strategy: locked in production, locked in the default environment, deliberately open in the one environment where a customer-facing agent belongs. That is a policy shape an admin can explain to an auditor. A blocked connector with three environment exclusions is not.
Microsoft recommends that all customers move toward the admin center setting for exactly this reason.
The coexistence rule, and the screen that lies to you
This is the part to read carefully, because it is the part that will generate support tickets.
If both the virtual connector and the Authentication for agents setting are in use, access must be allowed in both places for it to be allowed at runtime. Block it in either one and the most restrictive behavior is enforced.
As a security design this is correct. It fails closed, and a migration between two enforcement surfaces should always fail closed.
As an operational reality it has a sharp edge. Consider the case that will actually happen. An admin sets Authentication for agents to allow anonymous access for the one environment that hosts a public support agent. The admin center screen shows the setting as allowed. Meanwhile a tenant-wide data policy written in 2024 still blocks the virtual connector. The agent is blocked at runtime, and the screen the admin is looking at says the opposite.
The new setting displays configured state. It does not display effective state. Until you have retired the virtual connector from your data policies, no single screen in the product answers the question of whether anonymous access is possible in a given environment. You have to check both and reason about the intersection yourself.
Two practical consequences follow. Any runbook you write for this needs to name both surfaces, not just the new one. And if you have a governance dashboard reporting on agent authentication posture, it needs to read both sources or it will report confidently on half the answer.
Agent access channels is the same pattern
Directly beneath it on the same page is a sibling preview feature, Agent access channels, which controls where agents may be published. The available channels include Microsoft Teams, Direct Line, Facebook, Dynamics 365 for Customer Service, SharePoint, and WhatsApp.
It carries identical framing. Modernized framework of the existing virtual connectors, environment-level configurations and rules, allow in both places or the most restrictive behavior wins, and the same recommendation to move toward the admin center setting.
Read together, these two are a signal about direction. Agent governance is migrating out of the data policy surface and into a dedicated security surface with environment scoping. The DLP virtual connectors were always a workaround for the absence of a proper home. That home is being built.
Anyone maintaining Copilot Studio governance documentation should expect the DLP-based instructions to become legacy guidance. Not immediately, and Microsoft has announced no deprecation. But writing new procedures that assume the virtual connector is the permanent answer would be optimistic.
The preview problem
Here is the tension the documentation does not resolve. Microsoft recommends that all customers move toward the new settings. The same section states that preview features are not meant for production use and might have restricted functionality, and that they are subject to supplemental terms of use.
Both statements are standard. Together they leave an admin without a clear instruction, and the reasonable reading is a sequence rather than a switch.
- Keep the virtual connector control in place. It is generally available, it is what your existing policy documentation describes, and it is currently what is protecting you.
- Turn on the new setting in a non-production environment and confirm the behavior matches the documentation, including what a maker sees when they are blocked.
- Model the environment-level rules you would want if you migrated. This is design work you can do now regardless of preview status, and it is the part that takes the longest.
- Wait for general availability before removing the virtual connector from your data policies.
Step four is the one to be disciplined about. The coexistence model means keeping the old control costs you nothing in security posture. It only costs clarity. Trading a small amount of clarity for a fail-closed guarantee during a preview is a good trade.
The rest of the page is worth ten minutes
Since you are already there, three other items on the same page are worth noting.
Guest access. All new Dataverse-backed environments prohibit guest access to Dataverse data by default. You can allow it where a business case requires it, and you can retroactively restrict it in existing environments, which blocks connections to resources guests previously reached. That last behavior is worth understanding before you use it, because it is a change with immediate effect on working access.
Administrator privileges (preview). Managed environments only. The admin center surfaces a proactive recommendation listing environments where a large number of users hold the System administrator security role, currently defined as more than twenty. Two known problems matter operationally. The Membership page shows only security roles in the default business unit unless you turn off the Display only parent security roles option, and it takes roughly twenty-four hours after removing a user for the administrator count to update. If you are running a privilege cleanup, plan for that lag rather than assuming your removals failed.
App access control (preview). Managed environments only. Controls which apps are allowed and blocked per environment.
One thing worth confirming yourself: several features on this page state that they apply only to managed environments. The Authentication for agents and Agent access channels sections do not carry that sentence. Whether that is a meaningful distinction or a documentation gap is not something the page settles, and it materially affects how much of your tenant these controls can reach. Check it in your own admin center rather than inferring it from the page.
What to do this week
- Determine whether anonymous agents are currently possible in your tenant. Do not assume. Check which data group the Chat without Microsoft Entra ID authentication connector sits in, and check which environments your data policies actually scope to.
- Inventory agents that are already published without authentication. If any exist, they were created by someone who had a reason, and that reason needs to be documented or reversed.
- Look at the Security area of the Power Platform admin center and see whether Authentication for agents and Agent access channels are visible in your tenant yet.
- Decide which environments have a legitimate case for anonymous agent access. In most organizations the honest answer is one environment or none.
- Update any governance documentation that names the virtual connector as the sole control, so that whoever reads it in six months knows a second surface exists.
- If you maintain a governance dashboard, add the new setting to it before you need it, not after a maker files a ticket about an agent that will not publish.
The broader point
Agent governance spent its first few years borrowing controls built for something else. Authentication expressed as a connector. Channel restrictions expressed as connectors. Data policies asked to carry identity requirements they were never designed to hold.
Those workarounds functioned, and they protected organizations that found them. They also meant the controls were discoverable only by admins who already knew to look, which is the wrong property for a control that decides whether strangers can talk to your data.
Moving these into a Security area with environment-level rules is the right correction. It is in preview, the documentation is prerelease, and the migration has a coexistence period with a genuine trap in it. All of that is worth working through. A control that an admin can find, scope, and explain is worth more than one that technically exists.
Sources
- Identity and access management, Microsoft Learn, Power Platform admin documentation
- Configure data policies for agents, Microsoft Learn, Copilot Studio
- Data policy example: require user authentication in agents, Microsoft Learn, Copilot Studio
- Configure user authentication in Copilot Studio, Microsoft Learn
- Control guest access in Microsoft Power Platform environments, Microsoft Learn