What breaks when RAG authorisation is enforced only in the frontend?

What breaks when authorization lives only in the frontend?

Frontend-only authorization creates a trust gap between what the user interface hides and what the data layer will actually serve. If the retrieval path can be called directly, or if the backend has no matching policy check, users can still receive embeddings, source passages, or records that the UI never showed them. The rule has to be enforced where data is returned, not just where it is displayed.

Why frontend-only rules fail for RAG

RAG systems split the flow between prompt handling, retrieval, and answer generation. That makes the frontend a weak place to enforce access rules because it is only one client of the retrieval service. Any other client, replayed request, direct API call, or internal integration can bypass UI logic unless the backend applies the same authorization decision before search or document fetch.

In practice, the failure is usually not that the UI is wrong, but that it is non-durable. A policy expressed in JavaScript or a page layer does not constrain the database, vector store, or retrieval API. Once the backend returns a result set, the model may see content the user should not have had access to, which turns authorization into a presentation issue instead of a security control.

Where the enforcement point must sit

The durable control point is the backend path that resolves retrieval, filtering, and document access. That can mean row-level filters, document-level entitlements, policy checks at query time, or pre-filtering of candidate chunks before they reach the model context. The important point is that the access decision must be bound to the data source and repeated on every request, not inferred from the browser session.

For retrieval-heavy systems, the same principle applies to embeddings and source documents. If a chunk, index entry, or vector search result can be reached without checking the caller’s rights, the system can leak information even when the final generated answer seems harmless. A user does not need the full document to learn something sensitive if the retrieved context already contains it.

How to think about this as an authorization problem

This is an authorization design problem more than a UI problem, which is why the answer usually depends on the backend policy model, not the frontend. NHIMG’s Authorisation Models Guide is useful here because RAG often needs a model that can express document-level or relationship-based access, not just coarse application roles.

If your RAG deployment serves people, workloads, or agents through the same retrieval layer, the policy has to survive each access path. The IAM and IGA Basics guide is a good reference point for separating authentication from authorization and for keeping entitlement decisions out of the presentation tier.

When the failure mode is overexposure of content through search or document lookup, the Permission-Aware RAG Guide is the most direct internal reference because it focuses on enforcing user permissions at retrieval rather than at display time.

Risk and Threat Considerations

Frontend-only authorization creates a disclosure risk because any alternate path to the retrieval backend can bypass the UI and expose data that should be filtered out. In RAG, that often means the sensitive material is not the final answer alone, but the retrieved context, source document, or embedding-backed match that fed the answer.

Failure mechanism: the backend accepts requests without re-checking entitlements, so direct API calls, alternate clients, or reused tokens can retrieve restricted content even when the frontend would have hidden it.

Impact: users can see data outside their permission scope, and the model may then incorporate that data into an answer, audit trail, export, or downstream workflow. Once the backend returns the wrong rows or passages, the security failure is already durable.

Practitioner Guidance

What to verify: Confirm that the retrieval service, index query, or database call enforces the same authorization rule the UI displays. If the backend cannot prove that it filtered the result set, treat the control as missing.

Decision rule: If the data source can be reached by anything other than the browser, authorization belongs on the server side and must be evaluated at retrieval time. UI checks can improve user experience, but they are not a security boundary.

Practitioner takeaway: In RAG, authorization is only real when the system that returns the content is the system that checks permission.

Related resources from NHI Mgmt Group

• What breaks when AI security is measured but not enforced?
• What breaks when segregation of duties is not enforced in identity governance?
• What breaks when token binding is absent from API authorisation?
• What breaks when retrieval permissions are too broad in RAG?