Okta Bedrock AgentCore Governance: Cara Amankan Akses Agen AI

Masalah Akses Agen AI: Kenapa Perlu Tata Kelola Identitas Khusus?

Selama ini, banyak developer memberikan service account dengan izin luas langsung ke agen AI. Cara ini gampang di awal, tapi jadi bom waktu saat masuk skala produksi. Kalau agen dibobol atau melakukan tindakan ngawur, sistem target mencatat aktivitas itu sebagai aksi service account, bukan atas nama pengguna yang memintanya.

Sebaliknya, kalau meminta izin per aplikasi lewat persetujuan OAuth biasa, pengelolaannya bakal luar biasa ribet saat ada puluhan agen dan ribuan tool. Model delegasi biasa sering kali memperluas scope tanpa sengaja atau gagal membawa konteks grup pengguna ke tool hilir.

Arsitektur Okta Cross App Access (XAA) memposisikan Okta sebagai governance plane—pusat penentu kebijakan yang memutuskan agen mana yang boleh mewakili siapa, untuk menyentuh resource apa. Sementara itu, Amazon Bedrock AgentCore bertindak sebagai execution plane yang memegang kredensial agen, menukarkan token keputusan dari Okta, dan menyimpannya di brankas token (token vault) yang aman.

Cara Kerja Rantai Tiga Token Okta XAA dan Amazon Bedrock AgentCore

Alih-alih cuma mengandalkan satu access token panjang umur, alur ini memakai rantai tiga token yang saling mengikat. Setiap token punya fungsi unik yang nggak bisa dipalsukan:

1. ID Token Pengguna: Diterbitkan saat pengguna masuk ke web front end (BFF) lewat aplikasi Okta yang terhubung dengan agen.
2. ID-JAG (Identity Assertion JWT Authorization Grant): BFF menukarkan ID token pengguna ke org authorization server Okta dengan protokol RFC 8693 token exchange. Okta memeriksa status agen, keterikatan pengguna, dan scope yang disetujui admin. Token ID-JAG ini hanya bisa dipakai sekali (single-use) dan kedaluwarsa dalam 5 menit.
3. Access Token Target: Agen meminta access token ke AgentCore Identity. AgentCore Identity menukarkan ID-JAG di custom authorization server resource via RFC 7523 (JWT authorization grant). Hasilnya berupa access token berumur 5 menit yang mencantumkan identitas pengguna sekaligus identitas agen, lengkap dengan klaim grup pengguna.

Di dalam infrastruktur AWS sendiri, AgentCore runtime menerbitkan workload access token internal. Token ini cuma berputar di internal AWS untuk mengikat runtime agen ke pengguna, tanpa pernah bocor ke Okta maupun server resource luar.

Dengan alur ini, tool hilir yang berbasis Model Context Protocol (MCP) server bisa memastikan dua hal sekaligus: apakah pemanggilnya benar-benar agen terdaftar, dan apakah pengguna manusia di belakangnya punya hak akses untuk mengeksekusi fungsi tersebut.

Langkah Pasang Okta Cross App Access dan AgentCore Identity

Untuk membangun fondasi ini, kamu butuh akun AWS dengan akses Amazon Bedrock AgentCore dan model Anthropic Claude di region US West (Oregon), akun Okta dengan fitur XAA dan API Access Management, serta AgentCore CLI dan SDK Python. Sampel dasarnya mengacu pada repositori resmi 08-okta-xaa-delegation-chain.

1. Daftarkan Agen di Okta Admin Console

Buka Okta Admin Console dan masuk ke menu Directory > AI Agents. Daftarkan agen AI secara manual dan buat OpenID Connect app terkait. Di sini, agen dan aplikasi bakal berbagi client ID yang sama.

Buat custom authorization server untuk aplikasi target (misalnya dengan audience api://task-manager), tambahkan custom scope xaa:read dan xaa:write, serta sertakan klaim groups yang difilter untuk grup berawalan xaa-. Sambungkan agen ke custom authorization server tersebut pada tab Resource connections dengan scope yang terbatas.

2. Konfigurasi Credential Provider di AgentCore Identity

AgentCore Identity bertugas menangani pertukaran token kedua. Kamu perlu mendaftarkan OAuth2 credential provider yang mengarah ke custom authorization server Okta dan memilih grant JWT_AUTHORIZATION_GRANT:

import boto3

control = boto3.client("bedrock-agentcore-control")
provider = control.create_oauth2_credential_provider(
    name="okta-xaa-obo",
    credentialProviderVendor="CustomOauth2",
    oauth2ProviderConfigInput={
        "customOauth2ProviderConfig": {
            "oauthDiscovery": {
                "discoveryUrl": f"{OKTA_ORG}/oauth2/{CUSTOM_AS_ID}/.well-known/openid-configuration"
            },
            "clientId": AGENT_CLIENT_ID,
            "clientSecret": AGENT_CLIENT_SECRET,
            "clientAuthenticationMethod": "CLIENT_SECRET_BASIC",
            "onBehalfOfTokenExchangeConfig": {
                "grantType": "JWT_AUTHORIZATION_GRANT"
            },
        }
    },
)

AgentCore Identity menyimpan rahasia klien di AWS Secrets Manager secara otomatis. Kode aplikasi agenmu sama sekali nggak bakal melihat rahasia klien ini atau menyentuh endpoint token Okta secara mentah.

3. Ambil Token di Kode Agen dan Lindungi Server MCP

Di dalam kode agen, jangan cari token di header permintaan biasa. Ambil workload token langsung dari context runtime AgentCore, lalu minta access token ke AgentCore Identity:

from bedrock_agentcore.runtime import BedrockAgentCoreContext
import boto3

identity = boto3.client("bedrock-agentcore")

def okta_access_token() -> str:
    workload_token = BedrockAgentCoreContext.get_workload_access_token()
    return identity.get_resource_oauth2_token(
        workloadIdentityToken=workload_token,
        resourceCredentialProviderName="okta-xaa-obo",
        scopes=["xaa:read", "xaa:write"],
        oauth2Flow="ON_BEHALF_OF_TOKEN_EXCHANGE",
    )["accessToken"]

Di sisi server MCP, lakukan verifikasi ganda. Pastikan klaim act atau cid mencantumkan ID agen yang terdaftar, dan periksa apakah grup pengguna memuat hak tulis sebelum mengizinkan modifikasi data:

REGISTERED_AGENTS = {"YOUR_AGENT_CLIENT_ID"}
WRITERS_GROUP = "xaa-writers"

def require_write(claims: dict) -> None:
    agent = (claims.get("act") or {}).get("sub")
    if agent not in REGISTERED_AGENTS or claims.get("cid") != agent:
        raise PermissionError("Akses ditolak: hanya menerima agen terdaftar Okta XAA.")
    
    user_groups = claims.get("groups", [])
    if WRITERS_GROUP not in user_groups or "xaa:write" not in claims.get("scp", []):
        raise PermissionError(f"Akses ditolak: butuh keanggotaan di '{WRITERS_GROUP}'.")

Kecepatan Respon dan Hasil Pengujian Keamanan di Lapangan

Dalam pengujian nyata yang dilakukan tim AWS terhadap tiga pengguna uji (Alice, Bob, dan Carol), delegasi identitas ini berhasil menyaring hak akses dengan sangat ketat:

Sistem juga langsung menolak berbagai skenario ancaman keamanan:

• Token ID-JAG milik Agen B yang dikirim ke agen task langsung dicegat oleh JWT authorizer bawaan runtime dengan status HTTP 401.
• Token ID-JAG yang ditahan selama 245 detik langsung ditolak HTTP 401 karena tersisa kurang dari 60 detik sebelum kedaluwarsa.
• Upaya menukarkan satu ID-JAG sebanyak dua kali ditolak oleh Okta custom authorization server dengan pesan error the id-jag was already used.

Berapa latensi tambahannya? Dari total waktu eksekusi sekitar 30 detik (sebagian besar dihabiskan untuk komputasi model AI dan panggilan tool), AgentCore Identity cuma menambah waktu sekitar 0,6 detik. Median panggilan pertukaran token dari pengujian menunjukkan data berikut:

Menariknya, saat agen memanggil server MCP kedua dalam permintaan yang sama, brankas token (token vault) mengembalikan access token yang sudah ada dengan median latensi cuma 58 milidetik tanpa perlu menukar ID-JAG ulang.

6 Praktik Terbaik Supaya Delegasi Token Tetap Aman dan Anti Jebol

Dari eksperimen lapangan tersebut, ada enam praktik penting yang wajib kamu terapkan di lingkungan produksi:

1. Terbitkan ID-JAG baru di setiap permintaan: Token ID-JAG bersifat sekali pakai dengan masa aktif 300 detik. Runtime bakal menolak token jika sisa umurnya di bawah 60 detik.
2. Titipkan hak pengguna di klaim groups: Karena koneksi resource Okta memberikan scope seragam untuk semua pengguna agen, filter otorisasi per individu harus dibaca dari klaim groups.
3. Kunci identitas agen di runtime dan tool: Gunakan parameter allowedClients di runtime authorizer untuk memeriksa client_id pada ID-JAG, dan validasi klaim act serta cid di dalam tool MCP.
4. Uji ulang kegagalan exchange langsung ke endpoint Okta: AgentCore Identity menyamarkan pesan error scope dan client yang salah dengan kode umum HTTP status 400. Reproduksi langsung ke Okta untuk tahu penyebab pastinya.
5. Beri izin role agen membaca secret provider: Pastikan IAM role runtime agen punya izin membaca AWS Secrets Manager tempat rahasia klien disimpan.
6. Gunakan resource connection sebagai kill-switch darurat: Memutus resource connection di konsol Okta langsung membatalkan akses pada detik itu juga. Sebaliknya, proses deactivate agen di Okta beta API sempat tertahan antrean hingga 86 menit saat diuji.

Skala Besar: Pakai AgentCore Gateway dan Cedar Policies

Arsitektur di atas bekerja mulus untuk satu agen dan dua tool MCP. Namun, saat perusahaanmu punya puluhan agen dan ribuan tool, menaruh logika pengecekan grup di tiap kode server MCP bakal bikin pusing dan rentan inkonsistensi.

Di sinilah Amazon Bedrock AgentCore Gateway dan mesin kebijakan Cedar masuk. Alih-alih agen memanggil server MCP secara langsung, semua panggilan tool diarahkan lewat satu pintu gerbang: Gateway.

Gateway ini bertindak mengambil alih tugas pertukaran token ke AgentCore Identity. Sebelum meneruskan panggilan ke server target, Gateway mengevaluasi aturan akses memakai bahasa kebijakan Cedar yang bersifat default-deny.

Dengan pola ini, agen kedua yang berjalan di luar AWS runtime—misalnya agen pelaporan di Amazon Elastic Kubernetes Service (Amazon EKS)—bisa memakai pintu gerbang yang sama tanpa perlu mengubah konfigurasi server MCP.

Semua jejak keputusan otorisasi terekam lewat OpenTelemetry spans ke AgentCore Observability. Ditambah integrasi Okta System Log melalui Amazon EventBridge ke Amazon CloudWatch, tim audit bisa melihat seluruh riwayat keputusan dalam satu kueri terpusat.

Perbandingan antara pendekatan Okta Cross App Access dan persetujuan OAuth per pengguna (per-user consent) menunjukkan keunggulan kontrol terpusat ini secara nyata.

Dampak Buat Developer dan Arsitektur AI di Indonesia

Bagi tim developer dan enterprise di Indonesia—terutama sektor perbankan, fintech, kesehatan, dan e-commerce—pola arsitektur identitas ini jadi jawaban krusial untuk memenuhi standar kepatuhan regulasi, termasuk Undang-Undang Perlindungan Data Pribadi (UU PDP).

Prinsip least privilege dan akuntabilitas audit menjadi harga mati. Saat agen AI membaca data sensitif nasabah atau database internal, sistem wajib membuktikan bahwa agen tersebut benar-benar diperintah oleh staf yang memiliki wewenang sah pada menit tersebut. Rantai tiga token dan pencabutan hak akses di bawah 1 detik ini menutup celah kebocoran data akibat kredensial statis yang bocor.

Kamu juga bisa mempelajari pola arsitektur penghubung data agen AI lainnya lewat ulasan kami tentang MCP Server ECS Fargate untuk data lake atau panduan membangun remote agent koding aman di Bedrock AgentCore.

Eksperimen Model LLM Agen Pakai Classai Router

Saat membangun dan menguji alur otorisasi agen AI berbasis Bedrock AgentCore ini, kamu tentu butuh model reasoning yang mumpuni untuk membaca konteks tool call dengan presisi tinggi. Claude 3.5 Sonnet atau varian model frontier lainnya biasanya jadi pilihan utama untuk agen otonom.

Biar proses prototyping agenmu nggak boncos dan nggak ribet gonta-ganti konfigurasi API, kamu bisa memakai Classai Router. Satu API key di Classai Router kompatibel langsung dengan SDK Anthropic maupun OpenAI. Harganya dihitung transparan per 1 juta token dalam rupiah tanpa langganan wajib:

• Claude Sonnet 4.6: Rp2.700 (input) / Rp13.500 (output)
• Claude Sonnet 5: Rp3.210 (input) / Rp15.750 (output)
• GPT-4o: Rp525 (input) / Rp2.700 (output)

Kamu bisa top up saldo mulai dari Rp10.000 via QRIS atau transfer bank lokal tanpa butuh kartu kredit luar negeri. Cukup arahkan base URL proyek agenmu ke router Classai untuk mulai bereksperimen.