Copilot agents explained declarative vs custom engine (and which you actually need)

Everyone is building Copilot agents now, and the first fork you hit is a confusing one: a declarative agent, or a custom engine agent? The names do not help, and most explanations bury the answer under a feature table. So here is the distinction that actually decides it, and it comes down to a single question: whose engine runs the thing.

What an agent even is

Strip away the jargon and an agent is a specialized version of Copilot. You give it instructions, some knowledge to draw on, and maybe a few actions it can take, and it shows up where your users already work in Teams, in Word, in the Copilot chat. An IT helpdesk agent that answers from your policies. A sales agent that pulls from your CRM. The two types are simply two different ways of powering that.

The one distinction that matters

The single thing that separates them is whose orchestrator and model does the reasoning.

A declarative agent runs on Copilot’s engine. You bring the instructions, the knowledge and the actions; Microsoft brings the orchestrator, the foundation model, the hosting and the compliance. You are not building an AI so much as configuring Copilot’s.

A custom engine agent runs on your engine. You bring the orchestrator, the model and the hosting, typically on Azure. You are building an AI application that plugs into Copilot’s surfaces, rather than borrowing Copilot’s brain.

Everything else the cost, the compliance, the flexibility — follows from that one choice.

What follows from it

Because a declarative agent rides on Copilot’s infrastructure, it needs no extra hosting and carries no extra hosting bill, and it inherits Microsoft 365’s security, compliance and responsible-AI guarantees automatically. The trade is that you are limited to Copilot’s model and orchestration you cannot swap in your own and the agent responds only when a user talks to it.

A custom engine agent gives all that flexibility back, and hands you the responsibilities with it. You choose the model, any model, and write the orchestration for whatever complex, multi-step logic you need. It can act proactively, without a user prompting it, and coordinate with other agents. But it lives on hosting you pay for, and the compliance, security and responsible-AI work is now yours to prove, not Microsoft’s to guarantee.

Tooling is not the dividing line

People assume the split is low-code versus pro-code. It is not. A declarative agent you can build with no code at all, in the Agent Builder that sits inside Copilot, or in code with the Microsoft 365 Agents Toolkit. A custom engine agent you can start low-code in Copilot Studio, or go full pro-code in Visual Studio with .NET or Python, Semantic Kernel or LangChain.

So the dividing line is whose engine, not which tool.

Which one to build

Start with the scenario.

Build declarative when the work lives inside Microsoft 365 and Copilot’s own intelligence is enough. A helpdesk agent that answers @mentions in a Teams channel from your IT policies. A document agent invoked in SharePoint to summarise a library. You want it fast, you want it to inherit compliance, and you are happy with Copilot’s model. This covers most of what organisations actually want, and it is where I would tell almost anyone to start.

Build custom engine when declarative genuinely cannot do it. When you need custom orchestration for real business logic a loan-approval agent with rules and multiple system checks. When you need your own or a domain-specific model. When the agent must act proactively, serve a whole group in a Teams channel, or live outside Microsoft 365 as well. These are real needs, but they are the exception, not the default.

The rule of thumb

It writes itself: start declarative, and reach for a custom engine only when you hit a wall declarative cannot clear. Because the moment you go custom engine, you have signed up to own the model, the hosting and the compliance indefinitely — the same trade you make when you build a custom connector instead of using a prebuilt one. Ownership is powerful and expensive, and you want to be sure you need it before you take it on.

The part that quietly goes wrong

One thing holds true whichever you build, and it is worth saying because it is where agents most often go wrong. An agent’s knowledge is grounded in your content through the same permission-trimmed retrieval that Copilot itself uses. Which means an agent is only ever as safe as the access underneath it.

Point a helpful helpdesk agent at an overshared SharePoint site and it will cheerfully answer from whatever that site overshares. The agent did not create the exposure. It just gave it a friendly conversational front door. It is the same lesson as everywhere else Copilot reaches, on a new surface and it is why agent sprawl is the next governance problem worth watching.

So the declarative-versus-custom-engine decision looks like an architecture choice, and it is one. But underneath, it is a question about how much you want to own: Copilot’s engine, or your own. For most scenarios, theirs is the right answer, and the right place to start. Build custom only when you have a reason you can name.

August 4, 2026 by Copilot Microsoft 365 0

Contributor is not enough why your permission audit is only as good as the account running it

You inherit a permission audit script, point it at the tenant, and it comes back with a tidy report. A few overshared sites, nothing catastrophic. You sign off on the Copilot rollout. And the report may be lying to you in a way that has nothing to do with the script, and everything to do with the account you ran it under. Because in SharePoint, reading permissions is itself a permission. If the account running your audit did not have it, the report is not showing you the site’s permissions. It is showing you the ones your account was allowed to see.

Reading permissions is a permission

SharePoint has a specific right called Enumerate Permissions. Microsoft defines it plainly: it lets you “enumerate permissions on the website, list, folder, document, or list item.” That is precisely what an audit does, so that is the right your audit needs.

Here is the part that catches people. Of the standard permission levels, exactly one includes Enumerate Permissions: Full Control. Not Contribute. Not Edit. Not Read. An account at any of those levels cannot enumerate the permission structure, full stop. Ask it to through the UI, or through PnP PowerShell and you get access denied on every scope it does not fully control.

What that does to a scan

Picture the common setup: an audit run under an account that is a member of the sites, or a SharePoint Admin who never added themselves as Site Collection Administrator, or plainly a Contributor. On every scope that account does not have Full Control over, the call to read role assignments fails. The script then does one of two things, and both are bad.

It errors, you skip the site, and the site quietly drops out of the report. Or it swallows the error and returns nothing for that scope, and the site shows up looking clean. Either way, “no unique permissions found” can mean “there are none” or “I could not see them” and the report does not tell you which.

This is worse than missing a route. A script that reads all five ways access arrives is still blind if it runs under the wrong account. Missing a route is a bug you can fix. Reporting confidently on a site you could not actually read is a report that manufactures false confidence.

The only account that sees everything

The account that reliably sees the whole picture is a Site Collection Administrator, because an SCA has full access to everything in the site collection. And this is the trap for tenant-wide scans: being a SharePoint Administrator in the admin center does not make you Site Collection Administrator on every site. You have to add yourself, per site, or run the audit under an app-only identity granted the rights to enumerate everywhere.

If you did neither, your “tenant-wide” scan silently skipped every site you were not admin on, and reported confidently on the handful you were.

Where it gets sharper

Now remember where the riskiest access actually lives. Sharing links do not add people to a site group; they create per-item scopes held in system groups. In Microsoft’s own words, when you share a link with everyone in your organization, SharePoint grants access through a group called the “Limited Access System Group.” Enumerating those scopes needs the very Enumerate Permissions right your under-privileged account lacks.

So the access most likely to be overshared  the sharing links that are not per-user grants  is precisely the access a Contributor-level scan is least able to see. The blind spots compound.

How to do it right

Two rules fix most of this.

First, run permission audits as a Site Collection Administrator on every site in scope, or under an app registration with the rights to enumerate everywhere. Never as a member, never as a Contributor.

Second, make the script fail loudly. An access-denied on a scope is not a pass; it is a finding. A permission audit that silently treats “I couldn’t read this” as “this is fine” is worse than no audit, because it hands you confidence you have not earned.

The question to ask

So before your next Copilot rollout, do not just ask what your permission audit reported. Ask what account it ran under. A report is only ever as complete as the rights of the identity that produced it — and in SharePoint, seeing permissions takes the highest right there is. Run your audit as a Contributor, and “clean” does not mean clean. It means blind.

That is the first question worth asking of any tool that reports on access, including the free ones I build: what identity does it run under, and can that identity actually enumerate everything? User Access Explorer is built to run with rights that can see the whole picture  because a “nothing found” is only worth trusting when you know something was actually looking.

August 4, 2026 by Copilot SharePoint Online 0

No prebuilt Copilot connector for your system? Check this before you build custom

You checked the connectors gallery, and your system is not in it. Documentum. iManage. An OpenText archive. An on-premises SharePoint farm nobody wants to talk about. So the plan forms: we will have to build a custom connector.

Stop for a moment. Between “Microsoft does not have one” and “we build our own” sits a step most people skip entirely, and it very often ends the search before it starts.

A connector can come from three places, not two

There are really three sources of a Copilot connector. There are the hundred-plus Microsoft-built ones in the gallery. There is custom development, which you own forever. And sitting quietly between them is the one people forget: the partner-built gallery.

The gallery people skip

Microsoft maintains a separate gallery of connectors built and supported by partners. These are not Microsoft’s connectors. They are developed, licensed and supported by the partner, and the support models vary from one to the next. Some carry a Certified for Microsoft 365 Copilot badge, which means Microsoft validated them for consistent retrieval behaviour across Copilot and Search.

The publishers are the names that have spent years in enterprise search: BA Insight, now part of Upland; RheinInsights; Accenture, with its Aspire connectors; ServiceNow; and the source vendors themselves. You find the connector in the gallery, then go to the partner to license and deploy it.

The range is wider than you think

And it covers far more than the Microsoft-built list. Between the partners, the gallery reaches Documentum, iManage, NetDocuments, OpenText Livelink, IBM Content Manager, Elasticsearch, on-premises SharePoint from 2013 through Subscription Edition, Notion, Slack, Trello, Google Drive, and a long list beyond. If your source is a mainstream enterprise system, the odds are good that someone has already built, and now maintains, a connector for it.

The example everyone reaches for

Take Documentum, the one people always name. There is no Microsoft-built Documentum connector. But there are several partner ones: BA Insight ships a Documentum connector and a Documentum Cloud connector, and Accenture’s Aspire has a Documentum DQL connector, with more vendors beyond.

Here is why that matters more than it first looks. The genuinely hard part of a Documentum connector is mapping Documentum’s permission model onto Graph ACLs, so that Copilot only ever surfaces content to the right people. The partner has already solved that, and maintains it. That is precisely the ownership burden I warned about with custom connectors, handed to a company whose whole business is carrying it.

If nobody has built it, is Microsoft about to?

When no connector exists yet, the next question is whether one is coming. Three places tell you:

  • The Microsoft 365 Roadmap, where you can filter for Copilot connectors and see what is planned or rolling out.
  • The connectors gallery in your own admin center, where connectors in the Admin Preview state are the live preview pipeline, arriving before general availability.
  • The monthly “What’s New in Microsoft 365 Copilot” posts, where new connectors are announced as they ship.

The catalogue grows every quarter, so a source missing today may be a click away in two.

The honest catches with partner connectors

Partner connectors are not free of trade-offs, and you should go in clear-eyed. You are taking a dependency on a third party: their price, their support quality, their release cadence, their survival. Support models vary, so read what you are actually getting. Favour the ones certified for Copilot where you can. And because the connector is doing the ACL mapping on your behalf, validate that it gets the permissions right before you trust it in front of Copilot, the same scrutiny you would give your own code.

With those checks done, a partner connector is almost always the better deal than building and owning your own.

The order to work through

So the search order is not “Microsoft-built, then custom.” It is four steps:

  1. Microsoft-built — the hundred-plus in the gallery.
  2. Partner-built — the gallery people skip.
  3. Roadmap and preview — wait, if something is close.
  4. Custom — only when the source is genuinely unique to you.

Custom belongs at the bottom of that list, not second on it.

The instinct to build is a developer’s instinct, and it is often the expensive wrong turn. Before you scope a project to connect some system to Copilot, spend an hour in the partner gallery. The connector you were about to spend a quarter building, and then own for as long as the source exists, may already be sitting there, maintained by a company whose entire job is to maintain it. Build last, not second.

August 3, 2026 by Copilot Microsoft 365 0

Custom vs prebuilt Copilot connectors when to actually build your own

Sooner or later, the prebuilt catalogue runs out. You go looking for a connector to bring some system into Copilot, and it is not there  because the system is homegrown, or niche, or something a vendor built for you a decade ago. Now you have a choice: build a custom connector, or find another way in. Having built several, here is how I decide  and it is not the question most people start with.

Two paths, and where the cost hides

There are two ways to get external content into Copilot. A prebuilt connector, which you configure in the admin center with credentials and a schedule while Microsoft’s service does the work. And a custom connector, which is a software project: a developer defines a schema, registers an app in Microsoft Entra ID, and writes code to pull content from the source and push it into the Microsoft Graph through the connectors API.

The first is configuration. The second is development. That distinction is where people underestimate the cost.

The build is not the expensive part

Writing a custom connector is not, honestly, that hard for a competent developer. The schema, the app registration, the crawl-and-push code  you can stand up a working connector in a sprint. That is why “can we build it?” is the wrong question to lead with. You almost always can.

The expensive part is not the build. It is the ownership.

What ownership actually means

A prebuilt connector, Microsoft owns forever. When the source’s API changes, they fix it. When throttling limits shift, they handle it. When the schema needs a new field, they ship it.

A custom connector, you own all of that, indefinitely:

  • the incremental crawl logic, so you index only what changed instead of re-crawling the world every night;
  • throttling and retry, so a large source does not rate-limit you into failure;
  • error handling and monitoring, so you know when it silently stops;
  • keeping up with the connectors API as it evolves;
  • and the mapping of the source’s permissions onto Graph ACLs.

That last one deserves its own paragraph, because it is where custom connectors most often go wrong.

The ACL mapping is the hard bit

The whole point of a connector is that every item it indexes carries an access control list, so Copilot only ever surfaces content to the people who should see it. For a prebuilt connector, Microsoft worked out how the source’s permission model maps onto Graph ACLs, and maintains that mapping. For a custom one, you do.

And it is genuinely hard. You have to translate the source system’s groups, roles and sharing into the identities and ACLs the Graph understands — correctly, for every item. Get it too loose and you have just overshared a whole new system into Copilot. Get it too tight and the content is invisible and the connector is pointless. There is no forgiving middle where “roughly right” is fine, because Copilot will faithfully honour whatever ACLs you hand it.

On-premises: the connector agent

If the source lives on-premises, behind the firewall, there is a specific piece to know about: the Microsoft Graph connector agent. It is a Windows service you install on a server inside your network that acts as the secure bridge between your on-prem data and the connector APIs.

Two practical facts shape your design. One agent instance is recommended for up to three connections before performance degrades. And the agent authenticates through an app you register in Entra ID which brings us to the lesson that is never in the quick-start.

The gotcha that takes things down quietly

That Entra app authenticates with either a client secret or a certificate. Client secrets expire.

When the secret behind your connectors expires and nobody renewed it in time, every connection that relies on it stops indexing at once. It is a silent outage: nothing errors in anyone’s face, the content just quietly goes stale, and you find out weeks later when someone asks why Copilot no longer knows about last month’s tickets.

Two things save you. Use a certificate rather than a client secret, because it can be valid for years instead of months. And whichever you use, put the expiry in a calendar with a reminder well ahead of the date, because a connector platform gives you no grace period. This is exactly the class of expiry that takes down more than you expect, precisely because a single shared credential can sit behind several connections at once.

The decision is not “can we”

So the question is not “can we build it.” You almost always can. The question is “do we want to own it.”

Use a prebuilt connector whenever one exists every time because the maintenance you are handing to Microsoft is the expensive, unglamorous, never-ending part. Build custom only when two things are both true: the source genuinely is not supported, and it matters enough to justify owning a piece of indexing infrastructure for as long as the source exists.

And bear in mind the catalogue only grows. Every quarter, Microsoft and its partners add connectors, which means the set of sources that truly need custom work shrinks every year. Build custom for the genuinely unique the systems only your organization runs. For everything else, the out-of-the-box connector is the better deal. Not because it is easier to start, but because someone else carries the weight you would otherwise carry forever.

August 3, 2026 by Copilot Microsoft 365 0

Copilot connectors (formerly Graph connectors) the 100+ you get out of the box

Copilot is only as useful as the content it can reach. Out of the box, it reaches your Microsoft 365 — SharePoint, mail, Teams. But most organisations’ knowledge does not all live in Microsoft 365. It is in ServiceNow, in Salesforce, in a Confluence wiki, on a file share, in some homegrown app the finance team relies on. Copilot connectors are how you bring that content in. And before you assume that means a development project: Microsoft ships more than a hundred of them, ready to configure without a line of code.

First, the name changed

What used to be called Microsoft Graph connectors are now Microsoft 365 Copilot connectors. Same technology, a new label that reflects where the content ends up. A connector defines a connection to an external system and brings its content into Microsoft 365, so that Copilot and Microsoft Search can reason over it alongside your SharePoint sites and email.

Two kinds: synced and federated

There are two flavours, and the difference matters.

Synced connectors crawl the source and index its content into Microsoft Graph, so it becomes part of your search index. They are organisation-wide and configured by an admin.

Federated connectors do not index anything. They fetch results live from the source at query time, over the Model Context Protocol, which suits sensitive or fast-changing data you would rather not copy into Microsoft 365. They are per-user, and the user authenticates to the source themselves.

Most of the classic “get our other system into Copilot” scenarios are synced. That is the model the rest of this covers.

The hundred-plus you already have

Here is the part that saves you a development budget. Microsoft and its partners ship over a hundred prebuilt connectors, and between them they cover most of what a typical organisation runs:

  • Files and content: Box, Dropbox, Google Drive, Confluence, MediaWiki, network file shares
  • Enterprise apps and databases: Salesforce, ServiceNow, Dynamics 365, SAP, SQL and Oracle databases, Azure services
  • And a long tail beyond: Workday, Zendesk, Jira, and more

To use one, you pick it in the Microsoft 365 admin center, give it credentials and a bit of configuration, and Microsoft’s connector service handles the crawling and indexing from there. No schema to define, no code to write, no app registration to build. Microsoft and its certified partners maintain and update them. You will need the AI administrator role to set them up.

How a synced connector actually works

Under the hood, a synced connector ingests each item into the Microsoft Graph index with three things attached: the content, its metadata such as title and URL, and — the important one — an access control list.

That ACL is what makes the whole thing safe. Copilot and Search only ever show a connector item to users who have permission to it in the source system. The connector also keeps itself current, periodically checking the source for new, changed and deleted content on a schedule you control. The indexing pipeline runs in Microsoft’s cloud, and the content is stored in your own tenant.

Where the content shows up

Once a connector is running, its content appears in the places your users already work:

  • In Copilot Chat, where a question like “summarise the Contoso deal” can pull the answer from a connected Salesforce record and cite it, without the user ever opening Salesforce.
  • In Copilot Search, which includes connector content automatically, with no extra setup.
  • In Microsoft Search across Office.com, SharePoint, Outlook, Teams and work Bing, where external results appear alongside internal ones, each labelled with its source.
  • As a knowledge source for custom agents you build in Copilot Studio.

The point of a connector is that the knowledge stops being trapped in a system nobody thinks to open.

When out of the box is not enough

Microsoft’s own rule of thumb is the right one: use a prebuilt connector whenever one exists, and reserve custom development for the sources that genuinely need it.

A custom connector is a real project. A developer defines a schema, registers an app in Microsoft Entra ID, and writes the code to pull content from the source and push it into the Graph. That is the right call for a homegrown or unusual system with no prebuilt option — I have built several for exactly that reason. But if your source is one of the hundred-plus already in the gallery, building your own is effort you do not need to spend. For on-premises sources, there is a middle path: the Microsoft Graph connector agent indexes local content without exposing it to the internet.

The permissions catch

One thing worth flagging, because it is the same lesson as everywhere else Copilot reaches. A connector respects the source’s permissions through that per-item ACL, which is exactly what you want. But it also faithfully reproduces the source’s oversharing. If a Confluence space or a file share is open to everyone, the connector will index it that way, and Copilot will surface it to everyone — just as it does for an overshared SharePoint site. The connector is not the exposure. The source’s permissions are. Get those right before you index, not after.

So before you assume that getting your other systems into Copilot means a development budget, open the connectors gallery in the admin center and look. There is a good chance the system you had in mind is already there, waiting for credentials and a crawl schedule. Start with what is out of the box, and build custom only for what genuinely is not.

The Copilot connectors gallery in the Microsoft 365 admin center, showing prebuilt connectors by category (Azure DevOps, Confluence, ServiceNow, Jira, and more) with Add buttons.

August 3, 2026 by Copilot Microsoft 365 2

A sharing link is not a per-user grant (and why your access report is lying)

You run a report to answer a simple question: who can access this site? It comes back reassuring — a handful of members, the owners you expected, nothing alarming. So you sign off on the Copilot rollout. And the report was lying to you. Not because it got the answer wrong, but because it was looking in the wrong place. The access that actually leaks content lives somewhere your report never checks. It lives in sharing links, and a sharing link is not a per-user grant.

What your report actually checks

Every “who has access” report — the ones built into SharePoint, and most of the scripts people write themselves — works the same way. It enumerates role assignments: who is an owner, member or visitor; which security groups are attached to the site; who was granted permission directly. That is the membership model, and it is a fair picture of how access is supposed to work.

It is not how a lot of access actually happens.

What a sharing link actually is

When someone shares a file or a folder, SharePoint does not add them to a site group. It creates a shareable link with permission to that one item. Behind the scenes, that breaks the file’s inheritance from the library and gives it a unique permission scope of its own — a hidden sharing-link grant attached to the item, entirely separate from the site’s membership.

The access is real. It is just held in a place your site-and-group report does not read.

Why it is invisible to a per-user check

It gets more slippery when you look at the three kinds of link, because each one hides in a different way.

A Specific people link grants the named recipients access to that item. Your report, reading site role assignments, sees nothing — because there is no site role assignment; the grant sits on the file. And here is the part that matters for a Copilot rollout, in Microsoft’s own words: a Specific people link makes the file appear in search results and accessible through Copilot for everyone added to the link.

A People in your organization link is harder still to audit, because there is no fixed list of people to audit. Microsoft describes it as “a transferable, revocable secret key.” Anyone inside the organisation who receives the link can redeem it and get in. There is no single user your per-user report can pin the access to — the link is designed to be forwarded.

And an Anyone link breaks the model entirely. There is no authentication and, again in Microsoft’s own words, the access “can’t be audited.” There is no user identity behind it at all. A per-user permission model has literally nothing to enumerate, because the person holding the link may not be a person in your directory.

So the question itself is wrong

Which is why “what can this user reach?” is an incomplete question, and any tool that answers only that is handing you false comfort. A sharing link is not a per-user grant. It is a key to one specific item, held in a scope your report does not read, sometimes given to people who are not users at all.

You can have a site whose membership is immaculate and whose files are quietly shared halfway across the company by link. The report will call it clean.

Why this stopped being a slow-burn risk

It used to be that an overshared file just sat there, technically reachable, but you had to know it existed to find it. Copilot removes that last bit of friction. The Specific people links that Microsoft says make files “accessible through Copilot” are exactly the ones your permission report cannot see.

So the gap between what your report shows and what Copilot will surface is not a rounding error. It is, precisely, the sharing links.

How to actually find them

You cannot get this from a per-user or per-site role report — by design, because the access is not a role. You have to enumerate the sharing links themselves: the unique per-item permission scopes scattered across your libraries.

Microsoft’s Data Access Governance sharing-links report does this, if you are licensed for it. So does the free PowerShell I wrote for it, which walks the tenant, finds every sharing link, risk-scores them, and lets you revoke the ones that should not exist. Different tools, same necessary move: stop auditing membership, and start auditing links.

So the next time a “who has access” report comes back clean before a Copilot rollout, do not exhale. It answered the membership question honestly and missed the one that leaks. Ask the other one: what is shared by link? That is the access that actually escapes — and it is the access Copilot reads.

August 3, 2026 by Copilot SharePoint Online 0

Data Access Governance reports: see your SharePoint oversharing before Copilot does

Before you switch on Copilot, there is one question worth losing sleep over: what in here is overshared? Not in theory — in fact. Which sites are open to the whole company. Which files a long-gone contractor can still reach. Which “anyone with the link” shares are still live from a project that ended two years ago. Most admins have no way to answer that, so they cross their fingers and hope.

SharePoint Advanced Management has a set of reports that answer it precisely. They are sitting in your admin center, and almost nobody runs them. They are called Data Access Governance reports, and this is the tour.

Where they are

In the SharePoint admin center, expand Reports and select Data access governance. Everything below lives on that one page. It splits into two kinds of report, and you want both.

Snapshot reports: the baseline

Snapshot reports show your organisation as it stands right now, the day you run them. Four of them, and the first two are the ones that matter most.

Site permissions across your organisation. Microsoft marks this one “recommended,” and it earns it. It analyses every SharePoint and OneDrive site and shows you which have the broadest access, the sites open to thousands of users, to external guests, or to “Everyone except external users.” This is your first look at where the exposure is concentrated. Run it, and the sites that need attention rise straight to the top.

Sites and files shared via special SharePoint groups. This is the one to really pay attention to. Where the report above tells you which sites are overshared, this one tells you exactly which items are effectively public, through the “Everyone except external users” or “Everyone” groups, and how that access was granted. Down to the file. That precision is the difference between “we have an oversharing problem somewhere” and a list you can actually script a cleanup against.

Site permissions for a user. Pick a person; get every site they can reach, and how, whether it was granted to them directly or inherited through a group. This is the question you dread in an access review or a leaver process, and it used to mean an afternoon of clicking. Here it is a report.

Sensitivity labels for files. Which sites hold files carrying a given sensitivity label, so you can confirm the sensitive stuff is where you think it is and protected the way you think it is.

Activity reports: what changed lately

Activity reports cover the last 28 days — the oversharing that happened recently, so you can catch it as it emerges rather than discovering it a year later.

Sharing links. The sites where people created the most new sharing links lately, across all the types: “anyone” links, “people in the organisation” links, and specific-people links. This is oversharing in the act.

Shared with ‘Everyone except external users’. The sites where content was shared with your entire internal organisation in the last 28 days. Broad internal exposure, as it happens.

How to actually use them

The two kinds work together. Run the snapshot reports quarterly to keep a true picture of your baseline exposure. Run the activity reports monthly to catch new risk before it settles in. Start with site permissions across your organisation; it tells you where to look, and everything else drills in from there.

And the reports are not a dead end. From a finding, you act, without leaving the governance tooling:

  • lock an overshared site to a single group with Restricted Access Control;
  • check the change history report to see who opened the access up, and when;
  • or delegate the cleanup to the site owners with a site access review, instead of doing it all yourself.

That is the whole loop: find the oversharing, decide what to do, enforce it. It is Copilot readiness in three steps.

The licensing catch

The full set needs SharePoint Advanced Management, which you have if anyone in the tenant holds a Microsoft 365 Copilot licence, or you have bought the add-on. There is one partial exception worth knowing: an organisation with Microsoft 365 E5 but no SAM can see the activity reports, capped at 10,000 sites, but not the snapshot reports and not the one-click remedial actions.

If none of this is switched on for you

Plenty of organisations have neither a Copilot licence nor the add-on, so this whole page is dark for them. If that is you, the two questions these reports answer, “every site this one person can reach” and “which sharing links are exposing content,” are exactly the two I built free tools for.

The User Access Explorer gives you the site-permissions-for-a-user view. The sharing-link auditor gives you the sharing-links view, and lets you revoke them. Not as polished as Microsoft’s reports, but free, and they answer the question that actually matters before you turn Copilot on: who can already reach what.

August 2, 2026 by Copilot SharePoint Online 1

SharePoint Advanced Management: the features that actually earn their keep

SharePoint Advanced Management has a long feature list. Open the Advanced management page and you will count more than twenty capabilities, which is its own kind of problem: a list that long tells you nothing about where to start. Most of them you will open once, nod at, and never touch again. A handful you will come back to every week. This is about that handful, grouped the way Microsoft groups them: preventing oversharing, controlling sprawl, and keeping an audit trail.

Preventing oversharing

This is the part that matters for a Copilot rollout, and it is where SAM earns most of its keep.

Data Access Governance reports. If you use one thing in SAM, use these. They are a set of reports that show how your content is actually exposed, and each answers a question that used to take a day of clicking:

  • the permission state report is a tenant-wide snapshot of how broadly your sites are shared;
  • the per-user report lists every site a given person can reach and how they got access, which is the question you dread in an access review;
  • the sharing links report surfaces the sites where people created the most new links lately;
  • the sensitivity label snapshot shows how your labels are distributed;
  • and the Everyone except external users report is the single most useful line in here: the content shared with, effectively, the whole company.

These are your oversharing X-ray. Run them before you turn Copilot loose, because they tell you exactly what it is about to surface.

Restricted Content Discovery. Hide a messy site from Copilot and organisation-wide search while you clean it up, without changing anyone’s access. It is the light-touch cover, and I went into it in detail in Restricted Content Discovery vs Restricted SharePoint Search.

Restricted Access Control. The heavier control: lock a site so only members of a specific security group can open it, even if someone else has a direct grant or a sharing link. It is a real access boundary, and it has its own write-up in Restricted Access Control for SharePoint.

Block download. Let people read a site in the browser but not move or download the files out of it. It also covers Teams meeting recordings, which is where a lot of sensitive material quietly walks out.

Site access reviews. This is the one that makes the reports actionable. You found the overshared sites in the Data Access Governance report; now, instead of fixing them all yourself, you delegate the review to the actual site owners, who know whether that access is still needed. It is the difference between a report you feel bad about and a cleanup that actually happens.

Controlling sprawl

Three policies stop your tenant slowly filling up with orphaned and forgotten sites.

The site ownership policy flags sites that have no real owner, or fewer owners than you require, and nudges someone to take responsibility. The inactive site policy finds sites nobody has touched in months and emails the owners to confirm or let go. And site attestations ask owners to periodically confirm that a site is still needed and its access is still right, so the cleanup does not depend on you remembering to chase it.

Run all three in simulation mode first. You want to see what they would flag before they start emailing people.

Keeping an audit trail

Boring until the day you need them, then invaluable.

Change history reports track changes made to individual sites, and to organisation settings, over the last 180 days. When someone asks “who turned sharing back on for this site, and when,” this is the answer. Recent actions is the shorter version: the last changes you made to a site’s properties in the last 30 days, so you can retrace your own steps after a busy afternoon in the admin center.

And a newer one worth a look now that anyone can build one: insights on agents in SharePoint, which show you the agents people have recently spun up across your sites, and which sites are accumulating the most. Agent sprawl is the next version of site sprawl, and it is quietly starting.

Where to start

If the feature list is overwhelming, ignore most of it and start in exactly one place: the Data Access Governance reports. They tell you where your oversharing is. The site access reviews let you delegate the fix. And Restricted Content Discovery or Restricted Access Control hold the line while the cleanup happens. That loop is the whole of Copilot readiness, and it is sitting in your admin center already.

The one thing none of it does is the judgement call underneath it all: deciding who should be able to reach what. SAM will show you the answer and help you enforce it. It will not make the decision for you.

And if you are one of the organisations without a Copilot licence or the add-on, so none of this is switched on for you, that oversharing view is exactly the gap I built User Access Explorer to fill, for free.

August 2, 2026 by Copilot SharePoint Online 0

Restricted Access Control (RAC) for SharePoint: the control that actually locks the door

In an earlier post I said Restricted Content Discovery hides a site from Copilot but does not change who can open it. Turn it on, and anyone with a sharing link still walks straight in. They just will not stumble across the site through search. That is fine when hiding is all you want. When you actually need the door locked, there is a different control, and it is the one people reach for RCD by mistake instead. It is called Restricted Access Control.

What it does that RCD does not

Restricted Access Control, or RAC, restricts a SharePoint site to the members of one or more security groups. Anyone who is not in the group cannot open the site or its content. Here is the line that matters, in Microsoft’s own words: users not in the specified group can’t access the site even if they had prior permissions or a shared link.

Read that again, because it is the whole point. A direct grant does not save you. A sharing link does not save you. If you are not in the control group, the door is shut. That is a real security boundary, which is exactly the thing RCD is not.

The catch in how it lets people in

There is one rule that trips everybody, so learn it first. Being in the control group does not, by itself, let anyone in. To open a RAC-protected site a user needs two things at the same time: permission to the content, and membership in the control group.

Add someone to the group and they still see nothing until they also have permission. Give someone permission and they still see nothing until they are in the group. Both, or nothing.

Copilot honours it too

Copilot and organisation-wide search respect the same policy. A user the door is closed to will not see the site’s content in Copilot or in search either. So RAC quietly gives you what RCD gives you, and then does the thing RCD cannot: it stops the person actually getting in.

Turning it on

You enable it once for the whole tenant, then apply it per site.

Set-SPOTenant -EnableRestrictedAccessControl $true

Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" -RestrictedAccessControl $true
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" -AddRestrictedAccessControlGroups "<group-guid>"

# read it back
Get-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" |
    Select-Object RestrictedAccessControl, RestrictedAccessControlGroups

You can point up to ten groups at a single site. For a group-connected site, the site’s own Microsoft 365 group is set as the default control group, and you add more from there.

Two things that will bite you

First, RAC locks who can open the site. By default it does nothing about who can share it. Someone inside can still send the content to a person outside the group, and that share works, until you separately turn off outside sharing for RAC sites:

Set-SPOTenant -AllowSharingOutsideRestrictedAccessControlGroups $false

Second, shared and private Teams channels are separate site collections, so a policy on the team’s main site does not reach them. You configure those one by one, as their own sites.

So which one, and when

Restricted Content Discovery is the light touch: keep a messy site out of Copilot’s line of sight while you clean it up, with access left untouched. It is fine to use on many sites during a rollout. Restricted Access Control is the heavy one: this site should only ever be reachable by this group, full stop, and the blocked list is real. You use it on the few sites that genuinely need a locked door, not casually across a tenant, because you are changing who can get in.

Both, though, rest on the same homework: knowing which sites hold the sensitive material, and who actually belongs in the group. RAC will enforce your answer perfectly. It will not tell you the answer. The who-can-currently-reach-what part is still yours, and it is the thing I built User Access Explorer to show.

August 2, 2026 by Copilot SharePoint Online 0

SharePoint Advanced Management: what you get, and whether you already have it

You are reading a Microsoft article about getting ready for Copilot, and it keeps telling you to use SharePoint Advanced Management for this and that. You assume it is one more paid add-on you do not have, and you close the tab. Here is the thing nobody puts in bold: if a single person in your organization has a Copilot license, you already have most of it, and it has been sitting in your SharePoint admin center the whole time.

So let us clear up what it is, and whether you have it, because both are simpler than they look.

What SharePoint Advanced Management actually is

SharePoint Advanced Management page in the SharePoint admin center showing the What's included feature list

SharePoint Advanced Management, or SAM, is a set of governance controls for SharePoint and OneDrive, run from the SharePoint admin center. Microsoft points it at three jobs, in their own plain words: managing content sprawl, managing the content lifecycle, and preventing oversharing.

That last one is why it keeps coming up around Copilot. Oversharing is the thing Copilot makes loud, and SAM is the box of tools Microsoft hands you to deal with it.

The part worth checking before you assume you cannot use it

If your organization assigns even one Microsoft 365 Copilot license to one user, your SharePoint admins get the SAM features that support Copilot. Read that again: not the licensed user, the admins, for the whole tenant. One license trips the switch for everybody who administers SharePoint.

If you have no Copilot anywhere, you can still buy SAM on its own as the Plan 1 add-on, which runs about three dollars per user per month. But most organizations that are even thinking about Copilot have already crossed that line without noticing, and are sitting on a set of governance tools they never opened.

What is actually in the box

You will not use all of it. You will use three or four. The pieces most people came for are the Data Access Governance reports, which are the oversharing reports:

  • a permission-state snapshot across all your sites, so you can see how broadly things are exposed
  • the list of every site a given user can reach, and how
  • a sharing-links activity report, the sites where people created the most new links lately
  • the Everyone except external users report, the single most useful thing in here for a Copilot rollout

Around those sit the controls you act with. Restricted Content Discovery and Restricted Access Control keep a site out of Copilot or lock it to one security group. Block download policies stop files leaving a site. Inactive-site and site-ownership policies handle the sprawl, and change history and recent admin actions cover the lifecycle, so you can see who changed what on a site over the last 180 days.

The one thing the Copilot license does not give you

Almost everything above comes with that one Copilot license. The exception worth knowing is restricting which non-Microsoft apps can create sites, which still needs the Plan 1 add-on. A couple of the reports, like the sensitivity-label snapshot, also want E5. Everything else in the list lands the moment the first Copilot license does.

How to find out what you have

It all lives under Advanced management in the SharePoint admin center. If you have never opened that node, open it. That is faster than reading any licensing table, because it only shows you what your tenant can actually use.

So before you go hunting for a third-party tool to tell you who can reach what, check whether the Data Access Governance reports are already there. If they are, start with them. And if they are not, because there is no Copilot and no add-on anywhere in sight, that same oversharing view is exactly the gap I built User Access Explorer to fill, for free.

August 2, 2026 by Copilot SharePoint Online 2

Start Here

PnP PowerShell for SharePoint Admins
The scripts, in reading order

What Copilot Chat (Basic) Can Do
Where the free tier stops

About this site
Who writes it and how it is tested