A permitting app wires frontend to API gateway to LLM to RAG with no dedicated policy enforcement point. Where should security place authorization and content-policy checks in that GenAI architecture?

Layered GenAI architectures for permitting and similar civic workflows need a reliable policy enforcement point that authorizes callers and applies content and tool policies before model inference and retrieval or tool actions execute. Placing those checks in a server-side enforcement layer between the API gateway and model/tool invocations ensures policy still holds when the browser is modified, bypassed, or scripted. Authorization and content-policy decisions belong on the trusted path the city operates, not solely in resident-controlled UI logic.

Only inside the browser before the request leaves the resident's device fails because client-side gates are advisory to a hostile or compromised client; attackers can call the gateway and model path directly. Solely in the vector database backup job that runs overnight fails on timing and purpose—backup jobs are not request-time authorization or content-policy enforcement and cannot stop an unauthorized permitting query as it happens. Only after answers are emailed to applicants as a weekly PDF digest fails on the same latency and control-point concepts: post-hoc digests do not prevent unsafe generation, tool use, or disclosure at interaction time.

Exam caveat: UI hints and progressive disclosure improve usability but are not substitutes for server-side enforcement; do not confuse presentation with authorization. Operational check: confirm a dedicated enforcement component or gateway policy sits on every path to the LLM and RAG tools, logs allow/deny decisions for permitting traffic, rejects unauthenticated or overscoped callers, and applies content/tool rules before tokens or retrieval results are returned to applicants.