When agents in SharePoint quietly showed up in tenants this autumn, the questions I got right away weren't about features. They were about what this means in practice. Every site now has a built-in agent that answers questions about its content, lists, documents and layout, and it stays limited to that site and its permissions. If you already work with Copilot, this feels like the obvious next step. The risks, though, are far more concrete. Oversharing in SharePoint used to mean someone stumbling on a file. Now an agent can surface or summarise everything that's accessible in a site, including content most users forgot about years ago.

Each site agent sees exactly what the user can already see, so permissions matter again

This is the core point. A site agent only knows what the user would see anyway, and it follows SharePoint's permission model strictly. That lines up with Restricted SharePoint Search (/blog/restricted-sharepoint-search-copilot-oversharing), with one difference. Users with edit rights can now create .agent files, which are custom agents built for specific tasks or datasets, and share them, even in Teams chats. The scope still comes from the site's permissions, always. In the tenants I work with, this brings access reviews back into focus, along with those old legacy sites where "Everyone" still has access. If a site is too open, its agent is too.

Here's a simple flow showing how SharePoint agents enforce this permission boundary:

flowchart TD
User["User asks question"] --> Agent["SharePoint Agent"]
Agent --> AuthZ["Permission check (site)"]
AuthZ --> Data["Access site content"]
Data --> Response["Generate answer"]
Response --> User

Figure: The agent only processes site content the user is allowed to access.

I'm seeing more admins take a second look at their oversharing risks and use tools like SharePoint Advanced Management for regular permission reviews. Once other people can build a custom agent in a shared site, having those controls in place pays off quickly. If you've already rolled out Restricted SharePoint Search, the same governance thinking applies. The difference is that users can now get answers about forgotten legacy documents too, so more is at stake.

Users without Copilot can use shared agents on a pay-as-you-go basis

One change I find particularly interesting is that users can share custom agents directly in Teams chats. Technically, the agent file is referenced from SharePoint, and processing stays scoped to the original site and governed by its permissions. Still, access to agents can now spread across your organisation with a single click.

For users without a Microsoft 365 Copilot licence, things are still moving. They can use SharePoint agents, but that usage is billed pay-as-you-go (metered and charged at tenant level). I've seen tenants caught off guard by these costs when an agent suddenly became popular. Licensing and billing are still settling, so check the admin center and the official documentation for the current details.

Practical tip: If you have a lot of guests or external users, limit which sites have agents enabled before it becomes a problem. Keep an eye on possible pay-as-you-go charges for unlicensed users, and use the admin controls to turn agents off where necessary.

The SharePoint admin center lets you approve or block agents centrally

The SharePoint admin center has picked up a few new tabs for agents. You get a list of every agent in your tenant, who created and shared it, and its approval status. Admins can approve or block individual agents centrally, for example when a custom agent turns up that doesn't meet compliance requirements. It's similar to the governance patterns in Copilot Studio (/blog/copilot-studio-governance-power-platform-dlp), only now it sits inside SharePoint itself.

At the moment, these are the controls that matter most:

  • One view of all agents and their sharing status
  • Central approval or blocking of agents
  • Usage and activity reports in the admin center
  • Agent policies you can configure per site

With SharePoint Advanced Management, you get more detailed insight and can enforce agent-related policies across many sites.

Content quality and scope make governance harder than before

A SharePoint agent is only as useful as the content behind it: structured, current and properly permissioned. If a site is a graveyard of outdated files or a pile of random documents, its agent will give confusing or misleading answers. My usual recommendation is to find the sites with good content and clear ownership, enable agents there and watch how they're used. In legacy or ungoverned sites, disable or restrict them. Combining Restricted SharePoint Search with agent controls is the most reliable way to avoid exposing data by accident.

I think SharePoint agents need real governance

Agents in SharePoint are among the most visible changes from Ignite 2024, but they won't fix anything on their own. If your permissions or content haven't been cleaned up, you'll notice very quickly. For me, this is the year permission hygiene, reporting and content lifecycle management stop being optional. The controls exist. They just only help if we actually use them.