Sandbox AI Agent Tembus? 7 Vektor Escape yang Orang Lewatkan

Agen AI Kamu Tidak Bisa Kabur. Atau Bisa?

Kamu sudah deploy AI agent otonom di dalam container. Docker, Kubernetes, namespace yang rapi. Rasanya aman, kan?

Sayangnya, banyak tim keamanan salah ngira container itu tembok besi. Padahal 37 persen tim enterprise baru sadar tahun ini bahwa agent mereka bisa mengakses data sensitif di luar sandbox tanpa terdeteksi.

Yang lebih menakutkan? Banyak vektor escape ini masih berlaku meskipun kamu sudah pasang se cc, AppArmor, dan network policy yang strict.

Intinya: container bukanlah isolation yang cukup untuk autonomous agent yang berpotensi mengeksekusi kode berbahaya.

Kenapa Container Bukan Solusi untuk AI Agent

AI agent beda dari aplikasi web biasa. Agent bisa memanggil tools, menjalankan shell commands, dan mengevaluasi hasilnya secara mandiri. Tantangnya: kamu hanya bisa mengontrol environment tempat agent berjalan, tapi kamu tidak bisa memprediksi apa yang agent minta lakukan.

Dua kekuatan container secara native:

• Process isolation — PID namespace mencegah agent mengintip proses lain di host
• Filesystem isolation — overlay filesystem memotong akses ke struktur direktori host
• Resource limits — cgroup mencegah agent memakan seluruh CPU dan memory

Tapi tiga kelemahan besar:

• Container bisa di-run sebagai root (privileged mode)
• Node kernel tetap bisa diakses dari dalam container
• Container runtime itu sendiri punya CVE sejarah panjang

7 Vektor Escape yang Masih Banyak Orang Lewatkan

1. Container Runtime Kernel Escape (CVE-2024-21626)

CVE ini di Qualys menyebutkan top-level container untuk banyak runtime bisa akses host filesystem via /proc/self/exe. Agent yang terinfeksi cukup jalankan:

ls -la /proc/self/exe
cat /proc/self/mountinfo

Karena bukan masalah aplikasi, tapi masalah kernel exposure. WAF sama sekali tidak bisa mendeteksi ini.

Kalau kamu belum pernah baca artikel tentang peraturan legal AI agent, ini saatnya mulai dokumentasikan audit trail untuk setiap eksekusi agent.

2. Kubernetes RBAC Over-Permission

Service account yang dipakai agent untuk komunikasi dengan API server sering dapatizin terlalu luas. Contohnya bisa baca secrets dari namespace lain hanya karena:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: agent-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
subjects:
- kind: ServiceAccount
  name: agent-sa
  namespace: agent-ns
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Hanya sesat role seperlunya, misalnya: read-only akses ke namespace milik agent sendiri.

Baca juga: cara deteksi WAF dan IDS gagal menangkap agent yang dicuri.

3. Environment Variable Leakage

API keys, database credentials, dan cloud tokens sering disimpan di environment variables. Agent yang sudah terkompromikan bisa membaca:

printenv | grep -i key
printenv | grep -i token
printenv | grep -i secret

Solusinya: gunakan workload identity atau secret store yang benar-benar lepas dari container environment.

Mungkin relevan juga dengan kredensial abandoned yang jadi celah serangan saat decommissioning agent.

4. Volume Misconfiguration

Bind mount yang salah konfigurasi membuat agent bisa mencuri file sensitif dari host:

volumes:
  - name: host-fs
    hostPath:
      path: /etc
      type: Directory

Kalau mounted path terlalu luas, agent bisa baca file /etc/shadow, ~/.ssh/id_rsa, atau database credential dari aplikasi lain yang jalan di host yang sama.

5. API Key Dump ke Disk atau Log

AI agent sering bikin temporary file untuk caching atau logging. API key yang dipakai untuk panggilan tools bisa tercetak ke file dengan ekstensi .json, .log, atau .tmp. Kemudian:

– Container filesystem bisa di-bind mount ke persistent volume
– Log aggregation framework bisa mengumpulkan dan menyimpan data sensitif
– Debug tools seperti kubectl exec bisa membaca file-container

6. Syscall Exploitation

Agent yang sudah dapat akses shell bisa mencoba syscall yang seharusnya diblokir:

• mount — mount host filesystem ke container
• pivot_root — ganti root filesystem
• ptrace — attach ke proses lain di host
• bpf() — jalankan eBPF program untuk privilege escalation

Penyelesaiannya seccomp profile yang benar-benar didefinisikan, bukan yang default bawaan Kubernetes yang terlalu permisif.

7. Network Pivoting ke Internal Services

Container dengan network policy kurang strict bisa menjangkau:

– Metadata endpoint cloud (GCP metadata.google.internal, AWS 169.254.169.254)
– Internal database tanpa autentikasi tambahan
– Message queue dari service lain yang tanpa encryption at rest
– Load balancer API endpoint internal yang belum diproteksi

Framework S.E.A.L. untuk Mencegah Escape

Framework ini dirancang khusus untuk ML platform architect dan AI security engineer yang perlu proteksi praktis.

S — Scope Permission Hanya Sesuai Kebutuhan

Lebih baik agent gagal karena kurang permission daripada terlalu banyak akses. Semua permission harus didemonstrasikan kebutuhan terlebih dahulu.

• RBAC dengan prinsip least privilege, bukan default cluster-admin
• Network policy yang whitelist-only untuk outbound traffic
• Service account khusus per agent, tanpa reuse antar deployment

E — Encrypt Secrets di Runtime, Bukan di Env

Pindahkan semua credential dari environment variable ke:

– HashiCorp Vault atau AWS Secrets Manager
– Workload identity (misal: GKE Workload Identity)
– Ephemeral secrets yang di-rotate secara otomatis per job session

A — Audit Every Action dengan Structured Log

Agent harus menghasilkan log terstruktur untuk setiap tool invocation:

– Timestamp
– Tool name + parameter yang dipanggil
– Response status
– Duration
– Resource yang diakses

Log ini dikirim ke system terpisah dari application log, dan dianalisis secara real-time untuk anomaly detection sesuai pendekatan yang sudah kita bahas di artikel deteksi anomali behavior untuk agent.

L — Limit Syscall Bersifat Restrictif

Konfigurasi seccomp dan AppArmor secara eksplisit:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "names": ["read", "write", "close", "poll", "futex"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Hanya allow syscall yang benar-benar dibutuhkan agent untuk operasi normal.

Checklist Dapur: Apakah Environment Kamu Aman?

• Agent tidak running sebagai root di dalam container
• Container runtime diperbarui ke versi terbaru tanpa CVE aktif
• RBAC ditinjau minimal sekali setiap sprint
• Tidak ada secrets di environment variables
• Seccomp profile aktif dan di-test secara berkala
• Network policy memblokir akses ke metadata endpoint cloud
• Log agent disimpan di sistem terpisah dan di-monitor untuk anomaly
• Agent tidak punya akses host filesystem lewat volume mount

Kalau ada yang merah di atas, itu titik pertama yang perlu diperbaiki sebelum deploy agent baru.

Apa yang Harus Kamu Lakukan Sekarang

Escape vector hanyalah satu dari banyak ancaman yang bisa menimpa AI agent otonom kamu. Di artikel berikutnya kita bahas prompt injection yang bisa memaksa agent mencuri data tanpa kamu sadari — siapa yang harus menanggung risiko hukum, dan cara menguranginya sebelum regulator datang mengejar.

Sampai ketemu di artikel selanjutnya.