Copilot Studio Knowledge Sources: What It Can Actually Read

A Copilot Studio agent that answers questions correctly from six well-chosen sources is worth more than one wired into every SharePoint site in the tenant. That is not a philosophical position, it is what the product's own limits push you toward. Microsoft publishes hard caps on how many knowledge sources an agent can hold, how many of them the orchestrator will actually consider on a given turn, and what authentication each source type demands. Read those numbers before you design the agent and you get something that works on day one. Read them afterwards and you spend a fortnight working out why the agent confidently ignores the policy document you uploaded.

This is a guide to what Copilot Studio can actually read, where it stops, and what to build outside it when you hit that edge.

The published caps

Microsoft's requirements and quotas page sets the outer boundaries. An agent supports up to 500 knowledge sources and 500 uploaded files. Those are generous ceilings and they are not the constraint that will bite you.

The constraint that bites is in the knowledge source documentation. The summary of knowledge source limits allows 4 website URLs and 4 SharePoint URLs in generative mode, and generative orchestration begins filtering knowledge sources once an agent holds more than 25 different sources in total. Classic orchestration is tighter still. So the 500-source ceiling is a sum across source types, not an invitation to point the agent at 200 SharePoint sites, and the per-type numbers are far smaller than the headline figure suggests.

Those last three rows are the ones worth understanding properly.

What happens past 25 sources

When an agent has more than 25 different knowledge sources, generative orchestration does not search all of them on every turn. It filters the set of knowledge sources before retrieval, choosing which ones look relevant to the question, and then searches within that subset.

That behaviour is sensible and it is also the reason "we connected everything" does not translate to "the agent knows everything". If the filtering step picks the wrong subset, the answer is wrong or the agent says it cannot find anything, and nothing in the transcript tells you a source was excluded before retrieval ever ran. The failure mode looks like a bad answer. The cause is a routing decision you cannot see.

Two practical consequences. First, source names and descriptions matter more than most teams assume, because the filter reads them. A SharePoint site labelled "Team Site 3" is a source the orchestrator has no reason to select. Second, the marginal source has a cost. Adding the twenty-sixth source does not just add its content, it adds noise to the selection step for every question the agent already answered correctly.

The design that works is a small, deliberately curated set. Six to twelve sources, each named for what it contains, each covering a distinct domain, and each one you can point to and say which questions it is meant to answer. If you have forty candidate sources, the work is deciding which ones the agent needs, not connecting all forty and hoping.

Permissions are per-user, and there is no service account

This is the item that most often changes a project plan. All unstructured data sources in Copilot Studio require user-level authentication, and single-credential sign-in is not supported.

In plain terms: you cannot give the agent one service account with broad read access and let it answer for everybody. Each user authenticates as themselves, and the agent returns only what that person could already open. This is the correct security posture and it is genuinely useful — it means the agent inherits your existing SharePoint permissions rather than becoming a way around them. It also has three consequences that catch people out.

Answers differ by user, and that is not a bug. Two people can ask the same question and get different answers, because one of them has access to the finance library and the other does not. Testing needs to happen under multiple accounts, not just the builder's, because the builder usually has the broadest access in the tenant and will never see the gap.

Bad permissions become visible. If your SharePoint has drifted — inherited permissions on a site that should be restricted, a library everyone can read that nobody realised — an agent that surfaces content by relevance will find it. Copilot Studio does not create that exposure. It removes the practical obscurity that was hiding it.

Anonymous and unauthenticated channels are limited. If the plan was a customer-facing agent on the public website that also answers internal policy questions from SharePoint, the user-level authentication requirement means those are two different agents with two different knowledge sets.

Getting permissions right before the agent goes live is the bulk of the work in a well-run Copilot Studio deployment, and it is where scoping and building agents on Copilot Studio tends to spend its effort rather than on conversation design, which is the part everyone expects to be hard.

What it costs

Microsoft's August 2026 licensing guide lists Copilot Studio at USD $200 per tenant per month for a capacity pack, with a separate pay-as-you-go path billed through Azure. That figure is in US dollars; at recent exchange rates it lands around AUD $300 a month before Australian list pricing and tax, so treat it as a starting point rather than a quote.

The structural point for an SME is that this is tenant-level capacity, not per-seat. The cost driver is message consumption, not headcount, which makes a low-volume internal agent across a hundred staff cheap and a high-volume customer-facing agent across the same hundred staff expensive. Pay-as-you-go is the sensible way to start when you do not yet know the volume: run the pilot, measure actual consumption for a month, then decide whether a capacity pack is cheaper. Committing to capacity before you have usage data is a guess.

Where the processing happens

Microsoft announced on 4 November 2025 that it would offer in-country data processing for Microsoft 365 Copilot in 15 countries, with Australia among those getting in-country processing by the end of 2025 alongside the United Kingdom, India and Japan, and 11 further countries following in 2026. That is a real commitment and worth having in your planning.

It is also narrower than it is often reported to be. In-country inferencing for Microsoft 365 Copilot is a distinct question from where your tenant data is stored at rest, and both are distinct from where an external connector or a custom action processes data when your agent calls out to something that is not Microsoft. An agent that reads SharePoint and calls a third-party API has a data path that runs through whoever operates that API. If you are in health, legal, financial services or government-adjacent work, the honest answer to "is our data staying in Australia" is that it depends on which components you connected, and it needs to be answered per component rather than per platform.

Where the answer has to be an unconditional yes today, that is the case for keeping the retrieval and generation layer on infrastructure you control, which is a different architecture rather than a Copilot Studio setting.

When to put retrieval outside Copilot Studio

Copilot Studio is a strong fit when the knowledge lives in Microsoft 365, the users are licensed staff, and the questions map onto a curated set of sources. It stops being the right container in a few identifiable situations.

• You genuinely need many SharePoint locations searched reliably. Generative answers take four SharePoint URLs, and past 25 sources in total the orchestrator filters before it retrieves. If a dozen sites must all be considered on every question, that is not what the platform does.
• The knowledge is in a line-of-business system, not a document. Job records in a scheduling system, stock in an ERP, matter files in a practice management tool. That is a query against a database, not retrieval over documents, and it belongs in a purpose-built tool or action.
• You need the same answer for every user. A published policy answer that must not vary by permission is a case for a curated index the agent reads, not a permission-scoped search.
• You need to see and tune the retrieval. If you must control chunking, embeddings, ranking or the exact grounding text, you need a retrieval layer you own.

The common architecture that resolves this is not "abandon Copilot Studio". It is to keep Copilot Studio as the interface — because it is already in Teams, already authenticated, already familiar — and move retrieval into a service behind a custom action. An n8n workflow or a small API that queries your own index, applies your own filtering, and hands back a clean grounded answer sidesteps the source caps entirely, and gives you a place to log every query and every document returned.

The first move

Before you connect anything, list the twenty questions staff currently ask a person, and next to each one write the single document or system that holds the answer. Count the distinct sources. If the number is under a dozen, Copilot Studio with curated knowledge is very likely the right build. If it is thirty and half of them are databases, you know now that you need retrieval outside the platform, and you have saved yourself the discovery.

If you would rather not work that out alone, send us the list and we will come back with a scope: which sources belong inside Copilot Studio, which need a retrieval layer or a custom action behind them, what the permission clean-up in SharePoint involves, an estimated monthly consumption cost against pay-as-you-go versus the capacity pack, and a plain answer on whether the agent is worth building at all. Most builds land in two to four weeks. Tell us what you are trying to answer and we will tell you what it takes.