Mengenali Agen Anda: Cara Mengikat Manusia ke Agen AI (ID)

Poin-poin Penting

• Kenali Agen Anda (KYA) tidak diselesaikan hanya dengan menamai agen. Kontrol yang tahan lama adalah rantai delegasi yang menghubungkan orang yang terautentikasi, klien terdaftar, cakupan yang diberikan, konteks organisasi, dan setiap tindakan yang dihasilkan.
• Endpoint Model Context Protocol (MCP) yang dihosting Didit mengekspos 115 alat di 19 domain dan menggunakan Open Authorization (OAuth) 2.1 dengan Proof Key for Code Exchange (PKCE) dan Dynamic Client Registration.
• MCP bertindak sebagai pengguna Didit yang masuk. Ini mewarisi peran organisasi pengguna tersebut, sehingga agen yang terhubung tidak dapat memperoleh izin yang tidak dimiliki orang tersebut sebelumnya.
• Kunci aplikasi yang disimpan dalam file konfigurasi membuktikan kepemilikan kredensial, bukan manusia mana yang mendelegasikan tindakan tertentu. Kunci bersama menggabungkan beberapa operator dan agen menjadi satu identitas aplikasi.
• Akuntabilitas membutuhkan penegakan dan bukti: token terlingkup dan pemeriksaan peran sebelum suatu tindakan, kemudian catatan audit yang menunjukkan siapa yang mengubah apa.

Didit telah mengirimkan mekanismenya. Server MCP yang dihostingnya menghubungkan klien AI ke operasi identitas dan penipuan melalui pengguna yang masuk, alih-alih memperlakukan agen sebagai pemegang rahasia aplikasi anonim. Endpoint ini gratis, menggunakan HTTP Streamable tanpa status, dan mengekspos 115 alat. Implementasinya juga tersedia di repositori GitHub berlisensi MIT publik.

Artefak itu mengubah pertanyaan yang bermanfaat. Alih-alih meminta definisi KYA lain, tanyakan: ketika agen membuat sesi verifikasi, membaca keputusan, atau mengubah data ruang kerja, apa yang membuktikan orang mana yang mengotorisasinya, apa yang diizinkan orang tersebut, dan organisasi mana yang menerima tindakan tersebut?

Pengikatan manusia adalah rantai delegasi

Nama agen, pengidentifikasi model, kunci publik, atau pengesahan perangkat lunak dapat membantu mengidentifikasi aktor mesin. Tidak satu pun dari mereka, sendirian, menetapkan siapa yang bertanggung jawab atas apa yang dilakukan agen. Pengikatan manusia membutuhkan rantai dengan tautan yang berbeda:

• Prinsipal: pengguna terautentikasi atau pemilik layanan atas nama siapa agen bertindak.
• Klien: aplikasi AI yang meminta akses.
• Delegasi: cakupan dan persetujuan yang diberikan kepada klien tersebut.
• Konteks otorisasi: peran organisasi dan batas aplikasi yang diterapkan pada permintaan.
• Bukti: catatan yang dapat ditinjau tentang tindakan dan hasilnya.

Setiap tautan menjawab pertanyaan yang berbeda. Autentikasi mengatakan siapa yang masuk. OAuth mengatakan klien mana yang menerima akses yang didelegasikan. Cakupan mengatakan kelas operasi mana yang disetujui. Peran mengatakan apa yang boleh dilakukan pengguna di dalam organisasi. Catatan audit mengatakan apa yang sebenarnya terjadi. Menggabungkan kontrol ini menjadi satu lencana "agen terverifikasi" menyembunyikan bagian terpenting: otoritas bersifat kontekstual dan dapat dicabut.

Agen yang dapat dipercaya tidak hanya dapat diidentifikasi. Agen harus dapat menunjukkan jalur yang tidak terputus dari prinsipal yang bertanggung jawab ke tindakan tertentu yang diizinkan.

Mengapa kunci dalam file konfigurasi gagal dalam uji akuntabilitas

Kunci API aplikasi mungkin sesuai untuk integrasi server-ke-server yang terkontrol. Kunci itu sendiri bukan mekanisme pengikatan manusia-ke-agen. Kunci yang disalin biasanya menjawab satu pertanyaan: "Apakah pemanggil ini memiliki kredensial yang diterima untuk aplikasi ini?" Kunci itu tidak menjawab siapa yang meluncurkan agen, siapa yang menyetujui tugas saat ini, atau apakah dua panggilan menggunakan kunci yang sama berasal dari orang yang berbeda.

Mode kegagalan dapat diprediksi. Tim berbagi kunci di seluruh lingkungan lokal. Proses agen mewarisinya dari file konfigurasi. Agen kedua menerima salinan. Log kemudian mengaitkan setiap panggilan dengan kredensial aplikasi yang sama. Mencabut kredensial itu mengganggu setiap beban kerja yang menggunakannya, sementara peristiwa delegasi individu tetap tidak jelas.

Didit sengaja tidak menawarkan jalur kunci aplikasi untuk endpoint MCP yang dihostingnya. Integrasi backend masih dapat menggunakan API REST Didit dengan kredensial aplikasi, tetapi akses MCP jarak jauh memerlukan alur OAuth pengguna. Pemisahan itu penting: kredensial REST mewakili integrasi aplikasi; token MCP mewakili akses yang didelegasikan dari pengguna yang masuk.

OAuth 2.1, PKCE, dan Pendaftaran Klien Dinamis

OAuth adalah primitif delegasi dalam desain ini. Alur ini tidak menyerahkan kata sandi pengguna ke agen, dan tidak menempatkan rahasia platform yang dapat digunakan kembali dalam konfigurasi MCP. Sebaliknya, klien AI memperoleh token akses terbatas setelah pengguna mengautentikasi dengan Didit dan menyetujui akses.

1. Daftarkan klien

Pendaftaran Klien Dinamis memungkinkan klien MCP yang kompatibel untuk mendaftar dengan server otorisasi Didit tanpa pengidentifikasi klien yang telah disediakan secara manual. Ini memberi server otorisasi pendaftaran klien yang berbeda untuk menerbitkan akses. Pendaftaran mengidentifikasi klien OAuth; itu sendiri tidak mengesahkan bahwa perangkat lunak klien dapat dipercaya.

2. Ikat respons otorisasi ke klien

PKCE membuat verifier dan tantangan satu kali untuk upaya otorisasi. Klien yang memulai alur harus menyajikan verifier saat menukar kode otorisasi. Ini membatasi nilai kode yang dicegat karena proses lain tidak dapat menebusnya tanpa verifier.

3. Autentikasi dan persetujuan

Pengguna masuk di Didit Business Console, yang bertindak sebagai server otorisasi, dan menyetujui cakupan yang diminta. Didit mengiklankan didit:verification untuk operasi verifikasi dan didit:management untuk manajemen ruang kerja. Klien hanya boleh meminta cakupan yang diperlukan untuk tugas tersebut.

4. Validasi setiap panggilan

Server sumber daya MCP yang dihosting memvalidasi token pembawa sebelum mengirim panggilan alat. Token pengguna yang divalidasi dan konteks organisasi berjalan dengan permintaan ke Didit. Layanan hilir kemudian mengevaluasi peran dan izin yang ada untuk pengguna tersebut. Hasilnya adalah semantik bertindak-sebagai-pengguna, bukan identitas superuser baru yang dibuat untuk agen.

Panduan autentikasi MCP mendokumentasikan alur, sementara gambaran umum MCP menjelaskan endpoint yang dihosting dan model klien.

Bertindak sebagai pengguna membuat otoritas mudah dipahami

Misalkan operator kepatuhan menghubungkan klien AI ke Didit. Klien pertama-tama memanggil didit_context_get, yang mengembalikan organisasi dan aplikasi yang dapat diakses oleh pengguna yang masuk. Jika pengguna memiliki satu organisasi dan aplikasi yang tidak ambigu, konteks dapat diselesaikan secara otomatis. Jika ada beberapa yang tersedia, operasi dapat dipersempit ke organisasi dan aplikasi eksplisit.

Agen kemudian dapat memanggil didit_session_create untuk membuat sesi verifikasi dan didit_session_get_decision untuk mengambil hasilnya. Itu adalah nama alat domain-pertama yang nyata dalam katalog MCP saat ini. Pengguna yang tidak memiliki izin yang diperlukan tidak mendapatkannya dengan menghubungkan agen; batas otorisasi organisasi yang sama masih berlaku.

Ini adalah perbedaan utama dari kredensial aplikasi bersama. Dalam model OAuth, permintaan tiba sebagai pengguna yang dikenal yang beroperasi melalui klien terdaftar dengan cakupan yang dideklarasikan. Dalam model kunci bersama, sistem hilir melihat kredensial aplikasi, sementara manusia dan agen di balik panggilan tertentu tetap tidak dapat dibedakan kecuali bidang kontrol terpisah menyediakan konteks tersebut.

Auditabilitas: dari “siapa yang bisa bertindak?” menjadi “siapa yang melakukan apa?”

Otorisasi mencegah tindakan di luar cakupan. Auditabilitas menjelaskan suatu tindakan setelah terjadi. Didit mengekspos didit_audit_log_list sehingga pengguna yang berwenang dapat memeriksa entri audit aplikasi yang menjelaskan siapa yang mengubah apa. Karena setiap permintaan MCP yang dihosting membawa token pembawa pengguna yang masuk dan konteks organisasi yang diselesaikan, tindakan tersebut dapat diatribusikan ke pemanggil tersebut daripada ke proses agen anonim.

Catatan forensik lengkap juga harus menyimpan bukti sisi agen. Untuk alur kerja berdampak tinggi, catat pengidentifikasi eksekusi agen, pendaftaran klien, cakupan yang diminta, organisasi dan aplikasi target, nama alat, stempel waktu, status persetujuan, dan representasi input dan output yang aman. Jangan mencatat token akses atau payload identitas sensitif. Jejak audit platform dan log eksekusi agen harus dapat dikorelasikan tanpa menduplikasi rahasia atau data pribadi yang diatur.

Atribusi tidak sama dengan non-penolakan, dan log audit bukanlah pengganti hak istimewa paling sedikit. Kontrol saling memperkuat:

• Gunakan akses berjangka pendek dan refresh terkontrol daripada kredensial bersama permanen.
• Berikan cakupan OAuth tersempit dan peran organisasi dengan hak istimewa paling sedikit.
• Membutuhkan konfirmasi manusia untuk operasi yang merusak atau berdampak sangat tinggi.
• Jaga agar konteks organisasi dan aplikasi eksplisit ketika lebih dari satu target tersedia.
• Cabut sesi pengguna atau pemberian klien ketika delegasi harus berakhir.
• Pantau catatan audit untuk aktor, alat, target, atau waktu yang tidak terduga.

Apa yang dibuktikan oleh pengikatan—dan apa yang tidak

Pola ini membuktikan bahwa akun Didit yang terautentikasi mendelegasikan akses terlingkup ke klien OAuth dan bahwa setiap permintaan dievaluasi dengan izin organisasi pengguna tersebut. Ini menciptakan akuntabilitas praktis ke akun dan rantai yang dapat ditinjau untuk tindakan platform.

Ini tidak secara otomatis membuktikan bahwa pemegang akun memiliki identitas sipil yang terverifikasi, bahwa biner klien yang disetujui belum dimodifikasi, atau bahwa manusia secara aktif mengawasi setiap langkah. Itu membutuhkan jaminan tambahan. Jika jaminan identitas hukum diperlukan, verifikasi prinsipal selama orientasi dengan kontrol Kenali Pelanggan Anda (KYC) dan ikat hasilnya ke akun. Jika asal perangkat lunak penting, tambahkan pengesahan klien dan rilis yang ditandatangani. Jika kehadiran penting, perlukan persetujuan langkah-demi-langkah pada saat tindakan sensitif.

Tampilan berlapis ini menjaga KYA tetap jujur. Identitas agen, identitas manusia, otorisasi yang didelegasikan, kebijakan runtime, dan bukti audit adalah kontrol terkait, bukan label yang dapat dipertukarkan.

Implementasi yang berfungsi yang dapat Anda periksa

Implementasi Didit memberikan referensi konkret untuk tim yang merancang batas akuntabilitas yang sama. Server yang dihosting mengautentikasi sebagai pengguna Didit yang masuk, mewarisi peran organisasi pengguna tersebut, dan menerapkan identitas tersebut ke setiap panggilan alat. 115 alat yang dihostingnya mencakup 19 domain, mulai dari konteks dan sesi verifikasi hingga alur kerja, organisasi, analitik, dan log audit. Katalog alat saat ini mencantumkan permukaan yang tepat.

Untuk konteks produk, paket KYC lengkap berharga $0,33 dan menggabungkan Verifikasi ID, Liveness Pasif, Pencocokan Wajah, dan Analisis IP. Didit menyertakan 500 verifikasi gratis per bulan dan digunakan oleh 2.000+ perusahaan dalam produksi. Server MCP itu sendiri gratis, sehingga tim dapat mengevaluasi model delegasi dan izin tanpa menambahkan biaya konektor terpisah.

Untuk melihat bagaimana mekanisme ini sesuai dengan alur kerja agen yang lebih luas, baca cara kerja MCP identitas dan penipuan untuk agen AI dan referensi alat MCP Didit.

Ikat agen sebelum Anda memercayai tindakan tersebut

Masalah sulit dalam identitas agen bukanlah menciptakan nama yang tahan lama untuk perangkat lunak. Ini adalah menjaga akuntabilitas manusia karena perangkat lunak melintasi antarmuka dan bertindak dengan kecepatan mesin. OAuth 2.1 menyediakan akses yang didelegasikan. PKCE melindungi pertukaran otorisasi. Pendaftaran Klien Dinamis mengidentifikasi klien yang terhubung. Cakupan dan peran organisasi membatasi otoritas. Catatan audit membuat hasilnya dapat ditinjau.

Anda dapat memeriksa arsitektur di repositori MCP Didit, meninjau dokumentasi autentikasi, atau menghubungkan Didit ke Claude. Uji yang berguna sederhana: untuk setiap tindakan agen yang diusulkan, dapatkah Anda mengidentifikasi pengguna yang bertanggung jawab, klien, cakupan yang diberikan, batas organisasi, dan bukti audit yang dihasilkan? Jika ada tautan yang hilang, agen tidak sepenuhnya terikat.