ทำไม AI Agent กลายเป็นช่องโหว่ไซเบอร์ใหม่ขององค์กร
ความปลอดภัย AI Agent คือการออกแบบ ควบคุม และตรวจสอบการทำงานของตัวแทนอัตโนมัติที่ใช้โมเดลภาษาขนาดใหญ่และเครื่องมือดิจิทัลเพื่อดำเนินการแทนมนุษย์ โดยเน้นควบคุมสิทธิการเข้าถึง การใช้เครื่องมือ และการส่งข้อมูลออก เพื่อจำกัดความเสียหายจากการโจมตี Prompt Injection การใช้สิทธิอนุญาตผิดวัตถุประสงค์ และการรั่วไหลของข้อมูลสำคัญในโครงสร้างพื้นฐานองค์กร มุมมองที่หลายทีมไอทีพลาดคือการคิดว่า AI Agent เป็นแค่อีกฟีเจอร์หนึ่งของแอปพลิเคชัน แทนที่จะเห็นว่ามันคือผู้ตัดสินใจอัตโนมัติที่กำลังถูกปล่อยเข้าไปในระบบโดยที่กลไกความปลอดภัยเดิมไม่รู้ด้วยซ้ำว่ากำลังคุยกับตัวอะไร ระบบเครือข่ายและการยืนยันตัวตนถูกสร้างมาเพื่อแยกระหว่างคนกับโปรแกรมที่วิศวกรเขียน แต่ AI Agent พูดเหมือนมนุษย์และเชื่อมต่อเหมือนบริการ ทำให้มันสวมหน้ากากสองใบในคราวเดียว ช่องว่างนี้เองที่เปิดทางให้ช่องโหว่ไซเบอร์รุ่นใหม่ซึ่งการควบคุม AI ระดับองค์กรแบบเดิมรับมือไม่ทัน
จุดโจมตีที่ 1–3 การโจมตี Prompt Injection และตัวตนที่หลอกตา
การโจมตี Prompt Injection คือหัวใจของความเสี่ยง AI Agent เพราะโมเดลไม่สามารถแยกคำสั่งที่ตั้งใจโจมตีออกจากข้อมูลปกติที่มันอ่านได้ ทุกอย่างถูกมองเป็นข้อความในหน้าต่างบริบท ทำให้คำสั่งแอบแฝงในอีเมล เว็บเพจ เอกสาร หรือผลตอบ API กลายเป็นการสั่งงานทางอ้อมที่ทรงพลังมาก ซึ่งเรียกว่า indirect prompt injection ช่องโหว่แบบนี้เคยเกิดขึ้นจริงในระบบ Agent ที่มีชื่อเสียง และถูกจดบันทึกเป็นช่องโหว่อย่างเป็นทางการแล้วหลายกรณี เช่น CVE-2026-31854 ของเครื่องมือ Agent ด้านโค้ดที่เปิดทางให้คำสั่งบนหน้าเว็บถูกอ่านและรันได้หากหลุดจาก whitelist จุดโจมตีแรก คือทุกทางเข้าที่ป้อนข้อมูลสู่ context ของโมเดล ทั้ง ticket ข้อความ แนบ URL เอกสารฐานความรู้ที่คนแก้ไขได้ และผลลัพธ์จากเครื่องมืออื่นที่ Agent เรียกใช้ จุดโจมตีที่สอง คือการที่ Agent ใช้ credential ถูกต้อง แต่มี intent ผิดทาง มันสามารถใช้สิทธิถูกต้องทุกอย่างเพื่อดึง API keys credential และข้อมูลลูกค้าออกมาหลังโดนฝังคำสั่งโจมตีโดยไม่ให้ระบบใดสงสัย จุดโจมตีที่สาม คือช่องว่างของ Zero Trust สำหรับ AI เมื่อระบบยืนยันแค่ตัวตนและช่องสื่อสาร แต่มองไม่เห็นว่าฝั่งตรงข้ามคือ Agent ที่อาจถูกยึดการคิดไปแล้ว การรับมือทั้งสามจุดนี้ต้องเปลี่ยนกรอบคิด ทีมควรยอมรับว่าการโจมตี Prompt Injection ไม่มีทางป้องกันได้ครบถ้วน แต่ต้องจำกัดอำนาจ Agent ด้วยหลัก least privilege และการออกแบบเครื่องมือให้แคบที่สุด เช่น Agent ตอบ ticket ไม่ควรใช้เครื่องมือที่ลบบัญชีหรือดันโค้ดได้ ควบคู่กับการสร้าง identity แบบ Agent-aware ให้ทุกคำขอพกข้อมูลที่ตรวจสอบได้ว่า Agent ใดเป็นผู้ดำเนินการ มีการอนุมัติจากมนุษย์หรือไม่ และมีผู้รับผิดชอบชัดเจน
จุดโจมตีที่ 4–5 Shadow AI และการรั่วไหลผ่าน egress ที่ถูกต้องตามสิทธิ
จุดโจมตีที่สี่ คือ Shadow AI และ Shadow Agent บนอุปกรณ์และระบบองค์กร เมื่อพนักงานนำเครื่องมือ AI มาใช้เองโดยไม่ผ่านไอที ทำให้เกิด AI Agent ที่ไม่มีใครลงทะเบียนและไม่มีนโยบายรองรับ งานวิจัยหนึ่งรายงานว่า 78 เปอร์เซ็นต์ของผู้ใช้ AI ในที่ทำงานใช้เครื่องมือของตัวเองแทนการรอให้ไอทีจัดหา ซึ่งถูกชี้ว่าทำให้ข้อมูลองค์กรเสี่ยง Agent เหล่านี้มักเกิดจากสคริปต์เล็กๆ ที่เชื่อมโมเดลกับข้อมูลภายในโดยไม่มี ticket หรือการตรวจทาน แล้วค่อยๆ กลายเป็นงานจริงในไม่กี่วัน หากองค์กรไม่สามารถระบุได้ว่ามี Agent ไหนใช้งานอยู่บ้าง ก็ไม่มีทางเขียนนโยบายหรือทำ audit ให้มีความหมายได้ จุดโจมตีที่ห้า คือ egress และการเชื่อมต่อออกจากระบบที่ถูกต้องตามสิทธิแต่ผิดเจตนา Agent ที่ถูกโจมตีสามารถใช้สิทธิที่ได้รับอนุญาตเพื่อส่งข้อมูลออกไปยังปลายทางที่ไม่ควร ส่ง API keys source code หรือข้อมูลลูกค้าไปยังช่องทางภายนอกโดยไม่มีการปลุกเตือน เพราะทุกอย่างถูกต้องตาม credential และ role-based access การป้องกันตรงนี้ต้องวางกรอบที่ขอบทรัพยากรและขอบ egress ให้ชัดเจน กำหนดไว้ล่วงหน้าว่าระบบสำคัญจะยอมรับคำขอจาก Agent ในรูปแบบใด และ Agent แต่ละตัวสามารถส่งข้อมูลออกไปที่ไหนได้บ้างเท่านั้น นี่คือเลเยอร์เดียวที่ยังทำงานอยู่แม้ Agent ถูกยึดการคิดไปแล้ว จึงเป็นแกนสำคัญของ Zero Trust สำหรับ AI ที่ไม่ได้หยุดอยู่แค่การตรวจสอบตัวตน
จุดโจมตีที่ 6–7 เมื่อ sandbox ไม่มี และโลกไร้ log ที่อ่าน Agent ออก
จุดโจมตีที่หก คือการเชื่อคำตอบหรือโค้ดจากโมเดลมากเกินไปโดยไม่มี sandbox ทุกสิ่งที่ Agent สร้าง ไม่ว่าจะเป็นโค้ด สคริปต์ หรือ URL ควรถูกดูแลแบบเดียวกับโค้ดที่ผู้ใช้กรอกในเว็บแอป กล่าวคือไม่ควรถูก execute หรือ eval โดยตรง แต่ต้องถูกกักใน sandbox ก่อนเสมอ หากโค้ดจาก Agent สามารถวิ่งในระบบ production โดยตรง ช่องโหว่จาก Prompt Injection ก็แปรสภาพเป็นการรันคำสั่งโจมตีเต็มรูปแบบโดยใช้สิทธิของระบบเอง จุดโจมตีที่เจ็ด คือโลกที่ไม่มี log ที่เข้าใจ Agent เมื่อเกิดเหตุผิดปกติ ทีมมักไม่มีหลักฐานพอจะย้อนดูว่า Agent อ่านอะไรไป คิดอย่างไร และใช้เครื่องมือใดบ้าง การไม่บันทึกบริบทของการตัดสินใจทำให้ทั้งการสืบสวนและการปรับปรุง guardrail แทบทำไม่ได้ ในทางกลับกัน หากมีการ log ครบทั้ง input output และเครื่องมือที่ถูกเรียก ใช้เวลาและผู้ใช้ที่เกี่ยวข้อง ทีมสามารถ replay เหตุการณ์แบบอัตโนมัติ ทำ red-team ทดสอบกติกาใหม่ และดูได้ว่ามันจะจับการโจมตีรูปแบบเดิมได้หรือไม่ ความจริงที่ต้องรับให้ได้คือ ช่องโหว่ AI Agent ไม่ใช่เรื่องสมมติอีกต่อไป มีกรณีที่นักวิจัยโจมตี AI Assistant ขององค์กรด้วยเอกสารที่ฝังคำสั่งจนมันค้นระบบและส่ง credential ออกไปโดยไม่ต้องคลิกใดๆ แล้ว และช่องโหว่ใน Assistant โค้ดชื่อดังบางรายยังถูกประเมินคะแนนความรุนแรง CVSS สูงถึง 9.6 ด้วย นั่นหมายความว่าองค์กรที่ไม่มี sandbox และไม่มี log แบบ Agent-aware กำลังปล่อยให้ผู้ตัดสินใจอัตโนมัติทำงานอยู่ในระบบโดยแทบไม่มีหลักฐานให้เกาะเมื่อเกิดเหต
จากแนวคิดสู่แผนปฏิบัติการ การควบคุม AI ระดับองค์กรต้องเริ่มตรงไหน
องค์กรที่ต้องการยกระดับความปลอดภัย AI Agent ไม่จำเป็นต้องแก้ทุกอย่างพร้อมกัน แต่ต้องเลิกเชื่อว่ากลไกเดิมมอง Agent ออก ทั้งที่ในทางเทคนิคมันมองไม่เห็นเลย แนวทางที่เป็นรูปธรรมเริ่มจากหนึ่ง ระบุ Agent ที่ไม่มีการอนุมัติ สมมติว่ามันมีอยู่แล้ว และค้นหางานที่เรียกโมเดลโดยไม่ผ่านการลงทะเบียน เพื่อเปลี่ยนจากความเชื่อในวินัยนักพัฒนาไปสู่รายชื่อที่ตรวจสอบได้ สอง ลงทะเบียน Agent ทุกตัวและผูก identity เฉพาะเข้าไปให้ข้อมูลต้นทางเดินทางไปกับทุกคำขอ เพื่อให้ระบบปลายทางตัดสินใจได้ว่ากำลังคุยกับ Agent แบบใด สาม วาง boundary ที่ขอบทรัพยากรและ egress ตัดสินใจล่วงหน้าว่าระบบสำคัญจะรับอะไรจาก Agent และ Agent จะส่งข้อมูลออกไปไหนได้บ้างเท่านั้น สี่ ดูพฤติกรรมก่อนบังคับใช้กติกา ใช้โหมดสังเกต traffic จริงและจำลอง rule เพื่อหลีกเลี่ยง false positive ที่ทำ production ล้ม ก่อนค่อยเปิดใช้งานจริง ห้า ทำ audit trail ให้เข้าใจ Agent เปลี่ยนคำถามอย่างเช่น "มี Agent ใดแตะข้อมูลสำคัญในปีนี้บ้าง" ให้กลายเป็น query เดียวที่ตอบได้จากระบบ log เมื่อนำแนวทางเหล่านี้มารวมกับวินัยเรื่อง least privilege การออกแบบเครื่องมือให้แคบ การ sandbox output การทำ red-team และการ log ที่ละเอียด องค์กรจะค่อยๆ เปลี่ยนจากการปล่อย AI Agent ทำงานอย่างหลุดนโยบาย ไปสู่สถาปัตยกรรมที่มองเห็น ควบคุม และสอบกลับได้ ความปลอดภัย AI Agent จึงไม่ใช่การหยุดใช้ AI แต่เป็นการกล้าบอกว่า AI ตัวไหนในองค์กรกำลังทำอะไร อยู่ที่ไหน และถูกจำกัดความเสียหายไว้อย่างไร ซึ่งคือก้าวเดียวกันกับการสร้าง Zero Trust สำหรับ AI ให้มีความหมายจริงในสภาพแวดล้อมใหม่
