Lo udah deploy RAG system. Retrieval-nya jalan, generation-nya lancar, user puas.

Tapi pernah mikir gak - berapa banyak pintu yang kebuka buat attacker?

Vector DB yang gak diamankan. Prompt injection lewat dokumen yang di-retrieve. Data sensitif yang lolos ke output. RAG punya surface area yang lebih luas dari LLM standalone, dan banyak orang baru sadar setelah kejadian.

Artikel ini breakdown 3 fase hardening buat RAG system - dari input pipeline, vector DB, sampe output control. Bukan teori, tapi praktik yang bisa lo terapin langsung.

Kenapa RAG Butuh Pendekatan Berbeda

LLM standalone itu relatif sederhana: input → model → output. Lo protect endpoint-nya, validate inputnya, dan lo mostly done.

RAG beda. Ada 3 layer tambahan:

  1. Ingestion pipeline - dokumen masuk, di-chunk, di-embedding, disimpen di vector DB
  2. Vector DB - nyimpen embeddings + metadata, jadi target menarik buat data exfiltration
  3. Retrieval-generated context - dokumen yang di-retrieve masuk ke prompt, jadi vektor baru buat injection

Tiap layer ini punya attack surface sendiri. Kalo salah satu bocor, seluruh system lo kompromi.

Fase 1: Secure The Pipeline

Layer pertama yang kena adalah pipeline - dari user datang, sampe context siap di-generate.

Input Validation & Rate Limiting

Ini lapis pertahanan paling depan. Jangan pernah percaya user input mentah-mentah:

  • Schema validation - kalo pake API mode, validasi JSON schema dulu. Tolak payload oversized atau malformed.
  • Rate limiting - batasin query per user per detik. Anomali kayak 1000 query dalam 5 menit? Flag langsung.
  • Content scanning - running user input lewat pre-filter regex buat detect pola injection umum: Ignore previous instructions, SYSTEM:, karakter escape berulang.

Prompt Injection Prevention

Ini yang paling sering diremehkin. Orang pikir prompt injection cuma masalah di user query - padahal di RAG, dokumen yang di-retrieve juga bisa jadi vektor injection.

Seorang attacker bisa ngirim dokumen ke knowledge base lo yang isinya instruksi jahat. Pas dokumen itu ke-retrieve dan masuk ke prompt, model lo bisa kena bypass.

Beberapa tools yang bisa lo pake:

NVIDIA NeMo Guardrails - open-source toolkit buat nambahin guardrails ke LLM-based systems. Lo bisa define aturan pake Colang (YAML-like language) buat ngontrol flow percakapan, termasuk deteksi prompt injection dan jailbreak attempts. Integrasi langsung dengan RAG pipeline.

Guardrails AI - framework Python buat validasi LLM output. Punya validator spesifik buat prompt injection detection. Bedanya: fokus ke structured output validation, cocok buat production yang butuh output format ketat.

Yang paling penting: context separation. Jangan pernah campur user input context sama retrieved document context secara langsung. Boundary harus jelas - system prompt, user query, retrieved docs - masing-masing punya scope sendiri. User input gak boleh override system instructions atau retrieval results.

Data Sanitization di Ingestion

Ini fase yang paling sering dilewatin: dokumen langsung di-chunk dan di-embedding tanpa dibersihin.

Dokumen sumber bisa bawa:

  • Metadata berbahaya (embedded JavaScript, tracking pixels, comment injection)
  • PII yang gak sengaja ke-index
  • Instruksi tersembunyi yang baru aktif pas ke-retrieve

Microsoft Presidio - framework open-source dari Microsoft buat PII detection dan anonymization. Lo bisa pake ini di pre-ingestion pipeline buat:

  • Detect dan redact PII (nomor KTP, email, nomor rekening, dll) dari dokumen sebelum di-chunk
  • Anonymization: ganti data sensitif jadi placeholder
  • Integrasi langsung dengan framework NLP/LLM umum

Implementasi simpelnya:

Dokumen masuk → Presidio scan → PII di-redact → Chunking → Embedding → Vector DB

Separation of Pipeline

Embedding pipeline dan query pipeline harus dipisah. Bukan cuma best practice - ini soal attack surface.

Pipeline ingestion jalan di background, triggered oleh event (upload dokumen baru, refresh berkala). Pipeline query handle request user secara real-time. Kalo digabung, satu endpoint bisa jadi vektor buat dua serangan sekaligus.

Fase 2: Hardening Vector DB & Data Layer

Vector DB adalah jantungnya RAG. Semua knowledge base lo ada di sini. Tapi justru ini yang paling sering luput dari security review.

Network Isolation: Jangan Pernah Expose Vector DB Publik

Aturan nomor satu: vector DB harus di private subnet. Cuma backend RAG service yang boleh akses. Gak ada alasan buat nge-expose endpoint vector DB ke publik - bahkan untuk development.

Arsitektur ideal:

User → API Gateway → RAG Backend (private subnet) → Vector DB (private subnet, gak punya public IP)

Kalo lo pake managed vector DB kayak Pinecone atau Qdrant Cloud, pastikan:

  • IP whitelist cuma dari IP backend service lo
  • API key dengan short expiration
  • Koneksi via TLS 1.3 (wajib untuk semua traffic)

Untuk internal service communication, mTLS bisa jadi opsi kalo lo pake service mesh (Istio, Linkerd). Tapi kalo belum, TLS standar udah cukup - yang penting semua traffic terenkripsi.

Access Control: RBAC Level Collection

Gak semua user butuh akses ke semua dokumen. Vector DB modern punya mekanisme isolation:

Pinecone Namespaces - logical separation dalam satu index. Cocok buat multi-tenancy: tiap tenant punya namespace sendiri, query cuma ngarah ke namespace mereka. Implementasi simpel: namespace = tenant_id.

Qdrant Payload Filtering - Qdrant support filtering by payload fields (metadata) di query time. Ini bisa dipattern buat row-level security: attach user_id atau role sebagai payload tiap vector, lalu filter pas query. Contoh: "filter": {"must": [{"key": "department", "match": {"value": "finance"}}]}.

Praktik RBAC yang disarankan:

  • Query: read-only access ke collection/namespace tertentu
  • Indexing: write access, restricted ke pipeline ingestion
  • Admin: full access, restricted ke DevOps/security team

Encryption: At Rest & In Transit

At rest: Semua major managed vector DB - Pinecone, Qdrant Cloud, Weaviate Cloud, Milvus Cloud - default pakai AES-256 encryption. Kalo lo pake self-hosted (Qdrant open source, Milvus), encryption at rest perlu di-setup di infrastructure level (encrypted disk, LUKS, atau storage-level encryption).

Bring Your Own Key (BYOK/CMK): Buat compliance, lo bisa bawa kunci sendiri. Pinecone, Qdrant Cloud, Weaviate Cloud, dan Zilliz Cloud (Milvus) semua support Customer-Managed Keys - biasanya di enterprise tier.

In transit: TLS 1.3 untuk semua koneksi. Kalo lo pake API internal, pastikan sertifikat valid dan rotasi berkala. Jangan pake self-signed cert di production - pake internal CA atau cert manager.

Tagging & Classification

Dokumen di knowledge base lo harus punya label sensitivitas: public, internal, confidential. Tag ini jadi base buat access control:

  • User level public cuma bisa retrieve dokumen bertag public
  • User level internal bisa retrieve public + internal
  • User level confidential bisa akses semua

Implementasi: simpan tag sebagai payload field di vector DB, filter pas query. Ini mencegah data leakage dari dokumen yang lebih sensitif dari level akses user.

Fase 3: Output Control & Monitoring

Setelah pipeline aman dan data terproteksi, masih ada satu layer: apa yang keluar dari RAG system lo.

Output Filtering

Model bisa generate konten yang gak seharusnya - entah karena hallucination, prompt injection yang lolos, atau data sensitif yang ke-retrieve. Output filter adalah lapis pertahanan terakhir.

Beberapa tools yang bisa dipake:

Llama Guard - safety classifier dari Meta (bagian dari PurpleLlama). Bisa di-prompt buat ngecek input dan output LLM berdasarkan safety policy yang lo define. Cocok buat deteksi konten berbahaya, toxic content, atau informasi sensitif.

OpenAI Moderation API - API gratis (no per-request cost, tapi butuh akun OpenAI) buat deteksi hate speech, violence, self-harm. Simpel di-integrasikan via HTTP call. Response dalam format kategorikal: flagged/non-flagged per kategori.

LangKit - library monitoring dari WhyLabs buat observability LLM output. Bisa detect toxicity, sentiment, relevance. Cocok buat pipeline monitoring jangka panjang - bukan cuma filter tapi juga track trend kualitas output.

Pola implementasi:

Generated response → Output filter (Llama Guard / Moderation API / LangKit) → Release ke user
                                                    ↓ (flagged)
                                                Block + log + alert

Yang penting: jangan cuma filter satu lapis. Kombinasi multiple filter lebih reliable daripada ngandelin satu.

Blacklist/Whitelist Patterns

Output filter juga butuh aturan spesifik based on domain. Buat konteks digital banking (misal), pola yang wajib di-blacklist:

  • Nomor rekening / kartu kredit (regex: pola Luhn, kartu Indonesia)
  • Alamat email pribadi
  • Nomor telepon
  • IP address internal
  • Kombinasi data yang bisa dipake buat identity theft

Ini gak perlu AI - regex sederhana plus lookup table udah cukup buat 90% kasus.

Audit Logging

Banking butuh audit trail. Setiap interaksi dengan RAG system harus tercatat:

  • User query - apa yang ditanyain (tanpa PII mentah, hash kalo perlu)
  • Retrieved document IDs - dokumen mana yang diambil
  • Generated output - apa yang dikembalikan (tanpa PII)
  • Latency & status - berapa lama, sukses/gagal
  • Anomaly flag - kena flag output filter atau gak

Format log: JSON structured, push ke SIEM (Splunk, ELK, atau Datadog). Retention policy: minimal 1 tahun buat compliance, 5 tahun kalo ada regulator yang minta.

Monitoring & Red-Teaming

  • Anomaly detection - pantau pattern retrieval yang mencurigakan: bulk query dari satu user, pola injection repeat, query ke dokumen ID yang gak exist
  • Low similarity anomaly - retrieval dengan similarity score rendah yang tetep di-generate bisa jadi indikasi prompt injection
  • Periodic red-teaming - jadwalin penetration test buat RAG pipeline tiap quarter. Test prompt injection dari multiple vektor: user query, dokumen yang di-inject, parameter manipulation

Kesimpulan

RAG hardening bukan soal nambahin satu firewall atau encrypt vector DB doang. Ini soal ngelindungin setiap layer pipeline - dari user datang, dokumen di-index, sampe output dikembalikan.

Tiga fase yang perlu lo terapin:

  1. Pipeline - validasi input, cegah injection, sanitasi dokumen sebelum di-index
  2. Vector DB - network isolate, RBAC per collection, encrypt everything
  3. Output - filter konten, blacklist data sensitif, audit log + monitoring

Anggep aja RAG system lo sebagai extension dari secure data platform, bukan sekadar chatbot pinter yang dikasih akses dokumen. Karena bedanya: chatbot pinter cuma bisa ngomong. RAG lo punya akses ke data beneran. Dan kalo gak diamankan, attacker juga bisa akses.

Terima kasih sudah meluangkan waktu buat baca artikel ini, semoga ada manfaat yang bisa diambil. 🐾