AI Agent ในองค์กรคืออะไร และทำไมกลายเป็นพื้นผิวโจมตีใหม่
AI Agent ในบริบทองค์กรคือระบบอัตโนมัติที่ใช้โมเดลภาษาในการตัดสินใจและลงมือทำงานแทนมนุษย์ โดยเชื่อมต่อกับข้อมูลภายใน เครื่องมือธุรกิจ และ API ต่างๆ ผ่านสิทธิ์การเข้าถึงและข้อมูลยืนยันตัวตนที่ถูกต้อง AI Agent ไม่ได้เป็นเพียงแชตบอตตอบคำถาม แต่สามารถอ่านเขียนฐานข้อมูล ส่งอีเมล สร้างเอกสาร หรือเรียกใช้บริการอื่นในโครงสร้างพื้นฐานได้ ดังนั้นเมื่อ AI Agent ทำงานในนามของผู้ใช้หรือบริการหนึ่งๆ ทุกคำสั่งที่ออกจากมันจึงถูกมองว่าเป็นทราฟฟิกปกติของระบบ ทั้งที่เบื้องหลังอาจถูกชักใยด้วยคำสั่งที่คนในองค์กรไม่เคยเห็นมาก่อน
ปัญหาหลักคือสแตกความปลอดภัยในองค์กรถูกออกแบบมานานเพื่อแยกแยะระหว่างคนกับโปรแกรมแบบดั้งเดิม ระบบไฟร์วอลล์และแพลตฟอร์มยืนยันตัวตนจะถามคำเดียวว่า ตัวตนนี้มีสิทธิ์หรือไม่ และมักได้คำตอบว่าใช่ แต่ไม่รู้เลยว่าผู้ถือสิทธิ์คือมนุษย์ บริการเชิงกำหนด หรือ AI Agent ที่เพิ่งถูกโน้มน้าวด้วยข้อความหนึ่งย่อหน้าก่อนหน้า นี่คือหัวใจของความเสี่ยง AI Agent ที่หลายองค์กรยังประเมินต่ำกว่าความเป็นจริง และเปิดโอกาสให้การโจมตีแฝงตัวผ่านทราฟฟิกที่ดูถูกต้องทุกประการ
จากฟอร์มลูกค้าสู่การดูดข้อมูล: บทเรียนจากช่องโหว่แพลตฟอร์ม AI ระดับองค์กร
กรณีช่องโหว่ในแพลตฟอร์ม AI Agent ระดับองค์กรหนึ่งแสดงให้เห็นชัดว่าความปลอดภัย enterprise AI ไม่ใช่เรื่องทฤษฎี ระบบนี้อนุญาตให้ข้อมูลลีดที่ถูกวางยาสามารถยึดครอง AI Agent แล้วแอบขโมยข้อมูล CRM ออกจากระบบโดยไม่ต้องมีการคลิกใดๆ แถมยังใช้ตัวตนของ Agent ส่งอีเมลฟิชชิงหาเหยื่อได้ด้วย ช่องโหว่สองจุดแรกเปลี่ยนฟอร์มรับลีดสาธารณะให้กลายเป็นช่องทางดูดข้อมูลลูกค้าที่อ่อนไหวออกจากแพลตฟอร์ม นี่คือภาพของ AI Agent ที่ทำงานด้วยสิทธิ์ถูกต้อง แต่ถูกบิดเจตนาไปคนละทางโดยเจ้าของสิทธิ์ไม่รู้ตัว
แม้ผู้วิจัยรายงานช่องโหว่ทั้งสามให้ผู้พัฒนาแพลตฟอร์มตั้งแต่ต้นเดือนหนึ่ง และผู้ให้บริการได้ออกแพตช์ปิดช่องโหว่อย่างครบถ้วนในเดือนถัดมา แต่บทเรียนสำคัญคือ การออกแบบให้ปลอดภัยตั้งแต่ต้นยังไม่พอเมื่อเจอโลกจริง เจ้าตัววิจัยเตือนว่าแม้จะคิดว่ากัก AI Agent ไว้ในกรอบแล้ว ช่องว่างเล็กๆ ที่มองข้ามเพียงครั้งเดียวก็เปลี่ยนเกมทั้งหมดได้ ยิ่งไปกว่านั้น ระบบ AI Agent ด้านโค้ดดิงหลายเจ้าก็เคยมีช่องโหว่ prompt injection ที่ใช้ประโยชน์ได้ในอดีตเช่นกัน
การโจมตี prompt injection หลีกไม่พ้น ทำได้แค่จำกัดวงไม่ให้ลาม
จุดอ่อนเชิงโครงสร้างของ AI Agent คือมันไม่เห็นเส้นแบ่งระหว่างข้อมูลกับคำสั่ง ทุกอย่างที่เข้ามาใน context ไม่ว่าจะเป็นอีเมล หน้าเว็บ PDF การตอบกลับจาก API หรือเอาต์พุตของ Agent ตัวอื่น ถูกปฏิบัติเป็นข้อความชุดเดียวกัน การโจมตี prompt injection อาศัยจุดนี้ แฝงคำสั่งอันตรายไว้ในเนื้อหาที่ดูเหมือนข้อมูลปกติ เช่น ในฟิลด์คำอธิบายปัญหาของทิกเก็ตซัพพอร์ตหรือในเอกสารที่ถูกอัปโหลด แล้วปล่อยให้ Agent ที่ถือสิทธิ์เข้าถึงระบบภายในเป็นคนลงมือให้เอง โดยผู้โจมตีไม่ต้องขโมย credential หรือเจาะผ่านขอบเขตรักษาความปลอดภัยใดๆ
ผู้เชี่ยวชาญด้าน Agent เตือนตรงๆ ว่าเราต้องเลิกคิดว่าจะหยุด prompt injection ได้ร้อยเปอร์เซ็นต์ และต้องออกแบบบนสมมติฐานว่าคำสั่งมุ่งร้ายจะเล็ดรอดเข้ามาได้แน่ในสักวัน แปลว่ากลยุทธ์ที่สมเหตุสมผลคือการสร้างการป้องกันหลายชั้นที่เป็นอิสระต่อกัน ตั้งแต่การจำกัดความสามารถของ Agent ให้เหลือเท่าที่จำเป็น การตรวจสอบและทำ sandbox กับสิ่งที่โมเดลสร้างออกมา ไปจนถึงการบันทึกและตรวจสอบกิจกรรมแบบเรียลไทม์ จุดสำคัญคือเลเยอร์สุดท้ายต้องยังทำงานได้แม้ Agent จะถูกโน้มน้าวไปแล้ว เพื่อกันไม่ให้การละเมิดเจตนากลายเป็นเหตุข้อมูลรั่วไหลวงกว้าง
เมื่อ credential ถูกต้องแต่เจตนาถูกยึด ฝ่ายความปลอดภัยต้องมองเห็นว่าใครกำลังทำอะไร
ในระบบปัจจุบัน เมื่อคำขอไปถึงฐานข้อมูลหรือ API ระบบจะถามแค่ว่า principal ตัวนี้มีสิทธิ์หรือไม่ และถ้าใช้ credential ถูกต้องก็มักได้ไฟเขียวทันที โดยไม่รู้เลยว่าผู้ใช้สิทธินั้นคือมนุษย์ บริการเชิงกำหนด หรือ AI Agent ที่เพิ่งถูกชักจูงด้วย prompt injection เมื่อไม่แยกประเภท caller ระบบจึงมองทราฟฟิกจาก Agent เป็นเหมือนทราฟฟิกบริการปกติทั้งหมด ผลคือผู้โจมตีแค่ปลูกคำสั่งมุ่งร้ายไว้ในที่ที่ Agent อ่านเจอ เช่น เอกสารหรือการตอบกลับ API แล้วปล่อยให้ Agent ที่มี credential และอยู่หลังไฟร์วอลล์เป็นคนเดินงานแทนตนเอง
การควบคุมการเข้าถึง AI แบบดั้งเดิมที่ถามแค่ว่าใครทำอะไรจึงไม่พอ จำเป็นต้องเพิ่มมิติของ “อะไร” เข้ามาด้วยว่า caller เป็น Agent แบบไหนและมาจากไหน ผู้เชี่ยวชาญเสนอว่าต้องทำให้ Agent มีลายเซ็นประจำตัวที่โครงสร้างพื้นฐานด้านความปลอดภัยอ่านได้ และให้ข้อมูลต้นทางของ caller เดินทางไปกับทราฟฟิกทุกคำขอ คำแนะนำคือจดทะเบียน Agent ทุกตัว ผูกตัวตนเฉพาะให้แต่ละตัว แล้วทำให้ตัวตนนั้นติดไปกับการเรียกใช้บริการปลายทาง เพื่อให้ระบบ downstream ตรวจสอบและบังคับนโยบายเฉพาะ Agent ได้จริง ไม่ต้องเดาจากลักษณะทราฟฟิกย้อนหลัง
คู่มือป้องกันองค์กร: จาก least privilege ถึงการทดสอบเชิงรุกก่อนขึ้นโปรดักชัน
สำหรับทีมความปลอดภัยองค์กร การปกป้อง AI Agent ต้องเริ่มจากยอมรับว่าความเสี่ยง AI Agent กระจายเต็มองค์กรตั้งแต่วันแรก อันดับแรกคือค้นหา shadow agent ที่ทีมไม่เคยอนุมัติซึ่งถูกนักพัฒนาต่อเข้าระบบเอง แล้วติดธงให้เห็นอย่างเป็นรูปธรรม แทนการหวังพึ่งนโยบายอย่างเดียว ถัดมาคือออกแบบการควบคุมการเข้าถึง AI แบบ least privilege ให้ Agent แต่ละตัวถือสิทธิ์เท่าที่ต้องใช้จริงเท่านั้น และใช้ credential แบบอายุสั้นและขอบเขตจำกัดสำหรับการเรียกใช้เครื่องมือแต่ละครั้ง แทนการฝัง API key กว้างๆ ไว้ในสภาพแวดล้อมของ Agent
จากนั้นต้องทำ sandbox กับทุกสิ่งที่โมเดลสร้าง เช่น การจำกัดสภาพแวดล้อมที่โค้ดหรือคำสั่งจาก Agent สามารถรันได้ และสร้างเลเยอร์ตรวจสอบก่อนลงมือกับระบบจริง การบันทึกกิจกรรมอย่างละเอียดเป็นอีกหัวใจ เพราะหากไม่มี log ที่ดี การสืบสวนตอนเกิดเหตุแทบเป็นไปไม่ได้ สุดท้าย ก่อนปล่อย Agent ลงงานโปรดักชันควรมีการทดสอบเชิงรุกแบบ adversarial testing ให้ทีมภายในหรือผู้เชี่ยวชาญภายนอกลองโจมตี prompt injection จากทุกทิศ ตั้งแต่ฟิลด์อินพุต URL เอกสารแนบ ฐานความรู้ ไปจนถึงการตอบกลับจาก API เพราะทุกลูกศรที่ป้อนเข้า context ของโมเดลคือจุดที่ผู้โจมตีสามารถแอบใส่คำสั่งของตนเองได้
