Zenity เผย AgentCorruption: แชตบอตหน้าร้านเข้าถึงเอเจนต์หลังบ้านได้

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

งานวิจัยชื่อ AgentCorruption ครอบคลุมการอ่านบทสนทนาส่วนตัวและข้อมูลสำหรับเชื่อมต่อบริการอื่น Zenity ระบุว่าประเด็นที่เผยแพร่ได้รับการแก้ไขแล้ว แต่ AWS โต้แย้งการเรียกพฤติกรรมนี้ว่าช่องโหว่ ตามรายงาน The Next Web เรื่องนี้จึงควรอ่านทั้งผลทดลองและขอบเขตสิทธิ์ที่บริษัทของคุณตั้งไว้

สรุป 30 วินาที: เกิดอะไรขึ้น

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

ข้อมูลนั้นผูกกับ IAM role หรือชุดสิทธิ์ที่กำหนดว่าระบบทำอะไรได้บ้าง ปัญหาที่ Zenity รายงานคือชุดสิทธิ์เริ่มต้นกว้างเกินเอเจนต์ต้นทาง จึงใช้เรียกเอเจนต์อื่น อ่านบทสนทนา และเข้าถึงข้อมูลลับในบัญชีและภูมิภาคเดียวกันได้ ตามประกาศของบริษัท

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

ข่าวนี้เป็นการเปิดเผยงานทดลองของนักวิจัย ไม่ใช่รายงานว่าลูกค้าทุกรายถูกเจาะแล้วครับ ในแหล่งข้อมูลที่ใช้เขียนบทความนี้ยังไม่มีรายละเอียดเหตุข้อมูลรั่วของลูกค้าไทย จึงไม่ควรเอาผลสาธิตไปตีความว่าแชตบอตทุกตัวที่คุณใช้กำลังส่งข้อมูลออกนอกบริษัท

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

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

บอตหน้าร้านควรอ่านประวัติแชตของผู้ช่วยการเงินได้ด้วยหรือ? คำถามนี้ช่วยเปลี่ยนการตรวจรับงานจากดูว่าแชตตอบเก่งแค่ไหน ไปเป็นตรวจว่าสิทธิ์ที่ได้รับเหมาะกับหน้าที่หรือเปล่า สำหรับผู้ใช้งานทั่วไป คำตอบควรมาจากทีมที่ดูแลระบบ ไม่ต้องลองส่งคำสั่งเสี่ยงเพื่อพิสูจน์เอง

ทำงานยังไง

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

บริการนั้นชื่อ IMDS เป็นบริการภายในที่ให้ข้อมูลเกี่ยวกับเครื่อง และให้ข้อมูลรับรองสิทธิ์ชั่วคราวสำหรับงานที่กำลังทำงานอยู่ Zenity พบว่าเมื่อข้อมูลรับรองนี้ออกมาถึงผู้วิจัย ก็สามารถนำไปใช้สิทธิ์ตามบทบาทของเอเจนต์ได้ ตามคำอธิบายกลไกของ Zenity Labs คำว่า “ชั่วคราว” จึงอธิบายอายุของข้อมูลรับรอง ไม่ได้บอกว่าสิทธิ์นั้นแคบแค่ไหน

ปัญหาต่อมาคือ execution role หรือชุดสิทธิ์สำหรับให้เอเจนต์ทำงาน มีขอบเขตครอบคลุมทรัพยากรของ AgentCore ในบัญชีและภูมิภาคเดียวกัน Zenity ระบุว่าใช้สิทธิ์นั้นค้นพบเอเจนต์อื่น แล้วเข้าถึงระบบภายในที่ไม่ได้รับอนุญาตให้สนทนาด้วย ตามบทวิจัยเรื่องสิทธิ์เริ่มต้น

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

Zenity ยังรายงานว่าเข้าถึง container image หรือชุดไฟล์ที่บรรจุโปรแกรมเอเจนต์ไว้สำหรับนำไปรัน จึงอ่านโค้ดต้นฉบับได้ด้วย นอกจากบทสนทนาแล้ว ยังดึงข้อมูลรับรองสำหรับบริการอื่นจาก AWS Secrets Manager ซึ่งเป็นบริการเก็บข้อมูลลับของระบบ ตามประกาศผลการทดสอบ

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

จุดหักมุม: แก้แล้ว แต่คำว่า “ช่องโหว่” ยังเห็นต่าง

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

แต่ AWS บอก The Next Web ว่างานวิจัยนำพฤติกรรมที่คาดหมายและมีเอกสารกำกับมาอธิบายเป็นช่องโหว่อย่างไม่ถูกต้อง พร้อมย้ำหลักให้สิทธิ์เท่าที่จำเป็น ตามคำชี้แจงของโฆษก AWS ดังนั้น “มีการเปลี่ยนสิทธิ์” กับ “ผู้ให้บริการยอมรับว่าเป็นช่องโหว่” เป็นคนละข้อสรุป

เรื่องเงิน / ผลกระทบ

แหล่งข่าวไม่ได้ให้ยอดความเสียหายหรือค่ากู้ระบบของลูกค้าไทยครับ ผลกระทบที่มีหลักฐานในงานวิจัยคือการเข้าถึงข้อมูลและความสามารถของเอเจนต์อื่น Zenity ระบุว่าข้อมูลลับที่ดึงได้รวมถึง API key หรือรหัสสำหรับให้โปรแกรมเรียกบริการ และ OAuth token หรือข้อมูลรับรองที่ใช้สิทธิ์เชื่อมต่อบริการ ตามประกาศของ Zenity

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

อีกผลกระทบคือความน่าเชื่อถือของงานที่ผู้ช่วยทำให้ The Next Web รายงานการสาธิตที่ผู้ใช้ยังสนทนากับเอเจนต์ตามปกติ ขณะเอเจนต์ส่งบทสนทนาไปยังเซิร์ฟเวอร์ของผู้วิจัย ตามรายงานของสื่อ ผลสาธิตนี้ชี้ถึงการเปลี่ยนพฤติกรรมที่อาจไม่เห็นจากหน้าจอแชตเพียงอย่างเดียว

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่ง Zenity ชี้ที่สิทธิ์เริ่มต้นและการแบ่งขอบเขตระบบ Michael Bargury ผู้ร่วมก่อตั้งและประธานเจ้าหน้าที่เทคโนโลยีของ Zenity อธิบายว่าการให้อิสระแก่เอเจนต์มีความตึงเครียดกับการจำกัดสิทธิ์บนคลาวด์ Zenity มองว่าการเชื่อมช่องทางเข้าถึงข้อมูลรับรองกับบทบาทที่กว้างเกินไป ทำให้เอเจนต์ตัวเดียวเปิดทางถึงสภาพแวดล้อมที่ใหญ่กว่า ตามประกาศงานวิจัย

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

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

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

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

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

Zenity สังเกตเห็นการเปลี่ยนสิทธิ์ครั้งสำคัญเมื่อ 29 กันยายน 2026 โดยสิทธิ์เรียกเอเจนต์อื่น อ่านบทสนทนาส่วนตัว และเข้าถึง Secrets Manager ในขอบเขตกว้างถูกนำออก ตามการตรวจครั้งสุดท้ายก่อนเผยแพร่ วันนี้เป็นวันที่ผู้วิจัยพบการเปลี่ยนแปลง จึงไม่ควรเรียกว่าเป็นวันเริ่มแก้จริงโดยไม่มีหลักฐานเพิ่ม

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

แล้วเราควรทำอะไร

คนทั่วไปและพนักงานที่ใช้ผู้ช่วยในงาน

1. ขอให้ทีมดูแลระบุว่าผู้ช่วยที่ใช้ทำงานอยู่บน AgentCore หรือบริการอื่น อย่าเหมารวมแชตบอตทุกเจ้าเป็นระบบเดียวกัน บทวิจัยนี้เจาะจง AgentCore ตามZenity Labs
2. ก่อนส่งเอกสารลูกค้าหรือข้อมูลภายใน ให้ขอคำยืนยันว่าเครื่องมือได้รับอนุมัติสำหรับข้อมูลประเภทนั้น นี่เป็นคำแนะนำป้องกัน เพราะงานวิจัยแสดงการอ่านบทสนทนาส่วนตัวได้ ตามประกาศของ Zenity
3. หากต้องแจ้งความผิดปกติ ให้บอกชื่อผู้ช่วยและงานที่กำลังทำกับทีมดูแลผ่านช่องทางขององค์กร ไม่ต้องทดลองคำสั่งโจมตีเพื่อเก็บหลักฐานเอง

เจ้าของธุรกิจไทยที่จ้างผู้ขายหรือผู้รับเหมาดูแล

1. ขอชื่อ IAM role ที่เอเจนต์รับลูกค้าใช้ และรายการทรัพยากรที่บทบาทนั้นเข้าถึงได้ ให้ผู้ขายแสดงว่าขอบเขตตรงกับหน้าที่ ตามหลักสิทธิ์เท่าที่จำเป็นซึ่ง AWS แนะนำผ่าน The Next Web
2. ขอผลตรวจหลังการเปลี่ยนสิทธิ์ที่ Zenity พบในเดือนกันยายน แยกบทบาทเริ่มต้นออกจากบทบาทที่ผู้ขายแก้เอง อย่ารับเพียงคำตอบว่าผู้ให้บริการแก้แล้วโดยไม่มีผลตรวจระบบของคุณ
3. กำหนดผู้รับผิดชอบหากต้องเปลี่ยนข้อมูลลับหรือตรวจความจำเอเจนต์ก่อนเปิดใช้งานจริง ข้อเสนอนี้ช่วยให้ทีมตัดสินใจได้โดยไม่ต้องรอถกกันหลังพบเหตุ

ทีม IT และนักพัฒนา โดยเฉพาะงานทดลองก่อนใช้งานจริง

1. ตรวจ execution role ของแต่ละเอเจนต์ แล้วลดให้เหลือสิทธิ์ที่งานนั้นจำเป็นต้องใช้ หลัก least privilege หมายถึงให้สิทธิ์น้อยที่สุดเท่าที่ทำงานได้ ซึ่งเป็นคำแนะนำของ AWS ในคำชี้แจง
2. อย่าเปิดเอเจนต์ต่ออินเทอร์เน็ตสาธารณะพร้อมบทบาทที่ครอบคลุมระบบภายในกว้างๆ ตรวจสิทธิ์อ่านบทสนทนา เรียกเอเจนต์อื่น อ่านชุดไฟล์โปรแกรม และอ่านข้อมูลลับเป็นรายหน้าที่ นี่เป็นข้อเสนอป้องกันจากขอบเขตที่ Zenity ทดสอบพบ
3. ทบทวนค่าเริ่มต้นของ AgentCore หลังการแก้ไข แล้วตรวจบทบาทเดิมขององค์กรด้วยตนเอง บันทึกสิทธิ์ที่ยังจำเป็นและเหตุผลไว้ เพื่อให้ตรวจรับงานได้โดยไม่อาศัยชื่อบริการเพียงอย่างเดียว
4. หากพบเหตุหรือสงสัยว่าข้อมูลรับรองหลุด ให้เปลี่ยนข้อมูลลับที่เกี่ยวข้องและทบทวนการเชื่อมต่อบริการภายนอก ควรตรวจความจำของเอเจนต์ด้วย เพราะ Zenity รายงานการฝังคำสั่งที่อยู่ข้ามการสนทนา ขั้นนี้เป็นคำแนะนำรับมือ ไม่ใช่การยืนยันว่าระบบคุณถูกเจาะ

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

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

ถ้าบริษัทคุณมีแชตบอตรับลูกค้า วันนี้ผู้ดูแลบอกได้ชัดหรือยังว่ามันมีสิทธิ์อ่านข้อมูลของผู้ช่วยภายในตัวไหนบ้าง?

Recap

• เกิดอะไรขึ้น: Zenity รายงานการเข้าถึงเอเจนต์อื่นผ่านเอเจนต์สาธารณะ ภายในบัญชี AWS และภูมิภาคเดียวกัน ตามประกาศงานวิจัย
• ตัวเลขที่จำ: คำสั่งแชตหนึ่งคำสั่งในผลทดลองของ Zenity แปลว่าเริ่มจากจุดรับข้อความเดียวแล้วขยายผลผ่านสิทธิ์เริ่มต้นได้ ตามบทสรุป Zenity Labs
• ใครเห็นต่าง: Zenity เรียกเป็นห่วงโซ่ข้อบกพร่อง ส่วน AWS โต้ว่าเป็นพฤติกรรมตามเอกสาร ตามThe Next Web
• ยังไม่รู้: สถานะบทบาทเก่าของแต่ละองค์กรและรายละเอียดการโจมตีลูกค้าจริง รวมถึงยังไม่มีหลักฐานเหตุข้อมูลรั่วของลูกค้าไทยในแหล่งที่ใช้
• กระทบคุณอย่างไร: หากธุรกิจไทยใช้ AgentCore ให้ขอขอบเขต IAM role ของเอเจนต์หน้าร้าน ตรวจข้อมูลลูกค้าและบริการภายนอกที่เกี่ยวข้อง
• จับตาต่อ: ตรวจสิทธิ์ปัจจุบันหลังการแก้ไข และตรวจความจำเมื่อสงสัยเหตุ อย่าใช้ข่าวว่าแก้แล้วแทนผลตรวจของระบบตัวเอง
• แหล่งอ้างอิง: 1 — Zenity press release, 2 — Zenity Labs ภาพรวม, 3 — The Next Web, 4 — Zenity Labs สิทธิ์เอเจนต์