Gateway Agen Zero-Trust: Isolasi dan Sandboxing Eksekusi Tool MCP di Production

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:

1. 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.
2. 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-server hanya memiliki role roles/cloudsql.client, sementara mcp-github-server hanya memiliki akses ke Secret Manager untuk mengambil token GitHub.
3. 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 cp ke 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.
  }
}

Perhatikan baris execution_environment = "EXECUTION_ENVIRONMENT_GEN2". Ini adalah parameter paling krusial. Tanpa ini, Anda mungkin berjalan di lingkungan yang kurang terisolasi. Dengan ini, Anda mendapatkan perlindungan intersepsi System API dari gVisor. Selain itu, INGRESS_TRAFFIC_INTERNAL_ONLY memastikan bahwa endpoint MCP ini tidak terekspos ke internet publik, melainkan hanya bisa dipanggil oleh aplikasi agen utama kita yang berada di dalam VPC yang sama.

📊 Production FinOps & TCO Simulation: TCO Comparison: Always-On GKE vs Serverless Cloud Run Gen2 for MCP Gateways (Verified SKU Math)

Tentu saja, sebagai arsitek sistem, kita tidak bisa hanya berbicara tentang keamanan tanpa memperhitungkan biaya. Banyak tim berasumsi bahwa menjalankan sandbox yang aman membutuhkan klaster Kubernetes (GKE) yang selalu menyala (always-on) dengan node khusus. Namun, dengan menggunakan arsitektur serverless Cloud Run Gen2, kita tidak hanya meningkatkan keamanan, tetapi juga mengoptimalkan Total Cost of Ownership (TCO).

Berikut adalah simulasi deterministik yang membandingkan pendekatan GKE Autopilot (always-on) dengan pendekatan Cloud Run Gen2 (scale-to-zero) untuk menangani 1 juta eksekusi tool MCP per bulan.

Production Workload Assumptions (us-central1 / asia-southeast1):

• 1 million MCP tool executions per month
• Average tool execution time: 2 seconds
• Gemini 2.5 Pro usage: 500M input tokens, 50M output tokens
• Cloud Run instances use 1 vCPU and 1 GiB RAM
• GKE Autopilot uses 5 always-on pods (1 vCPU, 2 GiB RAM each)

Official Google Cloud SKU Pricing Sources (2026.09): cloud.google.com, cloud.google.com, cloud.google.com

Seperti yang terlihat pada data di atas, mengadopsi Zero-Trust Agentic Gateways di Cloud Run tidak hanya memberikan perlindungan kernel gVisor yang superior, tetapi juga menghasilkan penghematan biaya infrastruktur komputasi yang signifikan karena sifatnya yang scale-to-zero. Kita tidak membayar untuk idle time saat agen tidak sedang mengeksekusi tools.

Bedah Mendalam: Mekanisme Intersepsi Syscall di gVisor (runsc Sentry & Gofer)

Untuk benar-benar memahami mengapa parameter EXECUTION_ENVIRONMENT_GEN2 di Cloud Run memberikan jaminan keamanan yang jauh melampaui kontainer Docker standar, kita perlu membedah bagaimana kernel user-space gVisor menangani system calls (syscalls). Pada kontainer Linux tradisional yang hanya mengandalkan namespaces dan cgroups, sebuah proses Python atau Node.js yang mengeksekusi tool MCP berbicara langsung dengan kernel host Linux melalui tabel syscall yang sama. Jika terdapat kerentanan privilege escalation di kernel host (seperti eksploitasi io_uring atau dirty pipe), kode berbahaya yang diinjeksikan melalui prompt injection dapat melompat keluar dari batas kontainer (container escape) dan mengambil alih node komputasi.

Di Cloud Run Gen2, arsitektur ini diubah secara radikal melalui integrasi gVisor (runsc). Alih-alih meneruskan syscall langsung ke kernel host, gVisor menempatkan sebuah kernel user-space independen yang ditulis dalam bahasa Go bernama Sentry. Setiap kali kode di dalam server MCP memanggil fungsi sistem seperti openat(), socket(), connect(), atau execve(), panggilan tersebut ditangkap oleh Sentry melalui mekanisme platform virtualization berbasis KVM atau systrap. Sentry mengimplementasikan ulang ratusan syscall Linux di ruang memori terisolasi tanpa pernah memberikan akses langsung ke kernel host yang mendasarinya.

Lebih jauh lagi, akses sistem berkas (file system) didelegasikan ke komponen terpisah bernama Gofer. Sentry bahkan tidak diizinkan membuka file descriptor secara langsung di host; ia harus berkomunikasi dengan Gofer melalui protokol 9P (Plan 9 File Protocol) di atas saluran socket yang dibatasi secara ketat oleh aturan seccomp-bpf. Jika sebuah tool MCP yang terkompromi mencoba membaca /proc/kcore, memodifikasi /etc/shadow, atau memindai device driver di /dev, Sentry akan langsung menolak operasi tersebut pada level user-space. Bahkan jika penyerang berhasil menemukan buffer overflow di dalam Sentry itu sendiri, mereka hanya akan terjebak di dalam proses Go tanpa hak akses root terhadap hypervisor Google Cloud.

Strategi Pertahanan Berlapis: Otorisasi Dinamis & OAuth 2.0 Token Exchange (RFC 8693)

Isolasi kernel hanyalah separuh dari persamaan Zero-Trust. Tantangan berikutnya yang sering diabaikan oleh tim engineering adalah penyalahgunaan kredensial sah (confused deputy problem). Bayangkan skenario di mana sebuah server MCP untuk analisis data diberikan Service Account statis dengan peran roles/bigquery.dataViewer di seluruh proyek perusahaan. Jika pengguna yang memiliki hak akses terbatas melakukan prompt injection terhadap agen AI, agen tersebut dapat diperdaya untuk memanggil tool MCP guna mengekstrak tabel gaji eksekutif atau data PII pelanggan yang seharusnya tidak boleh diakses oleh pengguna tersebut.

Untuk menutup celah ini, arsitektur Zero-Trust Agentic Gateway yang saya rancang melarang keras penggunaan kredensial statis (ambient credentials) untuk tool yang mengakses data sensitif. Sebagai gantinya, kita menerapkan pola OAuth 2.0 Token Exchange (RFC 8693) yang dikombinasikan dengan Google Cloud Workload Identity Federation. Setiap kali pengguna memicu percakapan dengan agen utama (Orchestrator), identitas asli pengguna (Subject Token berupa JWT dari Google Identity Platform atau Okta) diteruskan bersama dengan konteks permintaan.

Sebelum Orchestrator mengeksekusi panggilan tool ke server MCP di Cloud Run, Gateway akan melakukan pertukaran token (token exchange) secara real-time ke Security Token Service (STS) Google Cloud. Gateway meminta token akses sementara (short-lived access token) dengan masa berlaku hanya 5 menit (lifetime = 300s) dan menerapkan kebijakan Downscoping (Credential Access Boundary). Kebijakan ini secara dinamis membatasi hak akses token tersebut hanya pada dataset atau bucket spesifik yang diizinkan untuk ID pengguna yang sedang aktif. Dengan demikian, meskipun server MCP berada di bawah kendali penuh penyerang melalui instruksi berbahaya, server tersebut secara matematis tidak memiliki otorisasi kriptografis untuk menyentuh sumber daya di luar batas sesi pengguna tersebut.

Audit Forensik & Deteksi Anomali Real-Time dengan Cloud Audit Logs

Dalam arsitektur enterprise yang diatur secara ketat (seperti perbankan dan kesehatan di Asia Tenggara), kemampuan untuk mencegah serangan harus selalu didampingi oleh visibilitas forensik yang lengkap. Ketika sebuah agen otonom mengeksekusi puluhan tool MCP dalam hitungan detik, tim SecOps membutuhkan jejak audit (audit trail) yang tidak dapat dimanipulasi (immutable) untuk menjawab pertanyaan kritis: Siapa yang memicu agen ini, parameter apa yang dikirim ke tool MCP, dan sumber daya cloud mana yang diakses?

Untuk mencapai standar observabilitas ini, setiap panggilan RPC antara Orchestrator dan server MCP wajib menyertakan header pelacakan terdistribusi traceparent (standar W3C Trace Context) serta metadata X-Agent-Invocation-ID. Di sisi Google Cloud, kita mengaktifkan Data Access Audit Logs untuk seluruh API yang berinteraksi dengan VPC Service Controls. Seluruh log telemetri ini dialirkan secara real-time melalui Cloud Pub/Sub ke BigQuery untuk dianalisis menggunakan model deteksi anomali. Jika sebuah server MCP tiba-tiba menunjukkan lonjakan panggilan storage.objects.get yang tidak lazim atau mencoba melakukan koneksi outbound ke alamat IP yang tidak dikenal (yang langsung diblokir oleh kebijakan egress VPC-SC), sistem secara otomatis memicu Cloud Functions untuk mencabut sesi token STS dan mengisolasi revisi Cloud Run tersebut dalam waktu kurang dari dua detik.

Selain itu, dalam fase transisi menuju produksi penuh, saya selalu menyarankan penerapan VPC Service Controls Dry-Run Mode terlebih dahulu selama minimal 14 hari. Mode ini memungkinkan tim SecOps dan Platform Engineering memetakan seluruh pola komunikasi jaringan dari server MCP tanpa memutus trafik produksi yang sah. Selama periode observasi tersebut, setiap pelanggaran batas perimeter dicatat secara mendetail di Cloud Logging dengan label dryRun=true, sehingga arsitek dapat memvalidasi daftar putih (allowlist) FQDN dan memastikan tidak ada ketergantungan tersembunyi terhadap repositori paket publik seperti PyPI atau npm saat kontainer dijalankan di lingkungan runtime yang terkunci rapat.

Masa Depan Eksekusi Agen

Saat kita melangkah lebih jauh ke tahun 2026, kompleksitas tugas yang kita delegasikan kepada agen AI akan terus meningkat. Model seperti gemini-3-flash-preview akan membuat pemanggilan tools menjadi sangat cepat dan murah, mendorong adopsi MCP ke tingkat yang belum pernah terjadi sebelumnya.

Namun, kecepatan dan kecerdasan tidak boleh mengorbankan keamanan. Membangun sistem agenik di production menuntut pergeseran pola pikir. Kita harus berhenti memperlakukan LLM sebagai pengguna yang dapat dipercaya, dan mulai memperlakukan mereka sebagai entitas eksternal yang berpotensi berbahaya. Dengan menggabungkan isolasi kernel gVisor, identitas layanan yang ketat, dan perimeter jaringan VPC SC, kita dapat membangun fondasi yang memungkinkan agen AI untuk bertindak secara otonom tanpa membuat para Security Engineer kita tidak bisa tidur di malam hari. Keamanan sejati dalam era AI bukan tentang membatasi apa yang bisa dilakukan oleh agen, melainkan tentang membatasi dampak dari kesalahan mereka.

Use Case Nyata di Lapangan: Ide Implementasi Praktis

Transisi dari AI eksperimental ke sistem otonom kelas produksi membutuhkan lebih dari sekadar prompt yang lebih baik; ini membutuhkan arsitektur yang memperlakukan setiap tindakan agen sebagai potensi insiden keamanan. Berikut adalah bagaimana Zero-Trust Agentic Gateways diimplementasikan saat ini untuk mendorong nilai bisnis sambil menjaga keamanan yang sangat ketat.

1. DevOps Otonom & Remediasi SRE

• Masalah Sehari-hari di Lapangan: Engineer on-call kewalahan oleh peringatan tingkat rendah (misalnya, tekanan disk, koneksi basi), yang menyebabkan burnout dan Mean Time to Recovery (MTTR) yang lambat.
• Cara Kerja Implementasinya: Agen berkemampuan MCP memantau peringatan dan memanggil tool remediate_disk_space. Agentic Gateway mencegat panggilan ini, menjalankan script pembersihan di dalam sandbox gVisor pada Cloud Run, memastikan agen tidak dapat mengakses kernel host atau melakukan pergerakan lateral ke dalam VPC.
• Dampak Nyata pada Bisnis & Sistem: Pengurangan 45% dalam MTTR untuk masalah infrastruktur umum dan isolasi 100% node produksi dari script agen yang bersifat non-deterministik.

2. FinTech: Rekonsiliasi Transaksi Otomatis

• Masalah Sehari-hari di Lapangan: Tim keuangan menghabiskan berjam-jam secara manual mencocokkan buku besar internal dengan berbagai API bank, proses yang rentan terhadap kesalahan manusia dan kebocoran data.
• Cara Kerja Implementasinya: Agen menggunakan tool MCP untuk mengambil laporan bank dan log internal. Zero-Trust Gateway menerapkan kontrol egress yang ketat (VPC Service Controls), memastikan agen hanya dapat berkomunikasi dengan endpoint bank yang telah disetujui dan tidak pernah mengeksfiltrasi data ke penyimpanan publik.
• Dampak Nyata pada Bisnis & Sistem: Siklus rekonsiliasi 90% lebih cepat dan kepatuhan SOC2/PCI-DSS yang terjamin dengan mencegah pergerakan data yang tidak sah.

3. Layanan Kesehatan: Sintesis Data Klinis & Pelaporan

• Masalah Sehari-hari di Lapangan: Dokter membutuhkan ringkasan riwayat pasien dari database yang terfragmentasi, tetapi memberikan LLM akses langsung ke PII (Informasi Identitas Pribadi) adalah risiko kepatuhan yang sangat besar.
• Cara Kerja Implementasinya: Agen memanggil tool fetch_patient_summary melalui server MCP. Gateway menerapkan Accidental Data Loss Prevention (ADLP) berbasis LLM pada respons JSON-RPC, secara otomatis menyamarkan field sensitif sebelum agen melihatnya.
• Dampak Nyata pada Bisnis & Sistem: Pengurangan 60% dalam beban administratif bagi klinisi sambil tetap mempertahankan standar privasi zero-trust untuk data kesehatan yang sensitif.

📚 Referensi Utama & Spesifikasi Keamanan

• Spesifikasi Keamanan Model Context Protocol: MCP Security Best Practices & Trust Boundaries
• Arsitektur Kernel Sandbox gVisor: gVisor Security Architecture & Syscall Interception Guide
• Identitas Layanan Cloud Run: Google Cloud Run Per-Service Identity & Least Privilege IAM
• Isolasi Perimeter VPC Service Controls: VPC Service Controls Exfiltration Prevention Overview