Database adalah tempat paling berbahaya yang bisa dimasuki agent AI. Di episode #57 kita bahas cara menjalankan model secara lokal; kali ini saya ingin menyentuh sisi lain dari AI engineering: saat model diminta berbicara dengan SQL — entah mengubah pertanyaan bahasa jadi query (text-to-SQL), maupun agent yang benar-benar diizinkan menjalankan query ke database produksi. Saya baru benar-benar paham setelah membaca satu studi kasus kerentanan MCP: satu string SQL yang kelihatan polos bisa membobol batas “read-only” yang justru dijual sebagai fitur keamanan.
Text-to-SQL: kelihatan mudah, ternyata benchmark-nya masih menengah
Intuisi pertama saya: SQL itu kan aturannya jelas, LLM sudah bisa menulis kode Python dengan baik, jadi menerjemahkan “berapa penjualan kuartal lalu” ke SQL seharusnya gampang. Angka benchmark menampar anggapan itu. Dua tolok ukur yang paling dipakai adalah Spider (10.181 pertanyaan, 200 database lintas domain) dan BIRD (12.751 pasangan pertanyaan-query, database dunia nyata berukuran 33,4 GB). Pada Juli 2025, sistem XiYan-SQL mencapai execution accuracy 75,63% di BIRD dan 89,65% di Spider — dan itu sudah status SOTA. Artinya: sepertiga pertanyaan di database “nyata” masih dijawab query yang salah oleh sistem terbaik sekalipun.
Ini berarti bagi saya: kalau membangun fitur text-to-SQL, saya tidak boleh mengukur cuma dengan rasa “wah jawabannya kelihatan benar”. Query yang salah sering tetap valid secara sintaks dan mengembalikan angka yang masuk akal — hanya saja angka itu salah. Makanya evaluasi berbasis execution (cocok dengan hasil ground truth) lebih jujur daripada menilai teks SQL-nya secara visual. Pola ini persis yang saya catat di episode #30 soal eval LLM: unit test untuk model, bukan untuk rasa percaya diri.
Titik lemah yang paling sering muncul bukan grammar SQL, tapi schema linking: model harus tahu bahwa “omzet” di sistem ini berarti kolom total_amount, bukan gross_revenue, dan bahwa status “lunas” ditandai kode 'PAID', bukan teks “lunas”. Karena itu praktik yang bagus adalah menyertakan DDL yang relevan saja (bukan seluruh database), plus kamus istilah bisnis, ke dalam prompt. Contoh kecil yang biasanya saya siapkan untuk model:
-- Skema ringkas yang dikirim ke model (bukan seluruh database) CREATE TABLE orders ( id BIGINT PRIMARY KEY, customer_id BIGINT REFERENCES customers(id), total_amount DECIMAL(12,2), -- "omzet" dalam istilah bisnis status VARCHAR(16), -- 'PAID' = lunas, 'CANCEL' = batal ordered_at DATE ); -- Semua query dibatasi 12 bulan terakhir supaya tetap ringan
Agent dengan akses database: “read-only” yang tidak benar-benar read-only
Di episode #28 kita sudah kenal MCP sebagai standar koneksi LLM dengan tools. Banyak MCP server database menjanjikan mode read-only — koneksi dibungkus transaksi READ ONLY, sehingga query tulis ditolak PostgreSQL. Kelihatan aman. Tapi Datadog Security Labs menemukan celah di server Postgres MCP referensi Anthropic: klien yang dipakai menerima multiple statement dalam satu string, jadi pengguna cukup menyelipkan COMMIT; di depan query untuk menutup transaksi read-only, lalu perintah bebas berikutnya jalan tanpa batasan. Contoh payload-nya semudah: COMMIT; DROP SCHEMA public CASCADE;. Server itu sudah di-deprecated 10 Juli 2025, tapi paket lamanya masih ribuan unduhan per minggu.
Pelajaran yang saya ambil: batas keamanan harus hidup di databasenya, bukan cuma di lapisan tool. Simon Willison menyebut kombinasi mematikan saat agent punya tiga kapabilitas sekaligus — akses data privat, akses menulis, dan kanal komunikasi ke penyerang (misalnya mengirim pesan support). Serangan prompt injection di satu pesan pengguna bisa memerintahkan agent membaca tabel token lalu menyalinnya ke tempat yang bisa dibaca penyerang. Matikan satu kaki saja — misalnya mode read-only yang sungguhan — risikonya turun drastis.
Checklist dasar yang sekarang saya pakai sebelum memberi agent akses DB:
- Role database khusus yang secara fisik tidak punya izin tulis, lengkap dengan
ALTER DEFAULT PRIVILEGESsupaya tabel baru ikut terbatas. statement_timeoutpendek (misalnya 5 detik) — read-only tetap bisa membanjiri server lewat full table scan tanpa LIMIT.- Row-level security untuk tabel yang memuat PII/rahasia, dan sandbox database terpisah kalau agent memang perlu bereksperimen menulis.
- Audit log untuk setiap query — supaya “sebenarnya tadi dia apa?” selalu bisa dijawab.
- Lebih suka tool spesifik (misalnya
lookup_orderdengan filter identitas di luar kendali model) daripada toolexecute_sqlyang serbaguna.
Semantic layer: jawaban untuk pertanyaan yang punya banyak definisi
Masalah lain yang saya temui: pertanyaan bisnis sering ambigu. “Pelanggan aktif” bisa didefinisikan tim mana pun dengan cara berbeda. Di sinilah semantic layer masuk — lapisan definisi terpusat (misalnya dbt Semantic Layer atau Cube) yang menerjemahkan istilah menjadi SQL kanonik, sehingga model hanya boleh memilih metrik dan filter, bukan menulis SQL bebas dari nol. Bagi saya ini pola yang menarik karena memperkecil ruang kesalahan model tanpa harus melatih model sendiri: kebebasan dipotong di tempat yang benar, yaitu lapisan definisi.
Kesimpulan catatan ini sederhana: AI dan database bukan soal membuat model “pintar SQL”, tapi soal membatasi apa yang boleh dilakukan model, sekaligus mengevaluasi hasilnya secara obyektif. Mulai dari role read-only yang sungguhan, timeout, dan eval berbasis execution — baru bicara soal pengalaman pengguna yang mulus. Di episode berikutnya kita naik satu level: AI di mobile dan perangkat edge, saat cloud bukan pilihan.
Sumber
XiYan-SQL: A Novel Multi-Generator Framework For Text-to-SQL — arxiv.org/abs/2507.04701
LitE-SQL (text-to-SQL ringan) — arxiv.org/abs/2510.09014
Datadog Security Labs: SQL injection di Postgres MCP server — securitylabs.datadoghq.com
Simon Willison: Supabase MCP & lethal trifecta — simonwillison.net
Google Cloud: best practices mengamankan agent via MCP — docs.cloud.google.com
Spider benchmark — yale-lily.github.io/spider | BIRD benchmark — bird-bench.github.io
Komentar Terbaru