Praktik terbaik untuk mengamankan interaksi agen dengan Model Context Protocol

Model Context Protocol (MCP) menstandardisasi 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 alat Model Context Protocol (MCP), ikuti praktik terbaik dalam panduan ini. Google Cloud

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 mengintegrasikan agen dengan server MCP, lihat Keamanan dan keselamatan AI.

Tanggung jawab keamanan

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

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 menggunakan alat MCP. Jangan menggunakan kembali SA yang ada, terutama yang memiliki izin luas.
Cakupan minimal: Berikan hanya peran Identity and Access Management (IAM) yang diperlukan kepada 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 mutlak 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 (dengan 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 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 diizinkan.
Spanner	Kontrol Akses Terperinci (Peran database dengan `GRANT/REVOKE`)	Menerapkan izin baca/tulis/perbarui yang tepat pada tabel dan kolom.
Firestore	Aturan Keamanan Firestore	Membatasi akses tingkat dokumen atau tingkat kolom berdasarkan logika aplikasi atau konteks pengguna yang meminta.
Bigtable	Peran IAM	Bigtable menawarkan kontrol terperinci melalui peran IAM di tingkat project, instance, dan tabel.

Desain agen yang aman

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

Perlakukan 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 yang tidak terbatas, 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 dalam salah satu dari sekumpulan kecil fungsi aman yang telah ditentukan sebelumnya. 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: menggunakan LLM utama (LLM tindakan) yang melakukan tugas inti, dan LLM sekunder yang sangat aman (LLM pembatas) yang melakukan prapenyaringan perintah pengguna untuk mendeteksi niat jahat dan pascapenyaringan output LLM tindakan untuk mendeteksi tindakan yang tidak sah atau kebocoran data.

Mencegah rangkaian 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: mendeklarasikan daftar yang diizinkan untuk fungsi atau tabel database yang dapat diakses oleh agen dalam perintah sistem awal dan kode backend-nya. Untuk contoh Gemini CLI, lihat Membatasi Akses Alat.

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 mengaktifkan perlindungan bawaan terhadap vektor serangan yang diketahui seperti injeksi dan jailbreak.

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 volume minimum data untuk operasi data sensitif

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

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 dapat mereferensikan 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 disusupi.

Menerapkan strategi pemulihan data

Meskipun kontrol berlapis seperti IAM dan peran native database dirancang untuk mencegah tindakan merusak, Anda harus memiliki rencana pemulihan jika pertahanan tersebut gagal. Agen yang disusupi 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. Selain itu, fitur ini mendukung Pemulihan Point-in-Time (PITR).
AlloyDB	Menyediakan pencadangan dan pemulihan berkelanjutan secara default. Hal ini memungkinkan PITR dengan perincian mikrodetik, sehingga Anda dapat memulihkan cluster ke waktu apa pun dalam periode retensi.
BigQuery	Pemulihan data dilakukan 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 ekspor/impor terkelola sebagai cadangan. Layanan ini juga menawarkan PITR—dinonaktifkan secara default—untuk melindungi dari penghapusan atau penulisan yang tidak disengaja.
Bigtable	Mendukung pencadangan sesuai permintaan dan otomatis. Cadangan ini dikelola sepenuhnya dan dapat dipulihkan ke tabel baru.

Mengaktifkan Cloud Audit Logs

Pastikan Log audit Akses Data diaktifkan untuk MCP serta semua layanan Google Cloud yang relevan seperti BigQuery, Cloud SQL, AlloyDB, dan Spanner. 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 pemberitahuan di Cloud Logging untuk mendeteksi tindakan yang 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 persisnya—misalnya, kueri SQL atau jalur dokumen—yang dihasilkan oleh LLM.
Tindakan akhir: apakah tindakan dieksekusi (model Khusus Agen) atau disetujui (Human-in-the-Middle). Untuk mengetahui informasi selengkapnya, lihat Memahami penggunaan agen.
ID pengguna dan sesi: ID untuk pengguna akhir yang memulai permintaan.