A historic probate-records helper’s knowledge base includes sealed adoption indices that only two clerks may open. Where must access control apply?
Select an answer to reveal the explanation.
Short Explanation
Think of sealed adoption indices that only two clerks may open. Access control has to sit on the AI corpus itself. A lobby kiosk window is not the lock.
Full Explanation
The historic probate-records helper's knowledge base includes sealed adoption indices that only two clerks may open. Access control must apply on the AI corpus itself—not merely on who can type in the public lobby kiosk. If retrieval can read sealed indices, a lobby UI restriction is cosmetic: answers and citations can still leak sealed content through the model path.
Applying controls only on the lobby chat window fails because retrieval and tools can bypass that sealed store's intent if the backend identity still reads everything. Applying controls nowhere fails because a knowledge base is not "always public" once it exists; sealed material requires identity-aware retrieval. Applying controls only on a dashboard title fails because charts are not sealed indices or authorization layers.
Exam caveat: chunking and embeddings can split sealed records across documents—classify and restrict at the source document and index filter level, not only at a single UI route. Operational check: enforce retrieval filters or separate indexes so only the two clerk identities can query sealed adoption content, verify the lobby kiosk role receives zero sealed hits in integration tests, and audit CloudTrail/data-access logs for any unexpected reads of those objects.