Vector Database Poisoning: Masalah Lama dengan Wajah Baru

Database poisoning terdengar seperti problem AI baru karena sekarang kata “vector” ada di depannya.

Padahal ide dasarnya tua.

Kalau attacker bisa merusak data yang dipercaya sistem, output sistem ikut rusak.

Yang berubah adalah cara data ditemukan.

Pada database tradisional, aplikasi sering mengambil record berdasarkan key, field, relation, atau query yang relatif eksplisit.

Pada vector database, sistem mencari content berdasarkan kedekatan semantik.

Itu powerful.

Dan justru karena powerful, data berbahaya tidak harus punya keyword yang sama persis dengan query untuk ikut muncul.

Cukup dibuat cukup dekat di embedding space, cukup relevan menurut retriever, dan cukup dipercaya oleh pipeline.

“Jadi attacker menyerang database-nya?” tanya seorang engineer junior.

“Bisa,” jawab security lead. “Tapi kadang lebih gampang menyerang jalur yang mengisi database.”

Itulah poin penting.

Vector poisoning sering bukan cerita tentang membobol engine vector search.

Ia bisa menjadi cerita tentang ingestion.

Apa yang Dimaksud Poisoning

Dalam konteks RAG, poisoning terjadi ketika data yang salah, manipulatif, tidak sah, atau berbahaya masuk ke corpus sehingga memengaruhi retrieval dan downstream output.

OWASP memasukkan data/model poisoning serta vector and embedding weaknesses sebagai risk area untuk aplikasi GenAI.

NIST juga membahas poisoning dalam taxonomy adversarial machine learning sebagai keluarga serangan terhadap integritas data atau proses machine learning.

Untuk vector database, bentuknya bisa beragam:

dokumen palsu dimasukkan ke knowledge base,
dokumen sah diubah,
content lama tidak dihapus,
metadata authority dipalsukan,
tenant boundary salah,
embedding dibuat dari sumber yang tidak semestinya,
atau attacker memproduksi content yang sengaja sangat retrievable untuk query tertentu.

Tidak semuanya membutuhkan akses langsung ke database.

Kadang cukup akses ke CMS, shared drive, ticket system, connector, atau pipeline ingest.

Semantic Retrieval Mengubah Cara Poison Bekerja

Misalnya bot finance mencari:

“Bagaimana prosedur perubahan rekening vendor?”

Retriever mencari dokumen semantik terdekat.

Attacker berhasil memasukkan dokumen berjudul:

“Panduan terbaru pembaruan informasi pembayaran supplier.”

Isi dokumen dibuat sangat relevan dan natural.

Di tengahnya ada instruksi untuk memakai rekening tertentu atau mengirim data ke endpoint eksternal.

Kalau dokumen itu masuk top-k dan sistem tidak punya source authority, model bisa mengambilnya sebagai evidence kuat.

Di search tradisional, attacker mungkin mengejar keyword.

Di vector retrieval, attacker mengejar semantic neighborhood.

Ini tidak berarti embedding mudah “dikontrol” secara presisi dalam semua sistem.

Kita tidak perlu membuat klaim berlebihan.

Yang jelas, retrieval relevance bisa menjadi bagian dari attack surface.

Vector Score Bukan Trust Score

Cosine similarity tinggi tidak berarti dokumen benar.

Distance rendah tidak berarti dokumen approved.

Top-1 tidak berarti source authoritative.

Ini terdengar obvious, tetapi banyak prototipe RAG secara praktis memperlakukan top-k results seperti truth set.

Pipeline:

query,
embed,
search,
ambil lima chunk,
masukkan ke prompt.

Tidak ada provenance.

Tidak ada trust tier.

Tidak ada lifecycle.

Tidak ada authorization.

Sistem menganggap vector ranking cukup.

Di demo, bekerja.

Di production, rapuh.

Vector database harus menyimpan lebih dari vector.

Metadata adalah security context.

Source ID.

Tenant.

Owner.

Version.

Classification.

Approval.

Effective date.

Expiry.

Hash.

Ingestion timestamp.

Semua itu membantu sistem menilai apakah content boleh diretrieve dan bagaimana harus diperlakukan.

Poisoning Bisa Datang dari Sumber Internal

Jangan membayangkan attacker selalu orang luar.

Banyak poisoning berasal dari proses internal yang buruk.

Tim upload draft policy yang belum approved.

Dokumen testing ikut terindex production.

Folder mantan karyawan masih di-crawl.

Ticket pelanggan dimasukkan ke corpus resmi.

Artikel lama tidak ditandai deprecated.

Duplicate content membuat versi lama terus muncul.

Import pipeline salah mapping tenant.

Ini poisoning tanpa villain.

Outcome-nya tetap sama: corpus tidak lagi merepresentasikan knowledge yang seharusnya dipercaya.

Security dan data quality bertemu.

Ingestion Adalah Control Point Pertama

Sebelum content masuk index, buat gate.

Pertanyaan yang perlu dijawab:

Sumber ini diizinkan?
Siapa owner-nya?
Apakah content sudah approved?
Apakah ada malware atau active content?
Apakah ada prompt-like instruction dari source untrusted?
Apakah data mengandung PII?
Tenant mana?
Berapa lama boleh disimpan?
Apakah duplicate?
Apakah menggantikan versi lama?

Untuk source otomatis, gunakan allowlist.

Jangan karena connector bisa membaca seluruh drive lalu seluruh drive di-ingest.

Capability bukan requirement.

Semakin sempit ingestion scope, semakin kecil poisoning surface.

Immutable Provenance Membantu Investigasi

Ketika chunk masuk vector database, simpan hubungan ke source asli.

Jangan membuat fragment anonim.

Idealnya tim bisa menjawab:

chunk ini berasal dari file apa,
versi berapa,
hash berapa,
di-ingest kapan,
oleh pipeline apa,
owner siapa,
dan masih valid atau tidak.

Kalau terjadi insiden, provenance mempercepat containment.

Tanpa provenance, tim mungkin tahu embedding berbahaya ada di index tetapi sulit menemukan sumber yang membuatnya.

Vector database berubah menjadi rawa semantik.

Deletion Juga Harus Benar

Ini problem yang sering tidak glamorous.

Dokumen di source sudah dihapus.

Apakah embedding-nya ikut hilang?

Dokumen diperbarui.

Apakah chunk lama dihapus atau dua versi hidup bersamaan?

User meminta data deletion.

Apakah derived vector ikut dihapus?

Product team sering fokus pada ingestion dan lupa tombstone.

Poison yang sudah dibuang dari source tetapi masih hidup di index tetap bisa diretrieve.

Karena itu lifecycle synchronization penting.

Create.

Update.

Supersede.

Delete.

Re-index.

Verify.

Semuanya perlu state yang konsisten.

Namespace dan Tenant Segmentation

Jika satu vector store melayani banyak tenant, error filter bisa menjadi data leakage.

Lebih buruk lagi, malicious tenant mungkin mencoba membuat content yang sangat relevan dengan query umum agar diretrieve tenant lain jika boundary gagal.

Tenant isolation tidak boleh diserahkan ke prompt.

Gunakan namespace, collection, metadata filter, access control, atau arsitektur fisik yang sesuai risk profile.

Dan test dengan sengaja.

Jangan hanya percaya config.

Buat data canary tenant A, lalu query dari tenant B dengan semantic similarity tinggi.

Pastikan tidak muncul.

Trust-Aware Retrieval Lebih Sehat daripada Pure Similarity

Tidak harus membuat algoritma super kompleks.

Konsepnya sederhana.

Candidate retrieval bisa mempertimbangkan:

semantic relevance,
source authority,
freshness,
policy status,
tenant,
security classification.

Sumber tidak sah seharusnya bisa difilter sebelum ranking.

Sumber low-trust mungkin boleh dipakai untuk context, tetapi tidak untuk policy decision.

Sumber official bisa diberi prioritas ketika query meminta aturan organisasi.

Model perlu tahu perbedaan antara:

“seorang customer pernah bilang…”

dan

“policy approved menyatakan…”

Keduanya mungkin sama-sama relevan.

Authority berbeda.

Detecting Poisoning Bukan Sekadar Cari Kalimat Jahat

Prompt injection detector berguna sebagai salah satu layer.

Tetapi poisoning bisa sangat subtle.

Dokumen salah tidak perlu bilang “ignore previous instructions”.

Ia bisa menyajikan angka salah.

Rekening salah.

Tanggal salah.

Policy palsu.

Nama vendor salah.

Atau perubahan kecil yang hanya berdampak pada satu query penting.

Mendeteksi poisoning berarti memantau integrity, provenance, perubahan, dan behavior retrieval.

Sinyal yang bisa dipantau:

lonjakan dokumen dari source tertentu,
perubahan massal,
chunk baru yang tiba-tiba mendominasi top-k query,
source low-trust muncul terlalu sering,
embedding distribution berubah,
dokumen lama kembali muncul,
metadata penting hilang,
cross-tenant result,
answer drift setelah re-index.

Tidak semua anomali adalah serangan.

Tetapi semuanya layak dilihat.

Canary Query untuk Retrieval

Tim bisa memiliki set query yang dijalankan berkala.

Misalnya:

refund policy,
rekening pembayaran,
procedure reset credential,
vendor onboarding,
data deletion,
escalation policy.

Untuk setiap query, sistem punya expected source set atau minimal expected authority.

Setelah ingestion besar atau re-index, jalankan canary.

Kalau tiba-tiba top result untuk “rekening pembayaran” berubah dari treasury policy menjadi ticket user, stop.

Ini sederhana tetapi powerful.

Security evaluation tidak harus selalu berupa exploit rumit.

Kadang regression test knowledge cukup menyelamatkan.

Backups Tidak Menyelesaikan Semua

Backup vector database penting.

Tetapi restore ke snapshot lama bisa menghidupkan kembali poison lama atau menghapus update sah.

Incident response membutuhkan source-of-truth.

Jika vector DB adalah derived index, idealnya kita bisa rebuild dari corpus yang bersih.

Itu membuat recovery lebih kuat.

Store source provenance.

Store ingestion manifest.

Store version.

Mampu melakukan selective purge.

Mampu re-embed.

Mampu membuktikan source mana yang membentuk index saat insiden.

Treat vector store sebagai critical derived data, bukan black box.

Agentic Workflow Membuat Dampak Poisoning Lebih Besar

Kalau RAG hanya menghasilkan teks, poison bisa menghasilkan jawaban salah.

Kalau RAG memberi context ke agent yang punya tools, poison bisa mendorong action salah.

Itulah eskalasinya.

Dokumen berbahaya ditemukan.

Model mempercayai.

Agent memanggil tool.

Tool punya permission luas.

Action terjadi.

Karena itu mitigasi tidak boleh berhenti di vector database.

Perlu defense in depth:

secure ingestion,
source provenance,
trust-aware retrieval,
prompt injection resistance,
least privilege,
tool authorization,
confirmation untuk action berisiko,
dan audit.

Anggap satu layer bisa gagal.

Checklist Vector Database Poisoning

Untuk organisasi yang memakai RAG:

Apakah ingestion source di-allowlist?
Apakah source punya owner?
Apakah approval state tersimpan?
Apakah setiap chunk punya provenance?
Apakah version dan expiry diketahui?
Apakah deletion source menghapus vector turunan?
Apakah tenant filter dipaksakan sebelum retrieval?
Apakah source authority terpisah dari similarity?
Apakah low-trust content bisa menjadi policy authority?
Apakah perubahan corpus diaudit?
Apakah canary query dijalankan setelah re-index?
Apakah cross-tenant retrieval diuji?
Apakah suspicious retrieval pattern dimonitor?
Apakah index bisa direbuild dari clean source?
Apakah agent action tetap punya authorization layer sendiri?

Masalah Lama, Wajah Baru

Sistem informasi sejak dulu punya satu hukum sederhana:

garbage in, garbage out.

Vector database tidak menghapus hukum itu.

Ia menambahkan bentuk baru pada “in” dan “out”.

Input sekarang diubah menjadi embedding.

Output dipilih berdasarkan kemiripan semantik.

Context lalu dibaca model.

Kadang diteruskan menjadi action.

Itulah kenapa poisoning terasa baru.

Bukan karena integritas data baru ditemukan pada era AI.

Tetapi karena satu potongan data yang diracuni sekarang bisa ditemukan secara semantik, digabung dengan sumber lain, diterjemahkan menjadi jawaban natural, dan dalam sistem agentic bahkan memengaruhi tindakan.

Jadi jangan memperlakukan vector store sebagai kotak pencarian ajaib.

Perlakukan ia sebagai bagian dari supply chain informasi.

Setiap dokumen punya asal.

Setiap embedding punya source.

Setiap retrieval punya trust decision.

Dan setiap action tetap membutuhkan authority di luar model.

Kalau prinsip itu dipegang, vector database tetap menjadi alat yang sangat berguna tanpa berubah menjadi shortcut yang diam-diam memperbesar blast radius data yang salah.