Identity Lifecycle Management untuk AI Agent: Dari Provisioning ke Rotasi Kunci

Bayangkan agen AI Anda memiliki akses ke database pelanggan, API pembayaran, dan email corporate. Suatu hari, prompt injection membuat agen tersebut mengirim 10.000 data pelanggan ke alamat eksternal. Tanpa identity lifecycle management yang baik, insiden itu baru bisa dihentikan dengan memutus total akses — termasuk agen lain yang masih aman. Itulah mengapa identitas agen tidak bisa diperlakukan seperti skrip tanpa wajah. Setiap agen butuh identity, credential, dan lifecycle yang jelas. Artikel ini membahas secara mendalam bagaimana merancang identity lifecycle management untuk AI agent dari provisioning hingga rotasi kunci, dengan fokus pada praktik yang realistis untuk bisnis Indonesia di 2026. Untuk konteks governance yang lebih luas, lihat artikel pillar AI Agent Governance.

Apa Itu Identity Lifecycle untuk AI Agent?

Identity lifecycle management untuk AI agent adalah proses mengelola identitas dan kredensial agen dari lahir (provisioning), beroperasi (usage & monitoring), hingga pensiun (decommissioning atau rotasi). Tanpa lifecycle, identitas agen menjadi zombie credential: masih aktif, tapi tidak ada yang tahu siapa pemiliknya dan untuk apa.

Tiga Fase Utama

Fase pertama adalah provisioning: agen dibuat dengan identitas unik, atribut (tim, fungsi, scope, expiry), dan kredensial awal. Fase kedua adalah operational: kredensial digunakan, dipantau, dan dirotasi sesuai kebijakan. Fase ketiga adalah decommissioning: saat agen tidak lagi dibutuhkan, identitas dan kredensial dicabut, dan semua resource yang diakses agen di-revoke. Untuk konteks mitigasi risiko, baca artikel insider risk.

Provisioning: Jangan Pernah Pakai Kredensial Hard-coded

Pola anti-pola yang masih sering kita temui di 2026: agen dibuat dengan API key yang hard-coded di environment variable file, atau service account yang tidak punya expiry. Ini berbahaya karena tiga alasan: tidak ada jejak audit, tidak ada mekanisme rotasi, dan saat developer keluar, kunci masih aktif.

Pola Provisioning yang Benar

Provisioning yang benar mengikuti empat langkah: (1) agen di-spawn dengan workload identity (misalnya SPIFFE atau OIDC untuk workload), (2) kredensial diterbitkan oleh identity provider dengan scope eksplisit dan TTL pendek, (3) metadata agen (owner, purpose, scope) disimpan di registry, (4) kredensial tidak pernah di-cache di disk, hanya di-memory untuk durasi sesi.

Metadata yang Wajib Tercatat

Setiap agen yang di-provision harus punya metadata minimal: nama unik, owner (tim atau individu), purpose statement satu kalimat, scope (resource apa saja yang boleh diakses), expiry default, dan contact untuk incident. Metadata ini bukan formalitas — ini yang membedakan managed agent dari shadow agent yang tiba-tiba muncul di log.

Rotasi Kunci: Bukan Opsional, Tapi Wajib

Rotasi kunci adalah proses mengganti kredensial agen secara berkala atau berbasis event. Tanpa rotasi, satu kebocoran kredensial akan berlaku selamanya. Artikel ini merekomendasikan rotasi hybrid: berbasis waktu (default 24 jam untuk token pendek) dan berbasis event (langsung saat ada indikasi compromise).

Rotasi Berbasis Waktu

Token jangka pendek (1-24 jam) untuk akses API, sertifikat TLS jangka pendek (7-30 hari) untuk identitas workload. Pola ini membatasi blast radius jika kredensial bocor: pelaku hanya punya jendela waktu pendek.

Rotasi Berbasis Event

Event yang memicu rotasi: anomali akses terdeteksi, owner agen resign dari tim, ada laporan insiden, atau ada perubahan scope. Sistem harus bisa memicu rotasi otomatis tanpa intervensi manual. Topik ini berkaitan erat dengan audit trail real-time yang memberi signal untuk event.

Decommissioning: Kunci yang Tidak Pernah Dicabut

Fase yang paling sering diabaikan. Saat workflow selesai atau agen di-replace, kredensialnya harus dicabut. Tanpa proses decommissioning, perusahaan akan mengumpulkan zombie credentials yang terus bertambah setiap bulan.

Pola Decommissioning

Tiga langkah: (1) revoke semua kredensial aktif, (2) hapus identitas dari registry (atau tandai sebagai retired), (3) audit log terakhir untuk memastikan tidak ada akses anomali sesaat sebelum revocation. Tanpa tiga langkah ini, ada celah di mana agen yang sudah “mati” masih bisa melakukan aksi.

Lima Praktik Terbaik Identity Lifecycle 2026

1. Workload identity over static key: pakai SPIFFE, OIDC workload identity, atau cloud-native identity broker.
2. Just-in-time access: akses diberikan sesaat sebelum dibutuhkan, dicabut segera setelah selesai.
3. Scoped permissions: agen tidak punya akses global, hanya ke resource yang dibutuhkan scope-nya.
4. Auto-rotation: tidak ada kredensial yang berlaku lebih dari 24 jam tanpa rotasi otomatis.
5. Owner-bound: setiap agen terikat ke owner manusia yang bertanggung jawab. Owner rotation memicu audit dan potensi re-provisioning.

Tool yang Mendukung Lifecycle

Beberapa kategori tool yang relevan: identity provider untuk workload (SPIRE, cloud IAM workload identity), secret manager (HashiCorp Vault, cloud KMS), agent registry (custom atau framework-native), dan observability stack untuk audit. Kombinasi yang umum di 2026: SPIRE + Vault + OpenTelemetry ke SIEM. Untuk detail risiko operasional, lihat artikel insider risk.

“Kredensial tanpa expiry adalah utang risiko. Anda hanya belum tahu kapan jatuh temponya.”

Kesimpulan

Identity lifecycle management untuk AI agent adalah fondasi yang tidak bisa ditunda. Tanpa identitas, tidak ada governance. Tanpa rotasi, tidak ada batasan paparan. Tanpa decommissioning, tidak ada cara membersihkan permukaan serangan. Mulailah dari provisioning, lalu rotasi, lalu decommissioning. Untuk kerangka governance yang lebih luas, kembali ke artikel pillar dan baca juga audit trail.

FAQ

Berapa lama TTL ideal untuk token agen?
Untuk aksi bernilai tinggi, 5-15 menit. Untuk workflow jangka menengah, 1-4 jam. Lebih dari 24 jam sebaiknya hanya untuk sistem yang sangat terbatas scope-nya.

Apakah SPIFFE wajib?
Tidak wajib, tapi sangat direkomendasikan. Alternatifnya bisa pakai cloud-native workload identity (AWS IAM Roles Anywhere, GCP Workload Identity, Azure Managed Identity).

Bagaimana dengan agen lokal tanpa internet?
Workload identity tetap berlaku, cukup dengan internal CA. Yang penting: identitas, scope, dan expiry-nya eksplisit.

Tinjau lifecycle agen Anda minggu ini — provisioning tanpa decommissioning adalah bom waktu yang terus berdetak.