Permission must happen before the answer
Start with the authenticated user, organization, role, source permissions, and requested action. Resolve those deterministically before retrieval and before exposing tools that can change records.
Preserve permission metadata through derivation
A document may become many indexed records or chunks. Each derived record needs enough permission context for query-time enforcement. A label in the text is not authorization, and a shared cache must not return a restricted result to a different user.
Microsoft's document-level access guidance describes the difference between indexing permissions and enforcing them at query time. Treat preview features and product-specific limits as configuration risks to verify, not generic guarantees.
Separate read access from action access
A user who can read a customer record may not be allowed to export it, change the owner, approve a refund, or send a message. Keep retrieval eligibility separate from tool authorization and approval.
MCP authorization documentation is useful for the protocol boundary, but the application still needs its own identity, scope, audit, and approval decisions.
Define safe failure
When identity is missing, permission metadata is stale, or a source check fails, choose a safe result before launch. The assistant may ask the user to sign in again, return that it cannot verify access, or route the request to an owner. It should not guess or fall back to a broad service account.
Run a revocation matrix
Create tests for a newly granted user, a removed user, a restricted document, a changed team, a shared link, and a cached result. Test both direct questions and indirect questions that might expose the same fact.
Keep audit logs protected and retain only what your security and privacy policy allows. Permission work is ongoing system ownership, not a checkbox in the launch plan.
Model the permission matrix
Write down who may retrieve, summarize, export, change, approve, and administer each class of source. Include organization, team, role, record, and action scope. Apply the matrix to original documents and derived chunks, embeddings, summaries, caches, and logs. A citation does not make a restricted passage safe after it has already reached the model.
Resolve identity and group membership at request time or within a documented freshness window. Do not use a broad service account to make a user-specific answer appear reliable.
Test revocation as a normal release gate
Create tests for a newly granted user, removed user, changed team, shared link, stale cache, and document that has moved to a restricted folder. Run the same questions before and after each change. Check both direct requests and indirect questions that could reveal the same fact.
Keep permission failures visible to the operator and vague to unauthorized users. The system should say it cannot verify access rather than reveal whether a private record exists.
The LeanOrchestr Business Brain connects approved company sources, preserves access boundaries, and turns useful context into a maintained operating layer. Start with one question, one accountable owner, and an evaluation set you can rerun.
Sources and verification
Primary product, architecture, risk, and security sources checked on 10 September 2026. Product behavior can change, so verify current plan and admin documentation before implementation.