Sandbox MCP Server dengan Docker: Panduan Keamanan AI Agent Tools

MCP (Model Context Protocol) makin populer sebagai standar komunikasi antara AI agent dengan tools eksternal. Tapi satu pertanyaan yang jarang dibahas secara serius: seberapa aman MCP server yang lo jalanin?

Masalahnya fundamental: MCP server punya akses ke filesystem, network, dan kadang sensitive data di host. Kalau AI agent bisa nge-trigger tool call secara otomatis — attacker yang berhasil ngelakuin prompt injection bisa ngeksploit MCP server buat ngerusak sistem yang lebih luas.

Di artikel ini gw breakdown cara sandbox MCP server properly pake Docker. Bukan sekadar "jalanin di container" — tapi hardening tiap layer: network isolation, read-only filesystem, capability dropping, dan monitoring yang real.

Kenapa MCP Server Jadi Attack Vector?

MCP server pada dasarnya adalah lokal API endpoint yang nyediain tools ke AI agent. Flow-nya:

User ngetik prompt di chat → AI agent decide butuh tool call
Agent kirim request ke MCP server → MCP server execute command / read file / akses API
Hasilnya dikembalikan ke AI agent → agent format response ke user

Attack surface-nya ada di step 2: MCP server execute operasi dengan privilege yang sama dengan user yang jalanin. Kalau gak di-sandbox, MCP server bisa:

Read semua file di home directory
Nge-exec command berbahaya
Mengirim data ke server eksternal
Modify system files

Ini relevan banget dengan temuan GitLost vulnerability — di mana prompt injection di GitHub AI agent bisa exfiltrate private repo content. MCP server yang running tanpa sandbox punya risk profile yang sama.

Layer 1: Network Isolation — --network none

Ini langkah paling simpel tapi paling impactful. Mayoritas MCP server gak butuh akses network sama sekali — mereka cuma komunikasi via stdin/stdout dengan AI agent.

# Jalanin MCP server tanpa network akses sama sekali
docker run --rm -i   --network none   mcp-server:latest

--network none bikin container gak punya network interface selain loopback. Gak bisa HTTP request, gak bisa DNS lookup, gak bisa konek ke database remote. Kalau MCP server butuh akses ke API tertentu? Jangan dikasih network full — pake --network host dengan proxy atau tunnel yang audit-able.

Gw punya MCP server buat filesystem operations yang jalan pake --network none. Ini artinya: bahkan kalau attacker berhasil prompt injection dan nyuruh MCP server ngirim file ke server external — secara network gak mungkin karena container gak punya akses keluar.

Layer 2: Read-Only Filesystem

Selain network, filesystem juga harus di-restrict. Banyak MCP server cuma butuh baca file tertentu, bukan nulis.

# Read-only filesystem + mounted volume terbatas
docker run --rm -i   --network none   --read-only   --tmpfs /tmp:size=64M   -v /home/user/data:/data:ro   mcp-server:latest

Yang terjadi dengan config ini:

Container filesystem read-only — gak bisa nulis file baru di system paths
/tmp di-mount sebagai tmpfs (bisa nulis, tapi ilang pas container stop)
/home/user/data di-mount read-only — MCP server bisa baca data yang diperlukan, tapi gak bisa modifikasi atau hapus

Untuk MCP server yang emang perlu nulis (kaya code editor tools), mount volume spesifik: -v /home/user/projects/allowed-dir:/workspace �� bukan seluruh home directory.

Layer 3: Drop All Capabilities

Docker container jalan dengan set of Linux capabilities bawaan. Beberapa di antaranya berbahaya kalo MCP server di-compromise:

# Drop semua capabilities — MCP server gak butuh satupun
docker run --rm -i   --network none   --read-only   --cap-drop ALL   --security-opt no-new-privileges:true   --security-opt seccomp=default.json   mcp-server:latest

--cap-drop ALL berarti container kehilangan kemampuan kaya CAP_NET_RAW (bikin raw socket), CAP_SYS_ADMIN (mount filesystem), CAP_DAC_OVERRIDE (bypass file permission). no-new-privileges mencegah container nge-escalate privilege via suid binary.

Monitoring: docker diff dan Logs

Sandbox aja gak cukup — lo perlu tau kalo ada yang mencoba breach. Docker punya built-in tools buat ini:

# Cek file apa aja yang berubah di container
docker diff mcp-server

# Output:
# A /tmp/malicious_script.sh  
# C /etc/passwd              
# Perubahan mencurigakan → investigasi

# Cek logs dengan detil
docker logs mcp-server --tail 100

Di production, integrasikan ini dengan monitoring:

docker events — real-time stream event Docker daemon. Filter container start/stop/modify
auditd — system-level audit buat track system calls dari container
Falco — runtime security monitoring yang detect anomalous behavior di container

Set benchmark dari container security hardening yang udah gw tulis sebelumnya: baseline-nya adalah setiap perubahan file di luar allowed paths harus di-log dan di-alert.

Setup Lengkap: Satu Script

Ini script yang gw pake di VPS production buat jalanin MCP server:

#!/bin/bash
# run-mcp-sandbox.sh — Jalanin MCP server dengan full sandbox

IMAGE="mcp-custom-tools:latest"
CONTAINER_NAME="mcp-sandbox-$(date +%s)"

docker run --rm -i   --name "$CONTAINER_NAME"   --network none   --read-only   --tmpfs /tmp:size=64M,noexec,nosuid   --tmpfs /run:size=32M,noexec,nosuid   --cap-drop ALL   --security-opt no-new-privileges:true   --security-opt seccomp=default.json   -v /opt/mcp-config/allowed-tools.json:/config/tools.json:ro   -v /opt/mcp-data/:/data:ro   --log-driver json-file   --log-opt max-size=10m   --log-opt max-file=3   "$IMAGE" "$@"

# Logging ke journal
echo "[MCP] Container $CONTAINER_NAME selesai di $(date)" | logger -t mcp-sandbox

Skenario Testing

Gw selalu test sandbox MCP server dengan 3 skenario sebelum production:

Network exfiltration test: Dari dalam container, coba curl https://attacker.com/test. Expect: connection timeout / network unreachable.
File exfiltration test: Coba baca /etc/shadow, /root/.ssh/id_rsa. Expect: permission denied / file not found.
Privilege escalation test: Coba sudo, chroot, mount. Expect: operation not permitted.

Kalau salah satu dari test ini berhasil — sandbox lo bocor. Fix dulu sebelum jalanin MCP server di production.

Untuk AI agent yang pake MCP server buat filesystem operations, baca juga self-hosted tools yang bisa jadi alternatif — mengurangi dependency ke third-party API yang gak bisa di-audit security-nya.