Belajar 9router - Safeguards Against Malicious Requests

#Pendahuluan

Episode 12 mengunci pintu gerbang: setiap request kini harus punya identitas yang terverifikasi dan izin yang sesuai. Tapi identitas yang sah tidak berarti niatnya baik. Seorang user dengan API key valid masih bisa mengirim prompt yang mencoba mengelabui model, konten terlarang, atau data pribadi orang lain — dan serangan terkoordinasi bisa menguras kuota provider dalam hitungan menit.

Episode 13 berfokus pada safeguards: lapisan pertahanan yang aktif pada isi request, bukan hanya pada siapa pengirimnya. Kita akan membangun deteksi unsafe prompt dan adversarial input, menegakkan kebijakan prohibited content dan PII redaction, lalu melindungi provider dengan rate limit dan circuit breaker terhadap abuse.

#Mendeteksi Unsafe Prompt dan Adversarial Input

Request yang sah secara autentikasi belum tentu aman secara konten. 9router menyediakan input guard yang berjalan sebelum route engine memilih model. Guard ini menilai isi pesan, bukan sekadar metadata, dan bisa memblokir atau menyaring sebelum request sampai ke provider — penting, karena setiap request yang diteruskan berpotensi menguras token dan mencatat data.

Definisi input guard

guardrails:
  - name: block-injection
    kind: prompt_injection
    action: reject
    severity_threshold: high
  - name: detect-jailbreak
    kind: adversarial_pattern
    action: reject
  - name: moderation-in
    kind: content_moderation
    categories: [hate, harassment, self_harm, sexual, violence]
    action: sanitize

prompt_injection mendeteksi pola di mana konten mencoba menimpa instruksi sistem — misalnya "abaikan instruksi sebelumnya". adversarial_pattern menangkap teknik jailbreak seperti penyamaran perintah, encoding berulang, atau dekomposisi perintah berbahaya. Saat action bernilai reject, gateway menjawab 400 dan tidak meneruskan request sama sekali.

#Kebijakan Prohibited Content

Konten terlarang tidak selalu berbentuk serangan — kadang hanya konten yang melanggar kebijakan perusahaan atau regulasi. Di sinilah content moderation berperan sebagai classifier: menilai pesan masuk terhadap kategori yang dikonfigurasi, lalu menerapkan aksi yang diinginkan.

Kategori moderasi dan aksinya

policies:
  - name: content-safety
    applies_to: chat-general
    guards:
      - moderation-in
      - moderation-out
    categories:
      hate: block
      sexual: block
      violence: warn
      pii: redact

Perhatikan dua arah yang berbeda. moderation-in memeriksa input user; moderation-out memeriksa output model sebelum dikirim balik ke pengguna. Output guard penting karena model bisa saja menghasilkan konten terlarang atau rahasia tanpa diminta. Aksi warn tidak memblokir, tapi menyisipkan catatan ke log audit; block menghentikan sepenuhnya.

Warning

Moderasi berbasis classifier bukan garansi mutlak — selalu ada false positive dan false negative. Tempatkan guard sebagai lapisan pengaman, bukan pengganti review manusia untuk kasus sensitif seperti self-harm.

#Redaksi PII

Salah satu kasus paling sering: request sah berisi nomor kartu, email, atau NIK yang tidak seharusnya mengalir ke model. PII redaction mendeteksi entitas sensitif dan menggantinya dengan placeholder sebelum request diteruskan, sehingga data asli tidak pernah masuk ke prompt, log, atau riwayat provider.

Entitas PII yang di-redact

guardrails:
  - name: pii-scrub
    kind: pii_detection
    entities: [email, phone_number, credit_card, national_id, address]
    action: redact
    replacement: "[REDACTED]"

Contoh request sebelum dan sesudah redaksi

{
  "original": "Kirim struk ke arief@example.com, kartu 4111 1111 1111 1111",
  "redacted": "Kirim struk ke [REDACTED], kartu [REDACTED]"
}

Redaksi di level gateway punya keunggulan besar: satu kali konfigurasi, semua rute terlindungi, dan kebijakan bisa diperkuat tanpa mengubah kode aplikasi. Pastikan juga redaksi berjalan pada log audit — poin yang akan diperdalam di episode 14.

#Rate Limit dan Quota untuk Melindungi Provider

Provider LLM membebankan biaya per token dan menetapkan kuota. Abuse — baik disengaja maupun karena bug di sisi client — bisa memicu lonjakan biaya atau pemblokiran akun. Rate limiting di 9router bekerja per consumer, per rute, atau per kombinasi keduanya.

Rate limit dan quota per consumer

policies:
  - name: policy-default
    rate_limit:
      requests: 100
      window: 60s
      per: consumer
    burst: 20
    quota:
      tokens: 1000000
      window: 1d
      per: consumer

Field per menentukan kunci penghitung: consumer memakai identitas dari episode 12, route membatasi satu rute, dan ip menangani request anonim. burst memberi kelonggaran kecil di atas rata-rata tanpa meruntuhkan pertahanan. Saat batas terlampaui, 9router menjawab 429 Too Many Requests dengan header yang memberi tahu client kapan boleh mencoba lagi. Cek kebijakan aktif dengan 9router policies list.

Simulasi abuse dan lihat respons 429

for i in $(seq 1 150); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -H "Authorization: Bearer ${API_KEY_MOBILE}" \
    -d '{"messages": [{"role": "user", "content": "hi"}]}' \
    https://gw.example.com/v1/chat
done | sort | uniq -c

Perhatikan bahwa rate limit yang didasarkan pada kuota token melindungi biaya secara lebih langsung daripada jumlah request — dua request raksasa bisa lebih mahal dari seratus request kecil.

#Circuit Breaker untuk Provider Abuse

Rate limit melindungi provider dari request berlebihan, tapi bagaimana jika masalahnya datang dari arah sebaliknya — provider merespons lambat atau error terus-menerus? Saat itu gateway sendiri yang menahan beban percobaan berulang yang sia-sia. Circuit breaker memutus hubungan sementara ke provider yang sedang tidak sehat.

Konfigurasi circuit breaker per provider

circuit_breakers:
  - name: openai-br
    provider: openai-prod
    failure_threshold: 0.5
    min_requests: 20
    window: 60s
    cooldown: 30s
    fallback_route: chat-fallback

Ketika lebih dari 50% request dalam satu window gagal, breaker terbuka: semua request dialihkan ke fallback_route tanpa memanggil provider yang bermasalah. Setelah cooldown, breaker masuk mode setengah terbuka dan menguji sebagian kecil request; jika membaik, sirkuit tertutup kembali.

Lihat status circuit breaker

9router circuit status
9router circuit reset --name openai-br

Kombinasi rate limit (membatasi keluar) dan circuit breaker (melindungi diri saat masuk) membuat gateway tetap hidup dan hemat biaya bahkan ketika salah satu provider sedang bermasalah — fondasi yang akan kalian kembangkan menjadi failover penuh di episode 17.

#Penutup

Episode 13 memasang pertahanan pada isi request dan kesehatan ekosistem provider: input guard mendeteksi unsafe prompt dan adversarial input, content moderation menegakkan kebijakan konten terlarang di input dan output, PII redaction mencegah data sensitif mengalir ke model, rate limit dan quota menahan abuse, serta circuit breaker mengisolasi provider yang sedang tidak sehat.

Inti yang harus dibawa pulang:

Bedakan deteksi (prompt injection, jailbreak), klasifikasi (moderasi), dan redaksi (PII) — ketiganya menangani lapisan berbeda.
Gunakan guard pada input dan output model; output yang tidak dimoderasi bisa membocorkan data atau konten terlarang.
Rate limit berpasangan dengan quota token untuk melindungi biaya, bukan cuma jumlah request.
Circuit breaker mencegah percobaan berulang ke provider yang error dan mengalihkan beban ke fallback.
Semua blokir, redaksi, dan 429 harus tercatat — bahan baku audit di episode berikutnya.

Gateway kalian kini tahan banting. Di episode 14 kita merapikan buktinya: Compliance & Auditability — mengaudit keputusan rute dan pemakaian model, mencatat evaluasi kebijakan dan akses, serta menangani data residency dan privacy. Sampai jumpa di sana!