How do we stop makers publishing anonymous Copilot Studio agents?

You’re right to treat “anyone with the link” as an organisational risk, not a maker preference. Anonymous agents are fine for a public FAQ on a website you control — they are a poor default for anything that can see SharePoint, connectors, or process prompts inside your tenant.

Here’s what’s going on. New Copilot Studio agents default to Authenticate with Microsoft, which uses Microsoft Entra ID and keeps chat inside Teams, SharePoint, Power Apps, or Microsoft 365 Copilot. Makers can still switch to No authentication, and Learn is blunt: anyone with the link can then chat with the agent. That is Schofield’s Third Law in product clothing — the easier you make access, the easier someone else gets in.

Practical options:

1. Block the anonymous connector in data policy (production-ready). In the Power Platform admin center, put Chat without Microsoft Entra ID authentication in Copilot Studio in the Blocked group (or ensure your Non-business default already blocks it — that connector often lands there). After enforcement, makers can only choose Authenticate with Microsoft or Authenticate manually, and Publish fails until they do. Best Steady default for most Wave 0 tenants.
2. Use Authentication for agents (preview) for stricter posture. Under Security → Identity and access → Authentication for agents, set the environment (or environment group) to Require Microsoft authentication if you only want the integrated Entra path, or Require Entra authentication if makers still need manual Entra configuration. Preview — not for sole reliance in production — but Learn says it modernises the same virtual-connector idea and that the most restrictive of DLP vs this setting wins at runtime.
3. Leave No authentication open for a sandboxed public zone. Only if you have a deliberate external FAQ environment with no business connectors. Don’t mix that with your production maker estate.
4. Wiki-only “please don’t.” Culture helps; it does not stop Publish.

The caution: blocking anonymous auth does not by itself stop risky channels, HTTP tools, or knowledge sources — pair with channel and connector policies. If both the DLP connector and Authentication for agents disagree, Learn’s matrix says either block wins. Already-published agents that fall out of policy stop responding until makers fix authentication. And SKUs and preview labels change — re-check Learn when you implement.

I’d suggest a one-page Wave 0 note: block Chat without Microsoft Entra ID authentication tenant-wide (or on production environment groups), reserve any public/anonymous pattern for a named sandbox, and decide later whether preview Require Microsoft authentication becomes your stricter long-term control. That is Steady Identity before the link leaks.

You’re asking the right question. Steady before scale means agents earn a signed-in audience; they don’t inherit anonymity by accident.