A SharePoint agent is a helper that only reads one shelf of your company's files. Anyone allowed to read that shelf can ask it questions.
Agents in SharePoint answer questions from the content of a site, a document library or chosen files. They respect permissions, so people only get answers from files they can open. People with a Copilot licence can use them, and so can others if the organisation pays per use.
Agents in SharePoint are scoped retrieval agents stored as .agent files, created by licensed users with add-file rights and grounded in selected sites, pages, libraries or files. Responses are permission-trimmed per user. Usage requires a Copilot licence or pay-as-you-go through an Azure-linked billing policy scoped to a security group.
What they are
Microsoft describes agents in SharePoint as AI helpers that "help users quickly find information and insights on SharePoint sites, pages, and document libraries". They access data the same way Copilot does elsewhere in Microsoft 365, "responding to users based on their access permissions to the data".
Each agent is saved as an .agent file on the site, and the permissions on that file decide who can open or edit the agent. You can scope an agent to a whole site, a library, a folder or particular files.
Who can make one, and who can use one
Microsoft's SharePoint admin page sets out the requirements. To create an agent, a person needs a Copilot licence and the ability to add new files to the site. To use one, they need a Copilot licence, or their organisation needs pay-as-you-go billing set up for them.
There's no activation step. Microsoft says that once a user has a licence, or pay-as-you-go is set up, the agents "automatically become available to the user on eligible sites where they have permissions".
The cost side of pay-as-you-go is covered in SharePoint agents on pay-as-you-go: who pays for what.
Permissions do the hard work
The most important design point is that the agent doesn't have its own access. Microsoft's guidance gives the example plainly: if a user can open the agent but not a library it references, that user's answers won't include content from that library.
That's reassuring, and it also means two people can get different answers from the same agent. A manager might get an answer that includes a restricted HR folder, while a new starter gets one without it. Neither would see a warning. When an agent is meant to give a consistent answer to everyone, its sources should be ones everyone in its audience can read.
Why I'd use one for decisions
Many routine decisions depend on a team's own documents: a process guide, a standard contract, last year's decisions. Those documents usually live on one SharePoint site. A site agent is the shortest route from "where's the rule for this?" to an answer that links back to the document.
Compared with Agent Builder, a SharePoint agent is narrower and closer to the content. Agent Builder can combine several kinds of source, such as websites, chats and email. A SharePoint agent is the right fit when the question is really "what does this site say?"
A worked example
This scenario is illustrative. A housing association's repairs team keeps its repair priority guide, contractor list and response time targets in one SharePoint library. Call handlers have to decide the priority of each repair request.
A team leader with a Copilot licence creates an agent scoped to that library and tells it to answer only from the priority guide and to quote the section it used. Call handlers, who are covered by the organisation's pay-as-you-go policy, ask questions like "Is a leaking pipe under a sink an emergency?" The decision stays with the call handler. The agent makes the rule quicker to find, and the quoted section makes it easy to check.
Keeping an eye on them
Microsoft says people with at least visitor access to the site can see an agent's file statistics, and SharePoint admins can monitor usage across the organisation using PowerShell, the Purview audit log, Azure Cost Management and SharePoint Advanced Management.
What I'm still checking
Microsoft's pages don't agree on who can create agents. The SharePoint admin page says creating needs a Copilot licence, while the Microsoft 365 agents admin guide says people can create them if the tenant has pay-as-you-go for SharePoint or they have a licence. I'd test it in your own tenant before telling unlicensed staff they can build agents.
Sources
- Microsoft Learn, Get started with agents in SharePoint, accessed 11 October 2026.
- Microsoft Learn, Manage access to agents in SharePoint, accessed 11 October 2026.
- Microsoft Learn, Agents admin guide for Microsoft 365, accessed 11 October 2026.