Spring AI retrieval: apply the tenant filter before prompt assembly

Filter at retrieval time

A prompt saying only use north-tenant documents is not an access-control rule. Build a metadata filter from an authenticated tenant, pass it to the retrieval query, and inspect returned document ownership before prompt assembly. The filter must be supported by the chosen vector store and its index. The SQL tenant predicate is the analogous data rule for relational rows.

Control stale and empty evidence

An index can lag a document deletion or permission change. Decide whether sensitive removals block answering until reindex completes, or recheck document IDs against the authoritative store before use. When no authorized evidence remains, return an explicit no-evidence result rather than asking the model to invent an answer. The source kit has no vector store or model provider; this remains a design example.

Boundary sketch

tenant = verifiedPrincipal.tenantId();
query = vectorQuery.withFilter(
    metadata("tenant_id").equalTo(tenant));
documents = vectorStore.search(query);
assertAllBelongToTenant(documents, tenant);

Cost and verification

A selective metadata filter can reduce prompt tokens but may require a matching index and extra authorization reads. Similarity search itself does not guarantee permission or freshness. This sketch is not executed by the current Spring source kit; verify it against the chosen dependencies and deployment.

Common Mistakes

• Do not put the tenant rule only in the prompt.
• Do not trust a tenant string supplied by the question.
• Do not assume vector deletion is immediately visible without testing the selected store.

Read next

Spring method authorization: reject a cross-tenant read, Spring AI prompt injection: treat retrieved text as data, not authority, Spring AI conversation memory: partition by verified tenant and caller, Spring AI evaluations: separate model quality from enforced safety contracts.