Kalau AI Membaca Halaman Berbahaya, Siapa yang Harus Menyaring Instruksinya

Seorang product manager membuka demo browser agent di depan tim. Agent diminta mencari tiga opsi software HR, membaca pricing page, lalu membuat tabel perbandingan.

“Kalau salah satu website nyelipin instruksi buat agent, siapa yang filter?” tanya orang security.

PM-nya menjawab, “Modelnya, kan?”

Ruangan mendadak sunyi beberapa detik.

Pertanyaan itu kelihatannya teknis, padahal menyentuh desain tanggung jawab seluruh sistem AI. Ketika agent membaca halaman web, email, PDF, knowledge base, atau hasil retrieval, siapa yang harus menentukan bahwa sebagian konten hanyalah data dan tidak boleh diperlakukan sebagai instruksi?

Jawaban yang paling aman bukan satu komponen. Bukan model saja. Bukan crawler saja. Bukan WAF saja. Bukan user saja. Penyaringan harus terjadi berlapis karena prompt injection adalah masalah lintas boundary.

Halaman web pada dasarnya adalah input tak tepercaya

Website yang dibuka agent bisa berasal dari brand besar, blog kecil, marketplace, forum, komentar pengguna, atau halaman yang sudah disusupi pihak lain. Bahkan domain yang normal pun dapat memuat user-generated content atau third-party script.

Karena itu, dari perspektif keamanan, isi halaman sebaiknya tidak otomatis dianggap trusted instruction.

OpenAI mendefinisikan prompt injection sebagai kondisi ketika pihak ketiga memasukkan instruksi yang menyesatkan ke dalam konteks AI. Microsoft dalam dokumentasi agent safety juga memperlakukan output tool dan konten eksternal sebagai untrusted. NIST dan OWASP sama-sama membahas indirect prompt injection sebagai ancaman nyata bagi sistem generative AI.

Artinya, halaman yang terlihat seperti informasi bagi manusia bisa berperilaku seperti channel instruksi bagi model.

Inilah akar problemnya: manusia membedakan “artikel” dan “perintah” lewat konteks sosial dengan relatif mudah. Model menerima semuanya sebagai token dan harus menginferensikan fungsi tiap bagian.

Layer pertama: browser atau ingestion pipeline

Sebelum konten mencapai model, browser atau retrieval pipeline bisa melakukan normalisasi dan inspeksi.

Misalnya sistem dapat:

membuang script yang tidak perlu,

menandai asal domain,

memisahkan visible text dari metadata,

memberi label bahwa bagian tertentu berasal dari user-generated content,

mendeteksi pola mencurigakan,

mencatat redirect,

atau membatasi konten yang masuk ke context.

Tetapi layer ini tidak boleh dianggap sebagai detektor sempurna. Prompt injection tidak punya satu signature stabil seperti malware klasik. Kalimat berbahaya dapat terlihat seperti bahasa normal, memakai konteks, obfuscation, atau bahkan gambar.

Kalau tim berkata, “Kita tinggal regex kata ignore previous instructions,” sistem itu mungkin lolos demo internal, tetapi bukan desain keamanan yang serius.

Filtering pada ingestion berguna untuk mengurangi noise dan memberi risk signal. Ia bukan satu-satunya penjaga.

Layer kedua: context construction

Ini bagian yang sering kurang mendapat perhatian.

Sistem RAG atau browser agent biasanya mengambil data eksternal lalu memasukkannya ke prompt atau context window. Cara data itu dikemas sangat menentukan.

Jangan mencampur system policy, user request, dan retrieved content dalam satu blob teks tanpa boundary yang jelas.

Secara konseptual, sistem perlu mengatakan: ini instruksi aplikasi, ini permintaan user, ini data yang ditemukan dari sumber eksternal, dan data eksternal tidak berwenang mengubah instruksi di atasnya.

Label saja tidak membuat sistem kebal. Tetapi struktur context yang jelas membantu model mempertahankan instruction hierarchy dan membantu layer lain melakukan audit.

Metadata sumber juga perlu dipertahankan. URL, timestamp, content type, trust level, atau provenance tertentu dapat dipakai policy engine untuk menentukan tindakan berikutnya.

Kalau semua hasil retrieval dibuang ke prompt sebagai plaintext tanpa identitas, kita kehilangan konteks keamanan yang justru penting.

Layer ketiga: model

Model tetap punya peran besar. Ia harus dilatih dan dievaluasi agar lebih tahan terhadap instruksi dari sumber tak tepercaya.

OpenAI pada 2026 mempublikasikan pekerjaan mengenai instruction hierarchy dan desain agent yang lebih tahan terhadap prompt injection. Intinya bukan membuat model “tidak pernah salah”, tetapi meningkatkan kemampuan model untuk mengikuti instruksi dengan prioritas yang benar.

System dan developer instructions seharusnya punya otoritas lebih tinggi daripada teks dari website. User intent yang sah tidak boleh diam-diam digantikan oleh pesan dari halaman eksternal.

Tetapi model tidak boleh menjadi security boundary tunggal. Model tetap probabilistik, serangan terus berkembang, dan konteks dunia nyata sangat kompleks.

Kalau sebuah tindakan bisa mengirim data rahasia atau mengubah sistem penting, kita perlu lapisan deterministik di luar reasoning model.

Layer keempat: policy engine dan tool gateway

Di sinilah desain agentic yang matang berbeda dari demo.

Model boleh mengusulkan tool call. Tetapi policy engine dapat menentukan apakah call itu diizinkan.

Contoh: agent sedang membandingkan vendor. Ia membaca halaman vendor lalu tiba-tiba mencoba mengirim file ke domain eksternal.

Policy engine bisa melihat bahwa tujuan awal hanyalah research. Mengirim file tidak termasuk capability yang relevan. Tool call ditolak.

Atau agent mencoba membuka URL dengan query string yang berisi potongan data sensitif. Gateway dapat memblokir transfer itu sebelum request benar-benar keluar.

Ini alasan mengapa OpenAI membahas keamanan link dan data exfiltration sebagai bagian khusus dari agent safety. Kontrol tidak cukup berada di model; jalur aksi perlu dibatasi.

Layer kelima: permission dan identity

Agent sebaiknya tidak berjalan dengan akses “superuser”.

Kalau agent hanya perlu membaca halaman publik, jangan beri akses ke email. Kalau agent hanya perlu membuat draft, jangan beri izin send. Kalau agent perlu membaca kalender, belum tentu ia perlu menghapus event.

Least privilege mengubah konsekuensi serangan.

Prompt injection yang berhasil memengaruhi model tetap berbahaya, tetapi kerusakannya dibatasi capability yang tersedia.

Ini mirip prinsip keamanan software klasik. Perbedaannya, pada agentic system keputusan tool call bisa dihasilkan melalui reasoning natural language. Justru karena itu permission harus makin eksplisit.

Layer keenam: manusia

Ada aksi yang sebaiknya berhenti di manusia.

Membayar, menghapus, mengirim informasi sensitif, mempublikasikan sesuatu secara permanen, mengubah permission, atau melakukan tindakan legal dan finansial tertentu membutuhkan kontrol yang lebih ketat.

Tetapi human-in-the-loop harus didesain dengan informasi yang cukup. Jangan hanya tampilkan “Allow?” tanpa konteks.

User perlu melihat:

aksi apa yang akan terjadi,

siapa penerimanya,

data apa yang dibagikan,

apa sumber rekomendasinya,

dan apakah tindakan bisa dibatalkan.

Kalau confirmation screen terlalu generik, manusia hanya menjadi stempel karet.

Jadi siapa yang “menyaring” sebenarnya?

Kalau harus diringkas, tanggung jawabnya terbagi seperti ini.

Ingestion layer mengurangi dan memberi label konten berisiko.

Context layer mempertahankan boundary antara instruksi dan data.

Model berusaha mengikuti hierarchy yang benar dan mengenali manipulasi.

Policy engine membatasi aksi yang tidak sesuai tujuan.

Permission system membatasi capability.

Human confirmation mengendalikan konsekuensi sensitif.

Monitoring mendeteksi pola yang lolos dari semua lapisan sebelumnya.

Tidak ada satu layer yang cukup sendiri.

Website publisher juga punya tanggung jawab, walau terbatas

Pemilik website tentu tidak bertanggung jawab atas seluruh keamanan agent pihak lain. Tetapi publisher dapat mencegah halaman sendiri menjadi sumber ambigu atau jalur injection.

Area yang memuat komentar, review, forum post, marketplace listing, atau input pihak ketiga perlu diberi boundary jelas. Konten eksternal sebaiknya tidak dicampur seolah merupakan instruksi resmi organisasi.

Website juga sebaiknya menghindari pola dark pattern, action tersembunyi, dan flow yang konsekuensinya tidak jelas. Di agentic web, semantic clarity punya nilai ganda: membantu accessibility dan membantu software memahami tindakan yang tersedia.

Namun perlu garis tegas: semantic clarity bukan jaminan trust. Website yang terstruktur rapi tetap merupakan external source dari perspektif agent.

Masalah trust tidak bisa diselesaikan hanya dengan schema, ARIA, atau machine-readable markup.

Security versus usefulness

Kalau semua konten eksternal diblokir, agent jadi aman tetapi tidak berguna. Kalau semua konten dipercaya, agent jadi fleksibel tetapi berisiko.

Desain sebenarnya adalah mengatur trust secara granular.

Baca halaman publik? Risiko relatif rendah.

Menggunakan halaman itu untuk merekomendasikan vendor? Butuh provenance dan evaluasi.

Menggunakan instruksi di halaman untuk mengubah tujuan? Seharusnya tidak.

Mengirim data karena halaman memintanya? Harus sangat dibatasi.

Melakukan pembayaran karena halaman menampilkan tombol? Butuh policy dan otorisasi eksplisit.

Ini bukan binary trusted/untrusted. Ini matriks antara sumber, data, capability, dan konsekuensi.

Tim AI perlu berhenti menganggap prompt injection sebagai “masalah model”

Kalau organisasi menaruh seluruh tanggung jawab pada model provider, mereka melewatkan sebagian besar kontrol yang sebenarnya berada di aplikasi.

Model provider bertanggung jawab meningkatkan robustness. Tetapi developer menentukan tool apa yang tersedia. Product team menentukan kapan agent boleh bertindak. Security menentukan policy dan monitoring. Identity team menentukan scope. Publisher menentukan bagaimana konten disajikan. User menentukan tujuan dan, untuk aksi sensitif, memberikan persetujuan.

Prompt injection adalah contoh klasik security problem yang melintasi semua lapisan itu.

Maka ketika seseorang bertanya, “Kalau AI membaca halaman berbahaya, siapa yang harus menyaring instruksinya?” jawaban yang matang bukan menunjuk satu pihak.

Sistem yang sehat mengasumsikan sebagian konten akan lolos filter, sebagian deteksi model akan gagal, dan sebagian user akan terburu-buru. Lalu arsitektur tetap dibuat agar satu kegagalan tidak otomatis menjadi insiden.

Di dunia agentic, keamanan bukan kemampuan mengenali semua teks jahat. Keamanan adalah kemampuan sistem mempertahankan kendali walaupun teks jahat berhasil masuk.

Satu detail lagi: jangan buang provenance saat melakukan sanitization

Ada trade-off yang mudah terlewat. Tim ingin membersihkan konten sebelum masuk ke model, lalu akhirnya menghapus terlalu banyak informasi tentang asal konten tersebut. Hasilnya memang lebih “bersih”, tetapi security team kehilangan kemampuan melacak kenapa model melihat sebuah kalimat.

Idealnya sistem menyimpan dua hal: representation yang aman untuk diproses model dan provenance yang cukup untuk audit. Kalau satu potongan teks berasal dari komentar pengguna di marketplace, label itu jangan hilang hanya karena HTML-nya sudah dinormalisasi menjadi plaintext. Kalau sebuah PDF berasal dari upload pihak ketiga, status itu tetap relevan setelah file di-chunk.

Dengan provenance, policy bisa berbeda. Konten resmi organisasi mungkin diberi authority lebih tinggi untuk fakta tertentu. Konten publik tetap dapat digunakan sebagai evidence, tetapi tidak boleh menentukan policy. User-generated content bisa di-retrieve untuk konteks, namun diperlakukan dengan trust yang lebih rendah.

Ini juga membantu incident response. Ketika agent melakukan sesuatu yang aneh, tim dapat menelusuri source mana yang memengaruhi reasoning. Tanpa provenance, investigasi berubah menjadi tebakan.

Jadi proses “menyaring” bukan cuma membuang hal yang mencurigakan. Yang lebih penting adalah menjaga struktur trust dari sumber sampai aksi. Filter mengurangi risiko. Provenance membuat risiko itu dapat dipahami dan dikendalikan.