Ringkasan Identitas Agen

Identitas Agen menyediakan identitas kriptografi yang dibuktikan secara kuat untuk setiap agen yang didasarkan pada 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 mendapatkan, mengelola, dan mengamankan kunci API, ID klien OAuth, secret klien OAuth, dan token OAuth pengguna akhir yang didelegasikan.

Tidak seperti akun layanan, identitas agen tidak dibagikan oleh beberapa workload secara default, tidak dapat di-impersonate, dan tidak mengizinkan developer membuat kunci akun layanan yang berlaku lama. Token akses yang dibuat untuk Google Cloud terikat secara kriptografis ke sertifikat X.509 unik agen untuk mencegah pencurian token.

Agent Identity bekerja dengan Agent Registry dan Agent Gateway untuk membantu mengamankan dan mengatur agen AI. Identitas Agen menyediakan identitas kriptografi dan mengelola kredensial, Registry Agen mencatat alat dan tujuan di lingkungan Anda, dan Gateway Agen menerapkan kebijakan akses dan memeriksa traffic jaringan saat agen memanggil tujuan tersebut.

Jika Agent Identity digunakan dengan Agent Gateway dan Gemini Enterprise, kredensial pengguna akhir, seperti yang disediakan oleh konektor Gemini Enterprise, dienkripsi oleh auth manager dan didekripsi di gateway, sehingga agen tidak akan pernah dapat mengakses kredensial mentah.

Layanan berikut mendukung Identitas Agen:

Model autentikasi

Untuk melakukan autentikasi dengan berbagai alat dan layanan, Identitas Agen 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 dan token pengguna. Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi menggunakan OAuth 3-legged dengan pengelola autentikasi.
Otoritas agen itu sendiri Identitas berbasis cloud (Agent Identity) Google Cloud layanan Saat agen yang dihosting di Google Cloud perlu mengakses layanan Google Cloud lain menggunakan identitasnya sendiri. Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi ke Google Cloud menggunakan identitas agen itu 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 federasi identitas OpenID Connect (OIDC) dan identitasnya sendiri. 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 kriptografi atau sandi untuk autentikasi. Anda mengonfigurasi penyedia autentikasi kunci API di pengelola autentikasi Identitas Agen 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.

Komponen inti

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

Identitas berbasis SPIFFE

Setiap agen diberi string identitas unik, atau ID SPIFFE, berdasarkan standar SPIFFE. Identitas ini dibuktikan dengan kuat, terikat 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

Saat 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 berikut ini:

  • TRUST_DOMAIN: Domain tepercaya 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 mana 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 mereferensikan akun utamanya. Binding ini tetap ada di kebijakan Anda sebagai pemberian yang tidak aktif, dan Anda harus menghapusnya secara manual sebagai bagian dari penonaktifan 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 utama baru. Binding IAM yang ada yang mereferensikan identitas sebelumnya tidak berlaku untuk akun utama baru. Anda harus memberikan peran yang diperlukan kepada akun utama baru.

Kredensial agen

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

Secara default, identitas agen menggunakan TLS timbal balik (mTLS) dengan sertifikat X.509 saat berkomunikasi langsung dengan Google Cloud API. Saat berinteraksi di seluruh 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 brankas kredensial terpusat dan broker autentikasi yang menyederhanakan autentikasi alat keluar untuk agen Anda. Agen dapat melakukan autentikasi menggunakan kunci API atau ID dan secret klien 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 mempermudah tata kelola.

Pengelola autentikasi Identitas Agen mengotomatiskan perolehan 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 Identitas Agen.

Keamanan dan tata kelola

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

  • Akses Kontekstual: Secara default, kebijakan Akses Kontekstual yang dikelola Google membantu mengamankan kredensial agen dengan menerapkan pengikatan token mTLS dan DPoP. Pendekatan ini memastikan bahwa token yang terikat dengan sertifikat tidak dapat diputar ulang di luar lingkungan runtime tepercayanya.
  • Integrasi IAM: Dukungan untuk kebijakan izin dan kebijakan penolakan IAM standar.
  • Batas Akses Principal (PAB): PAB membatasi resource yang dapat diakses agen, terlepas dari izin lainnya.
  • Kontrol Layanan VPC: Dukungan untuk perlindungan perimeter dan penggunaan prinsipal:
    • 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 Terbatas (restricted.googleapis.com).
    • Aturan ingress dan egress: Dukungan untuk menggunakan identitas agen sebagai akun utama dalam aturan ingress dan egress untuk 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 menetapkan identitas SPIFFE unik dan sertifikat X.509 untuk agen tersebut. Setiap sertifikat X.509 valid selama 24 jam, dan Google Cloud secara otomatis diperbarui untuk menjaga keamanan.
  2. Akuisisi kredensial: Metode yang digunakan agen untuk mendapatkan kredensial bergantung pada apa yang ingin mereka akses. Berikut beberapa contohnya:
    • Mengakses Google Cloud layanan: Agen meminta token akses terikat. Token ini terikat secara kriptografis ke sertifikat X.509 unik agen untuk membantu mencegah pencurian token. Untuk informasi selengkapnya, lihat Keamanan dan tata kelola.
    • Mengakses alat eksternal: Untuk melakukan autentikasi langsung ke layanan eksternal menggunakan identitasnya sendiri, agen meminta token ID OIDC. Untuk mengambil kredensial tersimpan (seperti kunci API atau token OAuth) dari penyedia autentikasi, agen menggunakan pengelola autentikasi Identitas Agen, 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 identitasnya, dan tidak mengizinkan developer membuat kunci akun layanan yang berlaku lama.
  • Keamanan kredensial: Kebijakan Akses Kontekstual default membuat token terikat tidak dapat diputar ulang, sehingga membantu melindungi dari pencurian token dan pengambilalihan akun. Saat Agent Identity digunakan dengan Agent Gateway dan Gemini Enterprise, kredensial pengguna akhir, seperti yang disediakan oleh konektor Gemini Enterprise, dienkripsi oleh auth manager dan didekripsi di gateway, sehingga memastikan bahwa agen tidak pernah dapat mengakses kredensial mentah.
  • Pendekatan hak istimewa terendah: Menyediakan identitas per agen, bukan akun layanan bersama, untuk menghilangkan agen yang memiliki terlalu banyak izin.
  • Gesekan yang lebih sedikit: Mengotomatiskan alur OAuth yang kompleks dan mengelola kunci API untuk integrasi alat yang lebih sederhana.
  • Kemampuan observasi yang ditingkatkan: Menyediakan 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