Kalau tim Anda mulai memakai agen AI — Claude Code, Codex, atau asisten coding lain — untuk menulis kode dan menjalankan perintah di server, cepat atau lambat muncul satu pertanyaan yang sulit dijawab: sebenarnya agen itu boleh mengakses apa saja? Docker menjawabnya lewat sebuah standar terbuka. Pada 24 September 2026 Docker menerbitkan Docker Sandbox Kit Specification v3 di bawah lisensi Apache 2.0, dan membawanya ke CNCF agar dikelola secara netral. Polanya persis seperti saat Docker menyerahkan format image dan runtime runc ke Linux Foundation — langkah yang dulu melahirkan OCI dan membuat image Docker bisa berjalan di mana saja.

Masalahnya: izin agen hidup di shell history, bukan di file

Kontainer dirancang untuk aplikasi, bukan untuk agen. Sebuah image kontainer menggambarkan bagaimana perangkat lunak dibangun dan dijalankan; untuk web service itu cukup — ia dapat satu network dan satu port. Agen berbeda: ia aktor probabilistik yang memutuskan sendiri langkah berikutnya. Ia akan menginstal paket yang butuh root, membuka port yang tidak pernah direncanakan, dan mencoba hal lain saat langkah pertamanya diblokir.

Karena itu izin diberikan sepotong-sepotong: satu bind mount, satu token dengan scope lebih luas dari kebutuhan tugas, satu aturan firewall yang lebih cepat dibuka daripada dipersempit. Masing-masing terlihat wajar. Gabungannya justru menghapus isolasi yang sedang diandalkan — dan tidak satupun butuh eksploit, sebab lubangnya adalah konfigurasi yang ditambahkan dengan sengaja.

Bagian terburuknya: tidak ada file yang mencatat izin itu. Ia tersimpan di shell history, dashboard, dan ingatan orang. Hasilnya, pertanyaan sederhana — apa yang boleh dilakukan agen ini? — tidak bisa dijawab, apalagi di-diff dengan konfigurasi minggu lalu.

Kit: satu image, satu digest, satu jawaban

Solusi Docker bernama Kit: cara mengemas agen, tools-nya, dan daftar izin yang dimintanya menjadi satu artefak yang bisa dibagikan ke seluruh tim. Perubahan penting di versi ketiga format ini adalah Kit kini image OCI biasa — bukan tipe artefak baru, tanpa media type khusus, tanpa file sampingan. Deklarasi izin disimpan pada satu anotasi manifest (vnd.docker.sandbox.kit.descriptor), sedangkan isinya berada di layer.

Konsekuensi praktisnya besar: Kit dibangun dengan docker buildx build, ditarik dengan docker pull, dipindai dan ditandatangani memakai tool yang sudah Anda jalankan, dan bisa dipakai di klausa FROM. Pinning digest berarti memaku isi, deklarasi, dan metadata sekaligus. Tidak ada yang perlu di-deploy ulang di registry maupun pipeline keamanan Anda.

Ada dua jenis Kit:

• Workload — berjalan di sandbox dan menyediakan root filesystem.
• Mixin — overlay: sebuah CLI beserta aturan network-nya, binding kredensial, atau konteks untuk agen.

Satu workload bisa diluncurkan bersama sejumlah mixin. Komposisinya mengikuti graph dependensi yang dideklarasikan lewat provides dan requires, bukan urutan flag yang Anda ketik, sehingga set yang sama selalu menghasilkan image yang sama.

Contoh: izin yang bisa dibaca, direview, dan ditolak

Berikut potongan mixin GitHub CLI dari repositori spesifikasi, ditulis dalam YAML yang bisa dibaca manusia:

capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

Bacalah sebagai surat izin. Kit ini meminta akses ke GitHub dan tidak ke mana pun selain itu; sebagian besar API boleh dipakai, tetapi DELETE di bawah /repos/** ditolak karena deny selalu menang. Artinya token yang bisa membuka pull request tidak bisa menghapus repositori. Bagian credential bekerja dengan cara serupa: kredensial dikelola proxy (proxyManaged: true), runtime yang sesuai menyuntikkan nilai asli hanya pada request ke domain yang disebut, sementara di dalam sandbox hanya ada sentinel.

Cara mulai di tim Anda

1. Pisahkan dua hal: kontainer mengemas aplikasi, sandbox mengurung agen. Docker Sandbox adalah microVM dengan kernel sendiri, sehingga batasnya berada di bawah jangkauan model.
2. Definisikan kemampuan agen Anda sebagai capability bertipe di dalam Kit — network rule, kredensial, volume, port, device, path skill — bukan lewat flag docker run atau ingatan orang.
3. Review daftar capability sebelum menjalankan. Saat versi baru meminta izin lebih, perubahannya muncul sebagai baris tambahan yang bisa ditolak.
4. Pin digest Kit di pipeline, lalu jalankan hanya pada runtime yang conforming.

Yang perlu diingat: spesifikasi tanpa runtime belum menegakkan apa pun

Dokumentasi Docker menegaskannya dengan jelas: “A Kit grants itself nothing. Each entry is a request, and the host decides.” Tanpa runtime yang mengimplementasikan perilaku spesifikasi, anotasi itu inert — hanya image tanpa penegakan. Runtime tersebut juga wajib memblokir host yang tidak ada di daftar. Docker Sandboxes adalah runtime conforming pertama, tetapi di bawah naungan CNCF diharapkan bukan satu-satunya. Satu lagi yang menjamin keamanan: permintaan wajib yang tidak bisa dipenuhi host akan menolak peluncuran, bukan menjalankan agen dengan wewenang kurang atau justru lebih dari yang dideklarasikan.

Kenapa ini penting untuk tim kecil dan instansi

MCP sudah menstandarkan cara agen berbicara dengan sebuah tool. Kit menstandarkan cara mempublikasikan seluruh kesepakatan: agen, tools, dan izin yang dimintanya, dalam satu image yang bisa ditarik siapa pun, direview, dan ditegakkan. Bagi tim TI yang tidak punya unit keamanan khusus, ini berarti aturan akses agen tak lagi bergantung pada disiplin individu. Docker menyebut sejumlah mitra yang sudah membangun Kit untuk tool mereka, termasuk AWS, Box, Datadog, Dynatrace, JFrog, Palo Alto Networks, dan Snyk — tanda bahwa format ini bergerak ke arah supply chain, bukan sekadar fitur satu vendor.

Sumber: From Dockerfile to Kit: the Docker Sandboxes Kit Specification (Docker Blog, 24 September 2026) dan Docker and CNCF partner on an open spec for agent permissions (Docker Blog, 24 September 2026). Spesifikasi v3 tersedia terbuka di repositori docker/sandbox-kit-spec (Apache 2.0).