An Agent icon showed up in the global header of your SharePoint sites. Nobody in IT turned it on. Nobody bought anything. A week later a director asks whether the organization can “use the AI on our files” without paying for Copilot for all 80 staff.
Both of those are the same question, and Microsoft’s answer to the second one is yes, at about twelve cents a question.
The starting point is a single line in the documentation that explains why the icon appeared: “Agents in SharePoint don’t require activation.” There was never a switch to leave off. What you control is who can use agents, what they can reach, and where they show up, and that list is the whole of it.
What an agent in SharePoint is, and the four things it isn’t
Most of the confusion on this topic comes from four different products all being called agents. They have different makers, different billing, and different admin centres.
| Thing | What it is | Who makes one | What an unlicensed user pays | Managed from |
|---|---|---|---|---|
| Agent in SharePoint | An .agent file on a site, grounded in that site’s pages and libraries | Any site member who can create files | $0.12 USD per complex question, via pay-as-you-go | SharePoint admin centre + Microsoft 365 admin centre |
| Microsoft 365 Copilot Chat | The chat experience in the Copilot app, web-grounded by default | Nobody, it ships as-is | Nothing for the chat itself; agent usage inside it is metered | Microsoft 365 admin centre |
| Copilot Studio agent | A purpose-built agent with custom knowledge, tools, and actions | A maker with Copilot Studio access | Copilot Credits: 2 per generative answer, 10 for tenant graph grounding, 5 per agent action | Power Platform admin centre |
| Microsoft Agent 365 | A per-user governance and security control plane for all agents, generally available since May 1, 2026 | Not an authoring tool | Not applicable, it’s licensed per user and works best on E5 | Microsoft 365 admin centre |
Nearly everything written about “governing SharePoint agents” is actually about the last two rows. Agent 365 sits in the Microsoft 365 E7 bundle alongside E5, Copilot, and Entra Suite, which puts it well outside the reach of a 90-person nonprofit. The first row is the one that arrived in your tenant without a purchase order, and it’s the one this post is about.
One more detail worth holding: Copilot Studio renamed its billing unit from messages to Copilot Credits on September 1, 2025, with no change to the rate. The SharePoint documentation still says messages. They are the same unit.
Do you need a Copilot licence to use SharePoint agents?
No, but you need one of exactly two things.
Option one is a Microsoft 365 Copilot licence. Interactive use of generative answers and tenant graph grounding by a licensed user inside Microsoft 365 apps is included at no extra charge, so a licensed user’s agent questions never touch the meter.
Two different seats hide behind the word Copilot, and which one you can buy depends on what you already own. Microsoft 365 Copilot Business is the add-on for tenants on a Microsoft 365 Business plan, and it requires one; it lists at USD $21 per user per month on an annual commitment, currently promotional at USD $18 until September 30, 2026. Microsoft 365 Copilot, the enterprise add-on, lists at USD $30 per user per month annual. Canadian list prices checked August 3, 2026: Copilot Business CAD $28.50, promotional CAD $24.43; Business Premium with Copilot bundled, CAD $43.40.
For a 10 to 500 user Ontario organization sitting on Business Premium, the $21 seat is the one that appears on the quote, not the $30 one. That single distinction moves the break-even arithmetic below by about 30%, so check which line item your reseller actually put in front of you before you use anyone’s numbers, mine included.
Option two is pay-as-you-go billing. You register SharePoint agents as a resource in Azure, create a billing policy in the Microsoft 365 admin centre under Copilot then Billing & usage, and attach a security group. Microsoft’s wording on the scoping is the part that matters:
Only users in the security group assigned to the billing policy have access to SharePoint agents.
That sentence is doing double duty. It’s a billing control and an access control at the same time. If a user has no Copilot licence and isn’t in the group, they have no agent access, whatever the icon in the header suggests.
The prerequisites split across two role sets, on two different documentation pages, which is where people stall. Registering SharePoint agents as an Azure resource needs a SharePoint administrator plus Owner or Contributor on the Azure subscription and the resource group, and Microsoft notes you only need those Azure roles during setup. Creating the billing policy in the Microsoft 365 admin centre is a separate job needing Billing Administrator, AI Administrator, or Global Administrator. A SharePoint admin working alone gets halfway and stops.
The tenant also needs “at least one SharePoint license, or a license that includes SharePoint”, which in practice means every tenant already qualifies. You pick a region during policy creation, and that choice determines where the tenant ID and usage data are stored, which is the first question anyone in Ontario public sector will ask.
Current limits: one security group per billing policy, up to 10 policies. Microsoft says support for multiple groups per policy is coming, which is a fair way of saying it isn’t here yet.
What do SharePoint agents cost per use?
The published rate, from the Microsoft 365 pay-as-you-go pricing table:
| Service | What’s counted | Billed (USD) |
|---|---|---|
| Agents in SharePoint | Number of messages used | $0.01 per message |
And the number that makes it real:
Each interaction includes a question and an answer. A successful interaction uses 12 messages.
The separate billing page for SharePoint agents splits the 12 for you: 10 messages for tenant graph grounding, 2 for the generative answer. SharePoint agents are always grounded in the tenant graph, so you don’t get to shave the 10 off. That gives you $0.12 USD per complex question for an unlicensed user.
Now run it against a seat. Take Microsoft 365 Copilot Business at $21 USD, the seat an SMB on a Business plan actually buys. At $0.12 a question, $21 buys 175 questions in a month, or about 8 a working day, every working day, sustained. On the $30 enterprise seat the same arithmetic gives 250 questions, about 12 a working day.
Either number is a high bar. Most people asking a document library questions do it in bursts, a handful of times a week, when a specific thing needs finding.
Worked example, 40 staff, all figures USD per month:
| Scenario | Monthly cost |
|---|---|
| 40 people, 5 questions each per working day, 21 days: 4,200 interactions | $504 |
| 40 people, 1 question each per working day: 840 interactions | $101 |
| 40 Microsoft 365 Copilot Business seats at $21 | $840 |
| 40 Microsoft 365 Copilot seats at $30 | $1,200 |
Note what the top row survives. Even at five questions per person per working day, which is heavier use than most document libraries ever see, metered access still comes in under the cheaper seat.
Two caveats before anyone takes that to a budget meeting. The rate is published in USD and Azure bills your subscription’s currency, so apply your own exchange assumption rather than mine. And pay-as-you-go has no spending ceiling unless you set one, which is what the budget section below is for.
There’s a middle option if usage turns out steady. Copilot Studio capacity packs list at $200 USD per pack per month for 25,000 Copilot Credits, which works out to $0.008 per credit and roughly 2,080 SharePoint agent interactions per pack. Cheaper per unit, and Microsoft is explicit that unused credits don’t carry over to the next month.
One catch before anyone buys a pack. The credits do cover SharePoint agent usage, but the mechanism for scoping credits to particular people, the Copilot credit policy, is Copilot Chat only at the moment: “For SharePoint agents, continue using pay-as-you-go billing as described in the existing setup process.” A pack buys you a cheaper unit rate and a tenant-wide pool, not per-department control. If capping one team’s spend was the point of the exercise, the pay-as-you-go billing policy is still the only thing that does it.
Who can create an agent, and what can it see?
Agents in SharePoint are ordinary files. That single design decision answers most permission questions.
The permissions on the .agent file determine who can access or edit the agent. Only users who can create or access files on a SharePoint site can create or access agents.
So there’s no separate agent permission model to learn, and no approval workflow. Microsoft’s end-user documentation is blunt about it: all site members can create their own agents and use them. Agents don’t appear in any published list; people find the .agent file the way they’d find a Word document, or they use the one a site owner has pinned to the Agent icon in the global header.
The question everyone actually wants answered is whether an agent leaks. It doesn’t, in the direct sense:
Two people can open the same agent and get different answers, because they have different access. Nobody reads a file through an agent that they couldn’t open directly.
The security boundary holds, then. The governance problem is what’s left standing. Every permission an agent uses was already granted to somebody. What changes is how easily those grants get exercised. If someone was given Contribute on the finance library in 2022 by mistake and never once browsed to it, that grant has been dormant for four years. Give that person an agent and it stops being dormant; they now have a tireless reader working through everything the mistake entitles them to.
Pay-as-you-go makes this cheaper to do at scale than it has ever been. Adding 200 people to a security group costs nothing until they ask a question.
If you haven’t done a permissions pass, do that before you widen the group, not after. Turn on Copilot without leaking your HR folder has the sequence.
One gap worth knowing: you can’t yet apply a sensitivity label directly to a .agent file. Microsoft’s workaround is to write Purview DLP conditions against the .agent extension instead. For content, a DLP policy using Content contains then Sensitivity labels will exclude items from being processed, and the behaviour is specific: the citations in the response still list the item, but its content isn’t used in the answer.
The four places you can switch agents off
| # | Control | Scope | What it stops | What it also stops |
|---|---|---|---|---|
| 1 | ”Microsoft 365 Copilot for SharePoint” service plan | One licensed user | That user’s use of agents in SharePoint | Copilot in OneDrive and SharePoint page authoring Copilot for that user |
| 2 | Pay-as-you-go billing policy security group | Unlicensed users | All agent access for anyone not in the group | Nothing else |
| 3 | Restricted content discovery | One site | The Agent icon, agent creation, and that site’s content in any other agent | The site’s content in org-wide search and Copilot generally |
| 4 | Copilot Control System, Agents section | One agent | That agent, in Copilot Chat | Nothing, and that’s the problem |
1. The service plan. On the Microsoft 365 Copilot licence details page in the Microsoft 365 admin centre, you can toggle Microsoft 365 Copilot for SharePoint on or off per user. A user could keep Copilot in Teams and lose agents in SharePoint. The trade is real though: the same toggle also disables Copilot in OneDrive and the page authoring Copilot for that user. It’s one switch covering three things.
2. The billing policy group. For unlicensed users this is the whole access model. Keep the group small and named, review it like any other access group, and don’t reach for “All users” because it was quicker.
3. Restricted content discovery. The site-level kill switch, and the broadest of the four. Flag a site and users stop seeing the Agent icon in the global header on it, can’t create agents there, and can’t pull that site’s content into any other agent. Microsoft’s RCD page describes the effect more widely than agents alone: the Copilot button, the AI actions menus, and Create pages with AI all disappear from that site. The cmdlet:
Set-SPOSite -Identity <site-url> -RestrictContentOrgWideSearch $trueRCD does considerably more than block agents. It also pulls the site out of organization-wide search and Copilot responses, and Microsoft’s caution about overusing it still stands. The full read on where RCD helps and where it quietly hurts covers the tradeoff.
4. The Copilot Control System. Tenant admins and AI admins get an inventory of agents under Agents in the Copilot Control System (the section formerly called integrated apps) in the Microsoft 365 admin centre, with block and unblock on each one. This is the control most admins reach for first, and it’s the one that will mislead you.
Keeping the bill and the blast radius predictable
Consumption billing has one failure mode: nobody notices until the invoice. Three things worth doing on day one.
Set a budget on the billing policy. The Microsoft 365 admin centre lets you set a limit when you create the policy, choose whether it resets monthly, quarterly, or yearly, and send alerts at percentage thresholds to named groups. Default alert threshold is 100%, which is late; add 50% and 75%. Alerts can take up to 24 hours to arrive, so treat them as a trend signal and not a circuit breaker.
Know where the charge lands. Agent usage bills under the Copilot Studio meter on your Azure invoice, not under anything named SharePoint. Microsoft Cost Management shows the breakdown by feature, but whoever reconciles the invoice needs telling, or the first line item becomes a mystery.
Start the group small and grow it deliberately. One department, four weeks, look at the actual interaction count against the $0.12 arithmetic before you widen. Microsoft’s own advice on controlling consumption is to restrict access to sites with agents to the people who need them, which is the same advice as tidying permissions, arriving from the direction of the finance team.
That third one is where the two halves of this post meet. Every user you add to the billing group is a user whose entire existing access becomes conveniently searchable. Twelve cents a question is a rounding error on any budget you’re likely to have. A staff member reading a colleague’s performance review because a 2019 sharing link was never cleaned up is not, and no budget alert will tell you it happened.
Frequently asked
01 Can users create agents without me enabling anything?
Yes. Microsoft's documentation states that agents in SharePoint don't require activation. Any site member who can create files on a site can create an agent there, because agents are .agent files. What you control is who is allowed to use one: a Microsoft 365 Copilot licence, or membership of the security group attached to your pay-as-you-go billing policy. Without one of those, a user can see the icon but can't use the agent.
02 Can an agent see files the asking user can't open?
No. Responses are filtered by each user's own permissions to the underlying content. Microsoft's example: a user with access to the agent but not to the site or library it references gets responses that exclude content from those sources. Two people using the same agent can get different answers. No new access is created. What changes is that dormant wrong permissions become easy to exercise.
03 How do I stop agents on one site only?
Apply restricted content discovery to the site, either from the site's Settings tab in the SharePoint admin centre or with Set-SPOSite -Identity <site-url> -RestrictContentOrgWideSearch $true. Users then don't see the Agent icon in the global header on that site, can't create agents there, and can't add that site's content to any other agent. Note that it also removes the site from organization-wide search and Copilot, and it needs SharePoint Advanced Management.
04 Does blocking an agent in the Microsoft 365 admin centre stop it everywhere?
No. As of the June 25, 2026 documentation update, blocking an agent in the Agents section of the Copilot Control System "only affects its availability in Copilot Chat. It doesn't yet apply to OneDrive, SharePoint, or Teams." The agent keeps working on its SharePoint site. Use the service plan toggle, the billing policy group, restricted content discovery, or delete the .agent file.
05 Can I put a sensitivity label on a .agent file?
Not yet. Microsoft says you can't add a sensitivity label directly to an .agent file, and recommends writing Purview DLP conditions against the .agent extension instead. For the content an agent reads, a DLP policy on Content contains > Sensitivity labels excludes items from processing; the citation still appears in the response but the item's content isn't used.
What to actually do this week
If you want a defensible answer for the director who asked, it’s four short jobs and none of them need a project.
- Check whether pay-as-you-go is already connected. Microsoft 365 admin centre, Copilot then Billing & usage, Pay-as-you-go services. If SharePoint agents is connected to a policy, find out which security group is on it and when that was decided.
- Pick the pilot group before you pick the budget. One team, named group, four weeks. The interaction count you get back is worth more than any estimate, mine included.
- Run the oversharing reports first if you have SAM. Data Access Governance and the content management assessment exist so you don’t find out what’s overshared by watching an agent tell somebody.
- Write down which of the four off-switches you’d use, before you need one. The wrong answer under pressure is the admin centre block, because it looks like it worked.
On cost, my honest read: for an organization where a dozen people occasionally need to find something in a document library, pay-as-you-go beats seats by a wide margin, and it keeps beating them until someone starts using an agent as their main way of working. At that point they’ve earned a licence, and the invoice will tell you exactly who they are. That’s a better signal than any rollout plan built on guesses.
On risk, the framing is less comfortable. The icon is already there. The file permissions already decide everything. The only reason any of this feels new is that agents make old permission mistakes productive, and fixing those was on the list well before agents arrived. If Restricted SharePoint Search was your holding measure, that option closed on July 31, 2026, so the permissions work is now the route through rather than one of two.