SharePoint agents are AI assistants built from SharePoint sites, libraries and files, and saved as .agent files. Anyone with a Microsoft Copilot (formerly Microsoft 365 Copilot) licence and edit rights can create one, and each agent answers only from content the person asking can open. Governing them means deciding where they belong, who owns them and when they go.
They spread easily because nothing needs switching on and no admin approves them. A project team can build an agent on a site, share the link in a Teams channel and move on, leaving nobody clearly responsible for it a few months later. Our Microsoft AI governance approach asks the same questions of Copilot Studio agents and the rest of Microsoft Copilot.
This article stays on SharePoint agents from start to finish: creation, access, switching them off and what admins can see. Two related topics have their own articles: Microsoft Agent 365 explained for Microsoft's control plane across all agents, and Power Platform governance for Copilot Studio for agents built by makers.
What are SharePoint agents?
A SharePoint agent is a file. Microsoft uses both names, "agents in SharePoint" and "SharePoint agents", for assistants scoped to the content their creator picks: a whole site, a library, folders or individual files. When someone creates an agent from a site's home page, the .agent file is saved under Site contents, Site Assets, Copilots. From a library or a list, it lands in the current folder or list (Create an agent in SharePoint).
Because the agent is a file, it follows file rules. The permissions on the .agent file decide who can use it and who can edit it (Manage access to agents in SharePoint). Agents do not appear in any published list by default: people find them like any other file, or through a link someone shares. Site owners can also choose one main agent for their site, which opens from the Agent icon in the site header.
Copilot in SharePoint is a different product
Copilot in SharePoint is the assistant built into SharePoint, generally available from late September 2026 and managed per site through Site AI settings and Restricted Content Discovery (Get started with Copilot in SharePoint). A site owner chooses which one opens from the Agent icon: Copilot in SharePoint or a custom agent.
In this article, "SharePoint agents" means the .agent files your users create. Keep the two apart when you read Microsoft's documentation: a setting written for Copilot in SharePoint does not necessarily govern .agent files, and the reverse is also true.
Who can create and use SharePoint agents?
People with a Copilot licence can create agents from SharePoint sites and files, and nothing needs to be activated first. To create one on a site, a person needs edit permissions on that site (Create an agent in SharePoint). Only people who can create or open files on a site can create or use agents there.
Using an agent works the same way, with one extra route. Users without a Copilot licence can create and use SharePoint agents if the organisation sets up pay-as-you-go billing, limited to a security group: only members of that group get access, and the billing is set up as a resource in Azure. Treat membership of that group as a budget decision, with a named owner.
Admins can also turn off the "Microsoft Copilot for SharePoint" service plan for a given user. That removes agents in SharePoint for that person, but it also turns off Copilot in OneDrive and the Copilot help for writing SharePoint pages. It is a blunt tool, best kept for specific cases.
What can a SharePoint agent see?
A SharePoint agent only answers from content the person asking can already open. It works like Microsoft Copilot itself, which only shows people content they can open (Microsoft Copilot privacy). If a user can open the agent but not the library it points to, their answers leave that library out.
Three consequences matter for admins:
- Two people can ask the same agent the same question and get different answers. The agent does not widen or narrow anyone's access.
- Sharing an agent shares a link, not the content behind it. Sending the link to a Teams chat does not change permissions on the sources, and an agent does not answer in a chat or channel that includes guests or external users (Share an agent from SharePoint in Teams).
- Overshared content becomes easier to find. A library shared with the whole organisation years ago is now one question away. Fixing that comes first, and our article on SharePoint Advanced Management walks through the reports and reviews that help.
Sensitivity labels and Microsoft Purview DLP can keep chosen files out of agent answers: the citation still shows, but the content is not used. As of October 2026, Microsoft's documentation says a .agent file cannot carry a sensitivity label itself. To govern the agent files with DLP, build the condition on the .agent extension (Manage access to agents in SharePoint).
How do you switch SharePoint agents off on a site or for some users?
Restricted Content Discovery is the site-level lever. Once a SharePoint admin applies it to a site, the Agent icon disappears: nobody can use the ready-made agent, create a new one there or add the site's content to another agent. Site access does not change (Manage access to agents in SharePoint).
Know what else it does before you use it. Restricted Content Discovery also keeps the site out of Copilot and organisation-wide search, and Microsoft describes it as a temporary control while permissions are fixed (Restricted Content Discovery). It suits a sensitive site that is being cleaned up. Give each restricted site an owner and a date to review the restriction.
The other levers Microsoft documents work per user or per surface:
- Per user: the Copilot licence, the "Microsoft Copilot for SharePoint" service plan, or membership of the pay-as-you-go security group.
- In Copilot Chat: the Microsoft 365 admin center lists the SharePoint agents used in Copilot Chat and lets admins block them. As of October 2026, Microsoft documents that this block applies to Copilot Chat only, not yet to SharePoint, OneDrive or Teams (Manage access to agents in SharePoint).
Build your plan on these levers and write down which one you use for which case.
Where do admins see SharePoint agents?
SharePoint agents show up in three places, each answering a different question.
- SharePoint admin center reports. Agent insights lists the agents created recently on SharePoint and OneDrive sites, from the audit log, and the sites that host the most. From the report, admins can apply Restricted Access Control or Restricted Content Discovery to a site (Agent insights). Agent access insights shows how agents, SharePoint agents among them, read content on each site (Agent access insights). Both cover windows of 1, 7, 14 or 28 days.
- The Agents section of the Microsoft 365 admin center. It shows the SharePoint agents used in Copilot Chat, with their details and the option to block them there.
- The agent registry. The Microsoft 365 admin center has an agent registry that lists the agents available in your organisation, with SharePoint among the channels you can filter on (Agent registry). Microsoft is bringing its registries together under Agent 365, which lists agents in one place, including agents that have no Microsoft Entra identity (Agent registry convergence). Microsoft's SharePoint documentation does not say that every .agent file appears in the registry, so use the SharePoint reports for the site-by-site view.
Decide who reads which view, how often, and what finding starts a review.
Which rules are worth setting before SharePoint agents spread?
Microsoft does not ask you to approve agents for a site (Manage agents in SharePoint), so any approval step is one you design. Agent sprawl on SharePoint is mostly a question of ownership and scope, and a handful of rules covers it:
- Decide where agents belong. Most sites can host them. Sites with sensitive content under clean-up get Restricted Content Discovery, with a review date.
- Name an owner for every agent. In practice, the owner is whoever controls the .agent file's edit permissions. Record a person, not a team mailbox, and a backup.
- Check sources before wide sharing. An agent pointed at a confidential library deserves a second look before its link goes to a large channel.
- Keep sensitive files out of answers. Use sensitivity labels with Purview DLP on the libraries that matter, and a DLP condition on the .agent extension if you want to govern the files themselves.
- Agree how agents are shared. Links in Teams are fine, but an agent does not answer at all in a chat or channel that includes guests or external users, so explain that to owners of shared channels.
- Review activity and retire. Use Agent insights and Agent access insights, which look back up to 28 days, to see which agents are created and which read content; ask the owner about the rest and remove what nobody needs.
- Control access without a seat. If you use pay-as-you-go billing, give the security group an owner and a review, like any other paid access.
SharePoint agents: the questions to settle
Microsoft provides the controls; your rules decide how they are used.
| Question | Microsoft control | What to decide |
|---|---|---|
| Who can create agents on a site? | Edit permissions on the site, plus a Copilot licence or pay-as-you-go access | Which sites welcome agents, and who may edit there |
| Should a site have agents at all? | Restricted Content Discovery, which also keeps the site out of Copilot and organisation-wide search | Which sites stay agent-free, and when the restriction is reviewed |
| Who can use agents without a Copilot seat? | Pay-as-you-go billing limited to a security group | Who joins the group, and who owns the budget |
| What can an agent answer from? | Each user's permissions, sensitivity labels and Microsoft Purview DLP | Which files must stay out of answers |
| Who owns an agent? | Permissions on the .agent file | A named owner and a backup for every agent |
| Where are agents created and used? | Agent insights and Agent access insights in the SharePoint admin center | Who reads the reports, and what triggers a review |
| Can people use an agent in Copilot Chat? | Agents section of the Microsoft 365 admin center, block for Copilot Chat | Which agents to block there, knowing that in October 2026 the block covers Copilot Chat only |
How Neptune helps with SharePoint agents
Neptune is an integrator. We select the governance tool that fits your tenant and licences, implement it with your team, train your admins and site owners, and stay with you after go-live. We configure Microsoft's controls first: Restricted Content Discovery where it is needed, blocks in Copilot Chat, and the SharePoint admin center reports.
The governance layer then adds the daily follow-up:
- SharePoint agents are listed site by site with their owner and activity, including sites where agents pile up with nobody accountable.
- Every Copilot Studio and SharePoint agent gets a named owner, and agents nobody uses are retired once the owner confirms.
- Agents are governed alongside the teams, sites and permissions they use, so a cleaned-up site and the agents built on it are reviewed together.
- Copilot Studio agents that read SharePoint sites are checked: connectors used by each agent, and agents shared with the whole organisation without approval are flagged and sent to the owner.
If oversharing is still open, the Copilot readiness work runs alongside. To see how the rules and owner reviews run in practice, read our AI governance page or contact us.
Sources
- Manage access to agents in SharePoint
- Create an agent in SharePoint
- Manage agents in SharePoint
- Share an agent from SharePoint in Teams
- Get started with Copilot in SharePoint
- Restricted Content Discovery
- Insights on agents in SharePoint
- Insights on agent access
- Agent registry in the Microsoft 365 admin center
- Agent registry convergence
- Microsoft Copilot privacy and data
