MCP telah menerbitkan spesifikasi “Enterprise-Managed Authorization” yang stabil; draf identitas machine-to-machine lainnya—termasuk draf OAuth client-credentials dan dua proposal terbuka—masih belum selesai. Bagi siapa pun yang mencoba menjalankan agen otonom dengan Model Context Protocol, itu berarti protokol saat ini dapat memverifikasi pengguna manusia tetapi tidak menawarkan cara siap pakai untuk membuktikan bahwa proses yang tidak diawasi (unattended process) adalah benar-benar entitas yang diklaimnya.

Mengapa roadmap ini penting

Roadmap Model Context Protocol (MCP) mencantumkan identitas dan keamanan agen sebagai salah satu prioritas utamanya. Empat item dijadwalkan untuk dirilis: alur browser yang berpusat pada manusia (human-centric browser flow), alur OAuth client-credentials untuk layanan, pengikatan token berbasis DPoP (DPoP-based token binding), dan mekanisme federasi identitas beban kerja (workload-identity federation mechanism). Hanya yang pertama—Enterprise-Managed Authorization—yang telah mencapai status stabil.

Apa yang sebenarnya dilakukan oleh spesifikasi stabil tersebut

Enterprise-Managed Authorization memungkinkan admin IT untuk memberikan akses server dari satu konsol tunggal, alih-alih mengharuskan setiap karyawan menyetujui setiap koneksi. Alurnya menggunakan pengalihan browser (browser redirect) dan login pengguna, sehingga seseorang di laptop dapat melakukan autentikasi dan kemudian server mempercayai sesi pengguna tersebut.

Keterbatasannya sangat jelas: proses ini membutuhkan manusia di depan keyboard. Sebuah agen yang berjalan semalaman, memproses data, atau menanggapi peringatan tidak memiliki siapa pun untuk mengeklik tombol login. Akibatnya, setiap deployment yang bergantung pada agen yang tidak diawasi (unattended agents) tidak dapat menggunakan satu-satunya spesifikasi yang saat ini dijamin oleh MCP.

Opsi draf dan kekurangannya

Dua ekstensi draf bertujuan untuk memberikan identitas sendiri kepada agen:

  • SEP-1932 (DPoP) – mengikat token ke pasangan kunci publik-privat, sehingga token yang dicuri menjadi tidak berguna.
  • SEP-1933 (Workload Identity Federation) – memungkinkan agen mewarisi identitas yang sudah disediakan di platform cloud.

Keduanya masih berupa pull request terbuka; belum ada yang digabungkan ke dalam spesifikasi resmi. Sementara itu, satu-satunya opsi terdokumentasi lainnya adalah alur OAuth client-credentials yang memerlukan rahasia (secrets) yang telah didaftarkan sebelumnya. Menyimpan rahasia tersebut di tempat yang dapat dibaca oleh agen menciptakan celah serangan (attack surface) klasik: jika rahasia tersebut bocor, penyerang mana pun dapat menyamar sebagai agen tersebut.

Langkah praktis untuk produksi saat ini

Karena protokol ini belum menyediakan identitas agen asli (native), tim masih dapat mengamankan agen dengan memindahkan manajemen identitas ke luar MCP:

  1. Terbitkan identitas yang dapat diverifikasi pada lapisan beban kerja (workload layer). Sistem seperti SPIRE menghasilkan sertifikat berumur pendek yang terikat pada akar kepercayaan (trust root) host, sehingga menghilangkan rahasia statis.
  2. Akhiri kredensial di gateway. Layanan front-end memegang kunci API atau token dan meneruskan permintaan atas nama agen, sehingga menjaga rahasia tetap berada di luar lingkungan runtime.
  3. Otorisasi berdasarkan identitas yang terverifikasi, bukan konten token. Pisahkan autentikasi (siapa yang memanggil) dari otorisasi (apa yang boleh mereka lakukan) agar kebijakan dapat ditegakkan bahkan jika metode autentikasi berubah.

Apa yang perlu diperhatikan selanjutnya

Dua pull request terbuka – pengikatan DPoP dan federasi identitas beban kerja – adalah satu-satunya jalan menuju standar identitas machine-to-machine yang sesungguhnya di dalam MCP. Jika komunitas menggabungkannya, agen akan dapat membuktikan kepemilikan kunci privat atau mewarisi identitas yang diterbitkan cloud tanpa mengekspos rahasia. Sampai saat itu, setiap deployment produksi harus mengandalkan kerangka kerja identitas eksternal atau menerima risiko kredensial statis.

Kesimpulannya jelas: MCP saat ini dapat mengautentikasi orang di balik sebuah permintaan, tetapi belum mengautentikasi perangkat lunak yang membuat permintaan tersebut. Tim yang membutuhkan agen otonom yang aman sebaiknya tidak menunggu spesifikasi tersebut dirilis; mereka harus membangun identitas pada lapisan beban kerja hari ini dan terus memantau proposal DPoP dan federasi yang sedang tertunda.