Saat aplikasi menambah fitur AI, pola trafik sering berubah: bukan lagi alur pengguna yang pendek dan terprediksi, tetapi rangkaian request eksploratif, berulang, dan kadang tidak efisien. Konteks ini sering digambarkan sebagai “The 100k Whys of AI”: sistem AI terus “bertanya” ke backend, memicu lookup tambahan, upload, retry, dan percobaan parameter sampai menemukan jawaban yang dianggap memadai.

Masalah utamanya bukan hanya lonjakan beban. Threat modeling auth saat fitur AI banyak bertanya ke backend perlu melihat bahwa volume request yang tinggi dan pola eksploratif bisa membuka jalur abuse baru: brute force yang tersamarkan, kebocoran session, pemakaian API key lintas konteks, upload berbahaya, input yang lolos validasi, dan rate limit yang salah dimensi. Artikel ini fokus pada langkah teknis yang bisa diterapkan tim backend/web modern tanpa bergantung pada vendor tertentu.

Apa yang berubah ketika AI sering memicu request ke backend

Pada aplikasi non-AI, alur auth biasanya relatif jelas: pengguna login, mendapatkan session atau token, lalu melakukan beberapa aksi. Pada fitur AI, satu interaksi pengguna bisa menghasilkan banyak request internal:

  • pengambilan konteks dari beberapa endpoint,
  • retry otomatis saat respons dianggap kurang,
  • upload dokumen atau gambar untuk diproses,
  • pemanggilan tool internal atas nama user,
  • pencarian bertahap dengan parameter yang berubah-ubah.

Dari sudut pandang keamanan, ini berarti:

  • lebih banyak keputusan authz per interaksi,
  • lebih banyak rahasia yang beredar di service boundary,
  • lebih banyak peluang abuse yang terlihat “normal” karena dibungkus oleh fitur AI,
  • lebih sulit membedakan user intent, sistem retry, dan serangan otomatis.

Threat model yang baik harus memetakan bukan hanya siapa user-nya, tetapi juga siapa yang bertindak atas nama user, dengan kredensial apa, ke endpoint mana, dan berapa sering.

Model ancaman: aset, aktor, dan trust boundary

Aset yang perlu dilindungi

  • akun pengguna dan mekanisme login,
  • session cookie, bearer token, refresh token,
  • API key untuk service internal atau integrasi eksternal,
  • secret di environment, CI/CD, worker, dan browser build,
  • data sensitif yang diunggah atau diambil ulang oleh AI,
  • quota, budget, dan kapasitas backend,
  • audit log dan jejak aksi atas nama user.

Aktor yang relevan

  • User sah yang memakai fitur AI secara normal.
  • Attacker anonim yang mencoba login abuse, scraping, atau DoS halus.
  • User sah yang jahat yang mengeksploitasi fitur AI untuk eskalasi akses.
  • Prompt/input tak terpercaya yang memengaruhi tool execution atau pemanggilan endpoint.
  • Service internal yang dipercaya berlebihan sehingga bisa jadi pivot saat satu komponen bocor.

Trust boundary yang sering terlupakan

  • Browser ke backend aplikasi.
  • Backend utama ke worker/queue.
  • Service AI orchestration ke API internal.
  • Storage upload ke pemroses dokumen/gambar.
  • Observability pipeline yang ikut menerima payload sensitif.

Jika sebuah service AI boleh memanggil banyak API internal, anggap ia sebagai privileged client. Jangan otomatis menyamakan trust level-nya dengan backend monolit utama.

Alur request yang rentan: contoh konkret

Contoh alur

  1. User login di web app dan mendapat session.
  2. User membuka fitur AI dan mengajukan pertanyaan.
  3. Frontend mengirim prompt ke endpoint /ai/ask.
  4. Backend meneruskan prompt ke orchestration layer.
  5. Orchestration layer memanggil beberapa API internal: profil user, histori transaksi, pencarian dokumen, upload parser, lalu menyusun jawaban.
  6. Jika jawaban dianggap kurang, orchestration melakukan retry atau memanggil endpoint tambahan.

Di mana letak risikonya

  • Session user dipakai terlalu luas: orchestration membawa token user asli ke banyak service, sehingga satu log atau dump memaparkan kredensial bernilai tinggi.
  • Confused deputy: service AI yang punya hak luas dipakai untuk mengakses resource yang seharusnya tidak boleh diakses user.
  • Amplification: satu request user berubah menjadi puluhan request internal tanpa guardrail quota.
  • Input chaining: teks atau file upload dari user memicu parser, search, dan fetch tambahan tanpa validasi ketat.
  • Rate limiting salah tempat: hanya membatasi endpoint publik, padahal ledakan terjadi di endpoint internal/tooling.

Contoh anti-pattern alur

Flow yang berbahaya biasanya terlihat seperti ini:

User Session Cookie -> /ai/ask -> AI Orchestrator -> meneruskan cookie/token user ke semua service internal

Masalahnya, satu kredensial user menjadi tiket universal. Jika satu service internal mencatat header mentah, token bisa bocor. Jika satu endpoint internal punya otorisasi lemah, orchestrator menjadi jalur bypass.

Pola yang lebih aman

User Session -> Backend App -> issue short-lived internal token scoped ke aksi tertentu -> AI Orchestrator -> panggil service internal dengan service identity + user context minimum

Prinsipnya: jangan fan-out kredensial user asli ke banyak komponen. Gunakan identitas service untuk antar-service, lalu kirim konteks user minimum yang diperlukan untuk keputusan otorisasi.

Threat modeling auth: fokus area yang wajib diperiksa

1) Login dan account abuse

Fitur AI bisa menutupi pola login abuse karena attacker menggunakan akun baru atau akun hasil credential stuffing untuk menjalankan request yang tampak “produktif”. Risiko utamanya:

  • credential stuffing dengan volume rendah tapi persisten,
  • otomasi pembuatan akun untuk menyalahgunakan quota AI,
  • enumerasi akun lewat perbedaan pesan error atau timing.

Kontrol yang praktis:

  • gunakan pesan error login yang tidak mengungkap apakah email terdaftar,
  • batasi percobaan login per IP, per identifier akun, dan per device fingerprint ringan bila relevan,
  • tambahkan step-up verification untuk perilaku anomali, bukan ke semua user,
  • pisahkan quota login dengan quota pemakaian fitur AI.

Kesalahan umum adalah hanya menerapkan rate limit per IP. Pada trafik AI, banyak request bisa datang dari NAT, proxy perusahaan, atau mobile network yang sama. Perlu kombinasi dimensi: IP, akun, session, endpoint, dan pola perilaku.

2) Session dan token propagation

Session yang aman bukan hanya soal cookie HttpOnly dan Secure. Tantangan utama di fitur AI adalah bagaimana session user dipakai untuk memicu aksi lanjutan.

Praktik yang disarankan:

  • simpan session user di boundary aplikasi publik,
  • jika perlu memanggil service internal, tukar session menjadi token internal berumur pendek,
  • batasi token internal dengan scope, audience, dan tujuan endpoint yang jelas,
  • ikat token dengan tindakan spesifik bila memungkinkan, bukan akses umum ke seluruh API.

Perhatikan juga sesi yang hidup terlalu lama pada chat UI atau dashboard AI. Jika tab dibiarkan terbuka, browser bisa terus mengirim request tambahan. Pastikan ada mekanisme expiry yang konsisten dan penanganan refresh token yang tidak membuat sesi zombie.

3) API key dan service-to-service auth

API key sering dipakai cepat untuk menghubungkan orchestrator AI ke backend. Ini praktis, tetapi berbahaya bila:

  • satu key dipakai untuk semua environment,
  • key ditempatkan di frontend atau mobile bundle,
  • key tidak punya rotasi, expiry, atau pembatasan scope,
  • key mewakili hak admin untuk operasi baca/tulis luas.

Lebih aman bila antar-service menggunakan identitas service yang bisa diaudit, dengan secret berumur pendek atau kredensial yang dapat diputar rutin. Bila tetap memakai API key, minimal:

  • pisahkan per service dan per environment,
  • batasi izin hanya ke endpoint yang diperlukan,
  • log penggunaan per key,
  • sediakan prosedur rotasi tanpa downtime panjang.

4) Secret handling

Fitur AI sering menambah lebih banyak secret: token ke model provider, storage, OCR, search index, parser, dan webhook. Semakin banyak komponen, semakin besar risiko secret bocor lewat log, crash report, atau debug console.

Prinsip implementasi:

  • jangan pernah mengirim secret ke browser, termasuk lewat source map, config publik, atau HTML bootstrap data,
  • redaksi header sensitif di access log dan error log,
  • pisahkan secret runtime dari kode dan dari image container statis,
  • batasi siapa yang bisa membaca secret di CI/CD dan worker,
  • uji skenario kebocoran: apa yang terjadi jika satu worker credential bocor?

Anti-pattern yang sering terjadi: developer menyalin token service internal ke file konfigurasi frontend untuk memudahkan prototyping upload atau streaming.

5) Validasi input pada prompt, parameter, dan tool call

Masalah keamanan bukan hanya prompt injection. Dari sisi backend, bahaya utamanya adalah input yang memicu aksi tak terduga: filter query yang terlalu bebas, identifier resource yang bisa ditebak, URL fetch yang tidak dibatasi, atau parameter upload yang memengaruhi parser.

Validasi yang disarankan:

  • gunakan allowlist untuk field, operator, dan tool yang boleh dipanggil,
  • pisahkan teks bebas dari parameter terstruktur,
  • validasi panjang input, jumlah item, tipe MIME, ukuran file, dan jumlah retry,
  • tolak URL arbitrer dari user bila backend akan melakukan fetch, kecuali ada sandbox dan pembatasan kuat,
  • normalisasi dan validasi identifier sebelum dipakai ke query internal.

Jangan menganggap karena request datang dari komponen AI internal maka inputnya otomatis aman. Input itu tetap berasal dari pengguna atau dari sumber yang bisa dimanipulasi.

6) Upload dan pemrosesan file

Fitur AI sering menambah upload dokumen, gambar, atau spreadsheet. Ini membuka risiko:

  • file terlalu besar dan memicu resource exhaustion,
  • parser crash atau loop pada file malformed,
  • ekstensi file menipu MIME sebenarnya,
  • dokumen memicu fetch eksternal atau macro-style behavior pada pipeline tertentu,
  • file sensitif tersimpan terlalu lama tanpa lifecycle policy.

Pola aman:

  • batasi ukuran file dan jumlah file per request,
  • verifikasi tipe file berdasarkan inspeksi server-side, bukan nama file saja,
  • simpan upload di area terisolasi sebelum diproses,
  • jalankan parsing secara asinkron di worker terbatas,
  • pisahkan bucket/path mentah dari hasil ekstraksi,
  • tetapkan masa retensi dan penghapusan otomatis.

7) Rate limiting dan abuse prevention

Pada pola “100k whys”, rate limiting sederhana per endpoint publik hampir selalu tidak cukup. Yang perlu dibatasi adalah biaya total yang dihasilkan satu interaksi, bukan hanya jumlah request awal.

Dimensi rate limit yang berguna:

  • per IP untuk noise anonim,
  • per akun untuk mencegah abuse oleh user login,
  • per session untuk tab atau automation runaway,
  • per endpoint/tool internal untuk mencegah fan-out berlebih,
  • per unit biaya, misalnya jumlah dokumen, upload, atau operasi pencarian yang dipicu.

Tambahkan juga:

  • concurrency limit per user atau tenant,
  • budget limit per jendela waktu,
  • circuit breaker saat satu dependency mulai error dan AI terus retry,
  • idempotency key untuk mencegah duplikasi aksi saat retry dari client atau worker.

Pola desain aman yang bisa langsung diterapkan

Gunakan “brokered access”, bukan token user mentah

Alih-alih mengirim bearer token user ke semua service, backend publik bertindak sebagai broker. Ia memverifikasi user, lalu menerbitkan konteks minimum atau token internal yang sempit untuk satu workflow.

Keuntungan:

  • kebocoran di satu service tidak otomatis memberi akses penuh sebagai user,
  • audit trail lebih jelas: service identity dan user context terpisah,
  • scope bisa dibuat spesifik untuk fitur AI.

Service identity + user context minimum

Untuk antar-service, utamakan identitas service yang terpisah dari identitas user. Sertakan user context minimum seperti user ID, tenant ID, dan daftar izin yang relevan, bukan seluruh session blob.

Policy gate sebelum tool execution

Setiap tool call atau pemanggilan endpoint internal sebaiknya melewati policy gate yang memeriksa:

  • siapa user dan tenant-nya,
  • tool apa yang diminta,
  • resource apa yang akan diakses,
  • apakah aksi itu hanya baca atau juga tulis,
  • apakah melampaui quota atau pola normal.

Ini penting untuk mencegah AI orchestration menjadi proxy serba bisa.

Asynchronous processing dengan budget yang jelas

Upload dan pemrosesan berat sebaiknya tidak berjalan sinkron di request auth utama. Gunakan queue/worker, tetapi pastikan setiap job membawa:

  • identitas pemilik job,
  • scope aksi yang diizinkan,
  • batas retry, timeout, dan masa berlaku,
  • jejak audit yang bisa ditelusuri ke request asal.

Observability yang aman

Logging dan tracing sangat penting untuk mendeteksi abuse, tetapi harus aman:

  • jangan log token, cookie, secret, atau isi file mentah,
  • hash atau redaksi identifier sensitif bila memungkinkan,
  • catat jumlah tool call, retry, ukuran upload, dan keputusan policy,
  • hubungkan request publik ke fan-out internal dengan correlation ID.

Contoh implementasi guardrail sederhana

Contoh berikut menunjukkan ide umum middleware untuk membatasi biaya satu request AI. Ini bukan bergantung pada framework tertentu; tujuannya memperjelas kontrol yang perlu ada.

function handleAiAsk(request) {
  const user = requireAuthenticatedUser(request);

  enforceRateLimit({
    key: `ai:user:${user.id}`,
    window: '1m',
    maxRequests: 20
  });

  enforceConcurrencyLimit({
    key: `ai:user:${user.id}`,
    maxInFlight: 3
  });

  const input = validate(request.body, {
    prompt: { type: 'string', maxLength: 4000 },
    attachmentIds: { type: 'array', maxItems: 5 }
  });

  const budget = createExecutionBudget({
    maxInternalCalls: 10,
    maxUploadBytes: 10 * 1024 * 1024,
    maxRuntimeMs: 15000
  });

  const internalContext = issueScopedInternalContext({
    userId: user.id,
    tenantId: user.tenantId,
    scopes: ['ai:ask', 'docs:read:own']
  });

  return runAiWorkflow({ input, budget, internalContext });
}

Yang penting di sini bukan sintaksnya, tetapi konsepnya:

  • auth dipastikan di awal,
  • rate limit dan concurrency limit dipisah,
  • validasi input dilakukan sebelum workflow dimulai,
  • workflow diberi budget eksplisit,
  • akses internal dibatasi dengan context scoped.

Checklist implementasi threat modeling auth dan abuse prevention

Checklist desain

  • Petakan semua endpoint yang bisa dipicu oleh fitur AI, termasuk endpoint internal.
  • Tentukan aset bernilai tinggi: token, session, file upload, data tenant, admin API.
  • Definisikan trust boundary antara browser, backend publik, orchestrator, worker, dan service internal.
  • Tentukan apakah AI boleh melakukan aksi tulis atau hanya baca.
  • Dokumentasikan identitas yang dipakai di tiap hop: user session, token internal, service identity.

Checklist auth dan session

  • Jangan teruskan session/cookie user mentah ke banyak service.
  • Gunakan token internal berumur pendek dengan scope sempit bila diperlukan.
  • Pastikan logout, expiry, dan refresh tidak meninggalkan sesi zombie.
  • Audit endpoint internal yang menerima context user dari orchestrator.

Checklist API key dan secret

  • Pisahkan key per service dan environment.
  • Rotasi secret secara rutin dan uji prosedur rotasinya.
  • Redaksi secret di log, trace, dan error report.
  • Pastikan tidak ada secret yang ikut ke frontend bundle atau source map.

Checklist input dan upload

  • Gunakan allowlist untuk parameter terstruktur dan tool call.
  • Batasi ukuran, jumlah, dan tipe file upload.
  • Jalankan parsing file di worker terisolasi dengan timeout dan retry terbatas.
  • Tolak fetch ke URL arbitrer dari input user kecuali ada sandbox jelas.

Checklist rate limiting dan observability

  • Terapkan limit per IP, akun, session, dan endpoint biaya tinggi.
  • Tambahkan concurrency limit dan execution budget.
  • Gunakan correlation ID dari request awal sampai fan-out internal.
  • Alert jika satu request AI memicu lonjakan tool call, retry, atau upload.

Anti-pattern umum

  • “Internal berarti aman.” Banyak insiden justru terjadi karena otorisasi antar-service terlalu longgar.
  • Meneruskan token user ke semua komponen. Praktis untuk awal, mahal saat terjadi kebocoran.
  • Rate limit hanya di CDN atau API gateway publik. Fan-out internal tetap bisa menghabiskan kapasitas.
  • Validasi hanya di frontend. AI workflow bisa mem-bypass asumsi UI normal.
  • Upload diproses sinkron. Satu file buruk bisa mengunci worker thread atau request pool.
  • Retry tanpa batas atau tanpa budget. Dependency yang melambat berubah menjadi amplifikasi beban.
  • Logging berlebihan. Debug payload lengkap sering memaparkan token, prompt sensitif, atau isi dokumen.

Cara menguji dan men-debug sistem yang mulai diserang pola “100k whys”

Skenario uji yang layak dilakukan

  • Simulasikan satu prompt yang memicu 10-20 panggilan internal.
  • Uji akun sah yang menjalankan request beruntun dengan variasi kecil untuk mencari celah quota.
  • Uji file malformed, file terlalu besar, dan tipe file palsu.
  • Uji apakah orchestrator bisa mengakses resource tenant lain dengan identifier yang dimanipulasi.
  • Uji apakah log, trace, atau error report menyimpan token atau cookie mentah.

Sinyal debugging yang berguna

  • rasio request publik terhadap internal fan-out,
  • jumlah retry per workflow,
  • jumlah tool call per prompt,
  • error authz per service internal,
  • volume upload per user/tenant,
  • request yang berhenti di policy gate versus yang lolos.

Jika ada lonjakan biaya atau error, cari apakah sumbernya berasal dari:

  1. user abuse,
  2. prompt/input yang memicu eksplorasi berlebihan,
  3. retry otomatis,
  4. bug otorisasi yang menyebabkan loop pencarian data.

Penutup

Threat modeling auth saat fitur AI banyak bertanya ke backend bukan sekadar menambah rate limit di endpoint chat. Perubahan utama ada pada cara satu aksi user berubah menjadi banyak keputusan auth, banyak akses data, dan banyak kesempatan abuse. Karena itu, desain aman harus membatasi penyebaran kredensial, memperketat validasi input dan upload, memberi budget pada workflow AI, serta memisahkan identitas user dari identitas service.

Jika tim Anda baru menambah fitur AI, langkah paling bernilai biasanya sederhana: petakan fan-out request, hentikan propagasi token user mentah, pasang policy gate untuk tool call, dan ukur biaya per workflow. Dengan itu, Anda bisa menahan pola eksploratif ala “100k whys” tanpa mengorbankan fungsi inti aplikasi.