Prompt dan konteks yang berlaku
Anda memiliki platform agen enterprise. Agen tersebut dapat memanggil sistem tiket, kontrol sumber, dan keuangan melalui MCP. Beberapa tool bersifat read-only; yang lain men-deploy kode, memproses pengembalian dana (refund), atau menghapus data. Server dapat berubah seiring waktu, dan deskripsi tool atau hasil dapat berasal dari server yang tidak sepenuhnya tepercaya. Rancang discovery, otorisasi, pemanggilan (invocation), penanganan hasil, audit, dan pemulihan. Jelaskan operasi mana yang memerlukan persetujuan manusia.
Pertanyaan intinya adalah apakah setiap pemanggilan memiliki jawaban yang jelas untuk empat pertanyaan: siapa bertindak untuk siapa dan dalam cakupan apa, versi tool mana yang digunakan, apakah input dan hasil divalidasi, dan apakah kegagalan dapat dilacak serta dibatalkan. Panduan SDE II Amazon secara eksplisit mengevaluasi keandalan, skalabilitas, keamanan, dan trade-off dalam desain sistem, menjadikan ini latihan desain end-to-end yang tepat.
Apa yang dinilai oleh pewawancara
Jawaban yang kuat memisahkan kemampuan model untuk mengusulkan pemanggilan dari otoritas platform untuk mengeksekusinya. Model dapat menyarankan tool dan argumen; mesin kebijakan (policy engine) harus mengotorisasi ulang menggunakan pengguna, tenant, sumber daya, tingkat risiko, dan status persetujuan.
Anda juga harus mengenali batasan MCP. Anotasi tool yang disediakan oleh server harus diperlakukan sebagai tidak tepercaya; readOnlyHint bukanlah fakta otorisasi. Hasil dapat berisi data terstruktur, teks, tautan sumber daya, atau sumber daya tersemat. Panduan NSA lebih lanjut menyoroti pemanggilan dinamis, kepercayaan implisit, dan pembagian konteks sebagai risiko sistemik.
Pewawancara akan menguji jalur kegagalan: katalog yang diracuni (poisoned catalog), argumen lintas-tenant yang lolos validasi skema, parameter yang diubah setelah persetujuan, waktu habis (timeout), efek samping berulang, dan pipeline audit yang tidak tersedia.
Pertanyaan klarifikasi
Pertama, tanyakan tentang efek samping. Bisakah kueri, penulisan, deployment, dan penghapusan diperingkatkan berdasarkan risiko? Jika setiap tool bersifat read-only, persetujuan dan pemulihan bisa lebih sederhana; perpindahan uang, perubahan produksi, dan data pribadi memerlukan kontrol yang lebih ketat.
Kemudian tanyakan tentang batasan kepercayaan (trust boundaries). Apakah server dikelola perusahaan, di-host oleh pihak ketiga, atau disediakan pengguna? Jika platform tidak mengontrol server, deskripsi, anotasi, teks hasil, dan URI sumber dayanya adalah data input, bukan kebijakan.
Terakhir, tanyakan tentang tujuan kepatuhan dan pemulihan. Principal, tenant, dan kelas data mana yang harus dicatat? Apakah pembalikan berupa transaksi kompensasi, operasi invers, atau prosedur manual? Jawaban-jawaban tersebut mengubah retensi, cakupan kredensial, dan desain alur kerja.
Kerangka kerja jawaban 30 detik
Anda dapat mengatakan:
“Saya akan memperlakukan model sebagai pengusul yang tidak tepercaya dan menempatkan eksekusi di balik policy engine dan runner yang terisolasi. Platform mendaftarkan dan membuat versi setiap tool, menerapkan hak istimewa terendah (least privilege) berdasarkan pengguna, tenant, sumber daya, dan efek samping, serta mengikat tindakan berisiko tinggi seperti deployment, refund, dan penghapusan ke persetujuan parameter yang tepat. Pemanggilan read-only tetap memvalidasi input dan hasil. Sebelum dan sesudah eksekusi, kami menulis event audit yang berkorelasi; hasil tidak boleh menjadi otorisasi untuk pemanggilan berikutnya. Idempotensi, timeout, circuit breaker, serta rollback atau pemulihan manual menangani percobaan ulang (retry), perubahan server, ketidakcocokan persetujuan, dan kegagalan parsial.”
Jawaban mendalam langkah demi langkah
Membuat katalog tool yang sadar identitas
Daftarkan identitas server, nama tool, JSON Schemas input dan output, versi kode, cakupan jaringan, dan efek samping aktual. Perubahan katalog menghasilkan rekaman versi dan tinjauan; pemanggilan runtime hanya menggunakan versi yang disetujui. Spesifikasi MCP mendefinisikan nama, deskripsi, dan skema input, serta mengizinkan skema output, namun klien tetap memerlukan validasi independen.
Mengikat otorisasi ke satu pemanggilan
Input kebijakan harus mencakup principal, tenant, sumber daya, tindakan, kelas data, lingkungan, dan versi tool. Keputusannya adalah izinkan (allow), tolak (deny), atau perlu-persetujuan (approval-required), dan ini menghasilkan token pemanggilan berumur pendek. Ikat token ke digest parameter sehingga model tidak dapat mengubah jumlah, repositori, atau sumber daya setelah persetujuan.
Menafsirkan anotasi dan deskripsi sebagai petunjuk
readOnlyHint dan destructiveHint dapat meningkatkan pemeringkatan, tetapi tidak dapat mengotorisasi eksekusi. Jika server mengklaim bersifat read-only, kebijakan tetap bergantung pada registrasi yang telah ditinjau dan kemampuan yang teramati. Teks seperti “ignore previous instructions” adalah data, bukan pembaruan kebijakan.
Mengeksekusi di dalam runner yang terisolasi
Gunakan kredensial berumur pendek, egress terbatas, dan kuota sumber daya. Runner hanya menerima argumen terstruktur yang telah diperiksa kebijakan; runner tidak menerima seluruh percakapan atau data tenant lain. Teks tool, tautan, dan sumber daya tersemat pertama-tama masuk ke karantina hasil, kemudian melewati pemeriksaan skema output, ukuran, content-type, dan label data.
Membuat persetujuan eksplisit dan terikat parameter
Tampilan persetujuan menunjukkan principal, server, versi tool, ringkasan parameter lengkap, sumber daya target, efek samping yang diharapkan, kedaluwarsa, dan jalur pencabutan. Simpan persetujuan bersama dengan digest parameter; setiap perubahan field akan membatalkannya. Pembacaan berisiko rendah dapat menggunakan sampling post-hoc, sementara tindakan berisiko tinggi memerlukan persetujuan sebelum eksekusi.
Menangani percobaan ulang dan penyelesaian parsial
Operasi penulisan membawa kunci idempotensi yang diturunkan dari tindakan bisnis dan niat pemanggilan, bukan hanya nilai acak dari model. Simpan status permintaan, hasil, dan retry. Saat timeout, lakukan kueri status eksekusi sebelum mencoba lagi. Jika kompensasi tidak aman, pindahkan tindakan ke antrean manusia daripada mengulangi refund atau deployment secara membabi buta.
Memancarkan event audit yang berkorelasi
Sebuah event mencakup ID permintaan, principal, tenant, sidik jari server, versi tool, digest parameter, keputusan kebijakan, pemberi persetujuan, hasil eksekusi, dan ID kredensial downstream. Simpan argumen sensitif hanya sebagai digest yang telah disunting (redacted) atau referensi terenkripsi. Jika penyimpanan audit tidak tersedia, panggilan berisiko tinggi harus fail-closed atau masuk ke status tertunda daripada dilanjutkan secara diam-diam.
Roll out dan cabut secara bertahap
Validasi katalog, kebijakan, dan pemeriksaan hasil terhadap server sandbox dan shadow traffic sebelum peluncuran untuk tenant atau versi kecil. Pertahankan versi katalog lama dan sakelar pencabutan kredensial. Jika Anda mendeteksi eskalasi hak istimewa, prompt injection, atau kontaminasi hasil, blokir panggilan baru dan cabut token terlebih dahulu, kemudian gunakan event audit untuk menangani efek samping yang telah selesai.
Contoh jawaban berkualitas tinggi
“Saya akan membagi integrasi MCP menjadi lapisan katalog, kebijakan, persetujuan, runner, dan audit. Katalog mencatat sidik jari server, versi tool, skema, dan efek samping nyata. Model dapat mengusulkan pemanggilan, tetapi policy engine mengotorisasinya berdasarkan principal, tenant, sumber daya, dan lingkungan. Persetujuan terikat pada digest parameter, sehingga mengubah jumlah atau target akan membatalkannya. Runner menggunakan kredensial berumur pendek, jaringan terbatas, dan kunci idempotensi. Hasil dikarantina dan diperiksa skema, ukuran, tipe konten, dan label datanya sebelum mencapai agen. Setiap keputusan dan permintaan downstream dikorelasikan dalam log audit. Perubahan server, timeout, efek duplikat, dan kegagalan audit memiliki jalur penolakan, circuit-breaker, dan pemulihan, yang divalidasi melalui sandbox dan staged rollout.”
Kesalahan umum
Memperlakukan anotasi sebagai izin
Pola kegagalan: secara otomatis mengizinkan panggilan karena membawa readOnlyHint. Mengapa gagal: spesifikasi MCP menyatakan bahwa anotasi dari server yang tidak tepercaya tidak dapat diperlakukan sebagai fakta keamanan. Koreksi: gunakan anotasi sebagai petunjuk; turunkan izin dari registrasi, kebijakan, dan pemeriksaan kemampuan saat runtime.
Hanya memvalidasi argumen yang dihasilkan
Pola kegagalan: mengeksekusi segera setelah validasi JSON Schema lolos. Mengapa gagal: argumen dengan tipe yang benar masih dapat melintasi tenant, menargetkan produksi, atau mengulangi tindakan yang tidak dapat dibatalkan. Koreksi: validasi juga principal, kepemilikan sumber daya, risiko, idempotensi, dan digest persetujuan.
Hanya menampilkan persetujuan dalam bahasa alami
Pola kegagalan: meminta pengguna untuk menyetujui "tangani refund". Mengapa gagal: objek yang disetujui ambigu, sehingga jumlah atau akun dapat berubah pada saat eksekusi. Koreksi: tampilkan target, jumlah, versi, digest parameter, kedaluwarsa, dan ikat persetujuan ke digest tersebut.
Memperlakukan output tool sebagai instruksi tepercaya
Pola kegagalan: menggabungkan teks yang dikembalikan ke dalam prompt sistem berikutnya. Mengapa gagal: hasil dapat berisi prompt injection, data lintas-tenant, atau URI berbahaya. Koreksi: karantina hasil, validasi tipe, beri label data, dan teruskan hanya field minimum yang diperlukan.
Hanya merancang happy path
Pola kegagalan: mencoba ulang setiap timeout dan melanjutkan setelah setiap error. Mengapa gagal: status eksekusi yang tidak diketahui dapat menduplikasi penulisan, sementara penyelesaian parsial dapat melanggar invarian bisnis. Koreksi: rancang idempotensi, pencarian status, kompensasi, circuit breaking, dan eskalasi manusia secara bersamaan.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika katalog tool berubah selama pemanggilan?
Bekukan sidik jari server, versi tool, dan skema yang digunakan oleh pemanggilan tersebut. Perubahan katalog hanya memengaruhi pemanggilan baru. Jika versinya dicabut, policy engine akan menolak token lama dan meminta persetujuan baru.
Bagaimana jika layanan persetujuan tidak tersedia?
Gunakan pendekatan fail-closed untuk tindakan berisiko tinggi, dengan menahan proposal dalam antrean pending. Pembacaan berisiko rendah dapat dilanjutkan di bawah kebijakan yang telah disetujui sebelumnya, tetapi tetap memancarkan event audit; timeout persetujuan bukanlah sebuah otorisasi.
Bagaimana jika JSON yang valid berisi data tenant lain?
Skema output memvalidasi bentuk data, bukan cakupan otorisasi. Teruskan cakupan tenant dan sumber daya ke downstream serta periksa kepemilikan, label data, dan kardinalitas hasil sebelum merilis hasil. Karantina dan beri peringatan jika terjadi pelanggaran.
Bagaimana Anda memutuskan apakah suatu tool boleh berjalan secara otomatis?
Beri skor pada reversibilitas, radius dampak (blast radius), sensitivitas data, biaya duplikasi, dan kemampuan deteksi. Kueri yang dapat dibatalkan, ber-sensitivitas rendah, dan berdampak rendah dapat berjalan secara otomatis; perpindahan uang, perubahan produksi, penghapusan, dan pembacaan lintas-tenant memerlukan persetujuan manusia atau alur kerja khusus.
Bagaimana Anda menyelidiki prompt injection?
Korelasikan input asli, versi deskripsi tool, proposal model, keputusan kebijakan, tampilan persetujuan, hasil tool, dan pemanggilan berikutnya berdasarkan ID permintaan. Cabut server dan token yang terpengaruh terlebih dahulu, lalu putar ulang keputusan dari log yang dikarantina untuk mengidentifikasi efek samping yang telah selesai.