ZeroID: Beri Setiap Agen AI Identitasnya Sendiri, Rantai Delegasi, dan Tombol Matinya

Ketika sebuah agen AI melakukan commit kode, memanggil API, atau memindahkan uang, log audit seharusnya bisa menjawab tiga pertanyaan: agen mana yang melakukan ini, atas otoritas siapa, dan dengan izin apa. Terlalu sering hari ini jawabannya tidak bisa ditemukan, karena agen itu bertindak dengan login manusia pinjaman atau service account bersama. ZeroID adalah infrastruktur identitas open source yang dibangun untuk celah itu. Ia memberi setiap agen identitasnya sendiri yang bisa diverifikasi secara kriptografis, membiarkan agen mendelegasikan sebagian kecil otoritasnya ke sub-agen, dan mencabut seluruh rantai delegasi secara real time saat ada yang salah.

Poin Penting

ZeroID adalah infrastruktur identitas untuk agen otonom, bukan sistem login manusia dan bukan platform identitas workload umum.

Setiap agen mendapat URI identitas WIMSE/SPIFFE yang stabil, dan delegasi memakai token exchange RFC 8693 dengan penyempitan scope otomatis.

Mencabut kredensial induk langsung membatalkan seluruh rantai di bawahnya, tanpa menunggu token kedaluwarsa.

Ia dibangun di atas OAuth 2.1, WIMSE/SPIFFE, RFC 8693, DPoP, CIBA, dan OpenID Shared Signals Framework, dengan SDK untuk Python, TypeScript, dan Rust.

Saat artikel ini ditulis, proyek ini punya 209 bintang, 24 fork, dan 329 commit, berlisensi Apache 2.0, dan dibuat pada 2026-03-17.

Ia berjalan sebagai layanan Go dengan PostgreSQL, lokal lewat Docker Compose atau hosted di auth.highflame.ai, jadi mencobanya hanya butuh setup kecil, bukan migrasi platform.

Tonton sinyal repo 30 detiknya

Apa Sebenarnya ZeroID Itu

ZeroID, buatan Highflame, menyebut dirinya "Identity Infrastructure for Autonomous Agents" dan Autonomous Agent Identity Management System (AAIMS). Dalam bahasa sederhana, ini adalah server yang menerbitkan kredensial berumur pendek dan berscope sempit untuk agen, mencatat siapa yang mengotorisasinya, dan bisa mencabutnya lagi.

Perbedaan yang ditekankan proyek ini penting. ZeroID bilang ia bukan sistem identitas manusia seperti Okta, Entra, atau Clerk, dan bukan platform identitas workload atau non-human identity umum seperti SPIFFE/SPIRE, cloud IAM, atau secret manager. Ekosistem itu sudah matang, dan ZeroID dibangun di atas primitif mereka, termasuk URI WIMSE/SPIFFE, OIDC, dan RFC 8693, serta berfederasi dengan mereka. Yang ditambahkannya adalah lapisan berbentuk agen yang tidak dimodelkan sistem itu: identitas per agen, delegasi yang menyempit di sepanjang rantai agen, tingkat kepercayaan dari attestation, rantai on-behalf-of act, dan pencabutan real time dengan cascade.

Kerangka itu sejalan dengan pernyataan masalah dalam whitepaper OpenID Foundation tentang Identity Management for Agentic AI, yang diterbitkan Oktober 2025 dan dikutip langsung oleh ZeroID: "User impersonation by agents should be replaced by delegated authority. True delegation requires explicit 'on-behalf-of' flows where agents prove their delegated scope while remaining identifiable as distinct from the user they represent." Saat agen menyamar sebagai pengguna, log hanya menampilkan pengguna itu. Saat agen bertindak lewat delegasi, log menampilkan pengguna dan agennya, dan perbedaan itu adalah inti produk ini.

Proyek ini juga sudah dipakai di produksi oleh pembuatnya sendiri. README-nya bilang Highflame sudah memakai ZeroID untuk menggerakkan Agent Control and Governance Platform mereka selama beberapa bulan dan mengontribusikannya ke open source untuk memajukan bidang ini. Liputan independen sepakat soal dasarnya: Help Net Security melaporkan pada 2026-04-13 bahwa ZeroID adalah platform identitas open source untuk agen otonom dan sistem multi-agen, dibangun di sekitar rantai delegasi RFC 8693 dan pencabutan real time lewat OpenID Shared Signals Framework. Business Wire meliput peluncuran April 2026 dengan istilah yang sama, mencatat lisensi Apache 2.0 dan opsi hosted di auth.highflame.ai.

Mengapa Service Account dan OAuth Biasa Gagal

Tabel perbandingan di README-nya blak-blakan, dan itu cara tercepat melihat argumennya.

Service account adalah kasus terburuk: bersama, buram, dan tanpa jejak delegasi sama sekali. Kalau lima agen berbagi satu service account, mencabut satu agen berarti merotasi kredensial yang masih dibutuhkan empat agen lain, dan jejak audit tidak bisa membedakan mereka. OAuth dan OIDC bekerja baik untuk manusia yang sign in, dan sebagian untuk satu agen di dalam satu trust domain, tapi modelnya runtuh saat agen beroperasi secara asinkron, menelurkan sub-agen, atau melintasi batas organisasi. Token yang diterbitkan untuk manusia tidak secara alami membawa informasi "agen ini, bertindak untuk manusia itu, di kedalaman delegasi 2, hanya dengan tool ini".

Jawaban ZeroID adalah menjadikan agen sebagai principal kelas satu. Setiap agen mendapat URI identitas yang stabil dan unik secara global dalam bentuk spiffe://{domain}/{account}/{project}/{type}/{id}. Setiap token membawa URI itu, plus seluruh rantai on-behalf-of: siapa yang mengotorisasinya, scope apa yang diberikan, dan seberapa dalam delegasinya. Sistem apa pun yang dipanggil agen bisa memverifikasi rantai itu secara kriptografis, bukan sekadar mempercayai secret bersama.

Cara Kerja Delegasi, Langkah demi Langkah

Alur intinya adalah rantai, dan setiap hop mempersempit apa yang bisa dilakukan agen berikutnya.

Dua detail penegakan membuat ini lebih dari sekadar skema penamaan. Pertama, scope ceiling: allowed_scopes sebuah identitas adalah batas mutlak dari apa yang bisa dibawa tokennya, kebijakan kredensial hanya mempersempit di dalamnya, dan grant yang lapisannya tidak menyisakan apa pun ditolak, bukan diterbitkan tanpa scope. Kedua, batas kedalaman: kebijakan kredensial menetapkan kedalaman delegasi maksimum, dan profil token default membatasi rantai act bersarang sampai 16 agen, sehingga rantai yang lepas kendali tidak bisa tumbuh tanpa batas.

Proyek ini juga mencakup alur di sekitar inti itu. Agen yang sepenuhnya otonom bisa memakai API key tanpa manusia di loop. Manusia bisa mengotorisasi sekali, lalu agen berjalan otonom. Agen yang berjalan lama bisa me-refresh tokennya tanpa autentikasi ulang. Untuk momen yang benar-benar butuh manusia, OpenID CIBA membiarkan agen meminta persetujuan out-of-band, dengan pengguna menyetujui atau menolak lewat email, Slack, atau push mobile, dan agen mengambil tokennya lewat poll, ping, atau push. Untuk agen berisiko tinggi, token DPoP yang terikat ke pengirim mengikat token ke key klien, sehingga token curian saja tidak cukup untuk memakainya.

Khusus untuk coding agent, ZeroID membawa kosakata scope yang menjaga tim tetap konsisten: tools:read, tools:write, tools:execute, tools:network, tools:agent, dan tools:vcs, plus persona seperti reviewer hanya-baca dengan kedalaman 1, code editor dengan kedalaman 2, dan agen otonomi penuh dengan kedalaman 5. Kosakata itu juga yang bisa dicek server MCP di batas tool, tepat di titik instruksi hasil prompt injection bertemu kredensial yang tidak bisa mengotorisasi penulisan itu.

Apa yang Didapat Selain Token

ZeroID adalah server yang lebih lengkap daripada sekadar penerbit token, dan daftar fiturnya menunjukkannya.

Bagian attestation layak dicatat, karena di situlah kepercayaan menjadi sesuatu yang dibuktikan, bukan sekadar diklaim. Verifier untuk attestation software, platform, dan hardware berada di balik kontrak fail-closed, dan verifier OIDC yang dikirim mencakup GitHub Actions, GCP Workload Identity, dan token service account proyeksi Kubernetes, dengan kebijakan attestation per tenant untuk allowlisting issuer dan claim binding. Agen yang tidak bisa membuktikan apa dirinya tidak mendapat tingkat kepercayaan yang lebih tinggi, apa pun klaimnya.

Menjalankannya: Setup Kecil, Dependensi Nyata

Mencoba ZeroID tidak mengharuskan mengadopsi platform komersial Highflame. Server open source-nya adalah layanan Go dengan PostgreSQL.

Baris terakhir itu adalah caveat operasional yang harus dihormati. Referensi API di README menandai endpoint admin sebagai "protect at network layer", yang berarti deployment yang mengeksposnya secara ceroboh adalah kesalahan deployment, bukan fitur produk. Hal yang sama berlaku untuk signing key yang dibuat setup lokal dan API key yang diterbitkan saat registrasi: keduanya adalah akar dari seluruh rantai, jadi tempatnya di secret store, bukan di repo atau log chat.

Tumpukan Standar, dan Bagian yang Masih Berkembang

Pitch ZeroID adalah ia mengimplementasikan standar yang sudah ada, bukan menciptakan protokol proprietary, dan tabel standar di README-nya luar biasa lengkap.

Kejujuran mengharuskan separuh lain dari tabel itu. WIMSE adalah draft IETF, bukan standar final, dan README itu sendiri memetakan ZeroID terhadap draft ODIS dari CoSAI dan OASIS serta mendaftar persyaratan yang belum dipenuhinya. Standar identitas agen sedang ditulis sekarang, dan itu sekaligus peluang dan risikonya: mengadopsi ZeroID berarti mengadopsi tumpukan yang bisa bergeser saat WIMSE, ODIS, dan pekerjaan agentic OpenID difinalisasi. Penyeimbangnya adalah tumpukan itu dibangun dari potongan yang sudah dipakai luas, OAuth 2.1, JWT, dan token exchange, sehingga taruhannya ada pada komposisi, bukan pada satu protokol baru.

Batas yang Perlu Diperhatikan

ZeroID menyelesaikan identitas, delegasi, dan pencabutan. Ia tidak menyelesaikan semua hal di sekitar agen, dan proyek ini jelas soal scopenya. Ia bukan penyedia identitas manusia, jadi tidak menggantikan sistem login yang sudah ada. Ia bukan platform identitas workload umum, jadi tim yang sudah menjalankan SPIFFE/SPIRE atau cloud IAM akan memakainya berdampingan dengan sistem itu, secara federasi, bukan sebagai pengganti. Ia juga tidak, dengan sendirinya, membuat aksi agen menjadi aman: agen yang teridentifikasi dengan benar dan bertoken dengan scope yang tepat masih bisa melakukan sesuatu yang keliru di dalam scopenya, dan karena itu scope ceiling, kosakata tool, dan pengecekan di batas MCP sama pentingnya dengan token itu sendiri.

Skala adalah batas jujur lainnya. Dengan 209 bintang dan 24 fork, ZeroID adalah proyek yang fokus dengan traksi nyata untuk usianya, bukan platform identitas mainstream dengan riwayat operasional satu dekade. Sebanyak 329 commit dan 106 rilis menunjukkan pengembangan aktif, tapi tim yang mengadopsinya sebaiknya membaca dokumennya, menjalankannya dulu di staging, dan memantau standar yang dilacaknya. Pekerjaan yang direncanakan, API approvals dengan human-in-the-loop, CLI khusus, dan validator upstream GitHub Actions OIDC, juga menunjukkan bagian mana yang masih akan datang.

Kalau agen Anda sudah menyentuh sistem produksi, pertanyaan terkaitnya adalah apa yang boleh ditemukan dan dilaporkan agen itu. Untuk sudut keamanan spesialis tentang memberi tool AI pekerjaan yang terdefinisi, baca CVE MCP Server: Ubah Claude Menjadi Analis CVE Otomatis. Identitas memberi tahu siapa yang bertindak; tool keamanan berscope memberi tahu apa yang boleh dilihatnya.

Siapa yang Sebaiknya Mencoba, dan Siapa yang Sebaiknya Menunggu

ZeroID paling masuk akal untuk tim yang sudah menjalankan sistem multi-agen di mana pertanyaan audit mulai terasa menyakitkan: orchestrator yang menelurkan sub-agen, agen yang melintasi batas tim atau organisasi, atau agen berjalan lama yang melampaui satu sesi manusia. Kalau agen Anda masih berjalan sebagai satu service account di balik satu API key, dan Anda pernah kesulitan mengatakan agen mana yang melakukan apa, inilah tool yang membuat pertanyaan itu bisa dijawab.

Ia juga cocok kalau Anda menyukai batasan desainnya: token berumur pendek, bukan secret bersama berumur panjang, scope yang hanya menyempit menuruni rantai, batas kedalaman, dan jalur pencabutan yang tidak menunggu kedaluwarsa. Itulah properti yang mengubah "kami punya masalah agen" menjadi "kami punya sistem identitas agen".

Anda sebaiknya menunggu, atau hanya menjalankannya di staging, kalau agen Anda masih tunggal, berumur pendek, dan internal, kalau Anda tidak punya rantai delegasi untuk diaudit, atau kalau organisasi Anda mengharuskan standar final yang sudah diratifikasi sebelum mengadopsi infrastruktur identitas. Dalam kasus itu, pegang konsepnya, identitas per agen, otoritas yang didelegasikan bukan impersonasi, dan pencabutan cascade, lalu kunjungi lagi ZeroID saat WIMSE dan ODIS matang.

Pergeseran yang diwakilinya sederhana untuk dinyatakan dan sulit untuk di-retrofit belakangan. Berhenti meminta agen meminjam identitas manusia. Beri setiap agen namanya sendiri, kredensial yang membuktikannya, rantai yang menunjukkan siapa yang mengotorisasinya, dan tombol mati yang bekerja secara real time. Semua hal lain dalam keamanan agen menjadi lebih mudah begitu hal itu benar.

Pertanyaan yang Sering Diajukan

Apakah ZeroID pengganti Okta, Entra, atau Clerk?

Tidak. ZeroID menyatakan secara eksplisit bahwa ia bukan sistem identitas manusia. Ia dibangun di atas primitif identitas manusia dan berfederasi dengan mereka, tapi subjeknya adalah agen, bukan orang yang sign in.

Apakah ZeroID menggantikan SPIFFE/SPIRE atau cloud IAM?

Tidak. Itu adalah sistem identitas workload umum, dan ZeroID bilang ia bukan salah satunya. Ia memakai URI WIMSE/SPIFFE dan berfederasi dengan identitas workload, sambil menambahkan lapisan delegasi dan attestation khusus agen di atasnya.

Apa yang terjadi saat kredensial orchestrator dicabut?

Seluruh rantai di bawahnya langsung dibatalkan lewat pencabutan cascade, tanpa menunggu token kedaluwarsa. Sinyal continuous access evaluation lewat OpenID Shared Signals Framework bisa memicu pencabutan yang sama saat sinyal risiko muncul.

Bisakah sub-agen mendapat izin lebih besar daripada orchestratornya?

Tidak. Delegasi memakai token exchange RFC 8693 dengan penyempitan scope otomatis, dan scope ceiling membatasi apa yang bisa dibawa token identitas apa pun. Grant yang tidak menyisakan scope ditolak, bukan diterbitkan kosong.

Apakah saya butuh platform komersial Highflame untuk memakai ZeroID?

Tidak. ZeroID berlisensi Apache 2.0 dan berjalan sebagai layanan Go dengan PostgreSQL, lokal lewat Docker Compose atau hosted di auth.highflame.ai. Platform komersial Highflame menambahkan enforcement, observabilitas, dan manajemen kebijakan di atas lapisan identitas yang sama.

Apakah ZeroID sudah siap produksi?

Ia sudah dipakai di produksi di dalam platform Highflame sendiri, dan tumpukan standarnya sebagian besar sudah mapan, tapi WIMSE dan ODIS masih draft dan beberapa fitur, termasuk CLI khusus dan API approvals, masih direncanakan. Jalankan dulu di staging dan pantau standar yang diimplementasikannya.

Baca artikel ini dalam bahasa Inggris