Panduan Arsitektur: Zero-Trust Agentic Gateways: Sandboxing MCP Tool — Bagaimana Menerapkannya Secara Efisien?
Ringkasan: Memberikan akses tools kepada LLM melalui Model Context Protocol (MCP) pada dasarnya adalah melegalkan Remote Code Execution (RCE) di dalam infrastruktur Anda. Esai ini membedah arsitektur Zero-Trust Agentic Gateways—sebuah pola defense-in-depth yang mengisolasi eksekusi tools agen menggunakan sandbox gVisor, IAM Workload Identity yang sangat spesifik, dan kontrol egress VPC Service Controls di atas Google Cloud Run Gen2 untuk mencegah eskalasi privilege dan eksfiltrasi data di production.
Era Eksekusi Agen dan Paradoks Keamanan
Tahun 2026 telah mengubah cara kita memandang Artificial Intelligence. Kita tidak lagi sekadar melakukan chatting dengan model; kita mendelegasikan tugas. Model-model mutakhir seperti gemini-2.5-pro dan gemini-3.1-pro-preview kini bertindak sebagai agen otonom yang mampu membaca database, mengeksekusi script Python, dan melakukan commit ke repositori Git. Standar de facto yang memungkinkan semua ini terjadi secara seamless adalah Model Context Protocol (MCP).
Namun, di balik keajaiban otomatisasi ini, terdapat kenyataan pahit yang sering diabaikan oleh para engineer: memberikan LLM kemampuan untuk memanggil tools eksternal pada dasarnya adalah menyediakan Remote Code Execution (RCE) sebagai sebuah fitur. Pertanyaannya bukan lagi "Apakah agen kita bisa menyelesaikan tugas?", melainkan "Bagaimana kita merancang sistem di mana agen yang terkena prompt injection tidak akan menghancurkan seluruh infrastruktur production kita?"
Ilusi Keamanan dalam Kontainer Standar
Saya masih ingat dengan jelas ketika pertama kali men-deploy server MCP ke production. Saat itu, pendekatannya sangat naif. Saya membungkus server MCP di dalam sebuah kontainer Docker standar, menaruhnya di dalam klaster Kubernetes biasa, dan memberikan agen akses ke tool SQL untuk melakukan query ke database analitik. Semuanya berjalan lancar, agen tersebut dengan cerdas menjawab pertanyaan bisnis yang kompleks.
Lalu, kami melakukan red-teaming. Kami menyisipkan instruksi tersembunyi (indirect prompt injection) ke dalam dokumen yang sedang dianalisis oleh agen. Instruksi tersebut memerintahkan agen untuk menggunakan tool Python REPL yang dimilikinya untuk membaca environment variables dan mengirimkannya ke server eksternal. Dalam hitungan detik, agen kami yang "cerdas" berubah menjadi vektor serangan, mengeksekusi kode arbitrer di dalam kontainer dan mencoba melakukan lateral movement. Itu adalah mimpi buruk keamanan.
Batas Tipis Antara Utilitas dan Bencana
Di sinilah letak konflik utamanya. Untuk membuat agen benar-benar berguna, mereka membutuhkan akses ke data dan sistem internal. Namun, kontainer Linux standar tidak memberikan isolasi yang cukup kuat untuk mengeksekusi kode yang tidak terpercaya (untrusted code).
Seperti yang dijelaskan dalam dokumentasi Model Context Protocol Security Best Practices, kita harus selalu berasumsi bahwa tools dapat disalahgunakan. Masalahnya, dalam arsitektur kontainer tradisional, semua kontainer berbagi kernel Linux (host kernel) yang sama. Jika seorang penyerang berhasil menemukan kerentanan di kernel (seperti eksploitasi System API atau System ABI), mereka dapat melakukan container escape, mengambil alih node Kubernetes, dan menyebar ke seluruh jaringan internal. Kita tidak bisa hanya mengandalkan prompt engineering atau guardrails di level LLM; kita membutuhkan isolasi di level infrastruktur.
Mengapa IAM Saja Tidak Pernah Cukup
Respons awal saya terhadap ancaman ini adalah memperketat Identity and Access Management (IAM). "Mari kita berikan Service Account dengan privilege paling rendah," pikir saya. Ini adalah langkah yang benar, tetapi tidak cukup.
Meskipun kita menggunakan Cloud Run Service Identity untuk memastikan bahwa server MCP hanya memiliki akses ke resource tertentu, IAM tidak melindungi kita dari ancaman jaringan. Jika kontainer MCP dikompromikan, IAM mungkin mencegah penyerang menghapus database, tetapi IAM tidak akan mencegah penyerang menggunakan tool curl atau library Python di dalam kontainer untuk memindai (port scanning) jaringan Virtual Private Cloud (VPC) internal kita, atau mengeksfiltrasi data publik ke bucket S3 milik penyerang. IAM mengontrol siapa yang bisa mengakses apa, tetapi tidak mengontrol ke mana data bisa mengalir.
Membangun Zero-Trust Agentic Gateways
Untuk menyelesaikan masalah ini secara komprehensif, saya merancang pola arsitektur yang saya sebut sebagai Zero-Trust Agentic Gateways. Pola ini tidak mencoba membuat agen menjadi "aman" secara inheren, melainkan membangun sandbox di sekeliling eksekusi tools sehingga blast radius dari agen yang dikompromikan menjadi nol.
Arsitektur ini bersandar pada tiga pilar utama:
- Isolasi Kernel dengan gVisor (Cloud Run Gen2): Alih-alih menjalankan server MCP di GKE standar atau Cloud Run Gen1, kita menggunakan Cloud Run Gen2 dengan Execution Environment generasi kedua. Di bawah kapnya, ini menggunakan gVisor. gVisor bertindak sebagai kernel ruang pengguna (userspace kernel) yang mencegat (intercept) semua panggilan sistem (system calls) dari aplikasi ke host kernel. Seperti yang dijelaskan dalam model keamanan gVisor, ini meminimalkan vektor serangan System API melalui pertahanan berlapis (defense-in-depth). Jika tool Python agen mencoba mengeksploitasi bug kernel, eksploitasi tersebut hanya akan mengenai sandbox gVisor, bukan host fisik.
- Identitas Beban Kerja yang Sangat Spesifik (Workload Identity): Setiap server MCP (misalnya,
mcp-sql-server,mcp-github-server) di-deploy sebagai layanan Cloud Run yang terpisah. Masing-masing diberikan identitas layanan (Service Identity) yang unik dan sangat dibatasi.mcp-sql-serverhanya memiliki roleroles/cloudsql.client, sementaramcp-github-serverhanya memiliki akses ke Secret Manager untuk mengambil token GitHub. - Mitigasi Eksfiltrasi dengan VPC Service Controls: Untuk mencegah agen mengirimkan data ke luar jaringan yang diizinkan, kita membungkus seluruh proyek dalam perimeter VPC Service Controls (VPC SC). VPC SC memastikan bahwa meskipun agen memiliki kredensial yang valid, mereka tidak dapat menyalin data ke resource Google Cloud di luar perimeter (misalnya, mencegah
gcloud storage cpke bucket eksternal). Kita kemudian mengonfigurasi aturan egress yang sangat ketat, hanya mengizinkan traffic keluar ke API spesifik yang dibutuhkan oleh tools.
flowchart LR
User([User / Client]) --> App[Agent Application]
App -- "Prompt + Tool Call" --> LLM{"Gemini 2.5 Pro\n(LLM Engine)"}
LLM -- "Tool Execution Request" --> App
subgraph "Google Cloud Project (VPC Service Controls Perimeter)"
App -- "HTTPS / MCP Protocol" --> CR_Gateway[Cloud Run Gen2\nAPI Gateway]
subgraph "Zero-Trust MCP Sandboxes (gVisor)"
CR_Gateway --> MCP_SQL["MCP Server: SQL\n(Identity: sql-sa)"]
CR_Gateway --> MCP_Python["MCP Server: Python REPL\n(Identity: python-sa)"]
CR_Gateway --> MCP_Git["MCP Server: GitHub\n(Identity: git-sa)"]
end
MCP_SQL -- "Private IP" --> CloudSQL[(Cloud SQL)]
MCP_Git -- "Read Token" --> SecretMgr[Secret Manager]
end
MCP_Python -. "Blocked Egress" .-> Internet((Internet))
MCP_Git -- "Strict Egress Rule" --> GitHub((GitHub API))
classDef secure fill:#e6f3ff,stroke:#0066cc,stroke-width:2px;
classDef blocked fill:#ffe6e6,stroke:#cc0000,stroke-width:2px,stroke-dasharray: 5 5;
class CR_Gateway,MCP_SQL,MCP_Python,MCP_Git secure;
class Internet blocked;
Implementasi Kode: Konfigurasi Infrastruktur sebagai Kode
Untuk mewujudkan arsitektur ini di production, kita tidak bisa mengandalkan konfigurasi manual (click-ops). Berikut adalah cuplikan Terraform yang menunjukkan bagaimana saya men-deploy server MCP Python REPL di Cloud Run Gen2 dengan sandbox gVisor yang diaktifkan secara eksplisit, identitas layanan yang terisolasi, dan kontrol jaringan.
# 1. Buat Service Account khusus untuk MCP Python REPL
resource "google_service_account" "mcp_python_sa" {
account_id = "mcp-python-executor"
display_name = "MCP Python REPL Service Account"
}
# 2. Deploy Cloud Run Gen2 dengan gVisor (EXECUTION_ENVIRONMENT_GEN2)
resource "google_cloud_run_v2_service" "mcp_python_sandbox" {
name = "mcp-python-sandbox"
location = "asia-southeast1"
ingress = "INGRESS_TRAFFIC_INTERNAL_ONLY" # Hanya bisa dipanggil dari dalam VPC
template {
service_account = google_service_account.mcp_python_sa.email
# KUNCI KEAMANAN: Memaksa penggunaan gVisor
execution_environment = "EXECUTION_ENVIRONMENT_GEN2"
containers {
image = "asia-southeast1-docker.pkg.dev/my-project/mcp-images/python-repl:v1.2.0"
resources {
limits = {
cpu = "1"
memory = "1Gi"
}
}
# Drop semua kapabilitas Linux yang tidak perlu
security_context {
run_as_user = 1000
}
}
vpc_access {
connector = google_vpc_access_connector.mcp_connector.id
egress = "ALL_TRAFFIC" # Semua traffic dirutekan ke VPC untuk dievaluasi oleh VPC SC
}
}
}
# 3. Konfigurasi VPC Service Controls Egress Rule
# Memastikan MCP Python tidak bisa mengirim data ke luar perimeter
resource "google_access_context_manager_service_perimeter" "mcp_perimeter" {
parent = "accessPolicies/${var.access_policy_id}"
name = "accessPolicies/${var.access_policy_id}/servicePerimeters/mcp_secure_perimeter"
title = "MCP Secure Perimeter"
status {
restricted_services = ["storage.googleapis.com", "sqladmin.googleapis.com"]
vpc_accessible_services {
enable_restriction = true
allowed_services = ["run.googleapis.com"]
}
# Tidak ada egress rule ke internet untuk mcp_python_sa. Eksfiltrasi diblokir.
}
}