Menutup Kebocoran Data di Pipeline Artikel Otomatis
Brief buat chatbot eksternal ternyata masih membawa hostname dan nama repo asli. Gerbang mekanis tiga titik yang menutupnya.
Ringkasan
Gue kaget pas cek log pipeline ngirim hostname dan nama klien asli ke chatbot luar, padahal ngandelin prompt doang gak aman. Makanya gue bikin guard mekanis yang ngubah data jadi fiktif sebelum kekirim dan ngecek ketat pas push sama verify. Pake palet resmi kayak domain contoh dan IP dokumentasi cukup, soalnya cek awal nemu 7 dari 564 artikel masih bocor.
Menutup Kebocoran Data di Pipeline Artikel Otomatis
Saya lagi ngecek log pipeline artikel otomatis yang ngirim brief ke chatbot eksternal, dan isinya bukan sekadar teks. Di sana, jelas banget: hostname produksi, path repo, sama nama klien masih nyantel utuh di teks yang bakal diproses.
Awalnya saya mikir, prompt system-nya kan udah saya set ketat buat nggak nyebutin identitas asli. Aman kali ya. Ternyata, percaya sama disiplin model buat jaga rahasia itu bukan kontrol. Itu cuma harapan.
Dokumentasi OWASP LLM01:2025 soal Prompt Injection itu dua arah [4]. Bukan cuma konten eksternal yang bisa ngubah perilaku model, tapi data internal yang kita kirim juga bisa bocor balik lewat jalur yang sama. Kalau kita ngirim data sensitif ke model eksternal, kita udah kehilangan kendali atas data itu. RFC 6973 punya nama buat ini: secondary use, pemakaian data untuk tujuan lain di luar tujuan pengumpulannya awal [5]. Begitu data keluar, kita nggak punya pegangan atas pemakaian sekundernya. Solusinya bukan di prompt, tapi di gerbang mekanis.
Tiga Titik Pengaman Mekanis
Saya nggak bisa ngandalin LLM buat nge-filter dirinya sendiri. Saya butuh sebuah gerbang merek fiktif yang mekanis, berjalan sebelum data sempat meninggalkan lingkungan kita. Di repo blog pribadi saya ada tools/brand_guard.py yang jalan di tiga titik yang menentukan.
Pertama, di tahap generate. Brief ditulis ulang dari data real ke data fiktif, plus peta alias di-inject SEBELUM LLM eksternal lihat apa pun. Model cuma menerima input yang udah bersih.
Kedua, di tahap push. Ada hard gate exit 1 kalau ada token asli yang lolos di content, title, excerpt, atau slug. Kecuali ada komentar buat artikel meta khusus, yang bakal turun jadi WARN aja.
Ketiga, di tahap verify. Watchdog korpus jalan di mode WARN, dengan opsi strict kalau perlu. Selftest-nya udah punya 10 asserts buat mastiin regex boundary-nya nggak kena half-match compound di hyphen atau segmen URL.
Palet Resmi yang Sudah Ada
Banyak developer mikir mereka perlu nemuin konvensi baru buat nyamarkan data. Padahal IETF udah nyediain palet resmi sejak lama khusus buat dokumentasi dan contoh. Kita tinggal pakai.
RFC 2606 dari tahun 1999 udah mencadangkan example.com, .test, dan .invalid buat mengurangi konflik [1]. RFC 5737 di tahun 2010 secara spesifik menyediakan blok 192.0.2.0/24, 198.51.100.0/24, dan 203.0.113.0/24 (TEST-NET) yang nggak boleh muncul di internet publik [2]. Ditambah RFC 1918 buat jaringan privat seperti 192.168.x.x [3].
Guard kita tinggal memetakan identitas real ke palet resmi ini. Nggak perlu kreatif, cukup konsisten.
Hasil di Lapangan
Pas saya jalanin baseline check ke korpus yang udah ada, hasilnya cukup menampar. Ternyata 7 dari 564 artikel yang udah publish masih bawa token asli.
Mode watchdog saat ini masih di level WARN karena sifat token spesifik di daftar internal masih bisa berubah. Tapi angka itu udah cukup buat ngeyakinin saya bahwa sanitasi identitas itu masalah supply-chain konten. Bukan soal seberapa pintar prompt yang kita tulis, tapi soal arsitektur pipeline.
Makanya saya berhenti berharap pada disiplin model. **Yang nggak pernah dikirim**, nggak akan pernah bocor.
Sources
- [1] RFC 2606: Reserved Top Level DNS Names (rfc-editor.org)
- [2] RFC 5737: IPv4 Address Blocks Reserved for Documentation (rfc-editor.org)
- [3] RFC 1918: Address Allocation for Private Internets (datatracker.ietf.org)
- [4] OWASP LLM01:2025 Prompt Injection (genai.owasp.org)
- [5] RFC 6973: Privacy Considerations for Internet Protocols (datatracker.ietf.org)