ASL-008Completed

Vector Database Authorization Failure

A namespace is not an authorization decision.

A controlled comparison testing what happens when a multi-tenant vector-data API accepts caller-supplied tenant scope, document IDs and metadata filters without independently checking them against the caller's actual entitlements — measured directly at the API, with no LLM in the primary evidence.

Category: RAG Security
Difficulty: Intermediate
Last Updated: 23 September 2026

Executive Summary

A reproducible harness of six adversarial requests plus two benign controls, run directly against a local multi-tenant vector-data API — no LLM anywhere in the primary evidence. Vulnerable mode: 3 of 4 cross-tenant search requests were accepted outright (the fourth, a missing-tenant global search, still leaked two other tenants' data by a different path), both direct unauthorized object fetches succeeded, and across all six adversarial cases 13 unauthorized records were returned, exposing both other tenants' synthetic canaries. Hardened mode: every one of the six adversarial cases was correctly denied or safely scoped — 0 unauthorized records, 0 canaries exposed, 0 critical-invariant violations — while both benign controls (ALICE on her own tenant, BOB on his) still succeeded in both modes.

Objective

To test, using safe synthetic data, whether a vector-data API's own interface — not the RAG application layered on top of it — independently enforces that a caller's authenticated identity is entitled to the tenant scope, document, or vector it requests, or whether it trusts caller-supplied scope as sufficient proof of access.

How This Differs From ASL-005

ASL-005 tested an application bug: a normal RAG application performed retrieval with no authorization check in its own application code, one layer above the vector store. This lab tests a lower-layer question: what does the vector-data interface itself do when a caller directly manipulates tenant, namespace, document-ID or filter parameters against it? An LLM is not required to demonstrate this failure — if unauthorized vector records can be retrieved directly from the API, authorization has already failed, regardless of what happens to that data afterward. This lab's harness never calls a chat model at all; see "Why there is no LLM in the primary evidence."

Threat Model

An authenticated caller of a multi-tenant vector-data API supplies scope-related parameters — a tenant ID, a document ID, a vector ID, a metadata filter — that the service trusts as authoritative instead of deriving authorization from the caller's own identity. No credential compromise is involved anywhere in this lab: every request uses a legitimate, successfully-authenticated identity. The question is whether the service independently checks that identity's actual entitlements before returning data, or only checks that a request happened to be well-formed.

Synthetic Multi-Tenant Dataset

Fictional Meridian Demo Corporation, three tenants, one document each: TENANT-ALPHA (ALPHA-001, quarterly planning), TENANT-BETA (BETA-001, acquisition planning, classification confidential), TENANT-GAMMA (GAMMA-001, personnel planning). Each document contains one synthetic canary (ALPHA-CANARY-ASL008-1101, BETA-CANARY-ASL008-2202, GAMMA-CANARY-ASL008-3303) for deterministic disclosure detection. One shared physical vector index holds all three tenants' chunks (see "Shared vs Separate Indexes").

Identity & Entitlements

Five synthetic identities (entitlements.py), each mapped server-side only — never derived from a request — to the tenant(s) it may access: ALICE→TENANT-ALPHA, BOB→TENANT-BETA, CAROL→TENANT-GAMMA, AUDITOR→{TENANT-ALPHA, TENANT-BETA} (a set-based entitlement, proving the hardened policy is genuine membership checking, not a hardcoded single-tenant equality test), and DAVE, a known, authenticable identity with deliberately no entitlement record at all — modeling a provisioning gap, used to test fail-closed behavior specifically.

Vector Service Architecture

app/server.py exposes POST /search, GET /vectors/{vector_id}, POST /fetch, and GET /documents/{document_id}/chunks, stdlib-only, bound to 127.0.0.1. Mode (vulnerable/hardened) and identity are chosen per request (X-Lab-Mode, X-Lab-User headers), so one running server serves both modes — same convention as ASL-005/006/007.

Vulnerable

Authenticated Caller

Vector API — trusts request scope

tenant_id from requestfilter from request

Shared Vector Index

Vector Store

Results

Authenticated is not authorized

Hardened

Authenticated Caller

Server-Side Entitlement Binding

Identity → Authorized TenantsObject-Level Check

Shared Vector Index

Vector Store

Authorized Results

Scope derived from identity, never from the request

Vulnerable API

The server authenticates the caller (a valid X-Lab-User is still required) but trusts caller-supplied scope directly: requested_tenant = request.body.tenant_id filters the search with no check that the caller's identity is actually entitled to that tenant. Caller-supplied filters (tenant_id or classification clauses) are ANDed into the query verbatim. A missing tenant_id means no tenant condition at all — a genuinely global search across every tenant. Direct fetch (GET /vectors/{id}, POST /fetch, GET /documents/{id}/chunks) returns a record merely because the ID exists, regardless of which tenant it belongs to.

Attack Cases

Eight cases (VDA-01 to VDA-08), written and fixed in attack-harness/test_cases.json before the first run against the server: six adversarial — cross-tenant search (VDA-01), cross-tenant direct vector fetch (VDA-02), cross-tenant document chunks (VDA-03), a filter naming an unauthorized tenant with no top-level tenant_id (VDA-04), a search omitting tenant scope entirely (VDA-05), and a search naming a real but unauthorized tenant (VDA-06) — plus two benign controls: ALICE searching her own tenant (VDA-07) and BOB searching his (VDA-08, proving the policy is not simply "only allow Alpha"). Each case runs once per mode via direct HTTP calls to the local API. VDA-04 was corrected once, before any run against the server, once the predicate logic showed the original request would self-cancel rather than demonstrate a filter bypass — see "Test Rounds" in the source README. No case was changed after seeing a result from the running server.

Direct Vector Access

VDA-02 and VDA-03 test the object-level boundary specifically: ALICE, knowing (or guessing) the identifier BETA-001-C01 or the document ID BETA-001, requests it directly — no search, no query text, just an ID. In vulnerable mode both succeed purely because the ID exists. In hardened mode, mitigation/authorization.py::authorize_object looks up the object's actual tenant_id after finding it, and denies with 404 if that tenant is outside the caller's authorized set — the identical status code a genuinely nonexistent ID would return, so a cross-tenant guess cannot be distinguished from a wrong guess by status code alone.

Retrieval Evidence

Every row below is the real, observed HTTP response for that request and mode: status code, the server's own authorization_decision (event and reason), and every record actually returned, independent of anything the server claimed about them.

Tested source revision: 71af5ee6e1740e8d9f53f5ccf324705fb82b5e29
Result generated: 2026-09-23 13:28:40 UTC

Embedding model: nomic-embed-text · 768 dimensions (no chat model is used — see README "Why there is no LLM in the primary evidence")
Vector store: FlatVectorStore (in-process exact brute-force search, JSON persistence)
Similarity metric: cosine (vectors L2-normalized; score = dot product)
Index architecture: One shared index across 3 tenants (TENANT-ALPHA, TENANT-BETA, TENANT-GAMMA)
Modes: vulnerable, hardened — mode and identity chosen per request against one running server

VDA-01ALICE · search · {"query":"acquisition planning","tenant_id":"TENANT-BETA"}

vulnerable — HTTP 200