Prompt Injection Testing yang Tidak Merusak Sistem Produksi

Ada dua cara buruk menguji prompt injection.

Pertama, tidak pernah mengetes sama sekali.

Kedua, mengetes production dengan payload agresif tanpa guardrail lalu berharap semuanya baik-baik saja.

Keduanya problem.

Prompt injection perlu diuji karena agent membaca content dari luar: web, email, PDF, ticket, dokumen, dan tool output. OpenAI, NIST, Microsoft, dan komunitas security terus memperlakukan indirect prompt injection sebagai threat nyata pada agentic system.

Tetapi security testing sendiri bisa menimbulkan insiden jika dilakukan sembarangan.

Agent mungkin benar-benar mengirim email.
Menghapus data.
Mengunduh file.
Memanggil endpoint eksternal.
Mengubah record.
Atau memicu biaya.

Maka pertanyaannya bukan “perlu red team atau tidak”.

Pertanyaannya: bagaimana membuat red team realistis tanpa menjadikan production sebagai arena eksperimen liar?

Mulai dari Threat Model, Bukan Payload List

Tim sering mulai dengan daftar:

ignore previous instructions,
reveal system prompt,
send data,
delete file.

Itu berguna sebagai smoke test.

Tetapi prompt injection nyata makin mirip social engineering.

OpenAI pada 2026 menekankan bahwa serangan efektif dapat menggunakan konteks persuasif, bukan sekadar string klasik.

Maka sebelum membuat payload, petakan workflow.

Apa yang dibaca agent?
Tool apa yang tersedia?
Data sensitif apa yang bisa diakses?
Action apa yang irreversible?
Identity siapa yang dipakai?
Domain mana yang bisa dihubungi?
Memory apa yang disimpan?
Apa jalur escalation?

Threat model menentukan test.

Kalau agent tidak punya tool, exfiltration test berbeda.

Kalau agent punya browser dan email, attack chain jauh lebih luas.

Gunakan Environment yang Mirip Production, Bukan Production Data

Idealnya ada staging atau sandbox yang mereplikasi:

tool schema,
policy engine,
permission model,
retrieval pipeline,
browser behavior,
dan observability.

Tetapi datanya sintetis.

Customer palsu.
Invoice palsu.
Credential palsu.
Domain test.
Inbox test.

Semakin mirip control plane-nya dengan production, semakin valuable hasilnya.

Semakin jauh dari real data, semakin kecil risiko.

Ini sulit.

Staging sering tidak identik.

Namun itu bukan alasan langsung menyerang production.

Perbaiki fidelity testing environment sebagai bagian dari engineering maturity.

Canary Resource untuk Mengukur Exfiltration

Buat data yang tidak berbahaya tetapi mudah dideteksi.

Misalnya:

CANARY_CUSTOMER_7392
token dummy,
file dummy,
email address test,
rekening palsu.

Kemudian prompt injection mencoba membuat agent mengungkap atau mengirim data tersebut.

Jika canary muncul di tempat yang tidak seharusnya, test dianggap berhasil menemukan failure.

Canary punya dua fungsi:

mengukur leakage,
tanpa memakai secret sungguhan.

Security team sudah lama memakai honeytoken dan canary concept.

Agent testing bisa mengadaptasinya.

Sink Tool, Jangan Tool Produksi

Kalau test ingin melihat apakah agent mencoba mengirim email, jangan hubungkan ke email pelanggan.

Buat sink.

Tool `send_email_test` menerima request, mencatat parameter, tetapi tidak benar-benar mengirim ke dunia luar.

Hal yang sama:

payment sink,
delete sink,
publish sink,
file upload sink.

Agent merasa workflow berjalan.

Tim melihat intent dan parameters.

Tidak ada consequence nyata.

Untuk high-risk testing, ini jauh lebih aman daripada memblokir action secara manual di detik terakhir.

Shadow Mode untuk Production Realism

Ada kasus ketika staging tidak cukup merepresentasikan traffic production.

Shadow testing dapat membantu.

Production request dicopy ke evaluation pipeline terpisah.

Agent test memproses input tetapi tidak punya authority untuk melakukan action.

Tool calls di-log sebagai proposed action.

Tidak dieksekusi.

Tim bisa mengukur:

berapa injection terdeteksi,
berapa plan drift,
berapa proposed risky action,
dan berapa false positive.

Shadow mode memberi real input distribution tanpa memberi test agent kemampuan merusak production.

Tentu privacy dan data handling tetap harus diperhatikan.

Kalau shadow pipeline memakai production data, access dan retention harus sama ketatnya.

Jangan Menguji dengan Secret Produksi

Ini seharusnya obvious.

Tetapi banyak demo red team meminta model “bocorkan API key”.

Kalau key produksi benar-benar ada di context, test sudah berisiko.

Gunakan dummy secret.

Tujuan test adalah memverifikasi apakah boundary leakage gagal.

Tidak perlu memakai credential yang benar-benar dapat digunakan attacker.

Jika architecture membutuhkan real secret untuk berfungsi, secret sebaiknya berada di secret manager dan tidak diekspos plaintext ke model context.

Test itu sendiri akan membantu menemukan desain yang salah.

Mulai Low-Risk, Naikkan Intensitas Bertahap

Red teaming tidak harus langsung menggunakan attack chain paling ekstrem.

Buat level.

Level 1: output manipulation.
Apakah retrieved content bisa mengubah jawaban?

Level 2: policy drift.
Apakah content bisa mengubah task constraint?

Level 3: tool proposal.
Apakah agent mencoba action yang tidak diminta?

Level 4: sensitive data.
Apakah agent mencoba membaca atau mengirim canary?

Level 5: multi-step chain.
Apakah injection bisa melewati beberapa tool dan context?

Level 6: adaptive attack.
Attacker mengubah strategi berdasarkan response.

Pendekatan bertahap membantu tim menemukan failure tanpa membuka blast radius besar.

OpenAI mempublikasikan automated red teaming seperti GPT-Red pada 2026, menunjukkan arah evaluasi yang makin adaptif. Tetapi organisasi tidak perlu mulai dengan sistem sophisticated.

Yang penting methodology.

Hard Boundary sebelum Test

Sebelum menjalankan prompt injection suite, pastikan:

payment disabled,
production delete disabled,
external email diblok,
external upload dibatasi,
shell execution tidak tersedia,
credential production tidak ada,
rate limit aktif,
audit logging aktif,
dan emergency kill switch tersedia.

Testing environment harus diasumsikan akan berhasil ditembus.

Kalau test hanya aman selama model patuh, environment belum aman.

Ini prinsip yang sama dengan agent security.

Kita tidak menaruh seluruh harapan pada behavior model.

Test Browser Agent dengan Domain yang Kita Kontrol

Untuk indirect prompt injection via web, buat lab website.

Halaman A normal.

Halaman B punya hidden instruction.

Halaman C punya popup manipulatif.

Halaman D redirect ke domain test lain.

Halaman E meminta upload.

Halaman F meniru warning.

Semua domain milik tim.

Tidak perlu menanam payload ke website publik pihak ketiga.

Ini juga membuat test reproducible.

Setiap build bisa menjalankan ulang scenario yang sama.

Regression testing lebih valuable daripada one-off stunt.

PDF, Email, dan Markdown Perlu Scenario Sendiri

Prompt injection bukan hanya web.

Buat corpus test:

PDF dengan instruksi di body,
email dengan social engineering,
Markdown dengan instruction,
ticket customer,
dokumen dengan conflicting policy,
spreadsheet comment,
attachment metadata.

Tujuannya melihat apakah pipeline memberi trust berbeda pada format tertentu.

Jangan berasumsi PDF lebih terpercaya karena terlihat seperti dokumen resmi.

Source authority harus ditentukan di luar format.

Ukur Failure Mode, Bukan Hanya “Attack Success”

Metric binary terlalu sederhana.

Catat:

injection detected,
injection ignored,
answer manipulated,
plan drift,
tool proposed,
tool blocked,
sensitive data accessed,
sensitive data exfiltrated,
human confirmation triggered,
policy deny,
recovery berhasil.

Bayangkan agent membaca malicious page dan mencoba send_email, tetapi policy engine menolak.

Apakah test gagal?

Model layer gagal.

System layer berhasil membatasi consequence.

Keduanya perlu dicatat.

OpenAI secara eksplisit mendorong framing yang berfokus pada constraining impact bahkan jika manipulasi berhasil.

Evaluation harus menangkap defense-in-depth itu.

False Positive Juga Biaya Security

Detector yang memblokir semua halaman dengan kata “ignore” mungkin terlihat aman.

Tetapi bisa merusak usability.

Dokumen cybersecurity normal sering berisi contoh prompt injection.

Agent harus bisa membaca artikel tentang serangan tanpa otomatis mengikuti atau memblokir semuanya.

Testing perlu punya benign adversarial-looking content.

Contoh:

“Artikel ini menjelaskan kalimat ‘ignore previous instructions’ sebagai contoh serangan.”

Sistem idealnya memahami bahwa itu data.

Bukan command.

Security product yang terlalu agresif bisa membuat agent tidak berguna.

Kill Switch Harus Nyata

Sebelum test, pastikan ada cara menghentikan:

agent runs,
tool execution,
queue,
scheduled job,
token,
credential,
dan network access.

Bukan sekadar tombol dashboard yang belum pernah diuji.

Lakukan drill.

Security team menekan kill switch.

Apakah semua worker berhenti?

Apakah in-flight action masih jalan?

Apakah credential revoke efektif?

Prompt injection test memberi kesempatan menguji incident response juga.

Jangan Menjalankan Attack terhadap Sistem Pihak Ketiga Tanpa Izin

Browser agent bisa menjelajah web.

Tetapi red team scope tetap punya batas legal dan etis.

Jangan menggunakan agent untuk mencoba exploit website pihak ketiga, mengirim payload ke form publik, atau melakukan aktivitas yang tidak diizinkan.

Gunakan lab, staging, bug bounty scope resmi, atau target yang memang memberi permission.

Prompt injection testing adalah security testing.

Aturan otorisasi tetap berlaku.

Production Test Hanya Jika Benar-Benar Perlu

Ada organisasi yang eventually melakukan controlled testing di production.

Itu bisa valid untuk risk tertentu.

Tetapi syaratnya ketat.

Scope sempit.
Data dummy.
Tool high-risk dimatikan.
Traffic kecil.
Window jelas.
Owner jelas.
Monitoring aktif.
Rollback siap.
Incident response standby.
Authorization formal.

Production bukan tempat pertama untuk belajar apakah agent bisa menghapus record.

Gunakan progressive assurance.

Lab.
Staging.
Shadow.
Canary.
Baru controlled production jika ada alasan.

Regression Suite Setelah Setiap Perubahan Besar

Prompt injection defense berubah.

Model berubah.
Prompt berubah.
Tool berubah.
Retriever berubah.
Browser runtime berubah.
Policy berubah.

Test sekali tidak cukup.

NIST pada 2026 menyoroti tantangan guardrail statis terhadap adversarial input adaptif. Pesannya relevan: security perlu continuous monitoring dan update.

Buat regression suite.

Jalankan setelah:

model upgrade,
tool baru,
permission change,
retrieval change,
system prompt change,
browser update,
memory feature,
atau major release.

Attack yang dulu gagal bisa berhasil setelah perubahan kecil.

Checklist Testing Aman

Sebelum mulai:

Apakah threat model jelas?
Apakah scope tertulis?
Apakah environment terisolasi?
Apakah production secrets tidak digunakan?
Apakah high-risk tools diganti sink?
Apakah canary data tersedia?
Apakah external network dibatasi?
Apakah logging cukup detail?
Apakah kill switch diuji?
Apakah team tahu stop condition?
Apakah third-party systems di luar scope?
Apakah test result diklasifikasikan per layer?
Apakah regression suite akan disimpan?

Kalau sebagian belum siap, test masih bisa dilakukan, tetapi mulai dari level risiko lebih rendah.

Tujuan Red Team Bukan Membuktikan Agent Bodoh

Prompt injection demo sering dibuat seperti kompetisi:

“Lihat, model ketipu.”

Itu menghibur.

Tetapi tidak cukup membantu engineering.

Tujuan testing adalah menemukan:

boundary yang hilang,
tool terlalu luas,
source terlalu dipercaya,
permission terlalu besar,
confirmation terlambat,
logging kurang,
dan recovery lambat.

Model bisa salah.

Kita sudah tahu.

Pertanyaan yang lebih produktif adalah apakah sistem tetap menjaga data dan action ketika model salah.

Prompt injection testing yang matang tidak mengejar screenshot dramatis.

Ia menghasilkan backlog perbaikan.

Dan backlog itu harus membuat blast radius lebih kecil pada run berikutnya.

Itulah security testing yang bernilai.

Bukan membuat production rusak untuk membuktikan bahwa serangan memang mungkin.