MCP Bukan Konektor — Ini Adalah Permukaan Tata Kelola Anda untuk Era Agen

Masalah pembingkaian: "konektor" meremehkan keputusan yang sebenarnya Anda buat

Ketika Anthropic memperkenalkan Protokol Konteks Model (MCP) pada November 2024 sebagai standar terbuka untuk menghubungkan sistem AI ke sumber data dan alat bisnis, industri melakukan apa yang biasanya mereka lakukan dengan spesifikasi integrasi baru: mereka memasukkan MCP ke dalam kategori "pipa ledeng". Adaptor, transportasi, cara rapi untuk berhenti menulis kode perekat sekali pakai untuk setiap model dan setiap alat. Semua true, dan semua itu tidak relevan jika Anda duduk di kursi CIO, CTO, atau CISO.

Berikut adalah kerangka kerja ulang yang penting bagi sebuah perusahaan. Saat agen dapat memanggil alat yang membaca data pelanggan Anda atau menulis ke sistem pencatatan Anda, Anda telah menciptakan titik kendali baru — terlepas dari apakah Anda menamainya atau tidak. MCP adalah tempat di mana titik kendali tersebut dapat dijelaskan secara eksplisit. Ini bukan hanya tentang bagaimana agen mencapai alat Anda; ini adalah tempat Anda memutuskan siapa yang menelepon, atas identitas siapa, alat mana yang terlihat, bagaimana setiap panggilan dicatat, dan berapa biaya yang diizinkan untuk setiap panggilan. Itu adalah pertanyaan tata kelola, bukan pertanyaan konektivitas.

Perlakukan MCP sebagai fitur konektivitas dan Anda akan mengoptimalkan hal yang salah — cakupan, jumlah integrasi, waktu hingga panggilan pertama. Perlakukan sebagai permukaan tata kelola dan Anda akan mengoptimalkan apa yang sebenarnya menentukan apakah agen aman untuk diterapkan dalam skala besar: antarmuka tunggal, terstandarisasi, dan dapat diaudit di mana kebijakan diberlakukan sekali dan dipatuhi di mana-mana.

Mengapa "banyak integrasi kustom" diam-diam menciptakan kembali tata kelola N kali

Sebagian besar perusahaan tidak memasuki era agen dengan lembaran kosong. Mereka datang dengan portofolio integrasi poin: konektor khusus di sini, akun layanan di sana, pembungkus API yang dibangun tim dua kuartal lalu yang tidak diingat sepenuhnya oleh siapa pun. Masing-masing merupakan keputusan lokal yang wajar. Secara kolektif, ini merupakan masalah tata kelola, karena masing-masing mengimplementasikan kembali identitas, otorisasi, pencatatan, dan kontrol tarif/biaya dalam idiomnya sendiri — atau melewatkan beberapa di antaranya sepenuhnya.

Tiga mode kegagalan terjadi secara dapat diprediksi. Pertama, identitas bergeser: satu integrasi berjalan sebagai akun layanan bersama, yang lain meniru pengguna akhir, yang ketiga menggunakan kunci yang sudah lama digunakan oleh seseorang yang kemudian berganti tim — jadi "siapa yang melakukan ini?" memiliki N jawaban berbeda, tidak ada yang lengkap. Kedua, otorisasi terfragmentasi, karena aturan tentang apa yang dapat dilakukan suatu alat berada di N basis kode dengan N siklus peninjauan; kontrol yang Anda perketat di satu tempat diam-diam tetap longgar di tempat lain. Ketiga — yang pertama kali dirasakan oleh bagian keuangan dan audit — angka-angka bergeser, karena pertanyaan yang sama yang dijawab melalui dua jalur integrasi menghasilkan dua jawaban. Setelah pemangku kepentingan berhenti mempercayai angka-angka tersebut, program agen menjadi tidak relevan.

Alternatif standar bukanlah sihir atau gratis, tetapi mengubah bentuk pekerjaan. Alih-alih mengatur N integrasi N kali, Anda mengatur satu antarmuka sekali dan mengekspos alat melalui antarmuka tersebut secara sengaja. Identitas ditetapkan di satu tempat. Otorisasi adalah properti antarmuka, bukan kebiasaan setiap konektor. Pencatatan bersifat seragam, sehingga jejak audit benar-benar merupakan jejak. Dan angka-angka berhenti bergeser karena ada satu jalur untuk menghitungnya.

Konteks identitas dan penyewa: putuskan di pintu masuk, bukan di alat

Pertanyaan pertama yang harus dijawab oleh antarmuka tata kelola adalah otoritas siapa yang dimiliki oleh suatu panggilan. Dalam konteks SaaS multi-tenant, hal ini rumit, karena ada dua fakta berbeda yang berperan: identitas pemanggil (agen mana, yang bertindak untuk pengguna atau layanan mana) dan konteks tenant tempat panggilan tersebut beroperasi (data dan hak pelanggan mana yang berlaku). Gabungkan keduanya dan Anda akan mendapatkan bug wakil yang bingung klasik, di mana agen yang diautentikasi secara sah untuk satu tujuan diarahkan untuk bertindak dengan hak istimewa yang seharusnya tidak pernah diwarisinya.

Disiplin yang layak diadopsi adalah mendapatkan konteks penyewa dari pengikatan penyewa sisi server, bukan dari apa pun yang diklaim oleh sesi pemanggil. Dalam implementasi kami sendiri, lapisan pelanggan yang membatasi akses fitur diselesaikan dari konteks penyewa, tidak pernah dibaca kembali dari sesi pemanggil — tepatnya agar pemanggil tidak dapat memperluas jangkauan dampaknya sendiri dengan menampilkan sesi yang tampak lebih kaya. Identitas memberi tahu Anda siapa yang bertanya; konteks penyewa memberi tahu Anda di dalam semesta data dan hak apa jawaban tersebut harus dihitung. Keduanya diputuskan di pintu masuk, sebelum alat apa pun dijalankan.

Di sinilah Anda juga memutuskan bahwa agen bukanlah pengguna. Manusia di konsol memiliki mata, keraguan, dan seorang manajer. Agen memiliki siklus. Identitas dan konteks yang Anda berikan kepadanya harus mencerminkan bahwa ia dapat bertindak lebih cepat dan lebih harfiah daripada siapa pun yang telah Anda sediakan.

Otorisasi per alat: paparan adalah keputusan, bukan default

Default yang paling umum dan paling berbahaya dalam penerapan agen awal adalah paparan semua atau tidak sama sekali: hubungkan agen ke platform dan biarkan agen tersebut mengakses semua yang dapat diakses oleh kredensial yang mendasarinya. Nyaman dalam demo, tidak dapat dipertahankan dalam produksi. Antarmuka tata kelola memperlakukan visibilitas dan izin setiap alat sebagai keputusan yang disengaja dan dapat ditinjau.

Secara konkret, otorisasi harus multi-aksial daripada sakelar on/off tunggal. Kami menggunakan model tiga sumbu — cakupan dan tingkatan, dengan tingkatan bersumber dari konteks penyewa seperti yang dijelaskan di atas — sehingga alat tertentu hanya diekspos ketika cakupan pemanggil mengizinkannya dan tingkatan penyewa mencakupnya. Inti dari sumbu kedua adalah bahwa kemampuan bukan hanya fungsi dari siapa yang meminta tetapi juga hak pelanggan mana yang berlaku. Ini menjaga permukaan paparan tetap jujur: menambahkan alat baru ke katalog tidak serta merta membuatnya dapat diakses oleh setiap agen di setiap penyewa.

Model mental yang harus diberikan kepada arsitek Anda adalah katalog, bukan papan sakelar. Setiap alat dalam katalog mendapatkan tempatnya melalui keputusan tentang siapa yang boleh memanggilnya dan dalam kondisi penyewa apa. Alat yang saat ini tidak dibutuhkan oleh agen mana pun, sama sekali tidak ada dalam katalog. "Semua atau tidak sama sekali" adalah ekonomi false; "per-alat yang disengaja" adalah satu-satunya sikap yang bertahan setelah berhadapan dengan audit nyata.

Tulisan yang gagal ditutup: asimetri antara membaca dan bertindak

Pembacaan dan penulisan tidak setara secara moral, dan antarmuka tata kelola Anda tidak boleh berpura-pura demikian. Pembacaan yang salah akan mengembalikan data yang usang atau kosong — dapat dipulihkan, seringkali tidak terlihat. Kesalahan penulisan akan mengubah sistem pencatatan, mengirim pesan ke pelanggan sebenarnya, atau memindahkan uang. Biaya kesalahan bersifat asimetris, jadi sikap default juga harus asimetris.

Aturan yang kami pegang adalah bahwa alat tulis gagal tertutup. Jika otorisasi ambigu, jika konteks penyewa tidak dapat diselesaikan dengan bersih, jika penjaga tidak dapat dievaluasi, penulisan tidak terjadi. Ini adalah kebalikan dari default yang didorong oleh kenyamanan yang diwarisi banyak integrasi, di mana pemeriksaan yang tidak dievaluasi diselesaikan menjadi "izinkan" sehingga alur tetap lancar. Gagal terbuka adalah cara Anda menemukan, berminggu-minggu kemudian, bahwa seorang agen menulis dalam kondisi yang tidak pernah disetujui siapa pun. Untuk apa pun yang mengubah status atau menyentuh pelanggan, default yang aman adalah penolakan, dan beban pembuktian ada pada panggilan untuk menunjukkan bahwa itu diizinkan.

Ada dimensi budaya di sini. Insinyur mengoptimalkan agar semuanya berfungsi; keamanan mengoptimalkan agar semuanya tidak rusak dengan cara terburuk. Permukaan tata kelola adalah tempat Anda mengkodekan bahwa cara terburuk — penulisan yang tidak sah yang dieksekusi secara diam-diam — tidak dapat diterima, bahkan dengan mengorbankan penolakan penulisan yang seharusnya baik-baik saja.

Buku besar anggaran dan sakelar pemutus: mengatur biaya sebagai kontrol kelas satu

Agen memperkenalkan kategori risiko yang sebagian besar tidak ada dalam integrasi tradisional: pengeluaran otonom. Sebuah siklus yang memanggil alat dapat, melalui bug atau perintah yang merugikan, memanggilnya jauh lebih sering daripada yang dimaksudkan siapa pun — membakar anggaran API, memicu biaya hilir, atau membanjiri pelanggan. Oleh karena itu, pengendalian biaya termasuk dalam permukaan tata kelola, bukan ditambahkan kemudian sebagai peringatan penagihan yang aktif setelah kerusakan terjadi.

Mekanisme yang kami jalankan adalah buku besar anggaran yang dievaluasi sebelum pengeluaran apa pun, dengan batasan per-eksekusi, per-hari, dan bergulir 30 hari, ditambah sakelar pemutus yang diperiksa sebelum eksekusi. Perhatikan urutannya: anggaran dan sakelar pemutus dievaluasi sebelum pengeluaran, bukan direkonsiliasi setelahnya. Peringatan yang memberi tahu Anda bahwa Anda telah melakukan pengeluaran berlebih adalah postmortem; buku besar yang menolak panggilan kelebihan anggaran adalah kontrol. Tiga horizon waktu penting karena mode kegagalan memiliki bentuk yang berbeda — loop yang tak terkendali melampaui batas per-run, jadwal yang salah konfigurasi melampaui batas per-hari, dan perayapan lambat hanya muncul pada jendela 30 hari.

Tombol pemutus layak mendapat baris tersendiri dalam desain. Ini adalah kontrol yang Anda gunakan ketika Anda belum memahami apa yang terjadi dan Anda perlu menghentikan aktivitas tersebut sekarang. Dievaluasi sebelum dieksekusi, ini adalah pemutus sirkuit, bukan alat pembersihan. Setiap program agen harus dapat menjawab satu pertanyaan secara instan: bagaimana cara kita menghentikannya? Jika jawabannya melibatkan menghubungi tiga tim dan mencabut kunci secara manual, Anda tidak memiliki tombol pemutus — Anda memiliki harapan.

Audit dan penyuntingan: terlingkup, dibatasi waktu, dan dapat diamati

Tata kelola yang tidak dapat diamati bukanlah tata kelola; itu adalah niat. Lapisan permukaan terakhir adalah lapisan yang membuat segala sesuatu di atasnya dapat dibuktikan setelah kejadian. Kunci agen harus dibatasi pada alat yang benar-benar mereka butuhkan dan dibatasi waktu sehingga radius ledakan kredensial menyusut menjadi nol sesuai jadwal daripada bertahan tanpa batas waktu. Kunci yang dapat melakukan apa saja selamanya adalah artefak paling umum yang ditemukan di reruntuhan tinjauan insiden.

Demikian pula, jejak audit itu sendiri harus menghormati data yang dicatatnya. Kami menerapkan penyuntingan per panggilan sehingga log menangkap apa yang terjadi — alat mana, di bawah identitas dan konteks penyewa mana, dengan hasil apa — tanpa menjadi salinan sekunder dari data yang sangat sensitif yang dilindungi oleh kontrol tersebut. Log audit yang diam-diam mengumpulkan catatan pelanggan teks biasa bukanlah kontrol; itu adalah tanggung jawab baru dengan nama yang ramah.

Bersama-sama, properti-properti ini — kunci yang terlingkup, batasan waktu, penyuntingan per panggilan, audit seragam — memungkinkan CISO menjawab pertanyaan-pertanyaan yang sebenarnya diajukan setelah suatu insiden: apa yang dapat dilakukan kredensial ini, berapa lama ia dapat melakukannya, apa yang sebenarnya dilakukannya, dan dapatkah kita membuktikannya tanpa membocorkan lebih banyak informasi dalam pembuktiannya.

Mengaitkannya dengan risiko berkelanjutan — dan jujur ​​tentang apa yang tersisa

Semua ini bukan pengaturan sekali saja. Kerangka Kerja Manajemen Risiko AI NIST (AI RMF 1.0) secara eksplisit menyatakan bahwa mengelola risiko AI adalah proses berkelanjutan, bukan daftar periksa yang Anda selesaikan dan simpan. Antarmuka tata kelola sangat berharga justru karena memberikan proses berkelanjutan tersebut satu tempat untuk bertindak: ketika risiko baru muncul, Anda menyesuaikan otorisasi, anggaran, paparan, atau audit dalam satu antarmuka daripada mengejar perubahan di berbagai integrasi. Standardisasi inilah yang membuat tata kelola berkelanjutan menjadi lebih mudah dikelola daripada sekadar aspirasi. Ini juga alasan mengapa keputusan paparan yang bijaksana memberikan keuntungan ganda — sekali saat Anda membuatnya, dan sekali lagi setiap kali Anda harus meninjaunya kembali.

Jujurlah tentang risiko residual, karena dewan direksi Anda akan jujur. Permukaan tata kelola mempersempit permukaan serangan dan membuat aktivitas dapat diaudit; itu tidak membuat agen tidak dapat salah. Injeksi cepat masih dapat mencoba mengarahkan agen yang berwenang secara sah menuju penyalahgunaan yang tampak sah. Alat yang sengaja diekspos masih dapat disalahgunakan dalam batas izinnya. Anggaran membatasi biaya tetapi bukan penilaian. Penelitian Deloitte "State of AI in the Enterprise" telah berulang kali menunjukkan kesenjangan antara ambisi AI dan kematangan operasional untuk mengaturnya — dan kesenjangan itulah tepatnya tempat risiko residual ini berada. Tanggapan yang tepat bukanlah mengklaim kesenjangan telah tertutup tetapi membuatnya kecil, dapat diamati, dan dikelola secara terus-menerus.

Kami membangun platform kami berdasarkan keyakinan ini. SocialHub.AI mengekspos alat lapisan semantik melalui MCP menggunakan transportasi yang dapat di-streaming HTTP, yang dapat diakses dari agen seperti Claude, GitHub Copilot, dan Microsoft 365 Copilot, dengan kontrol yang dijelaskan di sini diterapkan pada antarmuka daripada tersebar di seluruh konektor: otorisasi tiga sumbu dengan tingkatan dari konteks penyewa, penulisan yang ditutup jika gagal, buku besar anggaran per-jalankan/per-hari/30-hari dengan sakelar pemutus pra-eksekusi, dan kunci agen yang terlingkup dan dibatasi waktu dengan penyuntingan dan audit per-panggilan. Ini adalah disiplin tata kelola yang sama yang mendasari pekerjaan loyalitas di mana kami membantu meningkatkan kontribusi GMV anggota McDonald's China dari sekitar 5% menjadi 85% — hasil pada skala tersebut hanya bertahan jika antarmuka ke data dapat dipercaya sejak awal.

Jika Anda memutuskan bagaimana agen akan mengakses sistem pencatatan Anda, pertanyaan yang perlu diajukan kepada tim Anda bukanlah "konektor mana" — melainkan "di mana identitas, otorisasi, pencatatan, dan biaya diputuskan, dan apakah itu di satu tempat atau N tempat." Jika Anda ingin melihat seperti apa tampilan antarmuka MCP yang mengutamakan tata kelola dalam praktiknya, pesan demo, atau baca lebih lanjut tentang pendekatan kami di /platform/ai-frontier.