Guidance Required: Azure AI Search Architecture for 300+ SharePoint Sites with Vector Search and ACL Security Trimming

Hi Adari bhaskar,

The three requirements you've listed — 300+ sites, vector search, and ACL security trimming — are each supported, but they collide at the scale you're describing, so the architecture decision is worth making before you build anything.

The constraint that will shape your design

A SharePoint data source connection string points at a single site endpoint. You can widen it with includeSubsites=true and includeLibrariesInSite to pick up subsites and specific libraries, but it is scoped to that one endpoint. If your 300+ "sites" are 300+ separate site collections, that implies roughly one data source and one indexer per site collection — and the per-service ceilings are: S1 = 50 indexers / 50 data sources / 50 indexes; S2 = 200 / 200 / 200; S3 = 200 / 200 / 200.

So 300 site collections does not fit on a single search service at any tier, and at 16 new sites a month you would hit the S2/S3 ceiling within about a year even if you started at 200. Max services per region per subscription is 16 (S1), 8 (S2), 6 (S3), so sharding is possible but you are then managing a fan-out query layer yourself.

To be explicit about confidence: the per-service limits above are documented. The "one data source per site collection" part is my reading of the connection string format — the docs do not state anywhere that a single SharePoint data source can span multiple site collections, and I would not design around the assumption that it can. Worth validating in your own tenant with two site collections before you commit.

Three architectures worth evaluating

Option 1 — SharePoint in Microsoft 365 indexer + integrated vectorization + ACL ingestion. This gives you full control over the vector index, hybrid and semantic ranking, and your own chunking strategy. It is also the option that runs into the object caps above, and the connector is still in public preview — "as-is", best-effort support, explicitly not recommended for production. Before you pick this, check three hard blockers: no private endpoint support (firewall configuration only); no support for tenants that use Microsoft Entra Conditional Access, so if your tenant enforces CA this connector will not work at all; and renaming a SharePoint folder breaks incremental indexing for the content under it — with 300 sites and monthly onboarding, folder churn is near certain, so plan for periodic resets.

Option 2 — Remote SharePoint knowledge source. No index, no indexer, no ACL replication. Azure AI Search calls the Copilot Retrieval API with the user's token, so SharePoint permissions and Purview sensitivity labels are enforced natively, and your 16 new sites per month need zero new Azure objects — at most a filter update. This is the cleanest answer to your scale and ACL requirements. The trade-offs are real though: it requires a Microsoft 365 Copilot license and SharePoint must be in the same Entra tenant as your search service (billed through M365); you get 200 requests per user per hour, a 1,500-character query maximum, a maximum of 25 results, and results come back unordered; there is no vector index of your own, no multimodal, no tables or images, so if your requirement is genuinely "my own embeddings, my own chunking, my own hybrid scoring", this option does not give you that. Site scoping is a KQL filterExpression, e.g. SiteID:"" or several sites OR'd together — invalid KQL is silently ignored, so test your filters.

Option 3 — Graph or SharePoint webhooks, export to Blob Storage, index with the blob indexer and push ACLs. One data source for all 300+ sites, so you sidestep the object caps entirely, you keep full vector control, and you're on a GA connector rather than a preview one. The cost is that you own change tracking, deletion propagation, and ACL extraction. For a 300-site estate that is a real engineering investment, but it is the option that scales linearly.

If you go with Option 1, three things will bite you

First — and this is the single most common failure when you combine vectors with ACLs — if your skillset chunks documents with projectionMode set to skipIndexingParentDocuments, the indexer's field mappings for UserIds and GroupIds are bypassed entirely. Your chunks land in the index with empty permission fields and every query returns nothing. You have to carry the ACL fields through indexProjections.selectors[].mappings so they're stamped onto each chunk. Since you want vector search, you will be chunking, so assume this applies to you.

Second, item-level permission changes are picked up incrementally, but permission changes at a parent scope — site, library, list or folder — are not auto-detected. You have to call:

POST https://.search.windows.net/indexers//resync?api-version=2026-05-01-preview Content-Type: application/json Authorization: Bearer

{"options": ["permissions"]}

and then run the indexer. Budget for this on a schedule, not just on demand.

Third, two ACL gaps to design around: a Microsoft Entra group nested inside a SharePoint site group is not expanded, so users who get access only through that path will silently see no results; and the SharePoint data source supports up to 1,000 permission entries per file, beyond which permissions may not be enforced at query time. Also note that if ACL evaluation fails at query time — Graph unavailable, for example — the service returns a 5xx rather than a partially filtered result set, which is the safe behaviour but needs handling in your client.

Index-side configuration for ACLs, for reference

On the index, set "permissionFilterOption": "enabled", plus a UserIds field with permissionFilter "userIds" and a GroupIds field with permissionFilter "groupIds", both Collection(Edm.String), filterable true, retrievable false. On the data source, set "indexerPermissionOptions": ["userIds", "groupIds"]. Field mappings are metadata_user_ids → UserIds, metadata_group_ids → GroupIds, and metadata_spo_site_url → SharePointSiteUrl. At query time, pass the end user's token in the x-ms-query-source-authorization header — if you omit it, only content with no ACLs comes back. ACL ingestion requires application permissions; delegated permissions are not supported for this.

For the 16 new sites a month

On Option 1 this needs automation: a script or Logic App that creates the data source and indexer per new site from a template and registers it against your index, plus a runbook item for when you approach the 200-object ceiling. On Option 2 it's either nothing at all or a one-line filterExpression update. That difference alone is worth weighing carefully at your growth rate.

A few things that would let me narrow this down

1. Are the 300+ "sites" separate site collections, or subsites under a smaller number of site collections? If it's the latter, includeSubsites=true collapses the object count dramatically and Option 1 becomes viable.
2. Do you have Microsoft 365 Copilot licenses available? That's the gate on Option 2.
3. Does your tenant enforce Conditional Access? If yes, Option 1 is off the table.
4. Roughly how much content — total GB and document count? That drives tier and vector quota sizing.
5. Is a preview connector acceptable in production for you, or do you need a GA path? If GA is required, Option 3 is your route.

Docs, all current:

SharePoint in Microsoft 365 indexer — https://learn.microsoft.com/azure/search/search-how-to-index-sharepoint-online

ACL ingestion for the SharePoint indexer — https://learn.microsoft.com/azure/search/search-indexer-sharepoint-access-control-lists

Query-time ACL and RBAC enforcement (ACL entry limits, 5xx behaviour) — https://learn.microsoft.com/azure/search/search-query-access-control-rbac-enforcement

Service limits (the 50/200/200 numbers and vector quota) — https://learn.microsoft.com/azure/search/search-limits-quotas-capacity

Remote SharePoint knowledge source — https://learn.microsoft.com/azure/search/agentic-knowledge-source-how-to-sharepoint-remote

Indexed SharePoint knowledge source — https://learn.microsoft.com/azure/search/agentic-knowledge-source-how-to-sharepoint-indexed

Thanks