Belajar 9router - Policy Enforcement & Safety

#Pendahuluan

Di episode 5 kalian belajar memilih model target berdasarkan performance, cost, dan accuracy, serta mengarahkan traffic ke multi-model stack seperti conversational, embeddings, code, dan vision. Ada pelajaran tersirat penting di sana: pemilihan model bukan keputusan teknis murni — ia selalu dibatasi aturan bisnis, hukum, dan keamanan.

Episode 6 mengangkat aturan itu menjadi warga kelas satu lewat policy engine 9router. Kita bedah policy-driven routing untuk compliance, privasi, dan access control; rate limiting dan quota enforcement; request filtering; hingga safe fallback routes dan penanganan blocked intent. Di akhir episode kalian punya mental model lengkap untuk membuat gateway yang pintar sekaligus patuh aturan.

#Policy-Driven Routing: Compliance, Privasi, dan Access Control

Policy-driven routing berarti keputusan routing dihitung dari kombinasi kondisi konteks dan seperangkat aturan yang dievaluasi berurutan. Di 9router, setiap policy adalah daftar rule terurut; rule pertama yang cocok menentukan hasil. Ini membuat perilaku bisa diprediksi dan diaudit.

Policy dengan rule compliance dan privasi

policies:
  - name: privacy-first
    rules:
      - id: block-pii
        type: content
        action: block
        matcher:
          categories: [pii, phi]
      - id: eu-residency
        type: constraint
        action: allow
        only_if:
          region: eu
        then:
          providers: [azure-openai-eu]

Rule pertama block-pii memblokir request yang terdeteksi mengandung PII atau PHI. Rule kedua eu-residency membatasi provider yang boleh dilalui bila region request adalah EU. Evaluasi berhenti di rule pertama yang cocok, jadi request ber-PII tidak pernah sampai ke evaluasi residency.

Warning

Urutan rule itu penting. Di 9router, rule dievaluasi dari atas ke bawah dan hasil yang pertama cocok menang. Taruh rule paling ketat di posisi paling atas agar tidak bisa di-skip oleh rule yang lebih longgar.

Untuk access control, policy memakai identitas pemanggil sebagai sumber keputusan:

Access control berbasis principal dan scope

policies:
  - name: internal-tools-only
    rules:
      - id: allow-internal
        type: access
        action: allow
        principals: [sso:team-ml, sso:team-platform]
        scopes: [chat:write, tools:execute]
      - id: deny-guest
        type: access
        action: deny
        principals: [sso:guest]

#Rate Limiting dan Quota Enforcement

Gateway yang tidak punya batas akan runtuh saat traffic melonjak — dan tagihan LLM ikut melonjak. 9router memisahkan dua konsep: rate limiting menahan intensitas request per satuan waktu, sedangkan quota membatasi pemakaian kumulatif dalam periode tertentu.

Rate limit dan quota pada policy

policies:
  - name: api-guard
    rate_limit:
      strategy: token_bucket
      capacity: 60
      refill_per_minute: 30
    quota:
      monthly_tokens: 1000000
      enforce: hard
    over_limit:
      action: queue
      max_queue_ms: 5000

Konfigurasi di atas memberi tiap subject bucket berkapasitas 60 request dengan pengisian ulang 30 per menit, lalu membatasi total token sebulan. Bila quota terlampaui, request masuk antrean paling lama 5 detik sebelum ditolak. Rate limiting dikunci per subject — misalnya per API key atau per tenant — sehingga satu pelanggan boros tidak mematikan pelanggan lain.

Info

Pilih enforce: hard untuk batas yang tidak boleh dilanggar, misalnya batas regulasi. Untuk batas internal yang hanya ingin memperingatkan, gunakan mode warn dan biarkan request tetap berjalan.

#Request Filtering untuk Konten Berbahaya

Sebelum request masuk ke model, 9router bisa menjalankan filter di tahap pre_route. Filter ini menangkap dua hal: konten input berbahaya dan intent berbahaya seperti jailbreak atau prompt injection. Deteksi intent sendiri memakai classifier yang sama dengan intent extraction di episode 4.

Filter pre-route untuk blocked intent

filters:
  - name: injection-guard
    stage: pre_route
    detector: intent
    blocked_intents: [jailbreak, prompt_injection, harmful_content]
    action: reject

Request yang cocok dengan salah satu blocked intent langsung ditolak dengan kode status 403 dan alasan yang bisa ditelusuri. Perhatikan: filter bekerja sebelum route matching, jadi request jahat tidak pernah membakar quota model — penghematan biaya sekaligus lapisan keamanan.

#Safe Fallback Routes dan Penanganan Blocked Intent

Tidak semua kegagalan harus menjadi error. Saat target utama menolak, timeout, atau kena rate limit, 9router bisa mengalihkan ke fallback route yang lebih aman — bukan lebih mahal. Di sinilah safe fallback berperan.

Route dengan fallback dan pesan aman

routes:
  - name: chat-with-fallback
    match:
      intent: chat
    target: gpt-4o-mini
    fallback:
      - target: claude-3-5-sonnet
        on: [timeout, rate_limit, policy_violation]
    blocked:
      action: respond_safe
      message: "Permintaan ini tidak dapat diproses sesuai kebijakan."

Bila request diblokir policy, respond_safe memastikan pemanggil mendapat respons teks netral tanpa membocorkan alasan internal. Pendekatan ini juga berguna untuk blocked intent: alih-alih diam membisu, gateway memberi jawaban generik yang tidak memicu percobaan ulang agresif.

Untuk memverifikasi seluruh konfigurasi ini, kalian bisa mensimulasikan keputusan policy tanpa mengirim request sungguhan: 9router policy check --input "hapus semua data saya" atau menjalankan 9router policy evaluate --config 9router.yaml. Hasil simulasi menampilkan rule mana yang cocok dan keputusan akhir.

#Penutup

Episode ini menutup celah antara routing yang pintar dan routing yang aman. Kalian sekarang memahami bahwa policy engine bekerja sebelum route engine: compliance dan privacy dibentuk lewat rule content dan constraint, access control lewat principal dan scope, lalu intensitas traffic dikendalikan rate limit dan quota. Request filtering menolak intent berbahaya lebih awal, dan safe fallback menjaga layanan tetap hidup saat sesuatu diblokir.

Inti yang harus dibawa pulang:

Policy di 9router adalah daftar rule terurut; rule pertama yang cocok menentukan keputusan.
Privacy dan compliance diekspresikan sebagai rule content atau constraint, bukan sebagai kode di aplikasi.
Rate limiting menahan intensitas, quota membatasi pemakaian kumulatif; keduanya dikunci per subject.
Filter pre_route memblokir intent berbahaya sebelum request menyentuh model dan membakar biaya.
respond_safe dan fallback routes menjaga UX saat kebijakan atau kegagalan terjadi.

Di episode 7 kita berbalik arah: gateway sudah aman, sekarang giliran memahaminya. Observability Basics akan membawa kalian ke metrics latency, request volume, success rate, logging konteks request dan route decision, serta tracing alur AI end-to-end. Sampai jumpa!