Understand first
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Knowledge catalogChoose core direction and segmented content
Understand → Implement → Debug → Design
Consistent authorization across RAG and derived data
Enforce authorization throughout retrieval, reranking, context assembly, caching, and source access.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Tool calls: structure, authorization, and business contracts →From document ingestion to cited RAG answers →Which step do you want to learn from this knowledge point?
Select the starting point based on the current basis, or you can go deeper one by one. When you encounter an unfamiliar concept, go back to the core principles first; use the knowledge exercises to check your understanding when you are finished.
Realize again
Prepare to write the principles into code
Understand implementation steps and boundaries, complete small tasks, and check results against acceptance requirements.
View the code example →Will troubleshoot
Need to handle failures and changes in conditions
Follow the continuous questioning to locate the failure premise, and then compare the migration cases to explain how the plan should be adjusted.
Continue to delve deeper into the problem →Able to choose
Need to design or review plans
Combine engineering deductions and senior self-evaluation standards to explain the applicable conditions, costs and alternatives of the plan.
Analyze engineering scenarios →Knowledge unit directory
LEARN · PRACTICE · REFLECT
Knowledge learning and personal records
First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.
Answers and personal notes
Can be practiced directly. After logging in, answers, favorites, and notes will be saved to your account.
Log in and saveEach modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.
Core concept · Consistent authorization across RAG and derived data
Understand the core principles first
Preparatory concepts:Server identity authentication, ACLs and cache keys, Data derivation relationship
Authorization determines whether data can enter calculations, and relevance only determines the order of authorized data. All summaries, caches, and citations derived from the text must be subject to the current permissions.
Filters do not authenticate identity
A tenant_id filter is insufficient when models or clients can change its value. Trusted servers authenticate subjects, calculate effective permissions, and construct scopes the model cannot widen. Azure string security filters implement filtering, not automatic authentication. Other ACL features require configuration-specific verification.
Access constraints follow derived copies
Chunks, reranker text, model context, answer caches, historical summaries, and logs contain copied data. Final-answer filtering cannot undo disclosure to a model or third-party reranker. Citation downloads also require authorization; hiding titles while leaving public private-document links still leaks access.
Preserve authorization while improving recall
Post-filtering can lose authorized evidence because candidate truncation happens first. Improve retrieval within the same permitted scope, rather than handing unrestricted data to a model for filtering. Parent and neighboring chunk expansion need fresh checks, especially with paragraph-level permissions.
Handle authorization changes
Bind caches to tenant, effective permissions, knowledge, and policy versions. Recheck authorization during recovery and track source-to-derivative dependencies for invalidation. The strict teaching policy denies sensitive reads when permission services fail. Real deployments must define checkpoints and propagation delays; they cannot recall already-disclosed remote content.
Check understanding with a question
At what level should enterprise RAG permissions be filtered? How to avoid cache and reference leaks?
Trusted servers determine permissions before retrieved data reaches a model. Documents and chunks carry tenant and access metadata; identity determines filters. Apply the same rules to reranking, caches, logs, and downloads. Bind cache keys to tenant, effective access, and knowledge versions, invalidating changes. Final filtering cannot undo giving unauthorized data to the model.
Realization and trade-offs
Record enforceable access metadata at ingestion
The tenant_id, document_id, source_version, authorization principal and ACL version are saved when the document is stored in the database. Document permissions are inherited in blocks and cannot be lost after being divided into blocks. Source deletions or permission changes are propagated to the index, using an invalidation or deny policy during propagation. The application obtains the user's effective group from the authentication session and server-side permission service, and does not accept any group_ids passed in by the client. Azure's security filtering mode filters results based on string metadata and does not complete identity authentication itself; identity verification and filter condition construction are still borne by trusted applications.
Authorization before retrieval and after candidate selection
Retrieve within the security allowed candidate range to avoid unauthorized text from entering the rearranger and model. The search engine may support different filtering modes: post-vector filtering will first select candidates and then delete results that do not meet the conditions. If the permission selection is very narrow and k is small, it may miss the original authorized evidence. The recall needs to be verified based on the engine, rather than canceling permission filtering just to make up for the results. If using an independent reranking service, only authorized content is sent; final answer checks are used to prevent misreferences and cannot replace upstream authorization.
Cache and reference will also go out of bounds
The same question may have different answers in different departments, so you cannot just use question_hash to share the cache. The cache key includes the tenant, permission scope summary, knowledge and policy version, and sets the expiration path after the permission is revoked. Article reference links are re-authenticated by the backend, and it is prohibited to expose long-lasting public URLs that can directly access private objects. Retrieval logs, evaluation samples, and model trajectories may also leak the text, and access must be restricted independently. Sensitive retrieval is rejected when permissions are unknown or the service is abnormal; empty results should indicate that there is insufficient evidence in the accessible materials, and it cannot be inferred that the secret document does not exist.
Verify isolation with explicit counterexamples
The following SQL defines the minimum document and ACL table, and the query filters the authorization documents of the same tenant through the trusted identity parameter; it does not implement real authentication or full-text search. Production acceptance at least includes issues with the same name across tenants, cache hits after permissions are revoked, access to private reference URLs, missing block permissions, switching between administrators and ordinary users, etc. Assert Unauthorized The body was never sent to the model and does not appear in references, logs, or caches. Split indexes or services for different tenants when necessary, but physical isolation does not exempt application authentication.
code example
Same tenant, authorization document candidate query (SQLite)
The complete script can be executed in a new SQLite database. Fixed identities only facilitate reproducibility; real applications must not trust the identity conditions provided by the model or front-end.
CREATE TABLE documents (
id INTEGER PRIMARY KEY,
tenant_id TEXT NOT NULL,
title TEXT NOT NULL,
content TEXT NOT NULL
);
CREATE TABLE document_acl (
document_id INTEGER NOT NULL REFERENCES documents(id),
principal_id TEXT NOT NULL,
PRIMARY KEY(document_id, principal_id)
);
INSERT INTO documents VALUES
(1, 'tenant-a', '研发规范', '只供研发组读取'),
(2, 'tenant-a', '财务预算', '只供财务组读取'),
(3, 'tenant-b', '外部租户', '不属于当前租户');
INSERT INTO document_acl VALUES
(1, 'group-dev'), (2, 'group-finance'), (3, 'group-dev');
-- 演示中固定可信身份；生产应用使用绑定参数和服务端有效主体集合。
WITH trusted_identity(tenant_id, principal_id) AS (
VALUES ('tenant-a', 'group-dev')
)
SELECT d.id, d.title
FROM documents d
WHERE EXISTS (
SELECT 1 FROM trusted_identity i
JOIN document_acl a ON a.principal_id = i.principal_id
WHERE a.document_id = d.id AND i.tenant_id = d.tenant_id
)
ORDER BY d.id;
expected output
1 | 研发规范Engineering deduction
- scene
- Assume an engineering scenario: Finance and R&D both ask for "this month's budget", and the website caches answers for reuse of the same question.
- design decisions
- The server generates identity filtering; caches bound permission digests; references are read and re-verified; permission changes trigger cache invalidation.
- Verify target
- Expected behavior: R&D cannot obtain financial documents or their abstracts, and old answers will no longer be reused after revocation.
- applicable boundary
- SQL only demonstrates filter relationships and does not include authentication, vector searches, permission synchronization, or database-level row permissions.
Continuous questions and answers
Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.
Level 1A user has just been removed from a department group. How to deal with the cache of old answers?
Revocation makes the original legal derivatives into currently unreadable content.
Reference answer
First revoke the group membership and change the permission version at the authoritative permission level; retrieve the valid authorization before cache reading, and the cache key corresponding to the old summary is no longer available. Re-document dependencies actively invalidate old answers, citations, and derived summaries. Short TTL only shortens the risk window and cannot replace revocation verification; if there is no dependency, the subject or scope cache will be invalidated conservatively.
Follow this answer further
Level 2The cache has expired, but there is still a financial summary in the old Checkpoint. What should I do after restoring it?
After the parent repairs the cache, an independent copy of the persistence context still exists.
Reference answer
The historical summary is not directly used as available context when restoring. Recheck current permissions based on their source citations, delete unauthorized content and reassemble model inputs; old summaries with incomplete citations are conservatively considered unconfirmable. Also prevent the old worker from writing the old digest back to the new cache, verifying the current permissions version when writing.
Follow this answer further
Level 3If the authorization is revoked immediately after passing the authorization check, can I still guarantee that the request has not been sent?
There is still a race condition detected after re-authentication, and it is necessary to distinguish between the local prohibition of subsequent reads and the fact that it has occurred remotely.
Reference answer
A check and a network send are not naturally atomic operations. The window can be narrowed through short authorization leases, version checking at the sending gateway, and serialized submission, and the checkpoint at which deprivation takes effect is clarified. Requests that have entered the remote end cannot be withdrawn by deleting the cache; when stronger guarantees are required, the gateway and the revocation service need to jointly define and execute the submission boundary.
Level 1Why is it not enough to hand over unauthorized content to the model and then hide the output?
Backtrack the data from the final answer into the true boundaries of the calculation.
Reference answer
When the model has received unauthorized text, output hiding can only reduce the risk of display. It cannot withdraw processing, logs or external service retention, nor can it guarantee that the model will not be leaked in another way. Authorization should be done before reading and sending, supplemented by final verification. Relevant but untitled evidence cannot be used to produce a summary that appears to be public.
Level 1Should block permissions be maintained independently or should document permissions be inherited?
Implement authorization rules into chunking and context expansion.
Reference answer
By default, source document permissions are inherited in blocks and traceable ACL versions are saved; when paragraph-level permissions exist, they can be more stringent, but cannot be relaxed without basis. Maintaining ACLs independently increases the risk of synchronization misses and is best derived deterministically from origin rules. The parent block and adjacent block extensions are checked according to their actual permissions, and the entire article cannot be expanded just because a child block has permissions.
Draw inferences from one example: If the conditions change, how to deduce it?
First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.
Abstracts are distributed to multiple departments
Changing conditions:The original text is only visible for financial purposes, but you would like the summary to be shared
Extended question:Can the abstract be turned directly into public knowledge after deleting the numbers?
Derivation and reference solutions
Authorization cannot be inferred solely from textual deletions. The summary may still reveal the existence of the project, budget trends, or implicit business information. An independent, auditable publishing or redaction process is required to clearly approve the shared output and audience; otherwise, the original text permissions will continue to be inherited. Summary generation and public publication are two different actions.
The principles that remain unchanged:Derived content does not automatically gain wider permissions if it is shortened or rewritten.
Authorization service is temporarily unavailable
Changing conditions:From clear permissions to unknown permissions
Extended question:Can I use yesterday's cached group list for availability?
Derivation and reference solutions
Reject sensitive knowledge or limit it to explicit disclosure. If the business allows time-sensitive authorization snapshots, the maximum aging time, risk scope, and authorization withdrawal exceptions must be specified in advance. Unknown information cannot be temporarily interpreted as permission. Monitor for failures and indicate to the user that access scope cannot be confirmed at this time.
The principles that remain unchanged:When the authorization basis expires, neither correlation nor historical successes can supplement the evidence currently allowed to be read.
Easy to make mistakes
- Let the model generate the tenant_id or authorization group itself
- Only filter the final answer, reranking and context already contain private information
- Do shared cache keys across users using only question text
References
It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.
Check how far you understand
After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.
- Basic standards met
- Retrieval and reading are based on trusted user identities.
- Intermediate and advanced signals
- Permissions cover retrieval, reranking, citations, historical context, and caches.
- Senior Signal
- Can handle undo propagation delays, derived data, and old checkpoint recovery.
View verification records for independent examples
Hands-on verificationComplete on demand · Suggestions15 minutes
Design handling of vector indexing, caching, and saved summaries after permission revocation.
Expand acceptance requirements and checkpoints
- The old text cannot be read after revocation.
- Cache does not return across scopes
- References also recheck authorization
Key inspections
- The authorization identity cannot be taken from the retrieval parameters generated by the model
- Chunking, reranking, caching, and references all override permissions
- Understand the different impacts of pre- and post-retrieval filtering on recall and safety margins