AgentCorruption: risiko metadata dan IAM AgentCore

Riset Zenity pada Oktober 2026 melaporkan bahwa alat yang dipengaruhi model dapat mencapai metadata runtime AgentCore dan izin historis pada peran bawaan memperluas akses. AWS menyebut akses ke kredensial peran runtime sendiri sebagai perilaku yang diharapkan dan menyarankan hak akses minimum. Riset Zenity tidak mencantumkan ID CVE dan tidak membuktikan adanya insiden pada pelanggan.^{[1], [4]}

💡 Penjelasan Sederhana (ELI5)

Bayangkan agen di dalam bengkel mendapat kartu akses untuk tugas yang ditetapkan. Zenity mengatakan alat yang dipandu model dapat meminta kartu itu dari meja kredensial internal; izin lama pada kartu membuka lebih banyak ruangan daripada yang diperlukan agen. AWS menyebut pemberian kredensial peran milik runtime sendiri di dalam bengkel sebagai perilaku yang diharapkan. Pertahanan praktisnya adalah membatasi pintu yang dapat dibuka setiap kartu dan mengendalikan alat mana yang boleh mengirim permintaan internal.^{[1], [4]}

Konsep Kunci & Istilah

AgentCorruption: Nama Zenity Labs untuk rangkaian riset terkontrol terhadap Amazon Bedrock AgentCore. Zenity tidak mencantumkan ID CVE, dan risetnya tidak membuktikan insiden pada pelanggan.^{[1], [7]}
MMDS dan kredensial peran eksekusi: AWS mendokumentasikan bahwa kode di dalam microVM AgentCore dapat memperoleh kredensial sementara untuk peran eksekusi runtime tersebut melalui MMDS. Layanan menganggap perilaku ini wajar; izin peran menentukan operasi yang dapat dilakukan dengan kredensial itu.^{[4], [5]}
Cakupan izin: Peran eksekusi menentukan tindakan dan sumber daya AWS yang dapat diakses kode agen. Zenity melaporkan izin bawaan historis yang luas dalam akun dan Region yang sama. AWS menyarankan hak akses minimum; otorisasi mengikuti kebijakan identitas dan sumber daya yang berlaku untuk tiap operasi. AWS secara khusus mengatakan akses lintas akun memerlukan izin eksplisit pada peran dan sumber daya tujuan.^{[3], [1], [6]}
CWE-918 — klasifikasi editorial: Halaman ini menggunakan CWE-918 sebagai klasifikasi editorial untuk permintaan dari alat agen ke layanan metadata internal. AWS tidak menetapkan CWE ini; akses metadata merupakan perilaku yang didokumentasikan.^{[8], [4], [1]}

Pemetaan kerangka kerja

Pemetaan konseptual FlawOpen ke MITRE CWE; tidak ada vendor atau catatan CVE yang menetapkan ID kelemahan ini untuk demonstrasi riset tersebut. CWE-918

Alur Serangan Langkah demi Langkah

Langkah 1

Agen publik memiliki alat untuk koneksi keluar

Zenity menguji agen AgentCore yang dapat diakses publik dengan alat yang bisa mengirim permintaan keluar. Skenario ini memerlukan agen yang dapat dijangkau dan jalur alat yang bisa dipengaruhi model; ini tidak menggambarkan setiap deployment.^{[2], [1]}

Langkah 2

Pengaruh model mencapai metadata

Zenity melaporkan bahwa agen uji mereka dapat diarahkan untuk meminta layanan metadata lokal. AWS mendokumentasikan bahwa kode di dalam microVM dapat mengakses kredensial MMDS. Pertanyaan keamanannya adalah jalur kepercayaan dari model ke alat dan kewenangan kredensial tersebut, bukan keberadaan kredensial milik runtime itu sendiri.^{[2], [1], [4]}

Langkah 3

Respons mewakili peran agen

AWS mendokumentasikan bahwa MMDS menyediakan kredensial sementara untuk peran eksekusi yang dikonfigurasi. Kredensial itu tidak otomatis memberi akses ke semua sumber daya; kebijakan IAM dan kebijakan sumber daya yang berlaku menentukan operasi yang diizinkan. AWS menyebut izin eksplisit pada peran dan sumber daya tujuan untuk akses lintas akun.^{[4], [6], [1]}

Langkah 4

Izin historis memperluas dampak

Zenity melaporkan bahwa peran bawaan saat itu mengizinkan operasi pada sumber daya AgentCore lain dalam akun dan Region yang sama, termasuk pemanggilan runtime, akses sesi/peristiwa, operasi memori, dan akses rahasia. Zenity mengatakan AWS telah mempersempit peran bawaan secara signifikan pada 29 September 2026. Ini tidak membuktikan bahwa peran yang dikelola pelanggan berubah otomatis.^{[3], [1], [6]}

Langkah 5

Kontrol saat ini melindungi batas yang berbeda

Zenity mengatakan agen baru menggunakan MMDSv2 sejak 14 Februari 2026. Dokumentasi AWS saat ini mewajibkan MMDSv2 diaktifkan untuk pemanggilan runtime mulai 30 Juni 2026. AWS masih mendokumentasikan bahwa kode di dalam microVM dapat mengakses kredensial peran; karena itu MMDSv2 tidak menggantikan IAM dengan hak minimum atau pengendalian alat yang dipengaruhi model. Pemisahan kontrol ini merupakan inferensi defensif dari sumber.^{[5], [4], [1]}

Bukti dan cakupan saat ini

Batas	Bukti	Tindakan defensif
Akses metadata	Zenity melaporkan akses dalam pengujiannya; AWS mendokumentasikan kredensial MMDS untuk kode di dalam microVM.	Perlakukan kode agen dan alat yang dipengaruhi model sebagai pengguna kredensial peran eksekusi.
Izin peran	Zenity melaporkan izin bawaan historis yang luas. AWS menyebut akses lintas akun memerlukan izin eksplisit pada peran dan sumber daya tujuan; operasi lain mengikuti kebijakan IAM dan sumber daya yang berlaku.	Periksa peran yang telah diterapkan dan kebijakan sumber daya; verifikasi kebijakan tiap operasi dan jangan menyimpulkan cakupan izin dari prompt atau setelan bawaan layanan.
Perubahan peran bawaan	Zenity mengatakan melihat AWS mempersempit peran bawaan pada 29 September 2026. Risetnya tidak menyatakan peran yang dikelola pelanggan berubah otomatis; riset tidak mencantumkan ID CVE dan tidak membuktikan insiden pada pelanggan.	Verifikasi peran efektif di tiap akun dan Region; jangan menganggap peran pelanggan telah berubah.
MMDSv2	Zenity mencatat penggunaan MMDSv2 pada agen baru sejak 14 Februari 2026; dokumentasi AWS saat ini mewajibkannya untuk pemanggilan runtime mulai 30 Juni 2026. AWS masih mendokumentasikan akses kredensial dari dalam VM.	Aktifkan MMDSv2, lalu batasi tindakan, sumber daya, dan pemanggil peran secara terpisah.

Analisis Akar Masalah (Root Cause)

Evaluasi dua batas secara terpisah: alat yang dipengaruhi model dapat mengirim permintaan dari dalam runtime, sedangkan peran eksekusi menentukan kewenangan permintaan tersebut. AWS menganggap akses ke kredensial milik runtime sendiri sebagai perilaku yang diharapkan; dampak lintas agen yang dilaporkan Zenity bergantung pada cakupan izin peran historis. Mengaktifkan MMDSv2 tidak mempersempit IAM, dan mempersempit peran tidak mencegah permintaan internal yang diarahkan model. Tinjau egress alat dan otorisasi IAM secara terpisah; pembatasan egress saja tidak membuktikan bahwa kode di dalam microVM tidak dapat mengakses MMDS.^{[1], [3], [4], [5]}

Kode Sumber: Rentan vs Aman

Pernyataan kebijakan IAM ini hanya ilustrasi; bukan kebijakan historis AWS atau perubahan peran bawaan setelahnya. AWS menyarankan izin runtime dibatasi pada ARN sumber daya tertentu dan menghindari wildcard. Pernyataan pertama menunjukkan cakupan sumber daya yang luas; pernyataan kedua membatasi pemanggilan ke satu runtime yang disetujui jika izin itu memang diperlukan. Hapus izin jika tidak dibutuhkan. Validasi dukungan tindakan/sumber daya dan kebijakan sumber daya terkait untuk deployment sebenarnya; ini bukan kebijakan lengkap yang siap diterapkan.^{[3], [6], [5]}

IMPLEMENTASI RENTAN

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

PERBAIKAN AMAN & KUAT

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Daftar Periksa Penguatan Sistem Rekayasa

✓Inventarisasi setiap peran eksekusi runtime di semua akun dan Region; bandingkan izin efektif dengan kebijakan AWS saat ini dan kebijakan yang dikelola pelanggan.^{[6], [5]}
✓Hapus pemanggilan lintas runtime, akses percakapan, pengambilan rahasia, penulisan memori, dan akses image kecuali setiap kebutuhan didokumentasikan.^{[3], [6]}
✓Jika satu runtime harus memanggil runtime lain, batasi kebijakan identitas dan sumber daya pada runtime serta endpoint yang disetujui; uji bahwa runtime yang tidak terkait ditolak.^[6]
✓Aktifkan MMDSv2 sesuai ketentuan AWS, tetapi perlakukan akses kode microVM ke kredensial peran sebagai batas otorisasi tersendiri.^{[5], [4], [1]}
✓Batasi tujuan yang dapat dihubungi alat yang dipengaruhi model sesuai kebutuhan beban kerja; anggap ini pengurangan risiko egress, bukan bukti bahwa kode VM tidak dapat mengakses MMDS.^[5]
✓Berikan agen publik peran dengan hak akses yang tidak melebihi principal yang dapat memanggilnya; verifikasi izin efektif memakai IAM Access Analyzer dan uji penolakan otorisasi.^{[5], [6]}

Sumber

← AI Security Directory →