Sepuluh tahun lalu industri container menyelesaikan satu masalah besar: setiap vendor punya format image dan runtime sendiri. Docker lalu menyumbangkan format image dan runtime runc-nya ke Linux Foundation, dan lahirlah OCI (Open Container Initiative). Hasilnya, image yang dibangun di mana pun bisa berjalan di mana pun. Kini masalah serupa muncul lagi, tetapi kali ini soal agen AI: belum ada format bersama untuk menjawab satu pertanyaan sederhana — "apa sebenarnya yang boleh dilakukan agen ini?"

Jawaban pertanyaan itu hari ini tersebar di flag docker run, file Compose, konfigurasi CI, dashboard, riwayat shell, dan ingatan orang yang menyetelnya. Untuk tim yang sudah memakai coding agent seperti Claude Code atau Codex, aturan akses itu jarang tercatat utuh di satu tempat.

Pada 24 September 2026, di acara WeAreDevelopers, Docker mengenalkan Docker Sandbox Kit Spec — spesifikasi terbuka berlisensi Apache 2.0 tentang cara mengemas agen, tool-nya, dan seluruh hak aksesnya dalam satu artefak — lalu langsung menyerahkannya ke CNCF di bawah tata kelola netral. Sejumlah mitra seperti AWS, Datadog, Dynatrace, JFrog, Snyk, dan Palo Alto Networks sudah membangun Kit untuk tool mereka.

Apa itu Kit?

Kit adalah image OCI biasa. Di dalamnya ada tiga hal: agen yang dijalankan, tool pendukungnya, dan daftar bertipe berisi semua yang dimintanya — host jaringan, kredensial, volume. Tiga hal yang membuatnya rapi:

• Tidak ada format baru. Deklarasi disimpan di manifest annotation vnd.docker.sandbox.kit.descriptor, isinya di layer. Registry, scanner, dan tool signing yang sudah Anda pakai bisa menangani Kit tanpa perubahan apa pun.
• Satu artefak, satu digest. Mem-pin digest image berarti mem-pin isi, deklarasi, dan metadata sekaligus. Tidak ada file pendamping yang bisa basi.
• Hak akses jadi bisa di-diff. Ketika versi baru agen meminta kredensial atau host tambahan, perubahan itu muncul sebagai baris tambahan yang bisa ditolak — perubahan izin jadi setara dengan perubahan kode.

Contoh: batas akses dalam bentuk kode

Potongan descriptor dari Kit GitHub CLI di repo spesifikasi (diringkas) menunjukkan bagaimana "surat izin" ditulis:

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/**]

Bacanya: Kit ini meminta akses ke GitHub dan tidak ke mana-mana lagi; DELETE ke /repos/** dilarang, dan aturan deny selalu menang. Ada juga capability com.docker.sandbox/credential@1 yang bersifat proxy-managed: runtime yang menyuntikkan token asli, sementara di dalam sandbox hanya ada nilai sentinel. Artinya, token yang bisa membuka pull request tidak otomatis bisa menghapus repositori.

Dua kata kunci di sini adalah asks dan conforming. Kit tidak memberi izin kepada dirinya sendiri — setiap entri adalah permintaan, dan host yang memutuskan. Tanpa runtime yang conform, annotation itu hanya jadi image biasa tanpa penegakan aturan. Docker Sandboxes adalah runtime pertama yang menegakkannya.

Workload dan mixin

Ada dua jenis Kit. Workload memasok root filesystem dan hal yang dijalankan; mixin adalah overlay — bisa CLI, binding kredensial, aturan jaringan, atau konteks untuk agen. Komposisinya ditentukan oleh graf dependensi (provides/requires), bukan urutan flag, sehingga set yang sama selalu menghasilkan image yang sama.

Cara mencoba

1. Pasang CLI sbx (untuk menjalankan Kit). macOS: brew trust docker/tap lalu brew install docker/tap/sbx. Windows: winget install -h Docker.sbx. Ubuntu: pasang paket docker-sbx dari instalasi Docker (mode REPO_ONLY=1), lalu daftarkan akun Anda ke grup kvm agar /dev/kvm bisa dipakai.
2. Login: jalankan sbx login.
3. Jalankan Kit publik — Kit sudah tersedia sebagai image biasa di Docker Hub, tidak perlu build dulu:

   sbx run docker/sbx-kit-shell:1.0.0 --kit docker/sbx-kit-claude-mixin:2.1.281 .

   Mode cloud memakai referensi yang sama, dengan sbx --cloud run ....
4. Bikin Kit sendiri dari repo docker/sandbox-kit-spec: setel KIT_REGISTRY ke namespace registry Anda, lalu task kit:push KIT=hello TAG=1.0.0 dan jalankan hasilnya. Di dalam sandbox, Kit bisa "membaca dirinya sendiri": cat /usr/share/sandbox/kit/hello/kit.yaml.

Catatan penting: rilis stabil sbx saat ini mendukung Kit v3 (format pada spesifikasi ini) baik secara lokal maupun cloud. Jangan mencampurnya dengan Kit v2 yang masih ada di organisasi sbx di Docker Hub.

Status dan arah ke depan

Spesifikasinya masih eksperimental dan versi final ditargetkan Q4 2026. Perubahan dirancang tetap aditif: capability punya versi sendiri (@1, @2), jadi Kit yang dipakai hari ini diharapkan tetap bisa di-resolve. Masukan bisa disampaikan lewat issue di repositori GitHub-nya.

Untuk tim IT di Indonesia: jika tim Anda mulai memakai coding agent, jangan biarkan aturan aksesnya hidup di riwayat shell atau ingatan satu orang. Simpan sebagai artefak yang bisa direview, di-pin, dan diturunkan ke seluruh tim — itulah arah yang ditawarkan Kit. Mulailah kecil: tarik satu Kit publik, baca capability di dalamnya, lalu jalankan di sandbox yang terpisah dari mesin produksi.

Sumber: Docker and CNCF partner on an open spec for agent permissions (Docker Blog), From Dockerfile to Kit: the Docker Sandboxes Kit Specification (Docker Blog), docker/sandbox-kit-spec (GitHub).