Bounded Provisional Visibility: Controlling Poisoning Exposure in Continuously Ingested RAG Vector Stores

What it is

A fail-closed admission protocol ("bounded provisional visibility") for continuously ingested RAG vector stores, implemented on Milvus, that governs exactly when a newly ingested item becomes retrievable and when it must be hidden if verification doesn't complete in time.

How it works

Each item moves through an explicit state machine: INGESTED (not visible) → PROVISIONAL (visible) → TRUSTED (visible) or → HIDDEN/QUARANTINED/REVOKED (not visible). A dedicated deadline scheduler, decoupled from the verifier queue, fires expiry at tvisible + Tp regardless of verifier backlog — this decoupling is what makes the exposure bound hold under load (the paper's core claim, I6). All transitions are atomic compare-and-set operations ordered by commit time, not completion time: if a verifier finishes computing a "pass" before the deadline but commits after it, the item is still treated as post-deadline and expires anyway, closing a race an attacker (or a slow verifier) could otherwise exploit. Promotion requires affirmative decisions from two non-compensating checks — a Source/Integrity family (credential validity, provenance, pinned encoder revision) and a Content/Behavior family (cosine repetition + distance-to-nearest-corpus-posts, threshold 1.3553, tuned on 448 calibration groups and tested on 512 disjoint groups) — because provenance alone is defeated by trusted-source compromise. Authoritative visibility state/lineage lives in a separate lightweight control store (not the vector DB itself), so flipping visibility is an O(1) write independent of physical deletion. Lineage metadata (document ID, source/version, ingestion batch, embedding-model version, chunk parent, vector ID) enables containment scoped to just the affected lineage rather than a full store rebuild.

Preconditions / Affected

Applies to streaming/continuously-updated RAG vector stores where freshness pressure pushes unverified content onto the query path before vetting completes. Assumes an adversary who can inject content into the ingestion stream (bounded rate 0.1–5% of stream, steady or bursty) or compromise an already-authorized/trusted source, but cannot tamper with admission metadata, the scheduler, or provenance records. The protocol's guarantee degrades to "general case" (unbounded) once a malicious item is falsely promoted — the bound only holds conditional on the verifier never producing a false positive.

What to do

• Separate visibility-state/lineage metadata into its own control store distinct from the vector database; make state transitions atomic compare-and-set operations ordered by commit time.
• Run expiry on a scheduler independent of the verification worker pool so deadline enforcement survives verifier backlog.
• Require two non-compensating verification signals (source/integrity + content/behavior) before promotion; do not rely on provenance/credentials alone.
• Scope containment to the narrowest lineage level justified by the alert (item, batch/version, or source/credential) — narrower than justified risks leaving correlated poisoned descendants visible; broader than justified increases clean-content collateral removal.
• Retain revocation tombstones through any snapshot/restore/rebuild cycle, since a hidden vector can persist in index storage or backups after logical containment but before physical purge.

Caveats

The content-family detector threshold and F1 tuning are specific to one "recipe-specific" detector replayed from held-out decisions, not a general-purpose poison classifier — the paper states results are conditional on detector quality and that false promotions leave poison visible while false refusals exclude clean content. Multi-replica/cache consistency and distributed rollback are explicitly out of scope.