SharePoint’s Agent chat web part will put any M365 Copilot agent on a modern page — how do we stop intranet sprawl?

You’re right to worry that “add agent to page” will become the new “add news web part everywhere.” Intranet editors already ship faster than Security can inventory; a chat surface pinned to a homepage multiplies who bump into an agent — and who hit an access error when the knowledge library was never meant for them.

Here’s what’s going on. Roadmap 575298 (SharePoint: Agent chat web part) is In development, with Preview in November 2026 and GA in January 2027 (Worldwide plus GCC, GCC High and DoD). MRC’s description is short and consequential: a new web part for modern page editors that can be configured to use any M365 Copilot agent. Learn does not yet document this specific web part’s property pane — lean on the roadmap for the surface, and on Manage access to agents in SharePoint for the controls that will still matter underneath.

Those controls are familiar Steady material. SharePoint agents live as .agent files; file permissions decide who can open or edit the agent. Responses still honour each user’s permissions to the knowledge sources — access to the agent without access to the library means answers omit that content (and practitioner threads already report blunt “You don’t have access to this agent” / knowledge errors when sources and visitors don’t align). Site owners pick a main site agent for the header icon; SharePoint admins can use restricted content discovery to turn off agent features on sensitive sites; AI admins can block agents in Copilot Chat via the Copilot Control System — noting Learn’s caveat that block today targets Copilot Chat availability and doesn’t yet fully cover SharePoint/OneDrive/Teams surfaces. Licensing remains Copilot licence and/or SharePoint agent pay-as-you-go policy groups.

This is Schofield’s Third Law on a modern page: the easier it is to put an agent where everyone lands, the easier it is for the wrong audience to try it. Steady Adoption puts page-editor rights and agent registers ahead of “chat on every hub.”

Options that actually work:

1. Treat the web part like a high-risk page template, not a decoration. Limit who can edit hub and homepage modern pages; require an approved agent (named owner, knowledge sources, audience) before the web part goes live; pilot on one communications site, not the tenant root.
2. Align audience, .agent permissions and knowledge libraries first. If the page is org-wide, the agent’s sources must be org-readable or the experience will fail loudly. Restricted libraries belong on restricted pages — or behind RCD so the site never offers agents.
3. Register intranet-embedded agents in the AI register. Same Wave 0 habit as Copilot Studio and SharePoint header agents: owner, purpose, knowledge sites, licence path (Copilot vs PAYG), and who may add the web part.
4. Let every page author pin any agent from the catalogue. Fast — and how “You don’t have access to this agent” becomes the intranet’s most common toast.

12 Panes action / comms: Tell Adoption: 575298 is a distribution channel for agents you already govern — approve the agent, then the page, not the other way round. Tell SharePoint admins: Page edit rights, .agent permissions, site permissions and RCD are the stack; the web part only makes bad combinations visible faster. Tell makers: If visitors can’t read the library, don’t put that agent on a public hub — fix knowledge scope or page audience. Security: Blocking in Copilot Chat alone is not enough for page-embedded agents until Microsoft extends that control — verify in Preview.

Benefits / risks: Intranet pages become intentional agent entry points instead of scavenger hunts for .agent files; Learn is thin on the web part itself until Preview docs land — don’t invent property-pane click-paths; overshare and access-error UX will show up in helpdesk tickets before dashboards; PAYG and Copilot licence mix on anonymous-feeling intranet pages needs FinOps clarity before scale.

I’d suggest a Steady Adoption spike before Preview: pick one hub page, one approved agent with matched knowledge permissions, document the editor shortlist, and ban “any agent” configuration on organisational home pages until the register says otherwise. Once editors have seen one clean embed and one broken-permission embed, sprawl gets much harder to argue for.

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