A permitting RAG system returns confidential building plans because document ACLs were checked only at portal login, not at retrieve time. What authorization gap should appsec close?
Select an answer to reveal the explanation.
Short Explanation
Logging into the portal is not the same as being cleared for every blueprint in the vault. Authorization has to ride along on each retrieve—otherwise the bot can pull plans the user should never see.
Full Explanation
Enforcing the requester’s authorization on each retrieved chunk at query time—not only at portal login—closes the permitting RAG authorization gap. Login proves the user can open the portal; it does not prove they may see every confidential building plan in the index. If ACLs are checked once at the UI and then retrieval runs without re-evaluating the subject against each chunk’s ACL, the assistant can pull plans the requester is not cleared for. Authorization must travel with retrieve, filter candidates server-side, and only then enter the prompt.
Replacing RAG with fine-tuning so authorization is encoded in model weights fails by concept: weights cannot encode dynamic per-user, per-document municipal ACLs, and fine-tuning does not enforce runtime least privilege. Increasing top-k so more documents dilute confidential hits fails because wider retrieval increases—not reduces—the chance confidential plans appear in context. Moving ACL checks into frontend JavaScript before display fails because client-side checks are bypassable and occur after unauthorized retrieval and model processing have already happened.
Exam caveat: Distinguish authentication (logged into the permitting portal) from authorization (entitled to this specific plan chunk). Civic RAG needs query-time, server-side ACL enforcement on retrieval.
Operational check: For a test user cleared only for public plan metadata, run retrieve against confidential plan IDs, confirm zero confidential chunks return, verify UI login alone cannot widen retrieval, and log denied retrieves for appsec review.