Satu Prompt, Satu Agen, Seluruh Akun AWS: Menyelami AgentCorruption di Amazon Bedrock AgentCore

Pada 8 Oktober 2026, Zenity Labs mengungkap AgentCorruption: rangkaian kelemahan pada Amazon Bedrock AgentCore, platform terkelola AWS untuk men-deploy dan menjalankan agen AI, yang memungkinkan satu perintah berbahasa alami ke satu agen yang menghadap publik untuk mengambil kendali atas setiap agen AgentCore di akun dan wilayah AWS yang sama. Riset ini diterbitkan bersamaan dengan sebuah presentasi di SecTor 2026 di Toronto, tempat direktur riset keamanan Zenity, Tamir Ishay Sharbat, mempresentasikannya (Dark Reading, 8 Oktober 2026). Tulisan Zenity sendiri, yang dikreditkan kepada Sharbat, Lana Salameh, Dmitry Lozovoy, dan João Donato, dibuka dengan mekanismenya: agen AgentCore yang memiliki alat apa pun yang dapat membuat permintaan keluar dapat diarahkan untuk memanggil AWS Instance Metadata Service (IMDS) di alamat link-local 169.254.169.254, yang mengembalikan kredensial sementara untuk peran eksekusi agen itu sendiri. Zenity menyatakan bahwa pihaknya mengekspor kredensial tersebut ke mesinnya sendiri dan mengonfirmasi bahwa kredensial itu berfungsi dari sana. Tidak ada pengenal CVE yang diberikan.

Arsip mencatat ini sebagai kerentanan — sesuatu yang ditemukan, belum tentu dieksploitasi — dengan tinggi tingkat keparahan, keyakinan A, tidak ada bahaya nyata yang tercatat dan keterlibatan AI yang terkonfirmasi. Para pihak berbeda pendapat tentang pembingkaiannya meskipun mereka setuju tentang perilakunya: AWS mengatakan kepada Dark Reading bahwa riset tersebut "secara tidak akurat menggambarkan perilaku yang diharapkan dan terdokumentasi sebagai kerentanan."

Apa sebenarnya rantai itu

AgentCore mengemas setiap agen sebagai kontainer dan menjalankannya untuk setiap sesi di dalam Firecracker MicroVM. Posting pertama Zenity dalam seri ini mereproduksi seluruh pijakan dengan permintaan berbahasa sederhana kepada agen uji yang dibangun dengan Strands SDK, kerangka kerja agen sumber terbuka milik AWS, yang menyertakan alat permintaan HTTP bawaan dan alat shell. MicroVM tidak membatasi lalu lintas ke layanan metadata, sehingga permintaan itu datang dari dalam instans dan IMDS menjawabnya. Setelah itu, para peneliti menelusuri endpoint: nama peran IAM, kredensial STS sementara itu sendiri, endpoint user-data — yang mengembalikan ID akun, ARN lengkap, URL runtime, dan Amazon Elastic Container Registry (ECR) URI image milik agen — dan tag instans termasuk rantai sertifikat mTLS, kunci privat, dan URL presigned ke penyimpanan internal. Zenity mengatakan hasil yang sama diperoleh melalui alat shell, karena kegagalan isolasi terletak pada tingkat platform, bukan pada alat tertentu.

Dua detail dalam urutan itu mudah terlewat saat membaca. Kredensial tidak terbatas di dalam sandbox: Zenity mengekspornya ke luar AgentCore dan menjalankan panggilan identitas AWS yang kembali sebagai peran yang diasumsikan agen. Dan peran yang dicuri dapat menarik image kontainer, yang membuat kode sumber agen menjadi dapat dibaca — catatan Zenity menyebutkan bahwa image rutin membawa kunci hardcoded, token sisa, dan konfigurasi yang seharusnya tidak pernah dimasukkan, dan bahwa image yang ditarik adalah peta logika bisnis yang mendasarinya.

Peran default adalah tempat di mana sebuah pijakan menjadi akun

Cacat kedua, yang dilaporkan secara terpisah, adalah bahwa peran eksekusi yang dilampirkan AgentCore ke agen secara default tidak dibatasi pada satu agen. Zenity mendeskripsikan izin yang menjangkau setiap sumber daya AgentCore di akun dan wilayah, termasuk bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent dan, di ujung rantai kredensial, bedrock-agentcore:GetResourceApiKey dan secretsmanager:GetSecretValue.

Kemampuan enumerasi mengubah wildcard tersebut menjadi daftar target. Zenity menggunakan izin peran logs:DescribeLogGroups tersebut, karena AgentCore menamai grup log CloudWatch agen /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, dan memperoleh ID agen dari nama grup log tersebut. Nama repositori ECR mengikuti konvensi yang diamati para peneliti — bedrock-agentcore-<agent_name> — citra setiap agen di region tersebut dapat ditarik. Sumber daya memori ditemukan dengan cara yang sama, dari pola grup log /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, dan izin milik peran: ListActors, ListSessions dan ListEvents menghasilkan pengidentifikasi aktor dan sesi yang diperlukan untuk membaca konten percakapan.

Tulisan Zenity memberikan demonstrasi pergerakan lateral yang konkret: masuk melalui agen yang menghadap publik, menemukan alat dari billing_agent di wilayah yang sama, menemukan file bernama billing.json dan mengeksfiltrasinya melalui alat pembaca file. Siaran pers menyatakan skenario yang sama secara umum — penyerang yang masuk melalui agen layanan pelanggan yang menghadap internet dapat berpindah ke agen keuangan internal yang diterapkan di wilayah yang sama, memanggilnya, dan mencapai data, alat, kredensial terkait, dan percakapan pribadinya.

Ingatan adalah bagian yang hidup lebih lama dari prompt

AgentCore Memory menyimpan percakapan itu sendiri sebagai memori jangka pendek dan menyimpan catatan yang diekstrak sebagai memori jangka panjang, dengan menggunakan strategi bernama SEMANTIC, USER_PREFERENCE, SUMMARIZATION dan EPISODIC. Zenity menggunakan CreateEvent untuk menulis peristiwa percakapan ke sumber daya memori agen lain. Postingannya berhati-hati tentang apa yang bisa dan tidak bisa dilakukan primitif itu: CreateEvent tidak memungkinkan pemanggil memilih namespace jangka panjang atau menimpa catatan secara langsung — strategi yang dikonfigurasi pada memori target yang menentukan apa yang diekstrak dan di mana hasilnya disimpan. Zenity juga menjelaskan DeleteEvent digunakan untuk menghapus peristiwa hasil alat sehingga agen menarik kesimpulan yang salah dari data yang hilang, dan untuk menutupi jejak dengan menghapus peristiwa yang menanam sebuah memori.

Apa yang dihasilkan oleh primitif tulis adalah persistensi. Demonstrasi Zenity menanamkan permintaan agar agen mengambil halaman yang dikendalikan para peneliti sebelum menjawab, dan mengikuti isi halaman tersebut — titik akhir command-and-control yang instruksinya dapat diubah tanpa menanamkan memori lain. Saluran yang sama kemudian membawa keluar konten percakapan: laporan tersebut menjelaskan bahwa agen mengirim pesan pengguna dan balasannya sendiri ke titik akhir pengumpulan, dan menyatakan bahwa izin memori pada peran tersebut mencakup seluruh akun dan wilayah, bukan hanya pada agen yang dikompromikan. Sebuah video yang diterbitkan bersama riset tersebut memperlihatkan seorang pengguna melanjutkan percakapan sementara konten itu tiba di server para peneliti.

Kredensial di luar AWS

Postingan terakhir dalam seri ini menutup pembahasan tentang alat yang terhubung. AgentCore Identity dan Outbound Auth menyimpan kredensial alat sebagai secret di AWS Secrets Manager, dengan nama yang dibentuk dari nama penyedia dan pola tetap seperti bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity memulihkan nama penyedia dengan melakukan scraping terhadap kode sumber agen yang sudah ditariknya dari ECR, dan memulihkan nama lainnya dengan brute force: ia melaporkan bahwa sufiks lima karakter default dihasilkan di sisi klien dari digit dan huruf kecil, sehingga menghasilkan 2 x (10+26)^5 = 120,932,352 kombinasi di antara kedua jenis penyedia. Pada laju permintaan yang dapat dipertahankannya terhadap Secrets Manager, Zenity mengatakan bahwa enumerasi penuh memerlukan beberapa jam — lebih lama daripada masa berlaku kredensial STS — sehingga ia membuat loop yang menanyakan ulang endpoint IMDS agen untuk kredensial baru saat kredensial lama kedaluwarsa. Zenity menambahkan bahwa variabel lingkungan dapat dibaca melalui endpoint metadata user-data dengan setiap nama diawali CONTAINER_ENV_, termasuk kunci yang digunakan agen untuk mengautentikasi ke penyedia modelnya, dan bahwa memanggil setiap agen yang ditemukan dengan prompt yang sesuai memanen nilai-nilai tersebut dalam skala besar.

Mapan, dan diperdebatkan karena hal teknis

Yang telah ditetapkan bersifat sempit dan spesifik. Agen AgentCore dapat menjangkau IMDS dan menerima kredensial sementara dari peran eksekusinya sendiri — AWS tidak membantah hal ini, dan dalam pernyataannya menyebutnya sebagai "terdokumentasi dan sesuai ekspektasi." Peran eksekusi default membawa izin yang cakupannya pada akun dan wilayah, bukan pada satu agen; AWS sejak itu telah mengubahnya, dan Zenity mengatakan pengujiannya sendiri mengonfirmasi pengurangan tersebut. Penelitian ini adalah demonstrasi, bukan kampanye yang teramati: Sharbat mengatakan kepada Dark Reading bahwa Zenity tidak melihat bukti celah tersebut dieksploitasi di dunia nyata sebelum perbaikan, sebagian karena sulitnya mengidentifikasi organisasi mana yang menjalankan agen di AgentCore, dan menambahkan bahwa dia "100% yakin ada cara untuk melakukannya."

Yang diperdebatkan adalah apakah salah satu dari hal itu layak disebut sebagai kerentanan. Pernyataan AWS, seperti yang diberikan kepada Dark Reading dan The Next Web, berbunyi: "AWS mengetahui adanya riset yang diterbitkan tentang Amazon Bedrock AgentCore, yang secara tidak akurat menggambarkan perilaku yang diharapkan dan terdokumentasi sebagai kerentanan. Agen hanya dapat mengakses sumber daya di akun AWS lain jika pengembang secara eksplisit memberikan izin pada peran eksekusi agen dan sumber daya target." Pernyataan AWS yang direproduksi dalam unggahan Zenity sendiri mempertahankan substansi kalimat pertama — "perilaku yang dijelaskan didokumentasikan dan diharapkan" — dan menambahkan bahwa pelanggan harus memberikan peran eksekusi hanya izin yang dibutuhkan agen mereka. Dua hal mendasari perbedaan pendapat tersebut. AWS membingkai batasannya dalam hal akses ke sumber daya di akun AWS lain, sementara temuan Zenity berkaitan dengan agen di dalam satu akun dan wilayah AWS; dan peran yang dijelaskan Zenity berasal dari default platform, bukan dari pelanggan yang menulis kebijakan secara manual.

Koreksi The Next Web terhadap artikelnya sendiri layak dicatat, karena ini menunjukkan klaim tersebut diperketat oleh pihak selain para peneliti. Media itu awalnya memberitakan, lalu mengoreksi, sebuah judul yang menyatakan bahwa para peneliti mengambil alih setiap agen AgentCore di suatu region; versi koreksinya menyatakan bahwa penelitian tersebut mencakup agen-agen dalam satu akun AWS dan satu region, serta mencatat bahwa judul sebelumnya telah menyatakan klaim para peneliti sebagai fakta.

Linimasa pengungkapan

Zenity mengajukan dua laporan, bukan satu, dan keduanya ditanggapi secara berbeda. Laporan akses IMDS diajukan pada 25 Desember 2025; AWS menutupnya pada 12 April 2026 sebagai "informatif," dengan menulis bahwa AgentCore baru menggunakan IMDSv2 sejak 14 Februari 2026, dengan agen yang baru disebarkan diluncurkan dengan cara itu. Revisi itu penting untuk rincian penelitian ini, karena IMDSv2 memerlukan token sesi pada setiap permintaan dan menggagalkan pengambilan tanpa autentikasi biasa yang digunakan para peneliti untuk memperoleh kredensial. Laporan kedua, tentang peran default dan radius dampaknya, diajukan pada 12 Januari 2026. AWS memberi tahu Zenity pada 25 Februari 2026 bahwa tim sedang mengerjakannya sementara peran itu tetap seperti semula; Zenity meninjau peran itu lagi pada 22 Juni 2026 dan menemukan izinnya tidak berubah. Tinjauan akhir pada 29 September 2026 menemukan peran itu dipersempit secara substansial, dan siaran pers Zenity menyatakan bahwa penghapusan tersebut mencakup pemanggilan agen lain, pembacaan percakapan pribadi, dan akses ke rahasia di AWS Secrets Manager, dengan izin lain juga dibatasi secara signifikan. Postingan Zenity sendiri mencatat bahwa AWS sejak itu menjadikan IMDSv2 sebagai default untuk penyebaran AgentCore dan bahwa kedua pihak berkolaborasi selama proses tersebut.

Apa yang tidak diketahui

Zenity belum menerbitkan berapa banyak agen atau organisasi yang beroperasi dengan peran default dalam periode antara perubahan IMDSv2 pada Februari dan penyempitan pada akhir September, dan tidak ada apa pun dalam sumber yang dikutip yang menyatakan bahwa data pelanggan mana pun terekspos di luar lingkungan para peneliti sendiri. Perubahan IMDSv2 berlaku untuk agen yang diterapkan setelah 14 Februari 2026, menurut AWS sebagaimana dilaporkan oleh Zenity; apa artinya bagi agen yang diterapkan sebelum tanggal tersebut tidak dinyatakan dalam sumber yang ditinjau di sini. Arsip tersebut tidak mencatat kerugian nyata, dan sumber-sumber mendukung pembacaan itu dengan menggambarkan sebuah demonstrasi dan dengan AWS membantah label kerentanan tersebut alih-alih melaporkan insidennya sendiri.

Sharbat mengatakan kepada Dark Reading bahwa Zenity kini sedang memeriksa platform cloud lain untuk masalah akses metadata serupa, dan bahwa perusahaan tersebut belum menyebutkannya. Poin utama yang ia nyatakan adalah tentang izin, bukan hanya tentang layanan metadata itu sendiri: "Bahkan jika seseorang berhasil masuk ke IMDS, cakupan dampaknya akan jauh lebih kecil."

Mengapa catatan ini disimpan

AgentCorruption bukanlah hal yang menonjol karena endpoint metadata adalah ide baru. Sharbat mengarahkan perhatian audiens SecTor ke pelanggaran Capital One tahun 2019, ketika SSRF menjangkau IMDS dan berubah menjadi kredensial yang dicuri, dan menggambarkan hal itu sebagai kegagalan least-privilege dari jenis yang sama. Yang baru adalah aktor yang melakukan pengambilan tersebut. Permintaan yang menghasilkan identitas AWS dibuat oleh agen AI yang melakukan apa yang diminta, dalam bahasa biasa, melalui alat yang diberikan kepadanya agar bisa berguna — dan agen itu meneruskan jawabannya kembali. Dua kondisi yang mengubahnya menjadi masalah seluruh akun adalah endpoint metadata yang tidak diblokir oleh sandbox dan peran default yang lebih luas daripada agen yang memegangnya.

Riset lengkapnya, termasuk seri teknis lima bagian dan video demonstrasi, ditautkan dari siaran pers Zenity tanggal 8 Oktober 2026. Catatan ini adalah salah satu entri di antara insiden agen yang terdokumentasi dalam arsip insiden AI, di mana setiap entri memuat sumbernya sendiri, tingkat keparahan, tingkat keyakinan, dan penanda sengketa — bidang-bidang yang memungkinkan untuk membedakan sengketa vendor tentang pembingkaian, seperti di sini, dari temuan kerugian yang diperdebatkan.

Ini adalah satu catatan, yang diteliti dan dilaporkan oleh pihak lain serta dikutip di sini dengan atribusi kepada mereka. Insiden agen terdokumentasi lainnya, masing-masing dengan sumbernya sendiri, tingkat keparahan, tingkat keyakinan, dan penanda sengketa, berada di arsip insiden AI — sehingga pengaturan bawaan platform yang mengubah satu prompt menjadi pijakan yang mencakup seluruh akun dapat dibaca bersebelahan dengan apa yang sebenarnya telah terjadi di tempat lain.