Sistem AI agentic multi-tenant

Last reviewed 2026-10-16 UTC

Dokumen ini memberikan arsitektur referensi untuk membantu Anda mendesain dan men-deploy sistem AI agentic multi-tenant di Google Cloud. Seiring dengan perkembangan deployment AI generatif di organisasi Anda, berbagai unit bisnis memerlukan agen AI khusus yang mengakses alat unik, mengikuti aturan operasional tertentu, dan memproses data sensitif. Unit bisnis mungkin mengembangkan silo aplikasi yang terfragmentasi dalam organisasi, yang dapat menyebabkan overhead operasional yang tinggi, kesenjangan tata kelola yang parah, dan risiko eksposur data. Arsitektur ini menunjukkan cara membangun sistem terpusat yang memungkinkan Anda memberdayakan tim terdesentralisasi dengan kemampuan AI otonom sekaligus mempertahankan keamanan dan kepatuhan terpadu.

Audiens yang dituju untuk dokumen ini mencakup arsitek, developer, dan administrator yang membangun dan mengelola sistem multi-agen tingkat perusahaan di cloud. Dokumen ini mengasumsikan bahwa Anda memiliki pemahaman dasar tentang konsep AI, ML, dan LLM, serta AI agentic.

Bagian deployment dalam dokumen ini memberikan strategi implementasi untuk membantu Anda membangun dan men-deploy sistem AI agentic multi-tenant.

Arsitektur

Diagram berikut menunjukkan arsitektur untuk sistem AI agentic multi-tenant yang mengikuti model hub-and-spoke. Model hub-and-spoke adalah desain jaringan tempat lingkungan pusat, yang dikenal sebagai hub, terhubung ke beberapa lingkungan terisolasi, yang dikenal sebagai spoke.

Arsitektur yang menunjukkan sistem AI agentic multi-tenant.

Arsitektur ini terdiri dari komponen berikut:

Kontrol Layanan VPC
Arsitektur ini menggunakan Kontrol Layanan VPC untuk mengonfigurasi perimeter layanan di tingkat organisasi. Perimeter layanan ini memberikan batas keamanan yang ketat dan membantu mencegah pemindahan data yang tidak sah.
Hub pemilihan rute

Hub pemilihan rute bertindak sebagai titik ingress pusat untuk arsitektur dan mencakup komponen berikut:

  • Load Balancer Aplikasi Eksternal: Bertindak sebagai titik ingress pusat untuk pengguna eksternal atau internal. Load balancer membantu memastikan bahwa hanya traffic yang diautentikasi dan aman yang mencapai portal frontend.
  • Google Cloud Armor dan Model Armor: Load balancer mengintegrasikan Cloud Armor dan Model Armor untuk memeriksa dan membersihkan perintah berbahaya di edge jaringan. Hub pemilihan rute menggunakan Service Extensions pada Load Balancer Aplikasi eksternal untuk mengintegrasikan Model Armor langsung ke dalam alur permintaan.
  • Identity-Aware Proxy (IAP): Menerapkan model zero-trust untuk memverifikasi identitas dan konteks pengguna sebelum permintaan apa pun mencapai aplikasi.
  • Portal frontend: Aplikasi Cloud Run serverless yang bertindak sebagai mesin perutean untuk merutekan permintaan ke project tenant terisolasi yang sesuai.
Hub tata kelola dan keamanan pusat

Hub tata kelola dan keamanan pusat adalah project Google Cloud khusus yang menyediakan Identity and Access Management (IAM), logging, pemantauan, dan keamanan terpusat untuk seluruh platform. Hub ini mencakup komponen berikut:

  • Security Command Center: Layanan yang memantau seluruh sistem AI agentic multi-tenant untuk mengetahui risiko keamanan.
  • IAM: Framework kontrol akses yang mengelola identitas dan izin di seluruh hub bersama dan project tenant. Komponen ini menyediakan tata kelola terpusat untuk semua identitas manusia dan mesin.
  • Cloud Logging: Sistem yang menggabungkan log dari hub bersama dan dari project tenant yang terisolasi ke dalam hub tata kelola dan hub keamanan pusat.
Project tenant

Setiap project tenant adalah project Google Cloud khusus untuk setiap unit bisnis. Project tenant individual adalah lingkungan terisolasi yang mencakup komponen berikut:

Alur agentic

Contoh sistem multi-tenant dalam arsitektur sebelumnya memiliki alur berikut:

  1. Permintaan pengguna dirutekan melalui Load Balancer Aplikasi eksternal. Dalam hub perutean, pemeriksaan ini diselesaikan untuk membantu memastikan bahwa hanya traffic yang diautentikasi dan aman yang mencapai portal frontend:
    1. Cloud Armor menerapkan kebijakan keamanan untuk menyerap serangan distributed denial of service (DDoS) berbasis protokol jaringan Lapisan 4 awal. Cloud Armor memeriksa permintaan dan memfilter traffic berbahaya, seperti injeksi SQL (SQLi), pembuatan skrip lintas situs (XSS), dan signature bot yang diketahui.
    2. Model Armor mencegat payload untuk mendeteksi dan menolak serangan injeksi perintah atau niat jahat.
    3. Jika salah satu lapisan ini mendeteksi ancaman atau akses yang tidak sah, load balancer akan menghentikan permintaan di edge jaringan.
    4. Jika lapisan keamanan tidak mendeteksi ancaman dan memvalidasi akses pengguna, load balancer akan merutekan traffic ke layanan backend.
  2. Jika permintaan lulus semua pemeriksaan, load balancer akan merutekan permintaan ke platform frontend, yang melakukan tindakan berikut:
    1. Mengekstrak identitas pengguna, seperti unit bisnis atau ID tenant pengguna.
    2. Menggunakan IAP untuk memverifikasi identitas perusahaan dan kesehatan perangkat pengguna.
    3. Menggunakan registry yang dikelola secara dinamis untuk mengidentifikasi tenant target yang benar.
  3. Portal frontend mengarahkan permintaan ke tenant. Untuk membantu memastikan bahwa agen tidak dapat mengakses project tenant lain atau layanan Google Cloud yang tidak sah, Agent Runtime menggunakan Kebijakan PAB untuk membatasi resource yang dapat diakses agen.
  4. Model Armor menggunakan Sensitive Data Protection untuk memeriksa dan menyamarkan secara dinamis informasi identitas pribadi (PII) atau konten yang dibatasi. Model Armor melakukan pemeriksaan tambahan untuk injeksi perintah berbahaya dari permintaan guna membantu memastikan bahwa agen hanya memproses data yang aman.

  5. Gemini melakukan tugas berikut untuk menghasilkan respons:

    1. Melakukan proses penalaran awal untuk memahami niat pengguna.
    2. Jika Gemini menentukan bahwa ia tidak memiliki fakta spesifik, Gemini akan membuat rencana untuk memanggil alat data spesifik tenant:
      1. Untuk memverifikasi apakah pengguna memiliki izin untuk mengakses resource data, agen memverifikasi identitas pengguna dan binding peran IAM.
      2. Untuk mengambil konteks, agen menjalankan panggilan alat melalui server MCP ke datastore tenant.
      3. Agen membuat respons yang berisi rujukan dengan menggabungkan logika internalnya dengan fakta khusus tenant yang baru diambil.

    Jika Gemini tidak memerlukan fakta tambahan, Gemini akan membuat respons dan mengirimkannya ke Model Armor.

  6. Model Armor memeriksa dan menyamarkan secara dinamis setiap PII atau konten yang dibatasi, lalu mengirimkan respons yang telah dibersihkan ke agen tenant. Pemeriksaan akhir ini membantu memastikan tidak ada data sensitif yang bocor dalam output.

  7. Respons dirutekan kembali ke pengguna, dari agen tenant melalui platform frontend, lalu melalui load balancer.

Produk yang digunakan

Arsitektur referensi ini menggunakan produk dan alat Google Cloud dan open source berikut, yang dipilih karena sifatnya yang serverless, skalabilitas, dan fitur keamanannya:

  • Kontrol Layanan VPC: Fungsi jaringan terkelola yang meminimalkan risiko pemindahan data yang tidak sah untuk resource Google Cloud Anda.
  • Cloud Load Balancing: Portofolio load balancer berperforma tinggi, skalabel, global, dan regional.
  • Google Cloud Armor: Layanan keamanan jaringan yang menawarkan aturan firewall aplikasi web (WAF) dan membantu melindungi dari serangan DDoS dan serangan aplikasi.
  • Model Armor: Layanan yang memberikan perlindungan untuk resource AI generatif dan agentic Anda dari injeksi perintah, kebocoran data sensitif, dan konten berbahaya.
  • Identity-Aware Proxy (IAP): Layanan yang memungkinkan model akses zero-trust untuk aplikasi dan virtual machine Anda.
  • Identity and Access Management (IAM): Sistem yang memungkinkan Anda membuat dan mengelola izin untuk resource Google Cloud .
  • Cloud Run: Platform komputasi serverless yang memungkinkan Anda menjalankan container langsung di atas infrastruktur Google yang skalabel.
  • Gemini Enterprise Agent Platform: Platform komprehensif yang memungkinkan Anda membangun, menskalakan, mengatur, dan mengoptimalkan agen AI tingkat perusahaan.
  • Gemini: Rangkaian model AI multimodal yang dikembangkan oleh Google.
  • Model Context Protocol (MCP): Standar open source untuk menghubungkan aplikasi AI ke sistem eksternal.
  • Cloud Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan pemberitahuan.

Kasus penggunaan

Sistem AI agentic multi-tenant cocok untuk organisasi perusahaan yang ingin menskalakan deployment AI generatif di luar satu aplikasi. Untuk mengidentifikasi kasus penggunaan yang sesuai dengan arsitektur ini, analisis proses bisnis Anda dan identifikasi berbagai tim yang memerlukan agen AI khusus mereka sendiri yang mengakses alat unik dan data sensitif. Pendekatan ini membantu Anda memberdayakan tim yang terdesentralisasi dengan kemampuan AI otonom sekaligus mempertahankan keamanan terpadu dan kepatuhan perusahaan.

Berikut adalah contoh kasus penggunaan untuk sistem AI agentic multi-tenant.

Layanan pelanggan di seluruh perusahaan

Anda dapat menyesuaikan arsitektur referensi ini untuk menyediakan layanan pelanggan yang didukung AI di berbagai divisi bisnis. Misalnya, untuk mendukung divisi elektronik dan divisi perlengkapan rumah tangga, Anda men-deploy agen elektronik dan agen perlengkapan rumah tangga sebagai dua agen terpisah dalam project tenant yang terpisah. Agen AI khusus ini bertindak sebagai asisten cerdas yang menangani pertanyaan dukungan khusus divisi dengan mengakses spesifikasi teknis, garansi, atau kebijakan pengembalian barang yang unik. Otomatisasi ini memungkinkan tim dukungan manusia berfokus pada eskalasi pelanggan yang lebih kompleks.

Untuk kasus penggunaan ini, arsitektur memberikan manfaat berikut:

  • Isolasi data yang ketat: Desain multi-tenant membantu memastikan bahwa pengetahuan dukungan untuk setiap divisi diisolasi secara ketat. Kebijakan PAB memberikan batasan yang membantu memastikan bahwa identitas agen di satu tenant tidak dapat mengakses data di tenant lain.
  • Pengetahuan agen khusus: Karena setiap agen berada dalam project tenant yang terisolasi, agen hanya mengambil konteks dari datastore khusus divisinya. Pengambilan yang ditargetkan ini membantu meningkatkan akurasi dan membantu mencegah agen membingungkan kebijakan unit bisnis yang berbeda.
  • Mengurangi risiko lintas domain: Arsitektur ini membantu menghilangkan risiko eksposur data antar-unit bisnis. Meskipun identitas agen disusupi, agen tidak dapat mengakses resource Google Cloud yang tidak sah.

Arsitektur ini ideal untuk organisasi dan perusahaan retail besar yang mengelola beberapa merek atau unit bisnis yang berbeda dan memerlukan kedaulatan data yang ketat.

Alternatif desain

Bagian ini menyajikan pendekatan desain alternatif yang dapat Anda pertimbangkan untuk deployment AI agentic multi-tenant di Google Cloud.

Deployment akses pribadi

Dalam arsitektur yang dijelaskan dalam dokumen ini, pengguna mengakses sistem AI agentic multi-tenant melalui internet publik melalui Load Balancer Aplikasi eksternal yang terekspos secara terpusat. Jika organisasi Anda memerlukan sistem yang tetap tidak dapat diakses dari internet publik, Anda dapat menyesuaikan arsitektur untuk menggunakan salah satu strategi akses pribadi berikut.

Memblokir traffic dengan kebijakan keamanan edge

Untuk mengizinkan traffic hanya dari alamat IP perusahaan yang diverifikasi milik organisasi Anda, Anda dapat mengonfigurasi kebijakan keamanan Cloud Armor untuk menolak traffic lainnya. Aturan keamanan berprioritas tinggi ini memblokir semua permintaan yang tidak sah di edge jaringan. Untuk lapisan keamanan tambahan, Anda dapat menggunakan IAP untuk mewajibkan sesi identitas perusahaan yang valid dan Anda dapat mengonfigurasi izin IAM untuk semua pengguna.

Pendekatan ini memungkinkan Anda memanfaatkan kebijakan keamanan edge Cloud Armor untuk mengalihkan mitigasi DDoS dan pemfilteran WAF, seperti SQLi dan XSS, serta memberikan pengalaman zero-trust. Namun, alamat IP frontend Load Balancer Aplikasi eksternal tetap publik dan mungkin tidak memenuhi persyaratan kepatuhan beberapa organisasi.

Merutekan traffic melalui Load Balancer Aplikasi internal

Arsitektur dalam dokumen ini menggunakan Load Balancer Aplikasi eksternal, yang menyediakan kebijakan Cloud Armor yang kuat, fitur keamanan yang lebih canggih, dan kompleksitas operasional yang lebih rendah dibandingkan dengan load balancer internal. Namun, penggunaan load balancer eksternal berarti traffic melintasi internet publik.

Agar traffic tetap berada sepenuhnya dalam jaringan Google pribadi, Anda dapat menggunakan Load Balancer Aplikasi internal. Penggunaan Load Balancer Aplikasi internal mendukung IAP untuk verifikasi identitas. Load Balancer Aplikasi eksternal global mengevaluasi kebijakan IAP di lapisan edge. Sebaliknya, Load Balancer Aplikasi internal mengevaluasi kebijakan di lapisan jaringan internal. Karena traffic tidak pernah melewati internet publik, penggunaan Load Balancer Aplikasi internal membantu Anda memenuhi persyaratan kedaulatan data yang ketat dan persyaratan alamat IP publik nol.

Untuk mempertahankan latensi rendah dan mematuhi persyaratan residensi data regional, deploy Load Balancer Aplikasi internal regional di setiap region utama. Dengan Load Balancer Aplikasi internal regional, Anda merutekan traffic dari lingkungan lokal melalui Cloud Interconnect atau melalui Cloud VPN langsung ke alamat IP internal load balancer. Load Balancer Aplikasi internal regional mendukung Cloud Armor regional untuk perlindungan WAF internal. Namun, dibandingkan dengan Load Balancer Aplikasi eksternal, Load Balancer Aplikasi internal regional mendukung serangkaian kebijakan keamanan Cloud Armor yang terbatas, tidak memiliki fitur keamanan lanjutan, dan meningkatkan kompleksitas operasional.

Untuk lebih meminimalkan latensi dan membantu memastikan ketersediaan tinggi guna memenuhi persyaratan disaster recovery, Anda dapat men-deploy Load Balancer Aplikasi internal lintas region. Dengan Load Balancer Aplikasi internal lintas region, Anda menggunakan Cloud DNS dengan kebijakan pemilihan rute geolokasi untuk me-resolve URL internal aplikasi ke Load Balancer Aplikasi internal lintas region di regionGoogle Cloud yang terdekat dengan pengguna. Namun, konfigurasi lintas region tidak mendukung integrasi Cloud Armor.

Infrastruktur komputasi

Untuk memprioritaskan pendekatan serverless-first yang memberikan pengelolaan yang lebih mudah dan overhead operasional yang lebih rendah, arsitektur dalam dokumen ini menggunakan Cloud Run untuk infrastruktur komputasinya. Anda juga dapat menjalankan aplikasi dalam container di cluster GKE. Google Kubernetes Engine (GKE) adalah mesin orkestrasi container yang mengotomatiskan deployment, penskalaan, dan pengelolaan aplikasi dalam container. GKE sepenuhnya mendukung Load Balancer Aplikasi internal dan eksternal. Untuk mengetahui informasi tentang cara memilih layanan komputasi untuk workload Anda di Google Cloud, lihat Menghosting Aplikasi diGoogle Cloud.

Server MCP lokal dan bersama

Agar komponen sistem agentic Anda dapat berinteraksi, Anda perlu menetapkan protokol komunikasi yang jelas. MCP adalah protokol terbuka yang menyediakan antarmuka standar bagi agen untuk mengakses dan menggunakan alat, data, dan layanan lain yang diperlukan.

Untuk menghubungkan agen tenant ke datastore, pertimbangkan persyaratan aplikasi Anda untuk memilih dari opsi deployment server MCP berikut. Saat Anda memilih antara deployment MCP lokal dan bersama, pertimbangkan kompromi antara isolasi data dan efisiensi operasional.

  • Server MCP lokal: Server MCP lokal, atau server MCP khusus tenant, adalah server MCP yang Anda deploy dalam setiap project tenant dan yang memberi agen akses ke datastore dan alat yang khusus untuk unit bisnis tersebut.

    Berikut adalah fitur dan pertimbangan utama untuk server MCP lokal:

    • Jaringan: Perimeter Kontrol Layanan VPC level project dan Kebijakan PAB memberikan keamanan dan isolasi yang melekat, yang membantu memastikan tidak ada akses lintas tenant.
    • Pengelolaan: Setiap tim developer dan operasi mengelola project tenant secara independen. Isolasi ini memberikan otonomi untuk setiap unit bisnis.
    • Keamanan: Batas IAM tetap dari project tenant membantu meminimalkan permukaan risiko lateral dan tidak memerlukan pemetaan identitas yang kompleks.

    Server MCP lokal menawarkan isolasi maksimum dan dapat menangani akses data yang sangat sensitif atau diatur. Namun, jika Anda men-deploy beberapa server MCP lokal, beban operasional Anda akan meningkat. Sebaiknya gunakan server MCP lokal untuk aplikasi yang memerlukan akses ketat ke datastore yang mungkin berisi informasi sensitif.

  • Server MCP bersama: Server MCP bersama, atau server MCP global, adalah server MCP yang Anda deploy dalam project layanan bersama. Server MCP bersama menyediakan akses ke alat dan sistem yang umum di beberapa tenant.

    Berikut adalah fitur dan pertimbangan utama untuk server MCP bersama:

    • Jaringan: Untuk membantu memastikan bahwa traffic tidak melintasi internet publik, server MCP bersama memerlukan konektivitas pribadi, seperti Private Service Connect atau Peering Jaringan VPC.
    • Pengelolaan: Tim operasi terpusat mengelola implementasi untuk seluruh sistem. Pengelolaan gabungan ini mengoptimalkan efisiensi operasional dan menghilangkan persyaratan untuk menduplikasi implementasi lokal di beberapa tenant.
    • Keamanan: Anda menyebarkan identitas pengguna akhir dengan aman dari agen di project tenant ke server MCP bersama. Untuk membantu memastikan bahwa pengguna hanya dapat mengakses atau mengubah data yang diizinkan, server MCP bersama menggunakan identitas pengguna yang disebarkan untuk menerapkan kontrol akses terperinci pada sistem backend.

    Server MCP bersama memusatkan pengelolaan untuk alat umum, sehingga mengurangi duplikasi dan mengoptimalkan efisiensi operasional. Meskipun server MCP bersama mengurangi beban pengelolaan, server tersebut memerlukan logika propagasi dan otorisasi identitas yang kuat untuk menjaga akses yang aman. Sebaiknya gunakan server MCP bersama untuk interaksi dengan sistem dan alat perusahaan umum, seperti alat pelaporan pengeluaran, sistem sumber daya manusia (SDM), pusat informasi di seluruh perusahaan, atau pengelola kehadiran.

Dalam arsitektur ini, Anda menggunakan server MCP untuk menstandarkan koneksi antara agen tenant dan datastore Anda. Bergantung pada persyaratan workload, Anda dapat menggunakan jenis alat agen lain untuk menghubungkan agen dengan API dan sistem eksternal tertentu. Untuk mengetahui informasi selengkapnya tentang interaksi alat agen, lihat Alat agen.

Pertimbangan desain

Bagian berikut menjelaskan faktor desain, praktik terbaik, dan rekomendasi yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan spesifik Anda terkait keamanan, keandalan, biaya, dan performa. Panduan di bagian ini tidak lengkap. Bergantung pada persyaratan workload serta produk dan fitur yang Anda gunakan, mungkin ada faktor desain dan konsekuensi tambahan yang harus Anda pertimbangkan.

Keamanan, privasi, dan kepatuhan

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk mendesain topologi di Google Cloud yang memenuhi persyaratan keamanan, privasi, dan kepatuhan workload Anda.

Pertimbangan keamanan untuk agen

Agen AI menimbulkan risiko keamanan unik dan kritis tertentu yang mungkin tidak dapat dimitigasi secara memadai oleh praktik keamanan deterministik konvensional. Google merekomendasikan pendekatan untuk agen AI yang aman yang menggabungkan kekuatan kontrol keamanan deterministik dengan pertahanan dinamis berbasis penalaran. Pendekatan ini didasarkan pada tiga prinsip inti: pengawasan manusia, otonomi agen yang ditentukan dengan cermat, dan kemampuan observasi. Berikut adalah rekomendasi spesifik yang selaras dengan prinsip-prinsip inti ini:

  • Pengawasan manusia: Sistem AI agentic terkadang dapat gagal atau mungkin tidak berfungsi seperti yang diharapkan. Misalnya, model mungkin menghasilkan konten yang tidak akurat atau agen mungkin memilih alat yang tidak sesuai. Dalam sistem AI agentic yang penting bagi bisnis, sertakan alur human-in-the-loop agar pengawas manusia dapat memantau, mengganti, dan menjeda agen. Misalnya, pengguna manusia dapat meninjau output agen, menyetujui atau menolak output, dan memberikan panduan lebih lanjut untuk memperbaiki error atau membuat keputusan strategis. Pendekatan ini menggabungkan efisiensi sistem AI agen dengan pemikiran kritis dan keahlian domain pengguna manusia.
  • Identitas agen dan akses dengan hak istimewa terendah:
    • Berikan identitas berbasis SPIFFE yang terikat workload kepada setiap agen menggunakan Identitas Agen. Anda dapat menggunakan Identitas Agen saat men-deploy agen ke Agent Runtime atau ke Cloud Run.
    • Konfigurasikan izin per agen menggunakan kebijakan akses IAM dan kontrol akses Agent Platform dengan IAM. Berikan setiap agen hanya izin yang diperlukan untuk melakukan tugasnya dan untuk berkomunikasi dengan alat dan dengan agen lain. Untuk mengisolasi lebih lanjut setiap agen dan membatasi potensi dampak pelanggaran keamanan, ikat Kebijakan PAB ke identitas agen.
    • Jika agen perlu melakukan autentikasi ke alat eksternal atau ke API pihak ketiga, gunakan pengelola autentikasi Agent Identity. Dengan pendekatan ini, Anda dapat mengontrol token OAuth dan kunci API secara terpusat, bukan harus menyematkan kredensial dalam kode atau perintah agen.

  • Tata kelola traffic ingress dan egress: Rutekan traffic agen melalui Agent Gateway untuk menerapkan kebijakan keamanan runtime di batas ingress dan egress. Untuk mengetahui informasi tentang platform runtime yang mendukung Gateway Agen, lihat Runtime agen yang didukung.

    • Klien ke Agen (ingress): Deploy Agent Gateway di depan runtime agen Anda. Gateway membantu mengautentikasi pemanggil dan memeriksa perintah masuk secara real time menggunakan Model Armor.

    • Agen-ke-Mana Saja (egress):

      • Merutekan permintaan keluar agen ke agen (A2A) dan agen ke alat (MCP) melalui Agent Gateway dalam mode egress.
      • Terapkan kebijakan akses tolak default menggunakan kebijakan akses IAM dan IAP.
      • Pastikan agen dan alat target terdaftar di Agent Registry.
      • Periksa pemanggilan dan respons alat keluar dengan Model Armor untuk membantu mencegah pemindahan data yang tidak sah, injeksi perintah tidak langsung, dan penyalahgunaan alat.

  • Pemantauan: Pantau perilaku agen menggunakan kemampuan pelacakan komprehensif yang memberi Anda visibilitas tentang setiap tindakan yang dilakukan agen, termasuk proses penalaran, pemilihan alat, dan jalur eksekusi. Untuk mengetahui informasi selengkapnya, lihat Logging agen di Agent Runtime dan Logging di ADK.

Untuk mengetahui informasi selengkapnya tentang cara mengamankan agen AI, lihat Keamanan dan Keselamatan untuk Agen AI.

Pertimbangan keamanan Virtual Private Cloud (VPC)

Dalam arsitektur ini, Anda men-deploy setiap tenant dalam projectGoogle Cloud khusus. Untuk membuat batas keamanan yang ketat, gabungkan isolasi level project tenant dengan Kebijakan PAB dan Kontrol Layanan VPC di level organisasi.

Pertimbangan keamanan IAM

Untuk menerapkan prinsip hak istimewa terendah, gunakan model akses berbasis persona. Misalnya, Anda dapat menentukan peran IAM kustom untuk membantu memastikan bahwa developer yang membangun agen di satu tenant tidak dapat mengakses data di tenant lain.

Pertimbangan keamanan Cloud Armor

Cloud Armor memberikan keamanan dan perlindungan WAF untuk melindungi portal frontend dari serangan DDoS dan kerentanan web. Load Balancer Aplikasi eksternal global mendukung rangkaian lengkap fitur edge lanjutan, seperti pengelolaan bot dan Perlindungan Adaptif Google Cloud Armor.

Jika Anda men-deploy Load Balancer Aplikasi internal regional, Cloud Armor akan beroperasi dengan serangkaian kebijakan WAF standar yang terbatas. Kumpulan kebijakan yang dibatasi disesuaikan untuk batas jaringan internal dan mencakup kebijakan seperti perlindungan SQLi dan XSS. Untuk mengetahui informasi selengkapnya, lihat Mengintegrasikan Cloud Armor dengan produk Google lainnya.

Pertimbangan keamanan Agent Platform

Untuk membantu memastikan bahwa konfigurasi dan penggunaan Agent Platform Anda memenuhi persyaratan keamanan, pertimbangkan rekomendasi berikut:

  • Tanggung jawab bersama: Keamanan adalah tanggung jawab bersama. Agent Platform mengamankan infrastruktur yang mendasarinya serta menyediakan alat dan kontrol keamanan untuk membantu Anda melindungi data, kode, dan model Anda. Anda bertanggung jawab untuk mengonfigurasi layanan dengan benar, mengelola kontrol akses, dan mengamankan aplikasi Anda. Untuk mengetahui informasi selengkapnya, lihat Tanggung jawab bersama Agent Platform.
  • Kontrol keamanan: Agent Platform mendukung Google Cloud kontrol keamanan yang dapat Anda gunakan untuk memenuhi persyaratan residensi data, kunci enkripsi yang dikelola pelanggan (CMEK), keamanan jaringan menggunakan Kontrol Layanan VPC, dan Transparansi Akses. Untuk informasi selengkapnya, lihat dokumentasi berikut:
  • Keamanan: Model AI mungkin menghasilkan respons yang berbahaya, terkadang sebagai respons terhadap perintah berbahaya.
    • Untuk meningkatkan keamanan dan memitigasi potensi penyalahgunaan sistem AI agentic, Anda dapat mengonfigurasi filter konten untuk bertindak sebagai penghalang terhadap input dan respons yang berbahaya. Untuk mengetahui informasi selengkapnya, lihat Filter keamanan dan konten.
    • Untuk memeriksa dan membersihkan permintaan inferensi, perintah agen, panggilan alat, dan respons terhadap ancaman seperti injeksi perintah dan konten berbahaya, Anda dapat menggunakan Model Armor untuk panggilan API model langsung dan untuk permintaan yang dirutekan melalui Agent Gateway. Model Armor membantu Anda mencegah input berbahaya, memverifikasi keamanan konten, melindungi data sensitif, menjaga kepatuhan, serta menerapkan kebijakan keselamatan dan keamanan secara konsisten.
  • Akses model: Anda dapat menyiapkan kebijakan organisasi untuk membatasi jenis dan versi model AI yang dapat digunakan dalam project Google Cloud . Untuk mengetahui informasi selengkapnya, lihat Mengontrol akses ke model Model Garden.
  • Perlindungan data: Untuk menemukan dan melakukan de-identifikasi data sensitif dalam perintah dan respons serta dalam data log, gunakan Cloud Data Loss Prevention API. Untuk mengetahui informasi selengkapnya, tonton video ini: Melindungi data sensitif di aplikasi AI.

  • Endpoint model bersama: Untuk membantu mencegah penyalahgunaan dan memastikan penggunaan yang adil untuk endpoint model bersama, terapkan salah satu strategi berikut:

    • Pembatasan kapasitas tingkat tenant: Menerapkan kuota di portal frontend untuk setiap tenant sebelum permintaan mencapai endpoint bersama. Terapkan kuota dengan melakukan hal berikut:

      1. Ekstrak identitas tenant dari konteks IAP.
      2. Lacak penggunaan terhadap batas yang telah ditentukan untuk setiap tenant menggunakan penyimpanan eksternal seperti Memorystore for Redis.
      3. Menolak permintaan dari tenant yang melebihi batasnya.

    • Gateway API: Untuk menerapkan kuota per tenant menggunakan kunci API dan paket penggunaan, terapkan Gateway API sebelum endpoint bersama.

Pertimbangan keamanan MCP

Untuk membantu memastikan bahwa implementasi MCP Anda memenuhi persyaratan keamanan, pertimbangkan rekomendasi berikut:

  • Pendaftaran dan penemuan alat: Daftarkan server dan alat MCP di Agent Registry agar agen hanya terhubung ke endpoint MCP yang diinventarisasi dan disetujui administrator.
  • Kontrol akses dan pemeriksaan traffic: Rutekan traffic agen ke MCP melalui Agent Gateway dalam mode Agent-to-Anywhere (egress) dan lindungi server MCP (seperti server MCP yang dihosting di Cloud Run) menggunakan IAP dan kebijakan akses IAM. Konfigurasikan Model Armor atau kebijakan tata kelola semantik di Agent Gateway untuk memeriksa input dan output alat MCP guna mendeteksi eksposur data sensitif dan injeksi perintah tidak langsung.
  • Keamanan MCP umum: Saat Anda mengonfigurasi agen untuk menggunakan MCP, pastikan akses ke data dan alat eksternal diizinkan, terapkan kontrol privasi seperti enkripsi, terapkan filter untuk melindungi data sensitif, dan pantau interaksi agen. Untuk mengetahui informasi selengkapnya, lihat MCP dan keamanan.

Pertimbangan keamanan Cloud Run

Untuk meningkatkan postur keamanan portal frontend, prioritaskan rendering sisi server (SSR) daripada rendering sisi klien (CSR). Dibandingkan dengan CSR, SSR menawarkan manfaat berikut:

  • Menjalankan logika aplikasi dan mengelola secret dalam lingkungan Google Cloud yang terkontrol.
  • Mengurangi permukaan serangan sisi klien dan membantu mencegah kebocoran data sensitif ke browser pengguna yang tidak tepercaya.
  • Membatasi eksposur data dengan hanya mengirimkan HTML yang diperlukan ke klien.
  • Menyediakan encoding output terpusat untuk bertahan dari serangan pembuatan skrip lintas situs (XSS).

Pertimbangan keamanan Security Command Center

Untuk memantau ancaman dan menerapkan kebijakan keamanan seperti autentikasi multi-faktor (MFA) dan enkripsi data, gunakan alat di Security Command Center.

Rekomendasi keamanan lainnya

Keandalan

Bagian ini menjelaskan pertimbangan dan rekomendasi desain untuk membangun dan mengoperasikan infrastruktur yang andal untuk deployment Anda di Google Cloud.

Pertimbangan keandalan Cloud Load Balancing

Load Balancer Aplikasi eksternal global menyediakan satu alamat IP Anycast yang secara otomatis merutekan traffic pengguna ke edge Google geografis terdekat. Konfigurasi ini mengurangi latensi melalui penghentian Secure Sockets Layer (SSL) edge. Layanan ini juga membantu memastikan ketersediaan tinggi jika suatu region mengalami pemadaman layanan karena layanan ini mengalihkan traffic secara cerdas ke backend regional yang responsif.

Pertimbangan keandalan tenant

Untuk menoleransi atau menangani kegagalan di level agen, deploy agen di project tenant yang terisolasi. Isolasi ini membantu memastikan bahwa masalah operasional atau insiden keamanan tetap berada dalam satu unit bisnis dan tidak memengaruhi resource atau unit bisnis lain.

Pertimbangan keandalan Agent Platform

Jika jumlah permintaan ke model melebihi kapasitas yang dialokasikan, model akan menampilkan kode error 429. Untuk workload yang penting bagi bisnis dan memerlukan throughput yang tinggi secara konsisten, Anda dapat memesan throughput menggunakan Throughput yang Disediakan.

Pertimbangan keandalan Agent Runtime

Untuk membantu memastikan bahwa konfigurasi dan penggunaan Agent Runtime Anda memenuhi persyaratan keandalan, pertimbangkan rekomendasi berikut:

  • Skalabilitas serverless: Agen yang di-deploy di Agent Runtime diskalakan secara independen berdasarkan permintaan. Lonjakan penggunaan yang tiba-tiba di satu tenant tidak akan menghabiskan resource komputasi atau memengaruhi ketersediaan agen di project tenant lain.
  • Penanganan error: Untuk menangani error sementara seperti batas kapasitas kode error 429, logika orkestrasi agen menggunakan backoff eksponensial. Jika batas waktu konteks terlampaui, agen akan melakukan penghentian normal dan melaporkan progres parsial kembali kepada pengguna. Misalnya, batas waktu konteks dapat terlampaui karena panggilan alat yang lambat, latensi API pihak ketiga, pemrosesan set data yang sangat besar, atau pemrosesan yang memerlukan komputasi intensif.

Untuk prinsip dan rekomendasi keandalan yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keandalan dalam Framework Arsitektur yang Baik.

Efisiensi operasional

Bagian ini menjelaskan faktor yang perlu dipertimbangkan saat Anda menggunakan arsitektur referensi ini untuk mendesain topologi Google Cloud yang dapat Anda operasikan secara efisien.

Pertimbangan Google Cloud Observability

Logging dan Cloud Monitoring memungkinkan Anda memantau kesehatan dan performa seluruh platform. Anda dapat menyiapkan pemberitahuan untuk mendeteksi dan memecahkan masalah secara proaktif tanpa mengizinkan akses ke data sensitif.

Pertimbangan efisiensi operasional untuk semua produk dalam arsitektur

Menggunakan Agent Platform dalam pola arsitektur tenant yang terstandardisasi memungkinkan Anda menetapkan dasar pengukuran yang konsisten saat melakukan orientasi tenant baru. Untuk mengurangi beban operasional, otomatiskan proses deployment menggunakan alat Infrastructure as Code (IaC) seperti Terraform. Untuk kode Terraform yang dapat Anda gunakan untuk membangun dan men-deploy sistem AI agentic multi-tenant, lihat bagian Deployment dalam dokumen ini.

Untuk prinsip dan rekomendasi keunggulan operasional yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keunggulan operasional dalam Well-Architected Framework.

Pengoptimalan biaya

Bagian ini berisi panduan untuk mengoptimalkan biaya penyiapan dan pengoperasian topologi Google Cloud yang Anda bangun menggunakan arsitektur referensi ini.

Pertimbangan biaya Agent Platform

Untuk membantu memastikan bahwa konfigurasi dan penggunaan Agent Platform Anda memenuhi persyaratan biaya, pertimbangkan rekomendasi berikut:

  • Konsumsi token: Untuk mengelola biaya dan mencegah model AI Anda melampaui jendela konteks, gunakan strategi berikut untuk mengelola konteks model AI:
    • Peringkasan konteks: Alih-alih menyimpan seluruh percakapan sesi sebagai konteks, gunakan model AI untuk meringkas percakapan lama dan informasi yang kurang penting.
    • Pangkas output: Identifikasi dan hapus bagian yang kurang relevan atau panjang dari output alat atau konteks yang diambil. Misalnya, jika Anda hanya memerlukan nama kolom dari data, Anda dapat menghapus metadata yang berlebihan dari pengambilan skema database. Strategi ini memerlukan logika kustom yang menggunakan heuristik, pemfilteran, atau model bahasa kecil (SLM) untuk mengekstrak informasi yang paling penting.
    • Batas token maksimum: Untuk membantu mencegah loop tanpa batas dan membantu mengontrol biaya, terapkan batas token maksimum sesi.

  • Endpoint model: Untuk mengelola kuota API dan pemanfaatan resource, Anda dapat men-deploy endpoint Agent Platform dalam konfigurasi khusus atau konfigurasi bersama:

    • Endpoint khusus: Saat men-deploy endpoint dalam setiap project tenant, Anda memberikan isolasi kuota yang melekat. Penggunaan setiap tenant dihitung berdasarkan kuota project-nya sendiri, sehingga mencegah dampak antar-tenant. Dibandingkan dengan endpoint bersama, endpoint khusus menawarkan pengelolaan kuota yang lebih sederhana. Namun, endpoint khusus mencegah Anda memanfaatkan potensi penghematan biaya dari endpoint bersama.
    • Endpoint bersama: Untuk mengoptimalkan biaya, Anda dapat menghosting endpoint bersama di hub tata kelola dan keamanan pusat. Karena semua tenant menggunakan kumpulan kuota yang sama, untuk membantu mencegah serangan berbahaya, Anda harus menerapkan strategi mitigasi seperti pembatasan kapasitas tingkat tenant atau penerapan kuota dengan Gateway API. Dibandingkan endpoint khusus, endpoint bersama lebih hemat biaya. Namun, endpoint bersama memerlukan upaya engineering tambahan dan dapat menimbulkan latensi serta overhead pengelolaan.

    Untuk mengetahui informasi tentang biaya di Agent Platform, lihat Biaya membangun dan men-deploy model AI di Agent Platform.

Pertimbangan biaya Cloud Run

Instrumentasi memungkinkan Anda memantau performa, memecahkan masalah, dan melacak penggunaan resource untuk setiap tenant. Untuk mengidentifikasi tenant untuk setiap permintaan, ekstrak identitas pengguna dari konteks yang disediakan IAP. Untuk mengetahui informasi tentang cara menginstrumentasikan aplikasi Anda, lihat Memilih pendekatan instrumentasi.

Pertimbangan biaya Model Armor

Untuk menerapkan tata kelola yang ketat dan postur zero-trust, arsitektur ini men-deploy Model Armor di dua lapisan: di hub perutean dan dalam setiap project tenant. Meskipun pendekatan dua lapis ini membantu memastikan kedaulatan data, pendekatan ini meningkatkan latensi dan biaya operasional. Untuk mengurangi biaya dan kompleksitas sistem, filter semua perintah dan respons dengan men-deploy Model Armor secara eksklusif di hub perutean.

Pertimbangan biaya untuk semua produk dalam arsitektur

Untuk membantu memastikan bahwa arsitektur Anda memenuhi persyaratan biaya, pertimbangkan rekomendasi umum berikut:

  • Infrastruktur bersama: Komponen infrastruktur inti bersama, seperti portal frontend, hub keamanan dan tata kelola pusat, serta Agent Platform, dapat mengurangi biaya dibandingkan saat Anda membangun stack kustom terpisah untuk setiap agen.

  • Overhead platform: Untuk mendistribusikan biaya bersama dari hub keamanan dan tata kelola pusat, gunakan model alokasi yang sesuai dengan kemampuan pelacakan dan pola penggunaan Anda. Sebaiknya gunakan salah satu model alokasi biaya berikut:

    • Alokasi pembagian merata: Model pembagian merata mengalokasikan biaya bersama secara merata ke semua tenant. Gunakan model ini jika platform adalah utilitas dasar pengukuran atau jika overhead pelacakan terperinci lebih besar daripada manfaat biaya.
    • Alokasi proporsional: Model proporsional, atau proses penagihan balik, mengalokasikan biaya bersama berdasarkan proporsi biaya langsung yang dikeluarkan oleh setiap tenant. Gunakan model ini jika konsumsi tenant sangat bervariasi dan Anda memiliki telemetri yang kuat, seperti label Resource Manager dan penguraian log, untuk mengatribusikan biaya secara akurat.
    • Alokasi tetap: Model tetap, atau bertingkat, mengalokasikan biaya bersama berdasarkan koefisien yang ditentukan bisnis. Gunakan model ini jika tenant memerlukan perjanjian tingkat layanan (SLA) yang berbeda. Alokasi model tetap memungkinkan Anda mengenakan tarif tetap untuk kemampuan khusus premium dibandingkan kemampuan bersama standar.

    Untuk mengetahui informasi selengkapnya tentang cara mengalokasikan biaya layanan bersama, lihat Cloud FinOps: Alokasi biaya layanan bersama.

  • Pengelolaan biaya terpusat: Untuk melacak total biaya kepemilikan (TCO) sistem AI agentic Anda secara akurat dan mengatribusikan biaya ke masing-masing unit bisnis, gunakan label dan data ekspor Penagihan Cloud. Untuk mengetahui informasi selengkapnya tentang cara menggunakan label untuk kesadaran biaya, lihat Mendorong budaya kesadaran biaya.

Untuk memperkirakan biaya resource Google Cloud Anda, gunakan Kalkulator HargaGoogle Cloud .

Untuk prinsip dan rekomendasi pengoptimalan biaya yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Pengoptimalan biaya dalam Well-Architected Framework.

Deployment

Untuk men-deploy arsitektur referensi ini, gunakan contoh Terraform AI agentic multi-tenant yang tersedia di GitHub.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: