Menjalankan AI Agent di Sandbox agar Server Tetap Aman

Pernahkah kamu membiarkan AI agent menjalankan perintah langsung di server produksi, lalu baru sadar ia bisa menghapus folder, membaca file .env, atau mengirim data ke luar? Jawabannya sederhana: agent yang diberi akses ke terminal harus dikurung di sandbox, yaitu lingkungan terpisah yang kerusakannya tidak menjalar ke sistem utama.

AI agent berbeda dengan chatbot biasa. Ia tidak hanya menjawab, tapi juga menjalankan kode, memasang paket, dan memanggil API. Kesalahan kecil dalam instruksi, atau prompt injection yang tersembunyi di halaman web dan dokumen yang dibacanya, bisa berubah menjadi perintah nyata. Sandbox membatasi seberapa jauh akibatnya.

Kenapa agent tidak boleh langsung jalan di server utama?

Ada tiga risiko yang paling sering muncul saat agent punya akses shell penuh:

• Salah perintah. Model bisa salah menafsirkan tugas, misalnya membersihkan "file sementara" dengan pola yang ternyata ikut menghapus data aplikasi.
• Disusupi instruksi. Teks dari luar (isu GitHub, email, halaman web) bisa berisi perintah tersembunyi yang ikut dijalankan agent.
• Kebocoran rahasia. Agent yang bisa membaca seluruh disk juga bisa membaca kunci SSH, token API, dan kata sandi database, lalu tanpa sengaja menempelkannya ke log atau permintaan keluar.

Kalau konsep agent masih baru bagimu, baca dulu apa itu AI agent. Prinsip yang dipakai di sini sama dengan keamanan server pada umumnya: beri hak sekecil mungkin, dan anggap semua yang dijalankan agent belum tepercaya.

Langkah membuat sandbox untuk AI agent

Langkah berikut memakai Docker karena paling mudah dipasang di VPS Linux. Prinsipnya tetap berlaku untuk Podman atau alat lain.

1. Pisahkan mesinnya bila memungkinkan

Pilihan paling aman adalah VPS atau VM khusus untuk agent, terpisah dari server produksi. Kalau sesuatu rusak, kamu cukup menghapus dan membuat ulang mesin itu. Jangan simpan data pelanggan atau kunci produksi di mesin ini.

2. Jalankan container tanpa root dan cabut kapabilitas

Contoh perintah untuk memberi agent ruang kerja terbatas:

docker run --rm -it \
  --user 1000:1000 \
  --read-only --tmpfs /tmp:rw,size=256m \
  --cap-drop ALL --security-opt no-new-privileges:true \
  --memory 2g --cpus 1.5 --pids-limit 256 \
  --network none \
  -v "$PWD/kerja:/kerja:rw" -w /kerja \
  python:3.12-slim bash

Artinya: proses berjalan sebagai pengguna biasa, sistem file container hanya-baca kecuali /tmp dan folder kerja, semua kapabilitas Linux dicabut, proses tidak bisa menaikkan hak aksesnya, dan jaringan dimatikan sama sekali. Batas --memory, --cpus, dan --pids-limit mencegah agent menghabiskan sumber daya mesin, misalnya karena loop tak berujung.

Untuk lapisan tambahan, Docker juga bisa dijalankan dalam mode rootless, sehingga daemon Docker sendiri tidak berjalan sebagai root.

3. Jangan pernah memasang socket Docker ke dalam sandbox

Memasang /var/run/docker.sock ke container sama saja memberi akses root ke host, karena siapa pun yang memegang socket itu bisa membuat container baru dengan hak penuh. Hal yang sama berlaku untuk --privileged dan mount folder sistem seperti / atau /etc. Kesalahan konfigurasi Docker lain yang sering terjadi dibahas di cara mengamankan Docker di VPS.

4. Atur jaringan keluar dengan daftar izin

Agent yang memang perlu internet (misalnya untuk memasang paket atau memanggil API model) sebaiknya tidak diberi akses bebas. Arahkan lalu lintasnya lewat proxy yang hanya mengizinkan domain tertentu, misalnya registri paket dan endpoint API yang dipakai. Dengan begitu, data tidak mudah dikirim ke alamat sembarangan.

5. Beri kredensial yang sempit dan berumur pendek

Jangan masukkan file .env produksi. Buat token khusus agent dengan izin terbatas: hanya baca untuk repositori tertentu, kuota biaya API yang kecil, atau akun database dengan hak SELECT saja. Cabut token setelah tugas selesai.

6. Minta persetujuan manusia untuk aksi berisiko

Kebanyakan kerangka kerja agent bisa diatur agar berhenti dan bertanya sebelum menjalankan perintah tertentu. Wajibkan persetujuan untuk hal seperti git push, perubahan DNS, pengiriman email, pembayaran, atau perintah penghapusan. Agent boleh menyiapkan, manusia yang menekan tombol.

7. Catat semua yang dilakukan agent

Simpan log perintah dan keluaran di luar sandbox, sehingga agent tidak bisa menghapus jejaknya sendiri. Log ini berguna untuk menelusuri kesalahan dan menilai apakah izin yang diberikan sudah pas.

Seberapa kuat isolasi container biasa?

Container berbagi kernel dengan host. Kalau ada celah di kernel, proses di dalam container secara teori bisa keluar. Untuk agent yang menjalankan kode dari sumber yang tidak kamu kendalikan, pertimbangkan lapisan isolasi yang lebih tebal.

gVisor bisa dipasang sebagai runtime Docker, lalu dipakai dengan menambahkan --runtime=runsc pada perintah docker run. Ada sedikit biaya performa, terutama untuk beban yang banyak melakukan operasi file dan jaringan, jadi uji dulu dengan tugas agent yang sebenarnya.

Kesalahan yang sering terjadi

• Menjalankan agent di laptop kerja yang berisi kunci SSH dan sesi browser yang sedang login.
• Memberi agent token API dengan izin penuh "supaya tidak repot".
• Membuka jaringan tanpa batas karena agent sering gagal memasang paket.
• Memakai satu sandbox jangka panjang untuk banyak tugas, sehingga sisa file dan rahasia dari tugas lama menumpuk. Sandbox yang dibuang setelah tugas selesai (--rm) jauh lebih bersih.

Checklist singkat sebelum agent mulai bekerja:

• Mesin atau VPS terpisah dari produksi
• Container tanpa root, --cap-drop ALL, no-new-privileges, sistem file hanya-baca
• Batas memori, CPU, dan jumlah proses
• Tanpa socket Docker dan tanpa --privileged
• Jaringan keluar lewat daftar izin
• Token khusus agent dengan izin sempit
• Persetujuan manusia untuk aksi berisiko, log disimpan di luar sandbox