Praktik terbaik untuk mengamankan interaksi agen dengan Model Context Protocol

Model Context Protocol (MCP) menstandarkan cara agen AI generatif terhubung ke AlloyDB untuk PostgreSQL. Karena risiko inheren agen otonom, memitigasi kerentanan seperti injeksi perintah memerlukan model tanggung jawab bersama, yang menggabungkan kontrol platform dengan desain aplikasi yang aman.
Untuk mendesain dan men-deploy aplikasi AI yang menggunakan Google Cloud Model Context Protocol (MCP) tools, ikuti praktik terbaik dalam panduan ini.

Sebelum memulai

Saat Anda menggunakan alat MCP, postur keamanan aplikasi Anda bergantung pada model interaksi agen. Untuk mempelajari pengaruh penggunaan agen terhadap risiko keamanan yang terkait dengan integrasi agen dengan server MCP, lihat Keamanan dan keselamatan AI.

Tanggung jawab keamanan

Sebagai pelanggan, Anda bertanggung jawab atas konfigurasi dan pengoperasian platform agen yang aman.

Mengikuti prinsip hak istimewa terendah

Jalankan agen Anda dengan akun layanan yang memiliki cakupan minimal. Ini adalah lapisan pertahanan pertama dan paling penting.

• Identitas khusus: Buat akun layanan khusus yang terpisah untuk setiap agen atau aplikasi unik yang menggunakan alat MCP. Jangan gunakan kembali SA yang ada, terutama yang memiliki izin luas.
• Cakupan minimal: Berikan peran Identity and Access Management (IAM) yang diperlukan saja ke akun layanan—misalnya, alloydb.viewer, bukan alloydb.admin. Jika agen hanya memerlukan akses baca ke set data tertentu, gunakan peran IAM kustom untuk membatasi akses ke minimum absolut yang diperlukan untuk fungsinya.
• Pemisahan tugas: Jika agen memerlukan akses baca ke data dan akses tulis ke log atau penyimpanan sementara, gunakan dua akun layanan terpisah—satu akun untuk akses data berisiko tinggi (cakupan minimal) dan satu akun untuk tugas operasional berisiko rendah.

Menggunakan kontrol terperinci native database

Untuk pertahanan terkuat, gabungkan peran IAM dengan kontrol akses terperinci yang ditawarkan oleh database itu sendiri. Hal ini memastikan bahwa meskipun penyerang membahayakan token IAM agen, cakupan kerusakan dibatasi oleh izin internal mesin database—misalnya, mencegah perintah DROP TABLE.

Produk	Mekanisme Kontrol Terperinci	Fokus
Cloud SQL dan AlloyDB	Peran tingkat database seperti CREATE ROLE di PostgreSQL dan MySQL.	Mengelola izin dalam instance dan skema database tertentu.
BigQuery	Kontrol Akses Tingkat Kolom (menggunakan tag kebijakan)	Membatasi akses agen ke kolom sensitif—misalnya, PII— bahkan dalam tabel yang diotorisasi.
Spanner	Kontrol Akses Terperinci (Peran database dengan GRANT/REVOKE)	Menerapkan izin baca/tulis/update yang tepat pada tabel dan kolom.
Firestore	Peran IAM dan kondisi IAM	Mengonfigurasi izin akses per database menggunakan peran IAM dan kondisi IAM.
Bigtable	Peran IAM	Bigtable menawarkan kontrol terperinci melalui peran IAM di tingkat project, instance, dan tabel.
Oracle Database@Google Cloud	Peran IAM	Oracle Database@Google Cloud menawarkan kontrol terperinci melalui peran IAM di tingkat project dan resource.

Desain agen yang aman

Model Khusus Agen memerlukan pertahanan tingkat aplikasi yang kuat terhadap serangan injeksi perintah, yang mencoba mengganti perintah sistem. Untuk mengetahui informasi selengkapnya, lihat Keamanan dan keselamatan AI.

Memperlakukan data dan input pengguna sebagai tidak tepercaya

Perlakukan input dari pengguna akhir, atau data yang diambil oleh agen dari sumber eksternal—seperti hasil penelusuran web atau dokumen pihak ketiga—sebagai tidak tepercaya.

Menerapkan pola pemilihan tindakan

Hindari arsitektur rencana dan eksekusi terbuka, yang memisahkan spesifikasi tugas tingkat tinggi dari eksekusi mekanis. Sebagai gantinya, gunakan pola desain yang membatasi kebebasan model.

• Pola pemilih tindakan: satu-satunya tugas model adalah menerjemahkan permintaan pengguna ke salah satu dari sekumpulan kecil fungsi aman yang telah ditentukan. Logika tindakan dikodekan secara permanen dan tidak dapat diubah oleh LLM. Hal ini membantu membuat agen kebal terhadap serangan injeksi yang menargetkan alur kontrol.
• Pola LLM ganda: gunakan LLM utama (LLM tindakan) yang melakukan tugas inti, dan LLM sekunder yang sangat aman (LLM pagar pembatas) yang melakukan pra-penyaringan perintah pengguna untuk mengetahui niat jahat dan melakukan pasca-penyaringan output LLM tindakan untuk mengetahui tindakan atau kebocoran data yang tidak sah.

Mencegah chaining alat yang tidak sah

Agen hanya boleh memanggil alat yang diperlukan untuk tugas tersebut. Pastikan kode orkestrasi Anda mencegah hal berikut:

• Alat dinamis: agen tidak boleh dapat mendaftarkan alat baru secara dinamis atau mengubah izin alat yang ada.
• Penerapan daftar yang diizinkan: deklarasikan daftar yang diizinkan untuk fungsi atau tabel database yang dapat diakses agen dalam perintah sistem awal dan kode backend. Untuk contoh Gemini CLI, lihat Membatasi Akses Alat.

Membatasi akses data dalam database multi-tenant

Alat umum seperti execute_sql memungkinkan pemanggil menjalankan kueri database yang dapat membaca data apa pun yang diizinkan oleh izin IAM dan database. Saat membuat agen yang mengakses data dalam aplikasi multi-tenant tanpa manusia tepercaya dalam loop, Anda mungkin perlu membatasi akses data lebih lanjut.

Untuk memastikan bahwa agen hanya dapat membaca subset data yang dapat diaksesnya, sebaiknya buat alat kustom menggunakan framework seperti MCP Toolbox for Databases. Untuk mengetahui informasi selengkapnya, lihat Alat Bawaan vs. Alat Kustom.

Misalnya, bayangkan database Anda menyimpan pesanan untuk semua pengguna akhir dalam tabel Orders. Anda mengembangkan agen chat yang berinteraksi dengan pengguna dan dapat mencari pesanan mereka. Agen chat memiliki izin untuk membaca seluruh tabel Orders, tetapi satu pengguna akhir tidak boleh dapat meminta informasi tentang pesanan pengguna lain.

Dalam skenario yang tidak aman, Anda melengkapi agen hanya dengan alat execute_sql, sehingga menimbulkan risiko kebocoran data. Pengguna yang berbahaya dapat menipu agen agar membaca dan menampilkan pesanan pengguna lain. Menginstruksikan agen untuk menerapkan aturan akses biasanya tidak cukup untuk melindungi data.

Dalam skenario yang aman, Anda memberi agen alat kustom yang lebih spesifik—seperti lookup_active_order—dengan identitas pengguna dalam filter kueri yang ditetapkan di luar kontrol agen.

Konfigurasi keamanan dan keselamatan

AlloyDB menyediakan Model Armor untuk menerapkan batas keamanan di tingkat platform. Anda harus mengaktifkan dan mengonfigurasi setelan ini.

Mengaktifkan Model Armor

Gunakan Google Cloud CLI untuk mengaktifkan Model Armor pada deployment model Anda. Tindakan ini akan mengaktifkan perlindungan bawaan terhadap vektor serangan yang diketahui seperti injeksi dan jailbreaking.

Contoh berikut mengaktifkan Model Armor di endpoint Vertex AI.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

Untuk mengetahui informasi dan contoh selengkapnya, lihat Mengonfigurasi perlindungan Model Armor untuk MCP di Google Cloud.

Menerapkan nilai minimum keamanan untuk operasi data sensitif

Model Armor memungkinkan Anda menerapkan nilai minimum keamanan untuk operasi data sensitif—misalnya, deteksi dan penghapusan identifikasi informasi identitas pribadi (PII). Gunakan Sensitive Data Protection DeidentifyTemplate untuk menyamarkan atau menutupi informasi sensitif sebelum ditampilkan kepada pengguna, meskipun modelnya dibahayakan.

Berikut adalah contoh konseptual untuk konfigurasi:

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

Dalam contoh berikut, model_armor_config.json mungkin merujuk ke template DLP:

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

Audit dan kemampuan observasi

Visibilitas ke dalam tindakan agen sangat penting untuk analisis pasca-insiden dan deteksi agen yang dibahayakan.

Menerapkan strategi pemulihan data

Meskipun kontrol berlapis seperti peran IAM dan native database dirancang untuk mencegah tindakan destruktif, Anda harus memiliki rencana pemulihan jika pertahanan tersebut gagal. Agen yang dibahayakan atau tidak berpengalaman dengan izin tulis (risiko "Khusus Agen") dapat ditipu untuk menjalankan perintah destruktif seperti DROP TABLE atau merusak data.

Pertahanan utama Anda terhadap skenario ini adalah strategi pemulihan yang kuat.

Hampir semua produk Data Cloud menyediakan fitur untuk pemulihan data, baik melalui pencadangan tradisional, pemulihan point-in-time (PITR), atau snapshot data. Anda bertanggung jawab untuk mengaktifkan dan mengonfigurasi fitur ini.

Produk	Mekanisme pencadangan dan pemulihan
Cloud SQL	Mendukung pencadangan sesuai permintaan dan otomatis, sehingga Anda dapat memulihkan instance ke status sebelumnya. Fitur ini juga mendukung Pemulihan Point-in-Time (PITR).
AlloyDB	Menyediakan pencadangan dan pemulihan berkelanjutan secara default. Hal ini memungkinkan PITR dengan granularitas mikrodetik, sehingga Anda dapat memulihkan cluster ke waktu mana pun dalam periode retensi.
BigQuery	Pemulihan data dicapai menggunakan "Perjalanan Waktu", yang memungkinkan Anda mengakses dan memulihkan data dari titik mana pun dalam 7 hari terakhir. Untuk retensi jangka panjang, Anda dapat membuat Snapshot Tabel.
Spanner	Mendukung pencadangan sesuai permintaan dan PITR.
Firestore	Mendukung pencadangan otomatis yang memungkinkan Anda memulihkan database ke status sebelumnya. Fitur ini juga menawarkan PITR untuk melindungi dari penghapusan atau penulisan yang tidak disengaja. Kedua fitur ini dinonaktifkan secara default.
Bigtable	Mendukung pencadangan sesuai permintaan dan otomatis. Cadangan ini dikelola sepenuhnya dan dapat dipulihkan ke tabel baru.
Oracle Database@Google Cloud	Mendukung pencadangan otomatis dan PITR.

Mengaktifkan Cloud Audit Logs

Pastikan log audit Akses Data diaktifkan untuk MCP serta semua Google Cloud layanan yang relevan seperti BigQuery, Cloud SQL, AlloyDB, Firestore, Spanner, dan Oracle Database@Google Cloud. Secara default, hanya log audit Aktivitas Admin yang diaktifkan. Log audit Akses Data mencatat setiap operasi baca dan tulis yang dilakukan oleh agen. Untuk mengetahui informasi selengkapnya, lihat Log audit akses data untuk MCP.

Mengaudit tindakan sensitif

Konfigurasi peringatan di Cloud Logging untuk mendeteksi tindakan anomali atau berisiko tinggi. Kueri Logs Explorer mengidentifikasi akun layanan yang melakukan operasi penulisan data di Firestore, misalnya, yang merupakan target umum untuk eksfiltrasi atau serangan destruktif:

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

Menggunakan logging khusus agen

Selain Cloud Audit Logs, pastikan kode aplikasi Anda mencatat data berikut untuk setiap keputusan agen:

• Eksekusi alat: alat MCP yang dipanggil.
• Perintah mentah: perintah yang tepat—misalnya, kueri SQL atau jalur dokumen—yang dihasilkan oleh LLM.
• Tindakan akhir: apakah tindakan dieksekusi (model Khusus Agen) atau disetujui (Manusia di Tengah). Untuk mengetahui informasi selengkapnya, lihat Memahami penggunaan agen.
• ID pengguna dan sesi: ID untuk pengguna akhir yang memulai permintaan.