AI Safety Incidents

พรอมป์ตเดียว เอเจนต์เดียว ทั้งบัญชี AWS: เจาะลึก AgentCorruption บน Amazon Bedrock AgentCore

ผู้เขียน

Elias Hawthorne

วันที่เผยแพร่

Oct 12, 2026

โมเดลล่าสุด · 20ดูโมเดลทั้งหมด →

เบนช์มาร์ก: Artificial Analysis · อัปเดตทุกวัน

กลับไปยังโพสต์ทั้งหมด

เมื่อวันที่ 8 ตุลาคม 2026 Zenity Labsได้เปิดเผยAgentCorruption: ชุดช่องโหว่ที่เชื่อมโยงกันเป็นลูกโซ่ในAmazon Bedrock AgentCore ซึ่งเป็นแพลตฟอร์มแบบจัดการของ AWS สำหรับปรับใช้และรันเอเจนต์ AI โดยช่องโหว่นี้ทำให้พรอมป์ภาษาธรรมชาติเพียงหนึ่งพรอมป์ที่ส่งไปยังเอเจนต์ที่เปิดให้เข้าถึงจากสาธารณะตัวเดียว สามารถเข้าควบคุมเอเจนต์ AgentCore ทุกตัวในบัญชี AWS และรีเจียนเดียวกันได้ งานวิจัยนี้เผยแพร่ควบคู่ไปกับการบรรยายที่SecTor 2026ในเมืองโทรอนโต ซึ่งTamir Ishay Sharbatผู้อำนวยการฝ่ายวิจัยด้านความปลอดภัยของ Zenity เป็นผู้นำเสนอ (Dark Reading, 8 ตุลาคม 2026) บทความของ Zenity เองซึ่งให้เครดิตแก่ Sharbat, Lana Salameh, Dmitry Lozovoy และ João Donato เปิดต้นด้วยกลไกดังนี้: เอเจนต์ AgentCore ที่มีเครื่องมือใดก็ตามที่สามารถส่งคำขอออกไปภายนอกได้ อาจถูกชี้นำให้เรียกAWS Instance Metadata Service (IMDS)ที่ที่อยู่ลิงก์-โลคัล 169.254.169.254 ซึ่งจะคืนข้อมูลรับรองชั่วคราวสำหรับบทบาทการทำงานของเอเจนต์ตัวนั้นเอง Zenity ระบุว่าได้ส่งออกข้อมูลรับรองเหล่านั้นไปยังเครื่องของตนและยืนยันว่าข้อมูลรับรองนั้นใช้งานได้จากที่นั่น ไม่มีการกำหนดหมายเลข CVE

คลังข้อมูลบันทึกสิ่งนี้ว่าเป็น ช่องโหว่ — สิ่งที่พบ ไม่ได้ถูกใช้ประโยชน์เสมอไป — ด้วย ระดับสูงของความรุนแรง, ความเชื่อมั่นระดับ A, ไม่มีการบันทึกความเสียหายที่เกิดขึ้นจริง และมีการยืนยันการมีส่วนร่วมของ AI ฝ่ายต่างๆ ไม่เห็นด้วยกับการตีความ แม้ว่าพวกเขาจะเห็นด้วยกับพฤติกรรม: AWS บอกกับ Dark Reading ว่างานวิจัย "พรรณนาพฤติกรรมที่คาดหวังและที่ได้รับการบันทึกไว้ว่าเป็นช่องโหว่อย่างไม่ถูกต้อง"

สิ่งที่เชนนั้นจริงๆ แล้วคืออะไร

AgentCore บรรจุเอเจนต์แต่ละตัวเป็นคอนเทนเนอร์และรันแบบต่อเซสชันใน Firecracker MicroVM. โพสต์แรกของ Zenity ในซีรีส์นี้จำลองการยึดเกาะทั้งหมดด้วยคำขอแบบภาษาธรรมดาไปยังเอเจนต์ทดสอบที่สร้างด้วย Strands SDK, เฟรมเวิร์กเอเจนต์โอเพนซอร์สของ AWS ซึ่งมาพร้อมเครื่องมือคำขอ HTTP ในตัวและเครื่องมือเชลล์ ไมโคร VM ไม่ได้จำกัดการรับส่งข้อมูลไปยังบริการเมทาดาทา ดังนั้นคำขอจึงมาจากภายในอินสแตนซ์และ IMDS ตอบกลับ นักวิจัยสำรวจปลายทางหลังจากนั้น: ชื่อบทบาท IAM, ข้อมูลรับรอง STS ชั่วคราวเอง, ปลายทาง user-data — ซึ่งส่งคืนรหัสบัญชี, ARN แบบเต็ม, URL รันไทม์ และของเอเจนต์ Amazon Elastic Container Registry (ECR) URI อิมเมจ — และแท็กอินสแตนซ์รวมถึงเชนใบรับรอง mTLS, คีย์ส่วนตัว และ URL ที่ลงลายมือชื่อล่วงหน้าไปยังที่จัดเก็บภายใน Zenity กล่าวว่าผลลัพธ์เดียวกันมาจากเครื่องมือเชลล์ เพราะความล้มเหลวในการแยกส่วนอยู่ที่ระดับแพลตฟอร์มมากกว่าในเครื่องมือใดเครื่องมือหนึ่ง

รายละเอียดสองอย่างในลำดับเหตุการณ์นั้นเป็นสิ่งที่อ่านผ่านได้ง่าย ข้อมูลรับรองไม่ได้ถูกจำกัดไว้ในแซนด์บ็อกซ์: Zenity ส่งข้อมูลเหล่านั้นออกไปนอก AgentCore และเรียกใช้การตรวจสอบตัวตนของ AWS ซึ่งตอบกลับมาเป็นบทบาทที่เอเจนต์สวมสิทธิ์ และบทบาทที่ถูกขโมยไปนั้นสามารถดึงคอนเทนเนอร์อิมเมจได้ ซึ่งเป็นช่องทางที่ทำให้ซอร์สโค้ดของเอเจนต์กลายเป็นสิ่งที่อ่านได้ โพสต์ของ Zenity ระบุว่า อิมเมจมักมีคีย์ที่ฝังตายตัว โทเคนที่ตกค้าง และการตั้งค่าที่ไม่ควรถูกฝังไว้ตั้งแต่แรก และอิมเมจที่ถูกดึงไปนั้นก็คือแผนผังของตรรกะทางธุรกิจที่อยู่เบื้องหลัง

บทบาทเริ่มต้นคือจุดที่จุดยึดเกาะกลายเป็นบัญชี

ข้อบกพร่องประการที่สอง ซึ่งมีรายงานแยกต่างหาก คือ execution role ที่ AgentCore ผูกให้กับเอเจนต์โดยค่าเริ่มต้นนั้นไม่ได้ถูกจำกัดขอบเขตไว้ที่เอเจนต์เพียงตัวเดียว Zenity อธิบายว่าสิทธิ์ต่าง ๆ ครอบคลุมไปถึงทรัพยากร AgentCore ทุกตัวในบัญชีและรีเจียน รวมถึง bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent และที่ปลายด้านข้อมูลรับรองของห่วงโซ่ bedrock-agentcore:GetResourceApiKey และ secretsmanager:GetSecretValue.

HTML card titled 'One prompt, one role, four capabilities', kicked 'AgentCorruption · the path Zenity Labs describes' and subtitled 'The studied attack path, with the AWS permission Zenity names at each step. No CVE was assigned; AWS disputes the vulnerability framing.' Four stacked bands run down the card. Step 1, 'Foothold through a chat message': a public-facing agent holding any tool that can make an outbound request is asked, in plain language, to fetch 169.254.169.254; the Firecracker MicroVM did not restrict traffic to the metadata service, so the request came from inside the instance and IMDS returned the agent's own execution-role credentials as a temporary STS key pair and session token. Step 2, 'Every agent in the account and region': permissions logs:DescribeLogGroups and region-wide ECR read; agent IDs were derived from CloudWatch log groups named /aws/bedrock-agentcore/runtimes/AGENT_ID-ENDPOINT_NAME, and ECR repository names followed the convention bedrock-agentcore-AGENT_NAME, so every agent's container image and source code could be pulled. Step 3, 'Conversations, sessions and persistence': permissions InvokeAgentRuntime, ListEvents, ListActors, ListSessions, CreateEvent, DeleteEvent and GetMemory; read private conversations across users and sessions, invoke internal agents, inject an assistant-role event into a live session, and plant a memory that sends the agent to an attacker-controlled page before each answer. Step 4, 'Credentials outside AWS': permissions secretsmanager:GetSecretValue and bedrock-agentcore:GetResourceApiKey; provider names recovered from scraped agent source code or by enumerating 2 x (10+26)^5 = 120,932,352 likely default names, reaching API keys and OAuth secrets for third-party services. A footer reads 'Steps and permissions as described by Zenity Labs on 8 October 2026. AWS states the behaviour described is documented and expected, and disputes the vulnerability framing. Card rendered by OrcaRouter.'

ความสามารถในการแจกแจงเปลี่ยนไวลด์การ์ดเหล่านั้นให้เป็นรายการเป้าหมาย Zenity ใช้สิทธิ์ของบทบาทlogs:DescribeLogGroups เพราะ AgentCore ตั้งชื่อกลุ่มบันทึก CloudWatch ของเอเจนต์แต่ละตัวเป็น/aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME} และได้มาซึ่ง ID ของเอเจนต์จากชื่อกลุ่มบันทึกเหล่านั้น ชื่อรีโพซิทอรี ECR เป็นไปตามรูปแบบที่นักวิจัยสังเกตพบ — bedrock-agentcore-<agent_name> — ดังนั้นอิมเมจของเอเจนต์ทุกตัวในภูมิภาคนี้จึงสามารถดึงได้ ทรัพยากรหน่วยความจำถูกค้นพบในลักษณะเดียวกัน จากรูปแบบกลุ่มบันทึก /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID} และสิทธิ์ของบทบาท ListActors, ListSessions และ ListEvents ได้สร้างตัวระบุ actor และ session ที่จำเป็นสำหรับการอ่านเนื้อหาบทสนทนา

บทวิเคราะห์ของ Zenity นำเสนอตัวอย่างการเคลื่อนที่ด้านข้าง (lateral movement) ที่เป็นรูปธรรม: การเข้าถึงผ่านเอเจนต์ที่เปิดสู่สาธารณะ ค้นพบเครื่องมือของ billing_agent ในภูมิภาคเดียวกัน พบไฟล์ชื่อ billing.json และขโมยไฟล์นั้นออกไปผ่านเครื่องมืออ่านไฟล์ ข่าวประชาสัมพันธ์ระบุสถานการณ์เดียวกันในลักษณะกว้าง ๆ — ผู้โจมตีที่เข้าผ่านเอเจนต์บริการลูกค้าที่เชื่อมต่ออินเทอร์เน็ตสามารถเคลื่อนไปยังเอเจนต์การเงินภายในที่ติดตั้งในภูมิภาคเดียวกัน เรียกใช้มัน และเข้าถึงข้อมูล เครื่องมือ ข้อมูลรับรองที่เกี่ยวข้อง และบทสนทนาส่วนตัวของมัน

ความทรงจำคือส่วนที่อยู่ยืนยาวกว่าสิ่งกระตุ้น

AgentCore Memory เก็บการสนทนาไว้เป็นหน่วยความจำระยะสั้น และจัดเก็บบันทึกที่สกัดได้เป็นหน่วยความจำระยะยาว โดยใช้กลยุทธ์ที่ชื่อ SEMANTIC, USER_PREFERENCE, SUMMARIZATION และ EPISODIC. Zenity ใช้ CreateEvent เพื่อเขียนเหตุการณ์การสนทนาลงในทรัพยากรหน่วยความจำของเอเจนต์อื่น โพสต์ของมันระมัดระวังเกี่ยวกับสิ่งที่ primitive นั้นทำได้และทำไม่ได้: CreateEvent ไม่อนุญาตให้ผู้เรียกเลือก namespace ระยะยาวหรือเขียนทับบันทึกโดยตรง — กลยุทธ์ที่กำหนดค่าไว้ของหน่วยความจำเป้าหมายเป็นตัวตัดสินว่าอะไรจะถูกสกัดและไปอยู่ที่ไหน Zenity ยังอธิบาย DeleteEvent ถูกใช้เพื่อลบเหตุการณ์ผลลัพธ์ของเครื่องมือ เพื่อให้เอเจนต์สรุปผิดจากข้อมูลที่หายไป และเพื่อปกปิดร่องรอยโดยการลบเหตุการณ์ที่สร้างหน่วยความจำขึ้นมา

สิ่งที่ write primitive ก่อขึ้นคือความคงอยู่ การสาธิตของ Zenity ได้ฝังคำขอให้เอเจนต์ดึงหน้าเว็บที่นักวิจัยควบคุมก่อนที่จะตอบ และทำตามเนื้อหาของหน้านั้น — จุดปลายทางการบัญชาการและควบคุมซึ่งคำสั่งสามารถเปลี่ยนแปลงได้โดยไม่ต้องฝังความจำอื่น ช่องทางเดียวกันนั้นได้นำเนื้อหาบทสนทนาออกไป: บทความบรรยายว่าเอเจนต์ส่งข้อความของผู้ใช้และการตอบกลับของตัวเองไปยังจุดปลายทางการรวบรวม และระบุว่าสิทธิ์ของความจำบนบทบาทนั้นขยายไปทั่วบัญชีและภูมิภาค ไม่ใช่เพียงแค่เอเจนต์ที่ถูกบุกรุกเท่านั้น วิดีโอที่เผยแพร่พร้อมกับงานวิจัยแสดงให้เห็นผู้ใช้กำลังสนทนาต่อในขณะที่เนื้อหานั้นไปถึงเซิร์ฟเวอร์ของนักวิจัย

ข้อมูลรับรองนอกเหนือจาก AWS

โพสต์สุดท้ายในซีรีส์นี้ปิดวงจรในเรื่องเครื่องมือที่เชื่อมต่อกัน AgentCore Identity และ Outbound Auth จัดเก็บข้อมูลรับรองของเครื่องมือเป็นความลับใน AWS Secrets Manager ภายใต้ชื่อที่สร้างขึ้นจากชื่อผู้ให้บริการและรูปแบบคงที่ เช่น bedrock-agentcore-identity!default/apikey/{provider_name} Zenity กู้คืนชื่อผู้ให้บริการได้โดยการดึงข้อมูลจากซอร์สโค้ดของเอเจนต์ที่มันดึงมาจาก ECR แล้ว และกู้คืนชื่ออื่น ๆ ด้วยการบรูตฟอร์ซ โดยรายงานว่าคำต่อท้ายห้าตัวอักษรที่เป็นค่าเริ่มต้นนั้นถูกสร้างขึ้นฝั่งไคลเอนต์จากตัวเลขและตัวอักษรพิมพ์เล็ก ให้ 2 x (10+26)^5 = 120,932,352 ชุดค่าผสมในผู้ให้บริการทั้งสองประเภท ด้วยอัตราการส่งคำขอที่มันทำได้อย่างต่อเนื่องกับ Secrets Manager Zenity กล่าวว่าการแจกแจงให้ครบทั้งหมดใช้เวลาหลายชั่วโมง — นานกว่าอายุของข้อมูลรับรอง STS — ดังนั้นมันจึงสร้างลูปที่สอบถามปลายทาง IMDS ของเอเจนต์ซ้ำเพื่อขอข้อมูลรับรองใหม่เมื่อของเก่าหมดอายุ Zenity เสริมอีกว่าตัวแปรสภาพแวดล้อมสามารถอ่านได้ผ่านปลายทางข้อมูลเมตา user-data โดยทุกชื่อมีคำนำหน้า CONTAINER_ENV_ รวมถึงคีย์ที่เอเจนต์ใช้ในการยืนยันตัวตนกับผู้ให้บริการโมเดลของมัน และการเรียกใช้เอเจนต์แต่ละตัวที่ค้นพบด้วยพรอมป์ที่เหมาะสมก็เก็บเกี่ยวค่าเหล่านั้นได้ในวงกว้าง

เป็นที่ยอมรับ และถูกโต้แย้งในทางเทคนิค

สิ่งที่ได้รับการยืนยันนั้นแคบและเฉพาะเจาะจง เอเจนต์ของ AgentCore สามารถเข้าถึง IMDS และรับข้อมูลรับรองชั่วคราวของบทบาทการเรียกใช้ของตนเองได้ — AWS ไม่ได้โต้แย้งเรื่องนี้ โดยระบุในแถลงการณ์ว่า "เป็นสิ่งที่บันทึกไว้และคาดหมายไว้" บทบาทการเรียกใช้เริ่มต้นมีสิทธิ์ที่จำกัดขอบเขตไว้ที่บัญชีและภูมิภาค มากกว่าที่จะจำกัดไว้ที่เอเจนต์ตัวเดียว AWS ได้เปลี่ยนแปลงสิ่งนี้ไปแล้ว และ Zenity กล่าวว่าการทดสอบของบริษัทเองยืนยันถึงการลดขอบเขตดังกล่าว งานวิจัยนี้เป็นการสาธิต ไม่ใช่แคมเปญที่ถูกสังเกตพบ: Sharbat บอกกับ Dark Reading ว่า Zenity ไม่พบหลักฐานว่าช่องโหว่ดังกล่าวถูกใช้ประโยชน์ในสภาพจริงก่อนการแก้ไข โดยให้เหตุผลส่วนหนึ่งว่าเป็นเพราะความยากลำบากในการระบุว่าองค์กรใดที่รันเอเจนต์บน AgentCore และเสริมว่าเขา "มั่นใจ 100% ว่ามีวิธีที่จะทำได้"

ประเด็นที่ถกเถียงกันคือว่าสิ่งใดสิ่งหนึ่งในนั้นควรถูกเรียกว่าช่องโหว่หรือไม่ แถลงการณ์ของ AWS ที่ให้ไว้กับ Dark Reading และ The Next Web ระบุว่า "AWS ทราบดีถึงงานวิจัยที่เผยแพร่เกี่ยวกับ Amazon Bedrock AgentCore ซึ่งนำเสนอพฤติกรรมที่คาดหวังและมีเอกสารกำกับไว้อย่างไม่ถูกต้องว่าเป็นช่องโหว่ เอเจนต์สามารถเข้าถึงทรัพยากรในบัญชี AWS อื่นได้ก็ต่อเมื่อนักพัฒนามอบสิทธิ์อย่างชัดเจนทั้งในบทบาทการทำงานของเอเจนต์และทรัพยากรเป้าหมาย" แถลงการณ์ของ AWS ที่ถูกนำมาอ้างในโพสต์ของ Zenity เองยังคงสาระสำคัญของประโยคแรก — "พฤติกรรมที่อธิบายไว้เป็นสิ่งที่มีเอกสารกำกับและเป็นสิ่งที่คาดหวังไว้" — และเสริมว่าลูกค้าควรให้สิทธิ์แก่บทบาทการทำงานเท่าที่เอเจนต์ของตนจำเป็นต้องใช้เท่านั้น มีสองประเด็นที่อยู่ภายใต้ความขัดแย้งนี้ AWS กำหนดขอบเขตในแง่ของการเข้าถึงทรัพยากรในบัญชี AWS อื่น ในขณะที่สิ่งที่ Zenity ค้นพบเกี่ยวข้องกับเอเจนต์ภายในบัญชีและภูมิภาค AWS เดียวกัน และบทบาทที่ Zenity อธิบายนั้นมาจากค่าตั้งต้นของแพลตฟอร์มมากกว่าที่ลูกค้าจะเขียนนโยบายด้วยตนเอง

การแก้ไขข่าวของ The Next Web ต่อเรื่องราวของตนเองนั้นน่าจดบันทึกไว้ เพราะมันแสดงให้เห็นว่าข้อกล่าวอ้างนั้นถูกทำให้รัดกุมขึ้นโดยคนอื่นที่ไม่ใช่นักวิจัย เดิมทีสำนักข่าวนี้รายงาน และต่อมาได้แก้ไข พาดหัวข่าวที่กล่าวว่านักวิจัยได้ยึดครองเอเจนต์ AgentCore ทุกตัวในภูมิภาคหนึ่ง โดยฉบับที่แก้ไขระบุว่างานวิจัยดังกล่าวครอบคลุมเอเจนต์ภายในบัญชี AWS เพียงบัญชีเดียวและภูมิภาคเดียว และตั้งข้อสังเกตว่พาดหัวข่าวก่อนหน้านี้ได้นำเสนอข้อกล่าวอ้างของนักวิจัยเสมือนเป็นข้อเท็จจริง

ไทม์ไลน์การเปิดเผยข้อมูล

HTML card titled 'How the disclosure ran, and what AWS changed', subtitled 'Two reports, filed on different dates and answered separately. Dates as published by Zenity Labs and as reported by Dark Reading and The Next Web.' Eight rows run down a vertical timeline. 25 December 2025: Zenity Labs reports the IMDS access issue to AWS, report number one. 12 January 2026: Zenity Labs files a second report covering the over-privileged default execution role and the resulting blast radius. 14 February 2026: per AWS, as reported by Zenity, newly deployed AgentCore agents launch with IMDSv2 only, which requires a session token on each request. 25 February 2026: AWS tells Zenity the team is working on the underlying role issue, and the default execution role stays the same. 12 April 2026: AWS closes report number one as 'informative', noting the February IMDSv2 change. 22 June 2026: Zenity reviews the default execution role again and confirms its permissions are unchanged. 29 September 2026: the final pre-publication review finds substantial changes, with permissions to invoke other agents, read private conversations and access Secrets Manager removed and other permissions significantly restricted. 8 October 2026: research, press release and SecTor 2026 talk in Toronto; AWS gives its statement to press the same day; no CVE was assigned. A footer reads 'Timeline per Zenity Labs' disclosure notes, with AWS's IMDSv2 date as reported by Zenity and Dark Reading. Card rendered by OrcaRouter.'

Zenity ยื่นรายงานสองฉบับแทนที่จะเป็นฉบับเดียว และทั้งสองได้รับคำตอบที่แตกต่างกัน รายงานเกี่ยวกับการเข้าถึง IMDS ถูกส่งเมื่อ25 ธันวาคม 2025 AWS ปิดรายงานดังกล่าวเมื่อ12 เมษายน 2026 โดยระบุว่าเป็น "informative" พร้อมเขียนว่า AgentCore ใช้ IMDSv2 เท่านั้นตั้งแต่14 กุมภาพันธ์ 2026 โดยเอเจนต์ที่ติดตั้งใช้งานใหม่จะเริ่มทำงานในลักษณะนั้น การแก้ไขดังกล่าวมีความสำคัญต่อรายละเอียดเฉพาะของการวิจัยนี้ เพราะ IMDSv2 กำหนดให้ต้องมีโทเค็นเซสชันในทุกคำขอ และทำให้การดึงข้อมูลแบบไม่ยืนยันตัวตนธรรมดาที่นักวิจัยใช้เพื่อรับข้อมูลรับรองนั้นใช้ไม่ได้ รายงานฉบับที่สอง เกี่ยวกับบทบาทเริ่มต้นและขอบเขตผลกระทบ ถูกส่งเมื่อ12 มกราคม 2026 AWS แจ้ง Zenity เมื่อ25 กุมภาพันธ์ 2026 ว่าทีมงานกำลังดำเนินการอยู่ โดยบทบาทยังคงเป็นเช่นเดิม Zenity ตรวจสอบบทบาทอีกครั้งเมื่อ22 มิถุนายน 2026 และพบว่าสิทธิ์การใช้งานไม่เปลี่ยนแปลง การตรวจสอบครั้งสุดท้ายเมื่อ29 กันยายน 2026 พบว่าบทบาทถูกจำกัดขอบเขตลงอย่างมาก และข่าวประชาสัมพันธ์ของ Zenity ระบุว่าการนำออกนั้นครอบคลุมถึงการเรียกใช้เอเจนต์อื่น การอ่านบทสนทนาส่วนตัว และการเข้าถึงความลับใน AWS Secrets Manager โดยสิทธิ์อื่น ๆ ก็ถูกจำกัดอย่างมีนัยสำคัญเช่นกัน โพสต์ของ Zenity เองระบุว่า AWS ได้กำหนดให้ IMDSv2 เป็นค่าเริ่มต้นสำหรับการติดตั้งใช้งาน AgentCore แล้ว และทั้งสองฝ่ายได้ร่วมมือกันตลอดกระบวนการ

อะไรที่ยังไม่เป็นที่รู้จัก

Zenity ยังไม่ได้เผยแพร่ว่ามีเอเจนต์หรือองค์กรจำนวนเท่าใดที่ทำงานด้วยบทบาทเริ่มต้นในช่วงระหว่างการเปลี่ยนแปลง IMDSv2 ในเดือนกุมภาพันธ์และการจำกัดวงให้แคบลงในช่วงปลายเดือนกันยายน และไม่มีข้อความใดในแหล่งอ้างอิงที่ระบุว่าข้อมูลลูกค้าใดถูกเปิดเผยออกไปนอกสภาพแวดล้อมของนักวิจัยเอง การเปลี่ยนแปลง IMDSv2 มีผลกับเอเจนต์ที่ติดตั้งใช้งานหลังวันที่ 14 กุมภาพันธ์ 2026 ตามข้อมูลของ AWS ที่ Zenity รายงาน สิ่งที่มันหมายถึงสำหรับเอเจนต์ที่ติดตั้งใช้งานก่อนวันนั้นไม่ได้ระบุไว้ในแหล่งข้อมูลที่ตรวจสอบที่นี่ คลังข้อมูลไม่บันทึกความเสียหายที่แท้จริง และแหล่งข้อมูลสนับสนุนการตีความดังกล่าวโดยการอธิบายถึงการสาธิต และโดยที่ AWS โต้แย้งป้ายกำกับช่องโหว่แทนที่จะรายงานเหตุการณ์ของตนเอง

Sharbat บอกกับ Dark Reading ว่า Zenity กำลังตรวจสอบแพลตฟอร์มคลาวด์อื่น ๆ สำหรับปัญหาการเข้าถึงเมทาดาทาในลักษณะเดียวกัน และบริษัทยังไม่เปิดเผยชื่อแพลตฟอร์มเหล่านั้น ข้อสรุปที่เขาระบุนั้นเกี่ยวกับสิทธิ์การเข้าถึงมากกว่าจะเกี่ยวกับบริการเมทาดาทาเพียงอย่างเดียว: "แม้ว่ามีคนเข้าถึง IMDS ได้ รัศมีความเสียหายก็จะเล็กลงมาก"

เหตุใดจึงเก็บบันทึกนี้ไว้

AgentCorruption ไม่ได้น่าจับตามองเพราะ metadata endpoint เป็นแนวคิดใหม่ Sharbat ชี้ให้ผู้ชม SecTor ไปที่เหตุการณ์ข้อมูลรั่วไหลของ Capital One ในปี 2019 ซึ่ง SSRF เข้าถึง IMDS และกลายเป็นข้อมูลรับรองที่ถูกขโมย และอธิบายว่านั่นเป็นความล้มเหลวด้านการให้สิทธิ์ขั้นต่ำแบบเดียวกัน สิ่งที่ใหม่คือผู้กระทำที่ทำการดึงข้อมูล คำขอที่สร้าง AWS identity ขึ้นมาถูกส่งโดย AI agent ที่ทำตามสิ่งที่มันถูกขอด้วยภาษาธรรมชาติ ผ่านเครื่องมือที่มันได้รับมาเพื่อให้มันมีประโยชน์ — และ agent ก็ส่งต่อคำตอบกลับไป สองเงื่อนไขที่ทำให้เรื่องนั้นกลายเป็นปัญหาระดับบัญชีคือ metadata endpoint ที่ sandbox ไม่ได้บล็อก และ default role ที่มีสิทธิ์กว้างกว่า agent ที่ถือมันอยู่

งานวิจัยฉบับเต็ม ซึ่งรวมถึงชุดบทความทางเทคนิคห้าตอนและวิดีโอสาธิต มีลิงก์เชื่อมจากข่าวประชาสัมพันธ์ของ Zenity ลงวันที่ 8 ตุลาคม 2026 บันทึกนี้เป็นรายการหนึ่งในบรรดาเหตุการณ์เอเจนต์ที่ได้รับการบันทึกไว้ในคลังเหตุการณ์ AI โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง เกรดความเชื่อมั่น และธงข้อโต้แย้งเป็นของตนเอง — ฟิลด์เหล่านี้ทำให้สามารถแยกข้อโต้แย้งของผู้จำหน่ายเกี่ยวกับการวางกรอบ ดังเช่นในกรณีนี้ ออกจากข้อค้นพบเรื่องความเสียหายที่ยังเป็นที่ถกเถียงได้

นี่คือบันทึกหนึ่งรายการ ซึ่งได้รับการวิจัยและรายงานโดยผู้อื่น และถูกอ้างอิงไว้ที่นี่โดยให้เครดิตแก่พวกเขา เหตุการณ์เอเจนต์ที่มีการบันทึกไว้รายการอื่น ๆ ซึ่งแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง ระดับความเชื่อมั่น และแฟล็กข้อโต้แย้งของตนเอง อยู่ในคลังเหตุการณ์ AI — ดังนั้นค่าเริ่มต้นของแพลตฟอร์มที่เปลี่ยนพรอมต์เดียวให้กลายเป็นฐานที่มั่นครอบคลุมทั้งบัญชี จึงสามารถอ่านเทียบกับสิ่งที่เกิดขึ้นจริงในที่อื่นได้

พรอมป์ตเดียว เอเจนต์เดียว ทั้งบัญชี AWS: เจาะลึก AgentCorruption บน Amazon Bedrock AgentCore

สิ่งที่เชนนั้นจริงๆ แล้วคืออะไร

บทบาทเริ่มต้นคือจุดที่จุดยึดเกาะกลายเป็นบัญชี

ความทรงจำคือส่วนที่อยู่ยืนยาวกว่าสิ่งกระตุ้น

ข้อมูลรับรองนอกเหนือจาก AWS

เป็นที่ยอมรับ และถูกโต้แย้งในทางเทคนิค

ไทม์ไลน์การเปิดเผยข้อมูล

อะไรที่ยังไม่เป็นที่รู้จัก

เหตุใดจึงเก็บบันทึกนี้ไว้

ผลิตภัณฑ์

ทรัพยากร

สำหรับผู้ให้บริการ

เข้าร่วมคอมมูนิตี้ของเรา

จากบล็อก

ผู้ให้บริการโมเดล