Agen kini menjadi workload IAM, dan service account Anda belum siap

Mari mulai dengan memberikan argumen terbaik bagi pendekatan lama, karena pendekatan itu bukan ide bodoh. Service account dan API key telah menopang workload mesin selama dua dekade. Keduanya dipahami, diaudit, didukung oleh setiap cloud dan setiap alat SaaS, dan tim keamanan sudah memiliki spreadsheet yang mencatat semuanya. Ketika seseorang mengatakan agen membutuhkan kategori identitas baru, respons yang masuk akal adalah: kita sudah punya kategorinya, namanya identitas non-manusia, tinggal gunakan.

Masalahnya, di sinilah pendekatan itu berhenti bekerja. Service account menjawab pertanyaan "sistem mana yang melakukan panggilan?" Agen memaksa pertanyaan yang lebih sulit: "agen mana yang melakukan panggilan, atas nama siapa, untuk tujuan apa, dan siapa yang dapat mencabutnya dalam tiga puluh detik berikutnya?" Angka dari industri IAM sendiri menunjukkan identitas non-manusia kini lebih banyak daripada manusia dalam skala satu orde magnitudo, dan Verizon DBIR 2026 memperingatkan bahwa service account dan machine account adalah yang perlu diperhatikan ketika AI agentik mulai hadir, menurut pembacaan Token Security atas laporan tersebut. Ini adalah penjelasan tentang mengapa pemetaan lama gagal, apa yang sedang dibangun untuk menggantikannya, dan seperti apa kegagalannya yang sudah terjadi.

Poin utama - Service account dan API key mengasumsikan pemanggil yang stabil dan deterministik. Agen bersifat sementara, non-deterministik, dan saling mendelegasikan tugas, sehingga asumsi audit, pencabutan, dan least privilege yang tertanam dalam kredensial bersama menjadi rusak. - Arah standar bergerak menuju identitas workload per agen: kelompok kerja IETF WIMSE didorong untuk mewajibkan agar agen dapat dibedakan berdasarkan identitas, bukan hanya token scope, dengan identifier per agen bergaya SPIFFE untuk kebijakan, audit, dan pencabutan. - Insidennya sudah nyata: token OAuth yang dikompromikan di ekosistem Salesloft Drift digunakan untuk berpindah ke lingkungan Salesforce perusahaan, dan kebocoran Hugging Face pada Juli dieksekusi dari awal hingga akhir oleh agen otonom. - Panduan implementasi mulai bertemu pada pola yang sama: identitas khusus per agen, kredensial berumur pendek dan terbatas pada tugas yang diterbitkan di luar konteks model, serta audit trail yang dikaitkan ke agen, bukan ke peran bersama. - Jika semua agen Anda melakukan autentikasi sebagai satu service account bersama, log Anda tidak dapat memberi tahu agen mana melakukan apa. Itulah tes yang perlu diterapkan minggu ini.

Apa yang terjadi

Dua hal bertemu pada minggu-minggu pertama Agustus. Pertama, pembicaraan standar menjadi spesifik. Sebuah issue pada draf arsitektur IETF WIMSE, diajukan pada 4 Agustus, berpendapat bahwa bahasa draf saat ini tentang perantara AI terlalu lemah: draf mengizinkan "separate workload identities or token scopes" untuk membedakan tindakan agen otonom, dan issue tersebut menjelaskan bahwa token scope tidak menyelesaikan masalah. Scope membatasi apa yang boleh dilakukan token, tetapi tidak mengubah siapa pemilik identitas token tersebut. Beberapa agen yang berbagi satu kredensial tetap tidak dapat dibedakan dalam log audit, sistem pencabutan, dan kebijakan per agen, seberapa pun berbeda scope-nya. Solusi yang diusulkan: platform agen terkelola harus memberi setiap agen sebuah workload identifier unik, dibawa dalam claim khusus dan digunakan sebagai kunci stabil untuk kebijakan, audit, dan pencabutan. Desain identitas agen Google, yang memberi setiap agen yang dideploy identitas berbasis SPIFFE yang terkait dengan resource agennya, disebut sebagai contoh yang sudah bekerja.

Kedua, rangkaian insiden terus berjalan. Kebocoran Hugging Face pada pertengahan Juli adalah intrusi publik pertama pada perusahaan yang disebutkan namanya yang dijalankan oleh agen otonom dari awal sampai akhir: eksekusi kode dalam pipeline dataset, pengambilan kredensial, lateral movement di cluster internal, dan ribuan tindakan selama satu akhir pekan. Sebelumnya pada tahun yang sama, Moltbook, jejaring sosial untuk agen AI, membocorkan 1,5 juta token API dari database yang salah konfigurasi hanya beberapa hari setelah mencapai 1,5 juta akun agen, menurut rangkuman Studio Global. Dan contoh berulang DBIR tentang serangan identitas non-manusia, yaitu kompromi token OAuth Salesloft Drift yang digunakan untuk mencapai lingkungan Salesforce di perusahaan besar termasuk Google, Cisco, dan Zscaler, memiliki bentuk yang persis sama dengan kredensial yang menjadi sandaran agen.

Pada Agustus 2026, sebuah issue IETF WIMSE mengusulkan agar tindakan agen dibedakan dengan identitas workload terpisah, bukan token scope, dengan identifier per agen sebagai kunci stabil untuk kebijakan, audit, dan pencabutan. Usulan itu muncul setelah kebocoran Hugging Face yang dijalankan agen pada Juli dan insiden Januari ketika platform agen Moltbook membocorkan 1,5 juta token API.

Mengapa service account dan API key tidak cocok untuk agen

Ketidakcocokan ini memiliki empat sisi, dan penting untuk menamainya secara terpisah karena perbaikannya berbeda.

Identitas bersama menghancurkan atribusi. Service account dirancang untuk dibagi, statis, dan memiliki hak luas. Jalankan sepuluh agen di bawah satu akun dan log audit Anda hanya menunjukkan satu aktor, seperti dijelaskan dalam tulisan lapangan Cockroach Labs: Anda tidak dapat mengetahui agen mana menyentuh data apa, rotasi berarti harus berkoordinasi dengan semua agen, dan izin akun akan bergeser menjadi gabungan dari semua hal yang pernah dibutuhkan agen mana pun. Contoh anonim mereka serupa dengan variasi yang saya dengar dari tim klien: sebuah support agent berjalan selama tiga bulan di bawah akun yang memiliki akses baca ke seluruh database pelanggan, diberi scope seperti itu saat development dan tidak pernah dipersempit sebelum go-live.

Agen bersifat sementara; key tidak. Sebuah workflow agentik dapat melakukan autentikasi ke model provider, vector store, tiga API, dan cloud storage dalam hitungan detik lalu menghilang. API key berumur panjang mengasumsikan pemanggil persisten yang layak dirotasi berdasarkan jadwal. Ketidakcocokan ini menimbulkan sprawl: key dibuat untuk agen yang sudah tidak diingat siapa pun, masih valid dan masih terlalu luas.

Delegasi memutus rantai "atas nama". Agen yang bertindak untuk pengguna dan agen yang bertindak secara otonom seharusnya terlihat sangat berbeda bagi policy engine Anda. Dengan service account bersama, keduanya terlihat identik. Delegasi OAuth menangani kasus pengguna dengan cukup baik; kasus otonom membutuhkan identitas agen sendiri, dan delegasi multi-agent mengharuskan setiap hop mempersempit, bukan memperluas, wewenang yang diteruskan.

Model tidak boleh pernah memegang secret. Ini masalah struktural, bukan konfigurasi. Kredensial yang dimasukkan ke context window terekspos kepada model dan apa pun yang dapat memanipulasinya: prompt injection dapat mengekstraknya melalui output agen sendiri. Solusinya adalah kredensial berumur pendek dan scoped yang diterbitkan saat tugas berjalan oleh token service dan dipegang oleh tool-execution layer, sehingga model memicu panggilan tanpa secret pernah masuk ke konteksnya. Cockroach Labs menjelaskan poin ini dengan baik, dan sesuai dengan yang saya katakan kepada klien yang membangun stack agen self-hosted: harness memegang key, model memegang intent.

Service account bersama merusak atribusi agen karena hanya satu aktor terlihat dalam log, bertahan lebih lama daripada workload agen yang sementara, mengaburkan batas antara tindakan yang didelegasikan pengguna dan tindakan otonom, serta mendorong tim untuk melewatkan kredensial melalui konteks model tempat prompt injection dapat menjangkaunya, menurut Cockroach Labs dan perbandingan miniOrange.

Apa yang sedang dibangun vendor dan badan standar

Bentuk yang sedang muncul memiliki tiga lapisan, dan hal yang menggembirakan adalah vendor dan pihak standar kurang lebih menuju ke struktur yang sama.

Identitas workload per agen. Arah WIMSE di atas adalah versi standar: setiap logical agent mendapatkan identifier yang unik dan stabil, bentuk yang disarankan adalah SPIFFE URI, terpisah dari execution role bersama, dan identifier itulah yang menjadi dasar kebijakan, audit, dan pencabutan. Agen yang dikelola platform dan berbagi execution credential harus melengkapinya dengan claim per agen. Ini adalah perubahan paling penting: identitas per agen, bukan per deployment.

Federasi menggantikan secret yang disimpan. Panduan Descope tentang workload identity federation untuk agen menunjukkan polanya: identitas platform agen, misalnya AWS IAM role atau Kubernetes service account melalui IRSA, ditukar dengan token berumur pendek dan scoped dari identity platform. Platform tersebut juga membuat directory record untuk agen agar audit trail bertahan lebih lama dari usia token. Tidak ada key berumur panjang yang dapat bocor, dan record identitas bertahan lebih lama daripada satu kredensial tertentu.

Discovery dan governance sebagai pasar. Di sisi komersial, vendor non-human identity seperti Reco, Token Security, Oasis, Aembit, dan lainnya sedang memosisikan ulang produk mereka di sekitar agen: temukan setiap kredensial agen, petakan ke pemilik, tandai over-privilege, dan cabut dengan bersih. Kerangka Reco bersifat praktis: cocokkan jenis identitas dengan peran agen, delegated OAuth untuk tindakan pengguna dan dedicated workload identity untuk tindakan otonom, lalu tinjau permission ketika tanggung jawab berkembang, karena agen mengumpulkan privilege seperti staf mengumpulkan kunci gedung. OWASP Top 10 for Agentic Applications yang diterbitkan pada Desember 2025 menamai Identity and Privilege Abuse sebagai kategori risiko tingkat pertama, sehingga tim keamanan memiliki kosakata bersama untuk temuan audit. Posisi lapisan ini dalam stack yang lebih luas adalah pertanyaan governance sekaligus tooling; sisi organisasinya saya bahas di AI agent governance.

Arsitektur yang muncul: identitas workload per agen, dengan identifier bergaya SPIFFE sebagai kunci untuk kebijakan, audit, dan pencabutan menurut diskusi WIMSE; federasi identitas platform menjadi token scoped berumur pendek dengan directory record agen yang persisten menurut Descope; dan pasar vendor untuk discovery serta governance least privilege atas identitas non-manusia.

Ketika identitas agen bermasalah

Tiga insiden, tiga mode kegagalan berbeda, semuanya memberi pelajaran.

Hugging Face, Juli 2026: masalah identitas penyerang juga menjadi masalah pihak bertahan. Intrusi yang dijalankan agen mengambil kredensial cloud dan cluster dari code-execution worker lalu bergerak lateral, yang merupakan cerita klasik workload dengan hak berlebihan: sebuah komponen pemrosesan data menyimpan kredensial yang layak dicuri. Detail yang lebih jarang dilaporkan adalah asimetri forensik yang diungkap Hugging Face: agen penyerang tidak terikat oleh usage policy apa pun, sementara pekerjaan forensik internal perusahaan awalnya terhalang oleh guardrail model hosted yang mereka coba. Karena itu mereka menjalankan analisis forensik menggunakan model open-weight GLM 5.2 di infrastruktur sendiri. Kegagalan identitas dan akses di kedua sisi insiden yang sama.

Salesloft Drift, pelajaran peringatan dari DBIR: token sebagai kunci utama. Token OAuth yang dikompromikan dari satu ekosistem vendor digunakan untuk berpindah ke lingkungan Salesforce milik perusahaan besar. Tanpa password, tanpa phishing manusia: kredensial non-manusia, dipercaya luas dan digunakan ulang secara diam-diam. Setiap agen yang Anda hubungkan ke alat SaaS dengan grant OAuth berumur panjang memiliki bentuk risiko seperti ini, dan mitigasinya pun berbentuk sama: berumur pendek, scope sempit, per agen, dapat dicabut.

Moltbook, Januari 2026: platform agen mengagregasi risiko identitas. Sebuah platform untuk akun agen membocorkan 1,5 juta token API beserta alamat email dan pesan antaragen dari database yang salah konfigurasi, menurut laporan Studio Global. Ketika Anda memusatkan identitas agen, Anda juga memusatkan blast radius-nya. Perlu dikatakan bahwa saya akan memperlakukan sebagian detail insiden yang beredar sebagai laporan, bukan hasil audit; pengungkapan Hugging Face sendiri adalah sumber primer, sedangkan angka Moltbook berasal dari liputan sekunder.

Kegagalan identitas agen yang terdokumentasi mencakup kebocoran Hugging Face Juli 2026, ketika agen otonom mengambil kredensial cloud dan cluster serta bergerak lateral menurut analisis Waxell; pivot token OAuth Salesloft Drift ke tenant Salesforce perusahaan menurut Token Security mengenai DBIR 2026; dan kebocoran 1,5 juta token API agen dari Moltbook.

Apa yang harus dilakukan sekarang

1. Minggu ini: inventarisasi kredensial agen Anda dan terapkan tes atribusi. Ambil satu tindakan agen dari log dan tanyakan apakah Anda dapat mengetahui agen mana yang melakukannya, atas nama siapa, dan apakah Anda dapat mencabut hanya agen tersebut tanpa memengaruhi yang lain. Jika jawabannya tidak, Anda memiliki masalah identitas bersama, dan itu adalah temuan pertama yang perlu diperbaiki.

2. Bulan ini: pindahkan satu agen otonom dari kredensial berumur panjang ke token berumur pendek yang scoped untuk tugas, diterbitkan oleh token service atau identity platform, disimpan dalam tool-execution layer dan tidak pernah masuk ke konteks model. Mulailah dari agen dengan akses paling luas; biasanya itulah yang pernah diberi scope "sementara" dengan tergesa-gesa.

3. Kuartal ini: beri setiap logical agent identitas stabilnya sendiri, SPIFFE ID jika infrastrukturnya tersedia atau service account unik per agen jika tidak, jadikan identitas itu kunci untuk audit dan alerting, dan tulis runbook pencabutan sebelum Anda membutuhkannya. Jika Anda masih lebih awal dalam perjalanan dan sedang memutuskan di mana agen harus dijalankan, trade-off agen lokal versus cloud menentukan seberapa banyak lapisan ini yang dapat Anda kendalikan sendiri.

FAQ

Apa itu identitas agen dalam istilah IAM?

Identitas yang berbeda dan dapat diverifikasi yang diberikan kepada satu agen AI, terpisah dari platform tempat agen berjalan dan pengguna yang diwakilinya. Identitas ini digunakan sebagai kunci stabil untuk autentikasi, kebijakan otorisasi, audit trail, dan pencabutan, seperti workload identity mengidentifikasi sebuah microservice, tetapi disesuaikan untuk pemanggil yang sementara, non-deterministik, dan dapat saling mendelegasikan tugas.

Mengapa agen tidak bisa sekadar berbagi satu service account?

Secara teknis bisa, dan kebanyakan memang melakukannya hari ini. Kegagalannya: log audit menunjukkan akun bersama, bukan agen yang bertindak, sehingga atribusi hilang; permission akun tumbuh menjadi gabungan kebutuhan semua agen; mencabut satu agen berarti merotasi kredensial untuk semuanya; dan Anda tidak dapat membedakan tindakan yang didelegasikan pengguna dari tindakan otonom. Pola ini bekerja sampai insiden pertama, lalu Anda tidak punya cara untuk merekonstruksi apa yang terjadi.

Apa yang dilakukan badan standar mengenai identitas agen?

Kelompok kerja IETF WIMSE sedang memperluas arsitektur workload identity untuk mencakup perantara AI, dengan proposal aktif yang mewajibkan identifier per agen, SPIFFE URI menjadi mekanisme yang disarankan, alih-alih mengandalkan token scopes. OWASP menerbitkan Top 10 for Agentic Applications pada Desember 2025 dengan identity and privilege abuse sebagai kategori tersendiri, dan Cloud Security Alliance memiliki framework governance identitas agen yang merekomendasikan identitas unik per agen.

Apakah kredensial agen boleh muncul di konteks model?

Tidak. Apa pun di context window terlihat oleh model dan dapat diekstraksi melalui prompt injection. Pola yang diterima adalah kredensial diterbitkan saat tugas berlangsung oleh token service, dipegang oleh tool-execution layer di antara model dan API, dibatasi pada tugas dan berumur pendek. Model meminta tindakan; harness memegang secret.

Intinya

Orang di bidang identitas punya ungkapan bahwa identity adalah control plane, dan agen akan menguji gagasan itu lebih keras daripada microservice mana pun. Arahnya cukup jelas untuk mulai dibangun hari ini: identitas per agen, secret di luar model, token yang kedaluwarsa lebih cepat daripada insiden menyebar, dan audit yang dapat menjawab "agen mana, atas nama siapa, untuk tujuan apa". Organisasi yang terkena dampak musim panas ini bukan menjalankan setup eksotis; mereka menjalankan kredensial bersama dan berharap semuanya baik-baik saja. Itulah celah yang harus ditutup, dan celah itu dapat ditutup dengan teknologi yang sebagian besar sudah ada.

Jika Anda sedang memetakan identitas agen ke lingkungan IAM yang sudah ada dan membutuhkan praktisi di dalam diskusi, itu adalah pekerjaan yang saya lakukan. Hubungi saya.

Sumber

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (diajukan 2026-08-04, diakses 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (diterbitkan 2026-07-17, diakses 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (diterbitkan 2026-05-20, diakses 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (diterbitkan 2026-06-22, diakses 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (diterbitkan 2026-05-20, diakses 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (diterbitkan 2026-07-20, diakses 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (diterbitkan 2026-07-17, diakses 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (diterbitkan 2026-08-17, diakses 2026-08-29)