City security tests whether department and classification metadata filters on similarity search are enforced only if the client sends them. What finding indicates a control failure?
Select an answer to reveal the explanation.
Short Explanation
If the browser gets to pick the 'classification=public' sticker, a crafty caller will peel it off. Enforce department and classification filters on the server—don't trust the client to police itself.
Full Explanation
Retrieval filters must be enforced server-side; client-supplied claims alone are insufficient—that finding marks a control failure when department and classification metadata filters apply only if the client sends them. Similarity search for city knowledge must apply mandatory filters (department, classification, audience) in the retrieval service using the authenticated subject and server policy. If the browser can omit or forge “classification=public,” an attacker bypasses confidentiality by simply not sending the sticker.
Treating client-side filter flags as adequate if the LLM is told to respect them fails by concept: prompts and client flags are not enforcement points for municipal ACLs. Claiming metadata filters are unnecessary when embeddings are encrypted at rest fails because encryption at rest does not authorize who may retrieve which class of vectors at query time. Allowing public 311 bots to accept any department filter the browser posts fails by letting callers choose their own access scope.
Exam caveat: Never trust the client to supply the confidentiality filter. Server-side mandatory filters tied to identity and policy are the GAIPS-aligned pattern for civic RAG.
Operational check: Authenticate a low-privilege 311 test client, omit and forge classification filters in API calls, confirm the server still restricts to public-allowed collections, and penetration-test filter bypass as part of appsec regression.