Private search is acceptable only when authorization follows every query and every result remains traceable. The test record must include denied cases, mapped principals, filter decisions, source passages, and unresolved exceptions.
Map source principals before indexing protected content
Inventory users, groups, nested groups, document owners, inherited rules, explicit grants, explicit denials, and public or organization-wide classes. Map source principals to the identities the search service will receive at query time. Missing, renamed, or ambiguous principals should become visible exceptions; do not silently broaden access because a group cannot be resolved or a source rule has no direct destination equivalent.
Microsoft's document-level access guidance describes several authorization patterns, all built around permission metadata and query-time enforcement. Choose a pattern that matches the buyer's identity system and threat model. Keep authorization logic server-side, minimize exposed metadata, and define what happens when the identity provider, permission lookup, or filter construction fails. A safe failure should not return the unfiltered index.
Test allowed and denied retrieval at the passage level
Create paired tests for users who may and may not retrieve the same document. Cover direct grants, groups, nested memberships, revoked users, newly added users, mixed-permission collections, deleted documents, and cached results. Run the tests against keyword, vector, hybrid, filter, autocomplete, and any generated-answer path, because an access check on one endpoint does not prove every retrieval surface is protected.
Display the exact authorized passage used by a result or synthesis, along with document identity and a stable link. A citation label without the supporting span is difficult to verify and can mask a mismatched or stale source. Logs should record the query, identity class or protected pseudonym, applied filters, returned document identifiers, index version, and timing while respecting the buyer's logging and retention rules.
Keep access authority and substantive judgment with the buyer
The system can enforce a supplied permission model, but it cannot decide who ought to see a document. The buyer's access authority resolves unmapped principals, approves exception handling, grants user rights, and tests the production identity path. Security, privacy, legal, or privilege reviewers may need to examine the design for the corpus; a technical relevance report is not their certification.
ExactSpan records permission mappings, denied cases, source spans, and unresolved exceptions as part of the acceptance packet. Reality Contact, LLC does not certify confidentiality, privilege, regulatory compliance, or completeness, and does not use private material outside the agreed processing boundary. Written secure-intake and deletion terms precede transfer. The buyer approves the access model and the operational uses permitted for retrieved material.
Where the service stops
Reality Contact, LLC implements and evaluates search but does not determine who should have access, certify confidentiality or legal privilege, make substantive professional judgments from retrieved material, or represent that a result set is complete. The buyer confirms lawful corpus access, approves permission mappings and evaluation cases, reviews failed and ambiguous results, and decides whether the system is acceptable for the team's operational search workflow. Do not send private material through the public form. Secure intake and written deletion terms are established before files, links, credentials, or sensitive records are transferred. This is technical search implementation and evaluation; it does not replace the buyer's legal, privacy, security, records, privilege, or substantive professional review. Search results are limited by the confirmed corpus, extraction, metadata, permissions, index version, queries, and evaluation set; the service does not promise that every relevant document or passage will be found.
Sources: Microsoft Azure AI Search document-level access overview; NIST role-based access control project.