Keamanan API untuk Aplikasi AI: RAG, Tool Calling, dan Cara Menangkalnya

Aplikasi AI jarang berjalan sendirian. Chatbot di website Anda terhubung ke database, API pembayaran, atau tool internal; asisten dengan RAG membaca dokumen perusahaan; agen yang bisa memanggil fungsi menyentuh sistem lain. Semakin banyak yang bisa "dijangkau" model, semakin lebar permukaan serangan yang harus diamankan.

Artikel ini membahas tiga risiko yang paling sering muncul di lapisan API aplikasi AI — prompt injection lewat data, excessive agency pada tool calling, dan pencemaran RAG — plus langkah praktis untuk menangkalnya. Ini bukan daftar lengkap, tapi titik awal yang tepat bagi tim yang baru mulai mengamankan aplikasi AI-nya.

1. Kenapa API aplikasi AI berbeda dari API biasa

Pada aplikasi klasik, API menerima data dan memprosesnya secara deterministik. Pada aplikasi AI, ada satu perbedaan fundamental: model membaca data sebagai instruksi. Sebuah dokumen PDF yang di-upload, email, atau halaman web yang diambil RAG bisa mengandung teks berbahaya yang tidak terlihat seperti serangan bagi manusia — tetapi bagi model, teks itu bisa mengubah perilaku.

Inilah yang disebut prompt injection tidak langsung (indirect prompt injection): instruksi jahat disembunyikan di dalam konten yang akan dibaca model, bukan diucapkan langsung oleh user. Ini kategori risiko nomor satu pada OWASP LLM Top 10 (LLM01). Scanner kode klasik tidak akan menemukannya — serangannya hidup di lapisan percakapan dan data, bukan di source code.

2. Tiga risiko utama di lapisan API aplikasi AI

2.1 Prompt injection lewat API input dan RAG

Setiap endpoint yang menerima teks — /chat, /ask, /generate — adalah pintu masuk. Yang sering terlupa: endpoint yang menerima dokumen, URL, atau data terstruktur untuk diproses RAG juga pintu masuk. Serangan bisa meminta model mengabaikan instruksi sistem, membocorkan isi prompt, atau mengeksekusi tool. Ciri khasnya: payload-nya tampak seperti data biasa.

2.2 Excessive agency pada tool calling

Ketika model bisa memanggil fungsi (mengirim email, membaca file, melakukan pembayaran), muncul pertanyaan: apa hal terburuk yang bisa dilakukan tool ini jika disalahgunakan? OWASP menempatkan excessive agency sebagai risiko tinggi (LLM03) — model diberi terlalu banyak kemampuan, dengan terlalu sedikit pengawasan. Sebuah tool "kirim email ke customer" bisa disalahgunakan menjadi "kirim email ke semua orang" jika instruksi jahat mengendalikan argumennya.

2.3 RAG poisoning dan kebocoran data

RAG mengambil konteks dari dokumen eksternal. Kalau dokumen itu bisa dimodifikasi — halaman web yang berubah, file yang di-upload user, atau API pihak ketiga — isinya bisa diracuni (data/model poisoning, LLM05). Selain itu, RAG yang terlalu permisif bisa bocorkan data antar-pengguna: user A bertanya sesuatu yang seharusnya hanya boleh diakses user B (cross-user data isolation). Ini bukan spekulasi — batas akses data RAG adalah kontrol keamanan nyata yang sering terlewat.

3. Tool calling: prinsip least privilege + persetujuan manusia

Tiga aturan yang langsung menurunkan risiko tool calling:

• Least privilege — berikan tool seminimal mungkin. Model tidak butuh akses ke semua database hanya untuk menjawab "berapa saldo saya?". Tentukan apa arti "iya, lakukan" untuk setiap tool sebelum mengaktifkannya.
• Human-in-the-loop — aksi berisiko (pembayaran, hapus data, ubah akun, kirim email massal) wajib konfirmasi manusia. Model boleh mengusulkan, manusia yang mengeksekusi.
• Validasi argumen server-side — jangan percaya JSON tool call dari model. Validasi ulang di sisi server: siapa pemilik objek, apakah aksi diizinkan untuk user ini (anti IDOR), dan apakah nilainya masuk akal.

4. Checklist praktis sebelum produksi

1. Perlakukan semua konten sebagai untrusted input — dokumen RAG, email, web page, file upload. Pisahkan instruksi sistem dari data.
2. Filter output — jangan render hasil model langsung ke HTML tanpa sanitasi (anti XSS) dan jangan langsung jalankan perintah.
3. Kredensial di env var — API key dan token jangan pernah ada di prompt, log, atau kode. Baca dari secret manager.
4. Log akses tool — catat timestamp, parameter, dan siapa user-nya. Tanpa log, insiden tidak bisa diinvestigasi.
5. Rate limit per user — batasi pemakaian API supaya biaya LLM dan risiko abuse terkendali.
6. Uji lapisan percakapan — jalankan red-team terhadap prompt injection, jailbreak, dan tool abuse — bukan hanya SAST pada kode.

5. Bagaimana AISG memeriksa lapisan ini

AISG adalah platform layer-1 prevention: menemukan kelemahan sebelum diserang, dengan bukti yang bisa diaudit — bukan klaim "aman". Untuk aplikasi AI, AISG memeriksa lapisan API dan LLM dari beberapa sisi:

• Kode — SAST (semgrep, bandit, codeql) mencari pola berbahaya seperti input yang tidak divalidasi, path traversal, SQL injection, dan secret yang hardcoded.
• API contract — fuzzing skema OpenAPI (schemathesis) menguji endpoint dari sisi request: parameter, autentikasi, dan error handling.
• Lapisan LLM — garak, PyRIT, dan promptfoo menjalankan probe terstruktur: prompt injection, jailbreak, dan perilaku berbahaya lainnya terhadap endpoint model Anda.
• MCP/agent — pemeriksaan endpoint MCP untuk pola penyalahgunaan tool pada aplikasi agentic.

Hasilnya disatukan dalam satu report dengan risk score yang transparan, prioritas perbaikan (Top Actions), dan panduan fix — lengkap dengan batasan yang ditulis jujur, karena keamanan tidak bisa dijanjikan, hanya diukur dan diperbaiki.

Kesimpulan

API aplikasi AI memperluas serangan dari "siapa yang bisa akses endpoint" menjadi "apa yang bisa dipercaya dari model dan datanya". Berita baiknya: sebagian besar risiko bisa ditekan dengan kontrol yang sudah dikenal — input validation, least privilege, human approval, dan pengujian terstruktur di lapisan percakapan.

Mulailah dari langkah kecil: periksa satu endpoint LLM Anda dengan probe injection, audit tool calling yang paling berisiko, dan pastikan RAG tidak membocorkan data antar-user. Plan Community tersedia gratis — scan berjalan di mesin Anda sendiri, dan kode tidak pernah meninggalkan perangkat Anda.