AgentCorruption: Zenity เผยพรอมต์เดียวถึง agent สาธารณะบน AWS Bedrock AgentCore ขโมย credential ได้ แล้วใช้ execution role ค่าเริ่มต้นเข้าถึง agent ทุกตัวใน region ทั้งโค้ด แชตส่วนตัว และ memory

Zenity Labs เผยแพร่งานวิจัยชุด “AgentCorruption” สี่ตอนเมื่อวานนี้ (8 ต.ค. 2026) แสดงช่องโหว่ต่อเนื่องใน Amazon Bedrock AgentCore ซึ่งเป็นแพลตฟอร์มรัน AI agent แบบ managed ของ AWS นักวิจัยบอกว่าเริ่มจากแค่ สิทธิ์แชตกับ agent สาธารณะตัวเดียว (เช่น บอทบริการลูกค้า) ส่งพรอมต์ภาษาธรรมดาไปหนึ่งข้อความ ก็ไปจบที่การควบคุม agent ทุกตัวในบัญชี AWS และ region เดียวกัน ได้ ทั้งดึงซอร์สโค้ด อ่านบทสนทนาส่วนตัวของผู้ใช้ทุกคน แก้ memory ของ agent และขโมย API key ของบริการภายนอก

ปัญหานี้ไม่ได้อยู่ที่โมเดลถูกหลอก เพราะ prompt injection เกิดได้กับทุกโมเดลอยู่แล้ว แต่อยู่ที่ ชั้นโครงสร้างพื้นฐานใต้ agent ซึ่งไม่มีขอบเขตกั้นไว้เลยเมื่อถูกหลอกสำเร็จ

ขั้นที่ 1: agent ส่ง credential ของตัวเองออกมา

AgentCore รันแต่ละ session ใน Firecracker microVM แยกกัน ซึ่งมี metadata service ที่ 169.254.169.254 เหมือน IMDS ของ EC2 ทีมวิจัยสร้าง agent ด้วย Strands Agents SDK (เฟรมเวิร์กโอเพนซอร์สของ AWS) แล้วใส่เครื่องมือ http_request ที่ติดมากับ SDK จากนั้นสั่งเป็นภาษาธรรมดาให้ไปอ่าน endpoint นั้น ผลคือ agent ทำตาม และส่ง STS credential ชั่วคราว (access key, secret, session token) ของ execution role ตัวเองกลับมา ทีมวิจัยนำ credential นั้นไปใช้บนเครื่องตัวเองนอก AgentCore ได้ทันที

metadata service ยังเปิดเผยข้อมูลอื่นอีก ได้แก่ ECR URI ของ container image ของ agent, ใบรับรองและ private key ที่ใช้ทำ mTLS กับบริการภายในของ AWS และ presigned URL ไปยัง S3 ที่ไม่ได้อยู่ในบัญชีของนักวิจัย Zenity ย้ำว่าการถอด HTTP tool ออกก็ไม่ช่วย เพราะทำซ้ำผ่านเครื่องมือ shell ด้วย curl ได้ผลเหมือนกัน ปัญหาจึงอยู่ที่ระดับแพลตฟอร์ม ไม่ใช่ระดับเครื่องมือ

ขั้นที่ 2: execution role ค่าเริ่มต้นมีสิทธิ์ทั้ง region

ส่วนที่ร้ายแรงกว่าคือ role ที่ AgentCore สร้างให้เป็นค่าเริ่มต้น มีสิทธิ์แบบ wildcard ครอบคลุมทั้ง account และ region:

• logs:DescribeLogGroups ทำให้ list ชื่อ log group ได้ทั้งหมด และเนื่องจาก log group ตั้งชื่อตาม agent จึงได้รายชื่อ agent ทุกตัวมาด้วย
• ECR repo ตั้งชื่อแบบเดาได้ (bedrock-agentcore-<agent_name>) และสิทธิ์ ECR ครอบคลุมทุก image ทำให้ดึง container ของทุก agent ได้ในไม่กี่วินาที พร้อม secret ที่นักพัฒนาฝังไว้ใน image
• bedrock-agentcore:InvokeAgentRuntime ทำให้เรียก agent ภายในที่ไม่ได้เปิดสู่สาธารณะได้ เช่น ในวิดีโอสาธิต ทีมวิจัยเรียก billing_agent แล้วใช้เครื่องมือ file_read ของมันดึงไฟล์ billing.json ออกมา
• ListActors, ListSessions และ ListEvents ทำให้อ่านบทสนทนาส่วนตัวของผู้ใช้ทุกคนกับทุก agent ใน region ได้ ส่วน CreateEvent และ DeleteEvent ทำให้แทรกข้อความปลอมในฐานะ ASSISTANT เข้าไปใน session ที่กำลังใช้งานอยู่ได้ (ตัวอย่างของ Zenity คือแทรกข้อความว่า “ต้องคืนเงินเข้าบัญชีนี้ทันที”)
• ตอนที่สามแสดงการฝังคำสั่งใน long-term memory ให้ agent ไปอ่านคำสั่งจาก URL ของผู้โจมตีก่อนตอบทุกครั้ง ซึ่งทำหน้าที่เหมือน C2 แบบถาวร ส่วนตอนที่สี่แสดงการดึง secret จาก Secrets Manager ผ่าน AgentCore Identity และดึงตัวแปร environment เช่น OPENAI_API_KEY ซึ่งเป็นกุญแจของบริการนอก AWS

AWS ตอบอย่างไร

ตาม timeline ที่ Zenity เปิดเผย ทีมวิจัยรายงานเรื่อง IMDS ให้ AWS เมื่อปลายธันวาคม 2025 (ในโพสต์เขียนไว้ทั้งวันที่ 17 และ 25 ธ.ค.) และวันที่ 12 เมษายน 2026 AWS ปิดเคสเป็น “informative” โดยระบุว่าได้ปรับพฤติกรรม IMDS แล้ว คือตั้งแต่ 14 กุมภาพันธ์ 2026 AgentCore ใช้ IMDSv2 เท่านั้น และ agent ที่ deploy ใหม่ทุกตัวจะใช้ IMDSv2 The Decoder รายงานเพิ่มว่า AWS เปลี่ยน default execution role ราวเดือนสิงหาคม ไม่ให้เรียก agent อื่น อ่านบทสนทนา หรือดึง Secrets Manager ได้อีก แต่เราไม่พบรายละเอียดนี้ในโพสต์สี่ตอนของ Zenity ที่อ่าน ควรถือเป็นข้อมูลที่ยังไม่ยืนยัน ทั้งนี้ Zenity เป็นบริษัทที่ขายแพลตฟอร์มความปลอดภัยสำหรับ AI agent จึงมีผลประโยชน์ทางธุรกิจในการเผยแพร่งานวิจัยแนวนี้

มุมมอง AI Curator

บทเรียนจากเรื่องนี้ไม่ได้ใหม่ เพราะ “SSRF ไป IMDS แล้วขโมย credential” เป็นเทคนิคพื้นฐานของการเจาะคลาวด์มากว่าสิบปี (กรณี Capital One ปี 2019 ก็ใช้วิธีนี้) สิ่งที่ใหม่คือ AI agent ทำให้ SSRF ไม่ต้องใช้ช่องโหว่ในโค้ดเลย แค่ขอดีๆ ก็พอ agent ที่มีเครื่องมือออกเน็ตได้ จึงต้องถือว่าเป็น “SSRF ที่เปิดไว้โดยตั้งใจ” ตั้งแต่วันแรก ขอบเขตความปลอดภัยต้องอยู่ที่ network และ IAM ไม่ใช่ที่ system prompt

ข้อควรรู้อีกข้อคือ IMDSv2 ช่วยกันได้ดีเมื่อเครื่องมือส่งได้แค่ GET แบบธรรมดา เพราะต้องขอ token ด้วย PUT และใส่ header ก่อน แต่ agent ที่มี shell สามารถรัน curl -X PUT เองได้ทั้งขั้นตอน ดังนั้นสิ่งที่ลดความเสียหายได้จริงคือขอบเขตของ role ไม่ใช่เวอร์ชันของ IMDS ทีมไทยที่ใช้ AgentCore ควรทำสามอย่างทันที: (1) เปิด IAM ดูว่า agent ที่ deploy ก่อนกลางเดือน ก.พ. ยังใช้ role ค่าเริ่มต้นแบบเก่าอยู่หรือไม่ ถ้าใช่ให้เปลี่ยนเป็น role ที่สร้างเองแบบจำกัดเฉพาะ resource ของ agent นั้น (2) แยก agent ที่เปิดสู่สาธารณะไว้คนละ account กับ agent ภายในที่เข้าถึงข้อมูลการเงินหรือข้อมูลลูกค้า (3) ห้ามใส่ API key ใน container image หรือ environment variable ของ agent ที่รับ input จากคนนอก

ในมุม PDPA บทสนทนาระหว่างลูกค้ากับ agent มักมีข้อมูลส่วนบุคคลอยู่แล้ว ถ้า agent ตัวหนึ่งถูกเจาะแล้วอ่านแชตของทุก agent ใน region ได้ ความเสียหายที่ต้องแจ้งจะครอบคลุมผู้ใช้ทุกระบบ ไม่ใช่แค่ระบบที่ถูกเจาะ ปี 2026 ที่องค์กรไทยกำลังเปิด agent ให้ลูกค้าใช้กันมาก ควรออกแบบ blast radius ให้เล็กตั้งแต่ตอนวางสถาปัตยกรรม เพราะแก้ทีหลังยากกว่ามาก

แหล่งข่าว

• AgentCorruption: Initial IMDS Access — Zenity Labs (8 ต.ค. 2026)
• AgentCorruption: One Role to Rule Them All — Zenity Labs
• AgentCorruption: Credential Theft from AWS Secrets Manager and More — Zenity Labs
• One public-facing AI agent on AWS could read, rewrite, and delete every other agent in the region — The Decoder (8 ต.ค. 2026)