Keep authorisation data out of user-editable claims and place it in server-issued metadata before the database evaluates access. In practice, that means using a token hook or equivalent trusted issuance step, then referencing only immutable claims in row-level security policies for retrieval.
Why JWT claims should not be the source of authorisation truth
JWT claims are useful for carrying identity context, but they are a poor place to let end users influence retrieval authorisation. If a claim can be edited by the caller, copied across sessions, or interpreted too early in the request path, it can become the decision point instead of a trusted input. RAG systems should treat claims as input to trust evaluation, not as the policy itself.
That distinction matters because retrieval authorisation is often enforced before the model ever sees content. If the claim carries the user’s entitlement directly, any weakness in token issuance, claim validation, or downstream policy logic can turn into over-broad retrieval.
For teams designing this control, the safest pattern is to separate assertion from authorisation. A token may identify the requester, but the data that decides what can be retrieved should come from trusted server-side state that the user cannot edit.
How to place trust in server-issued metadata instead
The practical pattern is to move authorisation facts into metadata created or refreshed by the server, then reference only those immutable fields in the retrieval policy. A token hook, enrichment step, or equivalent trusted issuance control can stamp the attributes that the policy engine will later consume. That keeps the policy tied to a trusted source of truth rather than to whatever the client presented.
This is especially important when the policy depends on row-level security or similar database controls. If the database evaluates access using stable metadata rather than user-editable claims, the retrieval layer can enforce consistent scope without relying on application code to reinterpret every token at runtime.
Teams should also distinguish between identity-bearing claims and decision-bearing metadata. A claim may say who the caller is, while the metadata says what that caller is allowed to retrieve. When those are separated, the same token can still support authentication and tracing without becoming a privilege container.
What this means for RAG retrieval policies
RAG pipelines tend to fail in predictable ways when authorisation is bolted on after indexing or scattered across application logic. The strongest design is to evaluate permissions at retrieval time, against immutable attributes that reflect the current server-side view of entitlements. That reduces the chance that a user can expand their own access by modifying a claim, replaying an older token, or exploiting a mismatch between application and database policy.
It also keeps the access decision close to the data. When retrieval is governed by the same trusted metadata that the database sees, the enforcement point is easier to reason about and audit. In practice, that is more reliable than trying to infer permissions from claim content alone, especially in multi-tenant or fine-grained document environments.
For architectures that use multiple services, the design should preserve a single authoritative authorisation source. Upstream services can enrich or normalize identity context, but the final retrieval decision should come from the trusted server-issued attributes that the policy engine actually enforces.
Risk and Threat Considerations
When users can influence JWT claims that later affect retrieval, the main risk is privilege inflation: the caller can appear entitled to data that should remain hidden. The same weakness can also create lateral exposure across tenants, collections, or document classes if the database policy trusts claim content too early or too directly.
Failure mechanism: the system treats caller-supplied or caller-influenced claims as authoritative authorisation input, so any tampering, replay, stale-token use, or claim mismatch can expand what the retrieval layer returns.
Impact: over-broad RAG results, data leakage, broken tenant separation, and audit uncertainty about whether access was granted by policy or by token manipulation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWT claim handling depends on secure token and claim lifecycle controls. |
| AC-6 — Least Privilege | RAG retrieval should expose only the minimum data allowed by trusted policy. | |
| IA-9 — Service Identification and Authentication | Server-side issuance and policy evaluation depend on trusted service-to-service identity. | |
| Recommendation — Manage token issuance, rotation, and validation so claims cannot expand access improperly. Apply least privilege in retrieval policies and keep entitlement data server-controlled. Authenticate policy and database services so retrieval decisions rely on trusted identity context. | ||
| OWASP ASVS | V8 — Authorization | The core issue is preventing client-controlled claims from driving access decisions. |
| Recommendation — Enforce authorization from server-side policy, not from user-editable token content. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | User-influenced claims can elevate access to protected retrieval functions or scopes. |
| Recommendation — Bind retrieval actions to server-side authorization checks instead of caller-controlled claims. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-03 — Device and User Authentication | Trusted identity context must be established before policy decisions consume it. |
| Recommendation — Separate authentication context from authorization data and evaluate both at the policy layer. | ||
Practitioner Guidance
What to prioritise: keep the retrieval decision dependent on server-issued metadata, not on fields a user can alter or influence. If the database or policy engine cannot explain where each entitlement value came from, the control is too weak to trust.
What to verify: confirm that the trusted issuance step is the only place where authorisation attributes are created or refreshed, and verify that row-level security reads only immutable claims or server-stamped metadata. A token that still authenticates the user is fine; a token that defines access scope is the problem.
Common mistake: teams often validate the JWT signature and stop there. Signature validity proves origin, not that the embedded authorisation claims are the right source of truth for retrieval.
Practitioner takeaway: the right boundary is not “JWT versus no JWT”, it is “user-editable input versus server-issued decision data”; keep that boundary explicit or RAG authorisation will drift into claim trust.
Related resources from NHI Mgmt Group
- How should security teams prevent unauthenticated users from changing IoT device settings through weak access control?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- What do teams get wrong about JWT claims?