JWT RBAC payload filters - documentation needed

[livnatzeira]

Hi,
I'm looking to enforce tenant isolation at the Qdrant level using JWT RBAC.
I found references to "payload filters" in JWT tokens:

• GitHub issue [RBAC] Tracking issue #3777 mentions "subsets of data - by payload filters"
• GitHub issue removing all unwraps and expects by adding more errors instead. #189 confirms payload filters work with write access
  But I cannot find documentation on the actual JWT claim format.

Questions:

1. Does JWT RBAC support payload filters? Can I create a token that automatically applies a filter (e.g., tenant_id IN [list]) to every query?
2. What is the JWT claim syntax? Running Qdrant 1.16.3 with jwt_rbac: true. What should the token payload look like?
3. Can it filter by multiple values? (e.g., tenant_id IN [t1, t2, t3])

Example of what I'm hoping exists
token = jwt.encode({ "access": "r", "payload_filter": { # <-- Is this the right format? "must": [{"key": "tenant_id", "match": {"any": ["t1", "t2", "t3"]}}] }}, api_key, algorithm="HS256")

Any pointers to documentation appreciated!

[generall]

Payload filters were deprecated in https://github.com/qdrant/qdrant/releases/tag/v1.16.0 as they had problems with write operations we could not easily solve.

[livnatzeira]

Thank you for the response!
So tenant separation inside a single channel (the recommended way) can only be in application level, is that correct?

[generall]

as of now, yes

[darfaz]

Tenant isolation at the vector DB level is critical for multi-tenant RAG applications — good that you're looking at JWT RBAC for this.

Your JWT payload format looks close. Based on the Qdrant docs and source code, the claim structure for payload-based access control uses the access claim with collection-specific filters. Something like:

{
  "access": [
    {
      "collection": "my_collection",
      "access": "r",
      "payload": {
        "must": [
          { "key": "tenant_id", "match": { "any": ["t1", "t2", "t3"] } }
        ]
      }
    }
  ]
}

Check the JWT auth docs — the payload filter syntax mirrors the standard filtering API.

One thing to keep in mind: JWT-based tenant isolation protects at the query level, but if your RAG pipeline lets users influence what gets written to the vector store (e.g., through document uploads), you also need to ensure tenant_id is correctly tagged at ingestion time and can't be spoofed.

Also worth considering: even with perfect tenant isolation at the DB level, the LLM itself can still leak cross-tenant data if it's shared. If the retrieved context from one tenant's query ends up in a shared model's context window alongside another tenant's data (e.g., through conversation history), you have a data leakage risk. Adding guardrails at the LLM layer to scan for cross-tenant data exposure is good defense in depth.