Ringkasan Identitas Agen

Agent Identity menyediakan identitas kriptografis yang dibuktikan dengan kuat untuk setiap agen berdasarkan standar SPIFFE. Dengan Identitas Agen, agen Anda dapat melakukan autentikasi dengan aman ke server MCP, resource cloud, endpoint, dan agen lainnya, baik atas namanya sendiri maupun atas nama pengguna akhir. Agent Identity menggunakan kredensial agen itu sendiri dan pengelola autentikasi Agent Identity. Anda dapat menggunakan pengelola autentikasi untuk membuat dan mengelola penyedia autentikasi, yang merupakan konfigurasi spesifik yang digunakan untuk memperoleh, mengelola, dan mengamankan kunci API, client ID OAuth, rahasia klien OAuth, dan token OAuth pengguna akhir yang didelegasikan.

Tidak seperti akun layanan, identitas agen tidak dibagikan oleh beberapa workload secara default, tidak dapat ditiru identitasnya, dan tidak mengizinkan developer membuat kunci akun layanan yang berumur panjang. Token akses yang dibuat untuk Google Cloud terikat secara kriptografis dengan sertifikat X.509 unik agen untuk mencegah pencurian token.

Agent Identity berfungsi dengan Agent Registry dan Agent Gateway untuk membantu mengamankan dan mengatur agen AI. Agent Identity menyediakan identitas kriptografis dan mengelola kredensial, Agent Registry membuat katalog alat dan tujuan di lingkungan Anda, dan Agent Gateway menerapkan kebijakan akses dan memeriksa traffic jaringan saat agen memanggil tujuan tersebut.

Layanan berikut mendukung Identitas Agen:

Model autentikasi

Untuk melakukan autentikasi dengan berbagai alat dan layanan, Agent Identity mendukung beberapa model autentikasi. Model yang digunakan agen bergantung pada metode autentikasi yang ditawarkan oleh resource target dan apakah agen bertindak atas otoritasnya sendiri atau atas nama pengguna akhir.

Otoritas Metode autentikasi Resource target Kasus penggunaan dan solusi
Otoritas yang didelegasikan pengguna OAuth 2.0 (3-legged) Alat dan layanan eksternal Saat agen bertindak atas nama pengguna tertentu (misalnya, untuk mengakses tugas Jira atau repositori GitHub pengguna). Anda mengonfigurasi penyedia autentikasi OAuth 3-legged di pengelola autentikasi Agent Identity untuk mengelola izin pengguna dan token. Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi menggunakan 3-legged OAuth dengan pengelola autentikasi.
Otoritas agen sendiri Identitas berbasis cloud (Identitas Agen) Google Cloud layanan Saat agen yang dihosting di Google Cloud perlu mengakses layanan Google Cloud lain menggunakan identitasnya sendiri. Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi ke Google Cloud menggunakan identitas agen sendiri.
Identitas berbasis cloud (token ID OIDC) Alat dan layanan eksternal Saat agen yang dihosting di Google Cloud perlu melakukan autentikasi ke backend eksternal, API kustom, atau platform cloud pihak ketiga menggunakan identitasnya sendiri dan federasi identitas OpenID Connect (OIDC). Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi ke layanan eksternal menggunakan identitas agen sendiri.
OAuth 2.0 (2-legged) Alat dan layanan eksternal Direkomendasikan untuk autentikasi machine-to-machine dengan layanan eksternal yang mendukung OAuth. Anda mengonfigurasi penyedia autentikasi OAuth 2-legged di pengelola autentikasi Agent Identity untuk menangani kredensial klien dan token akses. Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi menggunakan OAuth 2-legged dengan pengelola autentikasi.
Kunci API Alat dan layanan eksternal Untuk layanan eksternal yang memerlukan kunci kriptografis atau sandi untuk autentikasi. Anda mengonfigurasi penyedia autentikasi kunci API di pengelola autentikasi Agent Identity untuk membantu menyimpan dan mengelola kunci dengan aman. Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi menggunakan kunci API dengan pengelola autentikasi.
Autentikasi dasar HTTP Alat dan layanan eksternal Menggunakan sandi teks biasa. Metode ini tidak direkomendasikan. Anda dapat menyimpan sandi yang mirip dengan kunci API. Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi menggunakan kunci API dengan pengelola autentikasi.

Arsitektur delegasi identitas

Untuk menerapkan batas kepercayaan di seluruh pengguna manusia, workload otonom, dan alat eksternal tanpa mengandalkan peniruan akun layanan, Agent Identity menggunakan framework delegasi tiga identitas. Framework ini memisahkan dan mengoordinasikan tiga konteks identitas yang berbeda di seluruh lingkungan Anda:

  • Identitas pengguna: Identitas pengguna akhir yang memulai, yang diautentikasi melalui OAuth 2.0 atau OpenID Connect (OIDC) standar dengan Google Identity atau penyedia identitas (IdP) tenaga kerja gabungan.
  • Identitas agen: Identitas SPIFFE agen yang di-deploy, yang unik dan dibuktikan secara kriptografis, serta sertifikat X.509 yang disediakan secara otomatis, yang mewakili agen yang bertindak atas otoritasnya sendiri.
  • Identitas yang didelegasikan: Konteks otoritas gabungan saat agen bertindak atas nama pengguna manusia yang memulai menggunakan kredensial OAuth 3-legged (3LO) yang dicakup dan diperantarai oleh pengelola autentikasi Agent Identity.

Diagram berikut mengilustrasikan cara identitas pengguna, identitas agen, dan identitas yang didelegasikan berinteraksi di seluruh batas kepercayaan ingress, runtime, dan egress:

Diagram arsitektur delegasi identitas yang memetakan identitas pengguna, identitas agen, dan identitas yang didelegasikan di seluruh batas kepercayaan ingress, runtime, dan egress.

Untuk mengetahui informasi selengkapnya tentang cara platform mengevaluasi dan menyebarkan setiap lapisan identitas di seluruh batas kepercayaan, lihat Arsitektur delegasi identitas.

Komponen inti

Identitas Agen melibatkan beberapa komponen utama yang bersama-sama membantu memberikan autentikasi dan otorisasi yang aman.

Identitas berbasis SPIFFE

Setiap agen diberi string identitas unik, atau ID SPIFFE, berdasarkan standar SPIFFE. Identitas ini sangat terbukti, terkait dengan siklus proses agen, dan dipetakan langsung ke URI resource tempat agen dihosting.

Identitas mengikuti format ini:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Contoh:

  • spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

Jika identitas agen digunakan dalam kebijakan izin IAM, ID akun utama mengikuti format berikut:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Contoh:

  • Vertex AI Agent Engine (organisasi): principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Vertex AI Agent Engine (project tanpa organisasi): principal://agents.global.proj-9876543210.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Gemini Enterprise: principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent

ID menggunakan hal berikut:

  • TRUST_DOMAIN: Domain kepercayaan untuk hierarki resource Anda:
    • Untuk project dalam organisasi: agents.global.org-ORGANIZATION_ID.system.id.goog
    • Untuk project tanpa organisasi: agents.global.proj-PROJECT_NUMBER.system.id.goog
  • SERVICE: Nama pendek layanan Google Cloud (misalnya, aiplatform atau discoveryengine).
  • RESOURCE_PATH: Jalur lengkap ke resource yang menghosting agen.

Karena agen itu sendiri adalah akun utama, Anda memberikan izin langsung ke ID ini untuk mengontrol resource yang dapat diakses agen.

Siklus proses identitas dan izin

Anda harus mengelola binding IAM untuk identitas agen Anda. Menghapus agen tidak akan menghapus binding IAM yang merujuk ke akun utamanya. Binding ini tetap ada dalam kebijakan Anda sebagai pemberian yang tidak aktif, dan Anda harus menghapusnya secara manual sebagai bagian dari penghentian agen.

Identitas agen berasal dari ID resource yang menghostingnya, seperti ID resource reasoningEngines. Jika Anda menghapus agen dan men-deploy penggantinya, meskipun dengan nama tampilan, kode, dan konfigurasi yang sama, agen baru akan menerima ID resource baru dan oleh karena itu ID akun utama baru. Binding IAM yang ada yang merujuk ke identitas sebelumnya tidak berlaku untuk akun utama baru. Anda harus memberikan peran yang diperlukan kepada akun utama baru.

Kredensial agen

Kredensial agen memberikan bukti kriptografis identitas agen. Sistem ini mendukung sertifikat X.509, token akses, dan token ID OIDC. Google Cloud Sertifikat X.509 disediakan dan dikelola secara otomatis di agen untuk membantu mendukung autentikasi yang lebih kuat.

Sertifikat X.509 ini terhubung ke root certificate authority (CA) yang dikelola Google. Anda dapat melihat sertifikat CA default publik di endpoint berikut:

Secara default, identitas agen menggunakan mutual TLS (mTLS) dengan sertifikat X.509 saat berkomunikasi langsung dengan API Google Cloud . Saat berinteraksi melalui Agent Gateway, agen juga menggunakan Demonstrating Proof of Possession (DPoP), yang membuat kredensial terikat ganda untuk keamanan end-to-end. Binding ganda ini berarti bahwa agen melakukan autentikasi menggunakan mTLS untuk akses pihak pertama ke gateway dan menggunakan DPoP untuk interaksi di luar gateway.

pengelola autentikasi Agent Identity

Pengelola autentikasi Agent Identity adalah vault kredensial dan broker autentikasi terpusat yang menyederhanakan autentikasi alat keluar untuk agen Anda. Hal ini memungkinkan agen melakukan autentikasi menggunakan kunci API atau client ID dan rahasia OAuth, atau atas nama pengguna melalui delegasi OAuth menggunakan token akses pengguna akhir. Dalam pengelola autentikasi, Anda mengonfigurasi penyedia autentikasi yang menentukan jenis autentikasi dan kredensial untuk aplikasi pihak ketiga tertentu.

Akses ke pengelola autentikasi Agent Identity diatur oleh IAM, dan agen menggunakan ID SPIFFE Agennya sendiri untuk melakukan autentikasi ke pengelola autentikasi. Semua peristiwa akses pengguna akhir juga dapat diatribusikan ke ID SPIFFE agen, sehingga memudahkan tata kelola.

Pengelola autentikasi Agent Identity mengotomatiskan akuisisi kredensial OAuth, seperti membuka dialog untuk login dan izin pengguna. Fitur ini juga memberikan visibilitas ke akses pengguna akhir dan memungkinkan pencabutan akses, sehingga memastikan tata kelola yang lebih baik atas izin yang didelegasikan pengguna.

Untuk mengetahui informasi selengkapnya, lihat Ringkasan pengelola autentikasi Agent Identity.

Keamanan dan tata kelola

Identitas Agen terintegrasi sepenuhnya dengan sistem kebijakan Google seperti IAM, Principal Access Boundary (PAB), dan Kontrol Layanan VPC, yang memungkinkan peningkatan keamanan dan tata kelola. Alat ini juga terintegrasi dengan logging audit untuk memastikan akuntabilitas dan memberikan log audit yang jelas, baik saat agen bertindak sebagai dirinya sendiri maupun saat bertindak atas nama pengguna akhir.

  • Akses Kontekstual: Secara default, kebijakan Akses Kontekstual yang dikelola Google membantu mengamankan kredensial agen dengan menerapkan mTLS dan pengikatan token DPoP. Pendekatan ini memastikan bahwa token yang terikat sertifikat tidak dapat diputar ulang di luar lingkungan runtime tepercaya.
  • Integrasi IAM: Dukungan untuk kebijakan izin dan kebijakan penolakan IAM standar.
  • Principal Access Boundary (PAB): Kebijakan Principal Access Boundary membatasi resource yang dapat diakses agen, terlepas dari izin lain yang dimiliki agen. Kebijakan Batas Akses Utama (PAB) yang diterapkan ke identitas agen dievaluasi sebagai bagian dari panggilan keluar (egress). Identitas agen yang tunduk pada kebijakan Batas Akses Akun Utama hanya memenuhi syarat untuk mengakses resource yang ditentukan dalam kebijakan tersebut, sehingga mengisolasi agen secara ketat ke batas yang ditetapkan.
  • Kontrol Layanan VPC: Dukungan untuk perlindungan perimeter dan penggunaan akun utama:
    • Perlindungan perimeter: Anda dapat menambahkan Agent Identity API (agentidentity.googleapis.com) dan Agent Identity Credentials API (agentidentitycredentials.googleapis.com) ke perimeter layanan untuk membantu mengontrol akses ke API ini. Untuk menggunakan API ini dalam perimeter layanan, klien harus merutekan permintaan melalui VIP yang Dibatasi (restricted.googleapis.com).
    • Aturan ingress dan egress: Dukungan untuk menggunakan identitas agen sebagai akun utama dalam aturan ingress dan egress guna mengizinkan akses ke resource yang dilindungi oleh perimeter layanan.

Cara kerja Identitas Agen

Identitas Agen mengautentikasi dan mengizinkan tindakan agen melalui alur kerja yang dirancang untuk membantu meningkatkan keamanan:

  1. Penetapan identitas: Saat Anda men-deploy agen, Google Cloud akan menetapkan identitas SPIFFE unik dan sertifikat X.509 ke agen tersebut. Setiap sertifikat X.509 berlaku selama 24 jam, dan Google Cloud otomatis memperbaruinya untuk menjaga keamanan.
  2. Akuisisi kredensial: Metode yang digunakan agen untuk memperoleh kredensial bergantung pada apa yang mereka coba akses. Berikut beberapa contohnya:
    • Layanan Google Cloud akses: Agen meminta token akses terikat. Token ini terikat secara kriptografis dengan sertifikat X.509 unik agen untuk membantu mencegah pencurian token. Untuk mengetahui informasi selengkapnya, lihat Keamanan dan tata kelola.
    • Mengakses alat eksternal: Untuk melakukan autentikasi langsung ke layanan eksternal menggunakan identitasnya sendiri, agen akan meminta token ID OIDC. Untuk mengambil kredensial yang disimpan (seperti kunci API atau token OAuth) dari penyedia autentikasi, agen menggunakan pengelola autentikasi Agent Identity, yang mendukung otoritas yang didelegasikan pengguna dan otoritas agen itu sendiri.

Manfaat Identitas Agen

Identitas Agen meningkatkan keamanan dibandingkan akun layanan standar.

  • Isolasi yang kuat: Tidak seperti akun layanan, identitas agen tidak dibagikan oleh beberapa workload secara default, tidak dapat ditiru, dan tidak mengizinkan developer membuat kunci akun layanan yang berumur panjang.
  • Keamanan kredensial: Kebijakan Akses Kontekstual default membuat token terikat tidak dapat diputar ulang, sehingga membantu melindungi dari pencurian token dan pengambilalihan akun.
  • Pendekatan hak istimewa terendah: Memberikan identitas per agen, bukan akun layanan bersama, untuk menghilangkan agen dengan izin berlebih.
  • Mengurangi hambatan: Mengotomatiskan alur OAuth yang kompleks dan mengelola kunci API untuk integrasi alat yang lebih sederhana.
  • Peningkatan kemampuan observasi: Memberikan log audit yang jelas. Saat agen bertindak atas nama pengguna, log akan menampilkan identitas agen dan pengguna.

Batasan

  • Peran bucket lama Cloud Storage: Anda tidak dapat memberikan peran bucket lama kepada identitas agen (misalnya, storage.legacyBucketReader).

Langkah berikutnya