Hi
It took a bit of time by Microsoft engineers were able to show me that the problem was in the Confluence APIs -
The problem occurs as The Confluence Cloud API endpoints used by Microsoft Search connectors returns ONLY space-level and inherited permissions, and fail to return page-level restrictions.read overrides for nested or archived pages.
So the index believes the group has access unless the page explicitly denies all groups (and not propagate via the API).
regarding your question with parent child structure ,...Atlassian has confirmed that GET /content/ {id}?expand=restrictions the endpoint does not return inherited restrictions,
While, in theory, Microsoft Search could build a hierarchical permission model (where a child page inherits the permissions of its parent if none are defined explicitly), in practice the connector architecture intentionally mirrors the source system’s access model.
This design is based on two main principles:
* Data authority: Microsoft Search treats Confluence as the source of truth for all access control information. We don’t reconstruct or infer additional rules (like inheritance) beyond what the source API provides, to avoid mismatches if Atlassian later changes their permission logic.
* Scalability and reliability: Confluence spaces can contain tens of thousands of pages, and building or maintaining a real-time parent-child graph for every page would significantly increase indexing complexity and crawl time. Instead, the connector indexes the permissions returned per item (page) as-is.
The issue was also reported here
and the connected ticket
In our case, we went with the dedicated service account approach that we granted specific permissions to only what we consider open internal pages so the indexed content is limited.
I hope this helps a bit with this scenario.
Guy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.