สรุปสั้น

บทความวิเคราะห์ที่เผยแพร่บน The Hacker News ชี้ว่าความเสี่ยงจากเอเจนต์ AI ในองค์กรได้ย้ายจากเอเจนต์ที่องค์กรเลือกใช้เอง ไปสู่เอเจนต์ที่มากับซอฟต์แวร์ของบุคคลที่สามซึ่งองค์กรใช้อยู่แล้ว โดยอ้างรายงาน 2026 State of Agent Security Report ว่าในสภาพแวดล้อมที่ศึกษา มีผลิตภัณฑ์บุคคลที่สามราว 1,280 ตัวที่ฝัง AI แต่มีเพียงราว 282 ตัวที่อยู่หลัง single sign-on (SSO) อีกราวพันตัวจึงมองไม่เห็นจากโครงสร้างพื้นฐาน identity ตั้งแต่ต้น ไม่ใช่เพราะมีใครซ่อน แต่เพราะระบบ identity ควบคุมได้เฉพาะสิ่งที่ยืนยันตัวตนผ่านมันเท่านั้น และเอเจนต์ส่วนใหญ่ไม่เคยผ่าน

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

รายละเอียดข่าว

เว็บไซต์ The Hacker News เผยแพร่บทความนี้เมื่อวันที่ 10 ตุลาคม พ.ศ. 2569 ผู้เขียนยกตัวอย่าง Slack Code ของบริษัท Salesforce ที่เปิดตัวเมื่อสิงหาคม 2569 ซึ่งให้ผู้ใช้แท็กเอเจนต์เขียนโค้ดเข้ามาในบทสนทนาใดก็ได้ เอเจนต์จะอ่านบริบทในห้อง เขียนโค้ด และเปิด pull request เอง ประกาศเปิดตัวระบุว่าเอเจนต์ “สืบทอดโมเดลความปลอดภัย สิทธิ์ และการควบคุมของผู้ดูแลที่มีใน Slack ตั้งแต่วันแรก โดยฝ่าย IT ไม่ต้องทำอะไรเพิ่ม” ผู้เขียนชี้ว่าเมื่อทีมความปลอดภัยอ่านประโยคนี้ จะเห็นผู้กระทำอัตโนมัติที่เข้าถึง GitHub และโครงสร้างพื้นฐานโปรดักชันได้ โดยการกำกับดูแลขึ้นกับว่าใครอยู่ในแชนเนลของแอปแชต และไม่มีอะไรให้ตรวจ เพราะไม่มีการตัดสินใจนำมาใช้เกิดขึ้นเลย

ผู้เขียนแบ่งที่มาของเอเจนต์เป็น 3 แบบ แบบแรกคือเอเจนต์ที่ “สืบทอด” มากับแพลตฟอร์มเดิมผ่านอัปเดตผลิตภัณฑ์ แบบที่สองคือเอเจนต์ที่ “กำหนดค่า” เอง คือพรอมต์และตรรกะขององค์กรที่รันบน runtime โมเดล และตัวเชื่อมต่อของผู้อื่น และแบบที่สามคือเอเจนต์ที่ “สร้าง” เองบนเฟรมเวิร์กเปิดและโครงสร้างพื้นฐานที่องค์กรเป็นเจ้าของทั้งหมด สองแบบแรกเป็นส่วนใหญ่ของการใช้งานและโตเร็วมาก ขณะที่แบบที่สามเล็กที่สุดและโตช้าที่สุด แต่กลับเป็นแบบเดียวที่มี repo ให้สแกนและมีขั้นตอน build ให้ตั้งด่านตรวจ ไม่ว่าเอเจนต์มาจากไหน สุดท้ายก็ไปทำงานที่ชั้นแอปพลิเคชันขององค์กร เช่น เอเจนต์ที่เกิดใน CRM อาจไปอ่าน data warehouse และเขียนลงระบบ ticket หรือเอเจนต์บนแพลตฟอร์มคลาวด์อาจถือโทเค็นเข้าถึง Salesforce, Slack และ Drive พร้อมกัน

คำถาม 4 ข้อสำหรับประเมินเอเจนต์

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

ด้านที่ต้องตรวจในทางปฏิบัติ
Identityเอเจนต์ลงทะเบียนไว้ที่ไหนหรือไม่ มีคนที่ระบุชื่อได้รับเป็นเจ้าของเมื่อถามว่า “ตัวนี้ของใคร” หรือมันรันเงียบ ๆ ด้วยตัวตนของคนที่สร้างมัน
สิทธิ์ (Permissions)ทำอะไรได้บ้าง เกินกว่าที่จำเป็นหรือไม่ ได้รับ OAuth scope และบทบาทของใครมาตอนสร้าง และมีใครตั้งใจตัดสินใจเรื่องนี้หรือไม่
การเชื่อมต่อ (Connectivity)เข้าถึงอะไรได้ทั้งทางตรงและทางอ้อม ผ่านผลิตภัณฑ์ สิทธิ์ที่ได้รับ แหล่งข้อมูล และเอเจนต์อื่นที่มันแตะ คำถามนี้คือขอบเขตความเสียหาย และมักตอบไม่ได้จากหน้าตั้งค่าของเอเจนต์เอง
กิจกรรม (Activity)กำลังทำอะไรจริง และปกติสำหรับสิ่งที่มันเป็นหรือไม่ โดยตัดสินจากพฤติกรรม ไม่ใช่จากคำบรรยายในพรอมต์

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

ผลกระทบ

สำหรับองค์กรที่ใช้ SaaS จำนวนมาก บทความนี้ชี้ปัญหาที่ใกล้ตัวกว่าการเลือกโมเดล AI คือเอเจนต์ที่เปิดใช้งานเองผ่านอัปเดตของแพลตฟอร์มที่ใช้อยู่ แล้วได้สิทธิ์ OAuth และการเข้าถึงข้อมูลตามผู้ใช้ที่เปิดใช้มันโดยไม่มีใครทบทวน ผลคือเกิด non-human identity จำนวนมากที่ไม่มีเจ้าของชัดเจน และขอบเขตความเสียหายเมื่อเอเจนต์ถูกหลอกหรือถูกยึดโทเค็นอาจกว้างกว่าที่ทีมความปลอดภัยคาด ลักษณะนี้คล้ายความเสี่ยงห่วงโซ่อุปทานของซอฟต์แวร์บุคคลที่สาม ซึ่งนาย Patrick Opet ประธานเจ้าหน้าที่ความปลอดภัยสารสนเทศ (CISO) ระดับโลกของ JPMorgan Chase เคยเขียนจดหมายเปิดผนึกถึงอุตสาหกรรมเมื่อปี 2568 ว่าเป็นความเสี่ยงเชิงระบบ และบทความระบุว่าเขานำมุมมองเดียวกันมาใช้กับเอเจนต์ คือเอเจนต์ควรมี identity แต่ไม่มีสิทธิ์ใดเป็นค่าเริ่มต้น จนกว่าฝ่าย IT จะยืนยันว่าทำงานแทนใคร

ด้านกฎระเบียบ ภาระตาม EU AI Act ที่ทยอยมีผลในปี 2569 สมมติว่าองค์กรทำรายการระบบ AI ระบุเจ้าของ และแสดงหลักฐานการกำกับดูแลได้ องค์กรที่ไม่รู้ว่ามีเอเจนต์อะไรอยู่บ้างจึงปฏิบัติตามได้ยาก ข้อจำกัดของบทความคือเขียนจากมุมของผู้ขายแพลตฟอร์มด้านนี้ ตัวเลข 1,280 และ 282 มาจากรายงานของผู้ขายเองและไม่ได้ระบุขนาดหรือลักษณะของกลุ่มตัวอย่าง จึงควรใช้เป็นภาพสะท้อนแนวโน้ม มากกว่าสถิติที่ใช้อ้างอิงได้ทั่วไป

คำแนะนำ

  • ทำรายการเอเจนต์ AI ที่ทำงานในองค์กร โดยรวมฟีเจอร์เอเจนต์ที่มากับ SaaS ที่ใช้อยู่ ไม่ใช่เฉพาะโครงการ AI ที่องค์กรจัดซื้อเอง และกำหนดเจ้าของที่ระบุชื่อได้ให้ทุกตัว
  • ทบทวน OAuth grant และ API token ของแอปและเอเจนต์ที่เชื่อมกับ Microsoft 365, Google Workspace, Salesforce, Slack และ GitHub เป็นระยะ เพิกถอนสิทธิ์ที่เกินจำเป็นหรือไม่มีเจ้าของ
  • ตั้งนโยบายให้ฟีเจอร์ AI ใหม่ในแพลตฟอร์มที่ใช้อยู่ปิดไว้เป็นค่าเริ่มต้น และเปิดหลังผ่านการทบทวนด้านความปลอดภัย ในแพลตฟอร์มที่ผู้ดูแลควบคุมได้
  • จำกัดสิทธิ์เอเจนต์ตามหลัก least privilege และแยกบัญชีบริการของเอเจนต์ออกจากบัญชีผู้ใช้ เพื่อให้ตรวจล็อกและเพิกถอนได้ชัดเจน
  • เฝ้าระวังพฤติกรรมของ non-human identity เช่น การเข้าถึงข้อมูลปริมาณมาก การเรียก API ข้ามระบบ หรือการกระทำนอกช่วงเวลาปกติ ด้วยเครื่องมือ SSPM, ITDR หรือ SIEM ที่มีอยู่
  • เพิ่มคำถามเรื่องฟีเจอร์เอเจนต์ AI สิทธิ์ที่เอเจนต์ใช้ และการปิด/ควบคุมได้ ลงในแบบประเมินความเสี่ยงผู้ขาย (vendor risk assessment)

แหล่งอ้างอิง