I would trace one authorization decision before choosing a data structure. A document grants read to group A. A includes B. The employee belongs to B. Access is true only if that relationship path is valid under the current policy, for the current principal and object. Expanding the path into thousands of user IDs at ingest time turns every membership change into a potentially huge document-index update. The cached hit can remain visible after the employee is removed unless serving has a current check or a very strong invalidation mechanism.

Keep the graph or relation tuples in a policy system that can answer “may this principal read this object?” at a stated revision. Use index-time ACL summaries to prune obviously unauthorized candidates and keep the query efficient, then batch check candidate IDs before private text reaches a reranker or model. The check must use the document's current parent and permission relationships, not merely the ACL captured when its embedding was built. Google's Zanzibar paper is a useful primary reference for relationship-based authorization and consistency with content changes. Its architecture is not something a small team gets by copying a diagram. The consistency contract and operational cost matter.

The hard part is time. Define the removal event that starts the revocation clock and the latest policy revision a read may use. A positive decision cache that lives longer than that clock can make a perfect membership service irrelevant. Version or invalidate decision caches on group membership and document relationship changes, and measure end-to-end enforcement. Search-result caches should hold candidate IDs and re-authorize when serving them. A cached answer with private content needs a much tighter scope or no reuse. A principal's JWT may contain old group claims, so its expiry alone cannot stand in for a short revocation promise.

Nested groups need cycle handling. A cycle such as A contains B and B contains A must terminate, and deny and allow semantics must be specified rather than guessed. Membership may come from multiple identity providers, each with its own freshness. I would define bounded traversal or a materialized relation view with revision, reject malformed cross-tenant edges, and test the path by which a grant is inherited. If the source's semantics include explicit denies or exceptions, a simple union of user IDs is insufficient.

Now the membership service is down and the last snapshot is five minutes old. Whether we can serve depends on the explicit revocation bound and the snapshot's guarantees. “Cache is probably fine” is not a contract. If it is within a proven bound and receives invalidations, it may be usable for a short time. Once freshness cannot be established, private content should fail closed or use another current policy replica. Public search can continue. This is an availability choice with a measurable authorization contract.

I would test a user removed from a nested group while a query is in flight, after a move to a differently permissioned folder, during a warm cache, and during a missed event followed by reconciliation. The security metric is time from authoritative membership change to last possible disclosure, with negative tests. A low average ACL-update delay tells us little about the rare stale path that leaks the document.