Should we block Direct Line and external Copilot Studio channels by default?

You’re right to worry about where an agent answers, not only what it knows. An authenticated agent on Teams is a different risk profile from the same brain hanging off a public Direct Line demo URL.

Here’s what’s going on. Copilot Studio publish is channel-shaped. Learn lists dedicated connectors admins can block in Power Platform data policies: Direct Line channels in Copilot Studio (demo website, custom websites, mobile app, and other Direct Line surfaces), Facebook, WhatsApp, Omnichannel, SharePoint channel, and even Microsoft Teams + Microsoft 365 Channel if you ever need that nuclear option. Direct Line often sits in the default Non-business group — so many tenants accidentally discover it when Non-business is already blocked. There is also a preview Agent access channels control under Security → Identity and access that greys out disallowed channels in the maker UI.

Practical options:

1. Block external channels in production data policy; allow Teams + M365. Put Direct Line, Facebook, WhatsApp, and Omnichannel in Blocked for production environment groups. Leave Microsoft Teams + Microsoft 365 Channel allowed for Wave 0 employee agents. Best Steady default for most organisations.
2. Use a zoned model. Dev/sandbox may allow Direct Line for demos; production does not. Pair with environment groups so makers aren’t surprised mid-sprint.
3. Preview Agent access channels for clearer maker UX. Same intent as DLP channel blocks, with on-screen policy messaging. Preview — useful alongside, not instead of, documented data policy until GA language settles.
4. Block every channel including Teams. Stops publish entirely if no allowed channel remains. Use only as a short freeze, not a strategy.

The caution: Learn notes the built-in Direct Line test channel that powers Preview does not alone block Publish — so don’t assume “we blocked Direct Line” means makers can’t iterate in the test pane. Runtime policy still applies. If every configured publish channel is blocked, Publish fails. Already-published agents on a newly blocked channel show errors and fail at runtime until reconfigured. Blocking channels is not a substitute for requiring authentication, blocking HTTP tools, or scoping knowledge sources.

I’d suggest a one-page channel allow-list: production = Teams + Microsoft 365 (and SharePoint only if that is an approved surface); external Direct Line / social channels = named sandbox or change-board exception. Review the Non-business default so you don’t discover Direct Line the hard way. That is Steady GRC before the agent walks out of the estate.

You’re asking the right question. Steady before scale means channels are a privilege, not a maker convenience.