Memecahkan masalah konektivitas Agent Gateway

Panduan ini membantu Anda men-debug dan memecahkan masalah konektivitas dengan Gemini Enterprise Agent Platform, terutama saat Anda menggunakan Agent Gateway, Agent Identity, kebijakan Identity and Access Management (IAM), dan otorisasi yang didelegasikan dengan Service Extensions.

Memecahkan masalah menggunakan keterampilan Pemecahan Masalah Agent Platform

Untuk mendiagnosis masalah konektivitas, otorisasi, dan startup secara interaktif dengan asisten coding AI, Anda dapat menginstal kemampuan agent-platform-troubleshooting dari repositori Kemampuan Agen Cloud de Confiance by S3NS .

Keterampilan ini membekali agen AI dengan playbook diagnostik khusus domain, filter log, dan langkah-langkah penyelesaian di seluruh stack Agent Platform, termasuk:

  • Penolakan egress Agent Gateway: Mendiagnosis error 403 Forbidden yang dicegat oleh gateway dan memverifikasi keputusan otorisasi IAP.
  • Kegagalan startup Agent Runtime: Mengidentifikasi peran yang tidak ada (seperti roles/browser atau resourcemanager.projects.get) dan pengecualian bootstrap.
  • Masalah tujuan Agent Registry: Memverifikasi entri layanan, antarmuka endpoint, dan konfigurasi Google API gabungan.
  • Kebijakan akses IAM: Memvalidasi binding Unified Access Policy (UAP), ekspresi kondisi, dan cakupan Principal Access Boundary (PAB).
  • Kepercayaan container: Mendiagnosis error sertifikat TLS dan handshake untuk container kustom (BYOC) atau Certificate Authority (CA) pribadi.

Untuk menginstal skill di lingkungan agen Anda, jalankan perintah berikut:

npx skills add https://github.com/google/skills --skill agent-platform-troubleshooting

Alur permintaan egress

Agent Platform menerapkan kebijakan tolak default untuk semua traffic keluar. Agar agen dapat terhubung ke resource eksternal, Anda harus mengizinkan akses secara eksplisit di setiap lapisan jaringan dan identitas. Saat Agent Gateway diaktifkan, gateway akan mencegat semua permintaan dari agen dan menerapkan kebijakan yang dikonfigurasi.

Agar permintaan berhasil, permintaan tersebut harus memenuhi semua kondisi berikut:

  • Kebijakan Akses IAM: Identitas agen yang ditetapkan ke agen harus diberi izin iap.resources.egressViaIAP pada resource tujuan, baik secara langsung maupun melalui set akun utama. Untuk mengetahui detailnya, lihat Membuat kebijakan agen IAM. Pelajari cara Memecahkan masalah kebijakan IAP.
  • Agent Registry: Sebaiknya daftarkan tujuan di Agent Registry untuk menerapkan kebijakan akses per resource yang terperinci dan kontrol tingkat alat. Jika agen mencoba menjangkau tujuan yang tidak terdaftar, Anda harus memberikan izin iap.resources.egressViaIAP ke identitas agen dengan mengonfigurasi kebijakan untuk endpoint yang tidak terdaftar.
  • Agent Gateway: Gateway harus dikaitkan dengan kebijakan otorisasi yang secara eksplisit menargetkannya. Secara default, gateway menggunakan IAP dan Model Armor untuk mengamankan permintaan.
  • Otorisasi yang didelegasikan dengan Service Extensions: Anda dapat mendelegasikan keputusan otorisasi ke mesin otorisasi kustom menggunakan Service Extensions. Bergantung pada kebijakan otorisasi yang dikonfigurasi, satu atau beberapa mesin otorisasi ini akan mengizinkan atau menolak permintaan.

Masalah umum

Tinjau masalah umum dan solusinya berikut saat memecahkan masalah Agent Gateway.

Error selama memulai Agent Runtime

Jika instance Agent Runtime Anda gagal dimulai atau di-deploy, hal ini mungkin berarti IAP memblokir traffic internal atau agen Anda tidak memiliki peran dasar yang diperlukan untuk melakukan inisialisasi.

  1. Mengonfirmasi bahwa IAP tidak memblokir panggilan ke layanan internal

    Gejala: Error 403 Forbidden saat memulai.

    Penyebab: Agent Gateway menggunakan kebijakan penolakan default untuk semua traffic. Oleh karena itu, saat IAP dalam mode penerapan, IAP akan memblokir panggilan bahkan ke layanan internal (seperti aiplatform atau logging) kecuali jika layanan tersebut terdaftar dan agen memiliki izin IAM yang diperlukan.

    Perbaikan: Alihkan IAP ke mode uji coba untuk sementara guna melihat koneksi mana yang gagal tanpa memblokir startup, atau kueri Cloud Logging untuk mengidentifikasi nama host yang diblokir secara tepat. Setelah Anda mengidentifikasi nama host layanan target, daftarkan nama host tersebut di Agent Registry dan berikan izin iap.resources.egressViaIAP kepada agen.

    Untuk menemukan nama host tertentu yang diblokir menggunakan Cloud Logging, jalankan kueri berikut di Logs Explorer:

    resource.type="networkservices.googleapis.com/Gateway"
resource.labels.gateway_type="SECURE_WEB_GATEWAY"
httpRequest.status=403

    Periksa kolom httpRequest.requestUrl atau jsonPayload.authzPolicyInfo dalam hasil untuk menemukan nama host tujuan.

    Layanan internal umum yang mungkin memerlukan pendaftaran selama startup meliputi:

    • Agent Platform (Mesin Inferensi dan Sesi): https://REGION-aiplatform.mtls.googleapis.com
    • Resource Manager: https://cloudresourcemanager.mtls.googleapis.com dan https://cloudresourcemanager.mtls.googleapis.com/
    • Google Cloud Observability (jika diaktifkan): https://telemetry.mtls.googleapis.com/
    • Cloud Logging (jika diaktifkan): https://logging.googleapis.com/
    • Cloud Monitoring: https://monitoring.googleapis.com/ dan https://monitoring.mtls.googleapis.com/
    • Cloud Trace: https://cloudtrace.googleapis.com/ dan https://cloudtrace.mtls.googleapis.com/
    • Secret Manager: https://secretmanager.googleapis.com/ dan https://secretmanager.mtls.googleapis.com/

  2. Pastikan identitas agen memiliki peran dasar yang diperlukan

    Gejala: Dalam log aiplatform.googleapis.com/reasoning_engine_stderr, Anda melihat error seperti google.api_core.exceptions.Unknown: None atau Failed to convert project number to project ID. Error muncul selama startup Reasoning Engine.

    Penyebab. Identitas agen tidak memiliki izin resourcemanager.projects.get yang diperlukan untuk menyelesaikan nama project selama inisialisasi.

    Perbaiki. Pastikan identitas agen (atau set utamanya) memiliki izin yang diperlukan untuk membaca konfigurasi runtime-nya sendiri. Peran berikut diperlukan:

    • roles/aiplatform.agentDefaultAccess: Peran agen default.
    • roles/aiplatform.user: Diperlukan untuk menjalankan agen.
    • roles/agentregistry.viewer: Diperlukan untuk melihat resource terdaftar.
    • roles/logging.logWriter dan roles/monitoring.metricWriter: Diperlukan untuk kemampuan observasi.
    • roles/browser: Diperlukan untuk menjalankan resourcemanager.projects.get selama inisialisasi SDK.

    Untuk memverifikasi peran yang ditetapkan ke identitas agen, jalankan perintah berikut:

    gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \
--filter="bindings.members:AGENT_IDENTITY_PRINCIPAL"

    Ganti kode berikut:

    • PROJECT_ID: Project ID Cloud de Confiance Anda.
    • AGENT_IDENTITY_PRINCIPAL: Akun utama identitas agen. Menggunakan format: principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

    Untuk mempelajari cara memberikan peran, lihat Menggunakan Agent Identity dengan Agent Runtime.

403 Forbidden error

Jika Anda mengalami error 403 Forbidden, pastikan error tersebut terkait dengan keluar dari Agent Gateway. Berikut adalah contoh pesan error egress:

{"code": 403, "message": "403 Forbidden. {'message': 'Egress request is not authorized.', 'status': 'Forbidden'}"}

Kueri log agen di Logging untuk menemukan panggilan spesifik yang gagal:

resource.type="aiplatform.googleapis.com/ReasoningEngine"
resource.labels.location="LOCATION"
resource.labels.reasoning_engine_id="AGENT_ID"
textPayload:"403"

Ganti kode berikut:

  • LOCATION: Region tempat agen di-deploy, misalnya, us-central1.
  • AGENT_ID: ID agen (Reasoning Engine).

Cari pesan Egress request is not authorized di textPayload entri log. Jika error 403 berisi teks yang berbeda, layanan tujuan mungkin menolak panggilan secara langsung, bukan Agent Gateway.

Anda juga dapat melihat log traffic keluar, termasuk penolakan 403, dengan menggunakan dasbor kemampuan observasi bawaan.

Tujuan CA pribadi atau yang ditandatangani sendiri gagal terhubung

  • Gejala: Agen gagal terhubung ke tujuan yang menampilkan sertifikat yang ditandatangani sendiri atau sertifikat yang dikeluarkan CA pribadi.
  • Penyebab: Secara default, Gateway Agen hanya memercayai sertifikat yang diterbitkan oleh CA yang dipercaya publik. Menghubungkan ke tujuan yang menggunakan CA pribadi atau sertifikat yang ditandatangani sendiri memerlukan konfigurasi tambahan.
  • Mitigasi: Untuk terhubung ke tujuan menggunakan CA pribadi atau sertifikat yang ditandatangani sendiri, Anda harus mengonfigurasi anchor tepercaya TLS kustom menggunakan setelan tlsConfig di template konektivitas agen.

Agen yang di-deploy dengan container kustom (BYOC) gagal terhubung ke Agent Gateway

  • Gejala: Agen BYOC gagal membuat koneksi saat dirutekan melalui Agent Gateway. Log mungkin menampilkan error handshake TLS atau verifikasi sertifikat.
  • Penyebab: Penampung kustom agen tidak memercayai otoritas sertifikat Agent Gateway.
  • Perbaikan: Pastikan Anda telah menambahkan root certificate Agent Gateway ke penyimpanan CA container Anda. Lihat Mengonfigurasi agen container kustom (BYOC) untuk Gateway Agen.

Binding kebijakan gagal atau meniru penolakan tata kelola

  • Gejala: Konfigurasi pengikatan kebijakan gagal, Anda diminta secara interaktif untuk memasukkan etag saat mengikat kebijakan, atau permintaan gagal dengan error penolakan tata kelola yang salah (seperti "tujuan yang tidak terdaftar ditolak dengan benar").
  • Penyebab: Identity-Aware Proxy API (iap.googleapis.com) dinonaktifkan di project Anda.
  • Perbaikan: Aktifkan Identity-Aware Proxy API.

Kegagalan saat mengelola Gateway Agen dengan Workforce Identity Federation

Anda mungkin mengalami masalah ini jika mengelola Agent Gateway di konsolCloud de Confiance atau menggunakan gcloud CLI saat diautentikasi dengan Workforce Identity Federation (WIF).

Konsol menampilkan error pemuatan atau pembuatan umum, seperti berikut:

  • "Terjadi error saat memuat..."
  • "Server tidak dapat memenuhi permintaan Anda"
  • "Gagal membuat gateway agen"
  • "Gagal memuat"

Selain itu, perintah gcloud (seperti gcloud network-services agent-gateways import) mungkin menampilkan error internal, seperti error 13: an internal error has occurred.

Untuk mengatasi masalah ini, lakukan autentikasi dengan Akun Google standar yang dikelola melalui Cloud Identity atau Google Workspace yang memiliki izin yang diperlukan, seperti roles/networkservices.admin.

Identitas gabungan memiliki dukungan terbatas di seluruh layanan Gateway dan Tata Kelola Agent Platform dalam Pratinjau. Memberikan peran IAM yang lebih luas kepada akun utama gabungan tidak akan menyelesaikan masalah.

Alur kerja proses debug

Jika salah satu kondisi yang dijelaskan di bagian Alur permintaan keluar tidak ada, permintaan Anda mungkin diblokir.

Meninjau keputusan IAP

Untuk mempersempit penelusuran log Anda ke keputusan keluar IAP, jalankan kueri berikut di Logging:

protoPayload.serviceName="iap.googleapis.com"
protoPayload.authorizationInfo.permission="iap.resources.egressViaIAP"
protoPayload.metadata.mcp_attributes.base_protocol_method="true"

Jika Anda tidak melihat entri log IAP yang cocok sama sekali, maka gateway mungkin telah menolak permintaan sebelum IAP mengevaluasinya. Lanjutkan ke langkah berikutnya.

Jika Anda melihat entri log yang cocok, tinjau kolom berikut:

  • protoPayload.authorizationInfo[].granted: Menunjukkan apakah permintaan diizinkan (true) atau ditolak (false).
  • protoPayload.authenticationInfo.principalSubject: ID SPIFFE atau identitas principal://... pemanggil. Verifikasi bahwa ini cocok dengan identitas agen Anda.
  • protoPayload.authorizationInfo[].resource: Resource tujuan terdaftar yang di-resolve oleh panggilan.
  • labels."iap.googleapis.com/audited_resource_name": Jika nilai ini adalah unregisteredResource, nama host tujuan tidak terdaftar. Daftarkan nama host tujuan dengan Pendaftaran Agen dan pastikan agen memiliki izin iap.resources.egressViaIAP untuk tujuan ini.
  • Mode penerapan: Tinjau mode penerapan permintaan. Untuk memfilter permintaan uji coba, Anda dapat menambahkan protoPayload.metadata.iamEnforcementMode="DRY_RUN" ke kueri. Dalam mode DRY_RUN, IAP mencatat penolakan ke dalam log, tetapi tidak menerapkannya. Jadi, jika agen gagal dengan error 403 dalam mode uji coba, penolakan kemungkinan berasal dari proxy keluar gateway atau resource tujuan.

Meninjau keputusan Agent Gateway

Untuk meninjau cara Agent Gateway mengevaluasi permintaan, kueri log gateway di Logging. Dalam contoh ini, kita memfilter log hanya untuk error 403:

resource.type="networkservices.googleapis.com/Gateway"
resource.labels.gateway_type="SECURE_WEB_GATEWAY"
resource.labels.location="REGION"
resource.labels.gateway_name="AGENT_GATEWAY_NAME"
httpRequest.status=403
-httpRequest.requestMethod="CONNECT"

Tinjau kolom berikut dalam entri log yang cocok:

  • jsonPayload.authzPolicyInfo.policies.result: Hasil otorisasi keseluruhan, ALLOWED atau DENIED.
  • httpRequest.requestUrl: Catat URL tujuan persisnya yang coba dijangkau agen. Pada langkah berikutnya, kita akan memeriksa apakah nama host yang digunakan oleh resource tujuan telah terdaftar di Pendaftaran Agen.

Memverifikasi pendaftaran tujuan dan cakupan kebijakan akses IAM

Akses ke tujuan selalu memerlukan kebijakan izin IAM yang memberikan izin iap.resources.egressViaIAP ke identitas agen. Mendaftarkan tujuan di Registry Agen direkomendasikan untuk menerapkan kebijakan akses terperinci per resource dan memastikan pencocokan nama host yang akurat. Untuk tujuan yang tidak terdaftar, verifikasi apakah kebijakan untuk endpoint yang tidak terdaftar memberikan izin yang diperlukan ke identitas agen.

Jika Anda mengandalkan kebijakan per resource, setiap nama host tujuan dan variasi nama host yang coba dijangkau oleh agen harus didaftarkan di Pendaftaran Agen. Hal ini karena Google API seperti aiplatform.googleapis.com dapat diselesaikan melalui beberapa nama host, bergantung pada versi SDK, konfigurasi klien regional, atau penggunaan mTLS (misalnya, us-central1-aiplatform.googleapis.com atau us-central1-aiplatform.mtls.googleapis.com).

Karena gateway mencocokkan nama host secara persis, jika Anda mendaftarkan aiplatform.googleapis.com, tetapi agen memanggil us-central1-aiplatform.googleapis.com, gateway akan menganggapnya sebagai resource yang tidak terdaftar dan menolak permintaan.

Jalankan skrip contoh berikut untuk mencantumkan entri registri Anda berdasarkan jenis resource dan periksa entri untuk nama host tertentu yang digunakan oleh panggilan agen:

HOSTNAME="HOSTNAME"
PROJECT_ID="PROJECT_ID"
LOCATION="REGION"

echo "Checking Endpoints..."
gcloud agent-registry endpoints list \
  --project="$PROJECT_ID" \
  --location="$LOCATION" | grep "$HOSTNAME"

echo "Checking MCP Servers..."
gcloud agent-registry mcp-servers list \
  --project="$PROJECT_ID" \
  --location="$LOCATION" | grep "$HOSTNAME"

echo "Checking Agents..."
gcloud agent-registry agents list \
  --project="$PROJECT_ID" \
  --location="$LOCATION" | grep "$HOSTNAME"

Ganti kode berikut:

  • HOSTNAME: Nama host tujuan yang dicoba dijangkau oleh agen, misalnya, us-central1-aiplatform.mtls.googleapis.com.
  • PROJECT_ID: Project ID Cloud de Confiance Anda.
  • REGION: Lokasi resource Agent Registry dan Agent Gateway Anda, misalnya, us-central1.

Output 1: Nama host sudah terdaftar

Jika nama host ada dalam entri Agent Registry, Anda akan melihat output yang mirip dengan contoh berikut:

Checking Endpoints...
  url: https://us-central1-aiplatform.mtls.googleapis.com
Checking MCP Servers...
Checking Agents...

Lanjutkan ke Memverifikasi binding IAM pada resource tujuan untuk memeriksa apakah kebijakan per resource atau seluruh registry memberikan akses ke identitas agen.

Output 2: Nama host tidak ada di registry

Jika nama host tidak ada di registry, Anda akan melihat output yang mirip dengan contoh berikut:

Checking Endpoints...
Checking MCP Servers...
Checking Agents...

Jika Anda berencana menggunakan kebijakan per resource atau di seluruh registry, daftarkan tujuan di Agent Registry terlebih dahulu. Jika Anda menggunakan kebijakan untuk endpoint yang tidak terdaftar, lanjutkan ke Verifikasi binding IAM pada resource tujuan.

Memverifikasi binding IAM pada resource tujuan

Pastikan identitas agen atau set akun utamanya memiliki izin iap.resources.egressViaIAP di tujuan.

Anda dapat mengonfigurasi pengikatan kebijakan di tiga cakupan:

  • Di seluruh registry: Akses ke setiap agen, server MCP, dan endpoint yang terdaftar di registry.
  • Per resource: Mempersempit akses. Pengikatan per resource menggantikan pengikatan di seluruh registry untuk resource tertentu tersebut, bukan menggabungkannya.
  • Kebijakan untuk endpoint yang tidak terdaftar: Akses ke tujuan yang tidak terdaftar di Agent Registry.

Gunakan salah satu contoh berikut untuk memeriksa binding:

  • Untuk memeriksa binding kebijakan IAM tingkat registri, jalankan perintah berikut:

    curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-d '{}' \
-X POST "https://iap.googleapis.com/v1/projects/PROJECT_NUMBER/locations/LOCATION/iap_web/agentRegistry:getIamPolicy" \
-H "Content-Type: application/json"

  • Untuk memeriksa binding kebijakan IAM per endpoint, jalankan perintah berikut:

    export HOSTNAME=HOSTNAME

ENDPOINT_ID=$(gcloud agent-registry endpoints list \
--project="PROJECT_ID" \
--location="REGION" \
--filter="interfaces.url:$HOSTNAME" \
--format="value(name.basename())")

echo "ENDPOINT_ID=$ENDPOINT_ID"

curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}' \
-X POST "https://iap.googleapis.com/v1/projects/PROJECT_NUMBER/locations/LOCATION/iap_web/agentRegistry/endpoints/${ENDPOINT_ID}:getIamPolicy"

    Ganti HOSTNAME dengan nama host tujuan yang coba dijangkau oleh agen, misalnya, us-central1-aiplatform.mtls.googleapis.com.

  • Untuk memeriksa binding kebijakan IAM per server MCP, jalankan perintah berikut:

    export MCP_SERVER=MCP_SERVER

MCP_SERVER_ID=$(gcloud agent-registry mcp-servers list \
--project="PROJECT_ID" \
--location="REGION" \
--filter="interfaces.url:$MCP_SERVER" \
--format="value(name.basename())")

echo "MCP_SERVER_ID=$MCP_SERVER_ID"

curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}' \
-X POST "https://iap.googleapis.com/v1/projects/PROJECT_NUMBER/locations/LOCATION/iap_web/agentRegistry/mcpServers/${MCP_SERVER_ID}:getIamPolicy"

    Ganti MCP_SERVER dengan URL server MCP (misalnya, https://example-abc12345-uc.a.run.app/mcp).

Dalam informasi kebijakan yang ditampilkan, cari binding dengan izin iap.resources.egressViaIAP yang cocok dengan identitas agen atau set pokok. Jika output yang ditampilkan berisi kolom "etag", tetapi tidak ada binding, artinya tidak ada kebijakan IAM.

Jika binding ada tetapi menyertakan condition, pastikan ekspresi Common Expression Language (CEL) tidak mengecualikan agen. Kondisi yang memfilter menurut atribut yang tidak dimiliki agen dapat secara diam-diam mengecualikan agen.

Jika tujuan target tidak memiliki binding kebijakan yang cocok yang memberikan izin iap.resources.egressViaIAP ke identitas agen atau set akun utama Anda, berikan izin menggunakan salah satu opsi kebijakan berikut:

Memeriksa kebijakan dan ekstensi otorisasi

Di bagian ini, kita akan memastikan bahwa ada kebijakan otorisasi yang secara eksplisit menargetkan Agent Gateway yang terkait dengan agen.

  1. Dapatkan detail ekstensi otorisasi yang terkait dengan gateway dan konfirmasi bahwa ekstensi yang Anda gunakan dikonfigurasi seperti yang diharapkan.

    gcloud service-extensions authz-extensions describe AUTHORIZATION_EXTENSION_NAME \
  --location=LOCATION \
  --project=PROJECT_ID

    Ganti AUTHORIZATION_EXTENSION_NAME dengan nama ekstensi yang terkait dengan gateway. Jika tidak mengetahui nama ekstensi, Anda dapat membuka halaman detail gateway di konsol Cloud de Confiance Cloud de Confiance dan mencatat nilai kolom Extension name di bagian Service Extensions.

  2. Pastikan kebijakan otorisasi secara eksplisit menargetkan resource gateway dan ditautkan ke ekstensi otorisasi yang sama. Anda dapat membuka halaman detail gateway di konsol Cloud de Confiance Cloud de Confiance dan mencatat nilai kolom Policy name di bagian Service Extensions.

    Jika tidak ada kebijakan yang menargetkan gateway, atau jika pemetaan gateway ke kebijakan salah, ekstensi otorisasi tidak akan dieksekusi.

Memeriksa kebijakan batas akses utama (PAB)

Kebijakan batas akses utama (PAB) lebih diprioritaskan daripada kebijakan izinkan IAM. Artinya, meskipun Anda telah mengonfigurasi semua binding IAM dengan benar, permintaan akan gagal jika ada kebijakan batas akses akun utama aktif yang mengecualikan resource tujuan dari cakupan agen.

Untuk mencantumkan kebijakan di seluruh organisasi, jalankan:

gcloud iam principal-access-boundary-policies list \
  --organization="ORGANIZATION_ID" \
  --location=global

Untuk menemukan kebijakan yang terikat ke set akun utama agen, jalankan:

gcloud iam policy-bindings search-target-policy-bindings \
  --project="PROJECT_ID" \
  --target="PRINCIPAL_SET"

Ganti kode berikut:

  • ORGANIZATION_ID: ID organisasi Cloud de Confiance Anda.
  • PROJECT_ID: Project ID Cloud de Confiance Anda.
  • PRINCIPAL_SET: Kumpulan utama identitas agen.

Jika binding ada, periksa kolom details.rules[].resources[] untuk memastikan bahwa tujuan berada dalam cakupan agen Anda.

Menguji binding set utama versus utama

Jika izin tidak berfungsi secara konsisten atau gagal secara tidak terduga, masalahnya mungkin terkait dengan cara konfigurasi identitas grup agen Anda (set utama). Izin berbasis set akun utama mungkin gagal karena alasan berikut:

  • Penundaan sinkronisasi: Saat Anda menambahkan identitas ke set, IAM memerlukan waktu beberapa menit untuk memperbarui dan mengenali anggota baru.
  • Atribut tidak ada: Jika keanggotaan dalam set akun utama memerlukan atribut tertentu, identitas agen harus membawa atribut yang sama persis (misalnya, label departemen atau tim). Jika identitas tidak memiliki atribut ini, agen mungkin akan dikecualikan secara otomatis dari grup.

Untuk menguji apakah keanggotaan grup adalah masalahnya, berikan izin langsung kepada agen tertentu dengan menambahkan binding principal:// langsung pada resource yang terpengaruh. Jika agen berhasil terhubung dengan binding langsung, maka penyebab utamanya kemungkinan adalah ketidakcocokan atribut atau penundaan sinkronisasi dengan set akun utama. Untuk mengatasinya, verifikasi dan perbaiki atribut identitas agen, atau gunakan binding principal:// langsung.

Langkah berikutnya

Codelab

Pelajari cara mengelola workload agentic dengan Agent Gateway di Gemini Enterprise Agent Platform.

Panduan

Pelajari cara memantau Agent Gateway.