Agent Data Injection คืออะไร ภัยโจมตี AI Agent ที่ปลอมข้อมูล

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

การโจมตีรูปแบบนี้เรียกว่า Agent Data Injection หรือ ADI โดยผู้โจมตีจะไม่พยายามซ่อนคำสั่งอันตรายไว้ในข้อความโดยตรง แต่จะเปลี่ยนแปลงข้อเท็จจริงเล็ก ๆ เช่น ชื่อผู้ส่งอีเมล หมายเลขปุ่มบนหน้าเว็บ ชื่อผู้เขียนความคิดเห็น หรือผลลัพธ์จากเครื่องมือที่ Agent เชื่อว่าเคยดำเนินการแล้ว

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

Agent Data Injection คืออะไร

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

โดยทั่วไป AI Agent ต้องประมวลผลข้อมูลสองประเภท ได้แก่

คำสั่ง เช่น สิ่งที่ผู้ใช้ต้องการให้ Agent ทำ
ข้อมูล เช่น อีเมล หน้าเว็บไซต์ ความคิดเห็นใน GitHub ผลลัพธ์จากเครื่องมือ หรือข้อมูลจากฐานข้อมูล

การโจมตีแบบ Prompt Injection ทั่วไปจะซ่อนคำสั่งไว้ในข้อมูล เช่น สั่งให้ Agent เพิกเฉยต่องานเดิมและส่งไฟล์ให้ผู้โจมตี แต่ ADI ใช้วิธีที่แตกต่างออกไป โดยปลอมรายละเอียดที่ Agent เชื่อว่าเป็นข้อมูลจริง

ตัวอย่างเช่น ผู้ใช้สั่งให้ AI สรุปรีวิวสินค้า แต่รีวิวที่ถูกแทรกไว้มีข้อมูลปลอมเกี่ยวกับหมายเลขปุ่ม เมื่อ Agent ต้องการคลิกปุ่ม “อ่านเพิ่มเติม” ระบบอาจคลิกปุ่ม “ซื้อทันที” แทน

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

ช่องโหว่เกิดจากวิธีที่ AI Agent อ่านข้อมูล

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

โปรแกรมแบบดั้งเดิมจะอ่านโครงสร้างเหล่านี้ตามกฎที่แน่นอน หากเครื่องหมายไม่ตรงตามรูปแบบ โปรแกรมมักมองว่าเป็นข้อความธรรมดา แต่โมเดลภาษาขนาดใหญ่ไม่ได้อ่านด้วยกฎตายตัวเสมอไป ระบบจะตีความโครงสร้างจากความน่าจะเป็นและบริบทของข้อความ

นักวิจัยเรียกเทคนิคที่ใช้ประโยชน์จากพฤติกรรมนี้ว่า Probabilistic Delimiter Injection

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

เครื่องหมายคำพูดที่มีการ Escape
เครื่องหมายคำพูดแบบโค้ง
วงเล็บหรือแท็กที่ดูคล้ายโครงสร้างจริง
เครื่องหมายดอลลาร์
การขึ้นบรรทัดใหม่ในตำแหน่งที่ทำให้เกิดความสับสน

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

ตัวอย่างการโจมตี Agent Data Injection

ทีมวิจัยได้สร้างตัวอย่างการโจมตีบนเครื่องมือที่เปิดให้ใช้งานจริง โดยแบ่งออกเป็นหลายสถานการณ์สำคัญ

ปลอมหมายเลขปุ่มบนหน้าเว็บไซต์

ในระบบ Web Agent ผู้โจมตีสามารถแทรกรีวิวสินค้าที่มีข้อมูลอ้างอิงถึงหมายเลขปุ่มซึ่งตรงกับปุ่มจริงบนหน้าเว็บไซต์

เมื่อ Agent ต้องการคลิกปุ่ม “Read More” เพื่ออ่านรายละเอียดเพิ่มเติม ระบบอาจเลือกหมายเลของค์ประกอบที่ถูกปลอมไว้ และคลิกปุ่ม “Buy Now” แทน ทำให้เกิดการสั่งซื้อโดยที่ผู้ใช้ไม่ได้ตั้งใจ

เครื่องมือที่ถูกนำมาทดสอบประกอบด้วย Claude in Chrome, Google Antigravity และ Nanobrowser

ปัจจัยสำคัญคือ Web Agent บางระบบกำหนดหมายเลของค์ประกอบบนหน้าเว็บแบบเรียงลำดับ ผู้โจมตีจึงสามารถคำนวณหรือคาดเดาหมายเลขของปุ่มเป้าหมายได้ง่าย

ปลอมชื่อผู้เขียนความคิดเห็นใน GitHub

ในเครื่องมือช่วยเขียนโค้ด ผู้โจมตีสามารถสร้างความคิดเห็นที่ดูเหมือนมาจากผู้ดูแลโครงการ โดยปลอมส่วนที่แสดงชื่อผู้เขียนหรือโครงสร้างของข้อมูลความคิดเห็น

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

เครื่องมือที่ถูกนำมาทดสอบ ได้แก่

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

ปลอมผลลัพธ์ของการตรวจสอบโค้ด

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

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

หากผู้ใช้อนุมัติ Pull Request โค้ดอันตรายจริงอาจถูกนำเข้าสู่ระบบ แม้ขั้นตอนการตรวจสอบที่ Agent อ้างถึงจะไม่เคยเกิดขึ้น

ระบบขออนุมัติก่อนทำงานอาจยังไม่เพียงพอ

AI Agent หลายระบบมีขั้นตอนขออนุมัติจากผู้ใช้ก่อนดำเนินการที่มีความเสี่ยง เช่น คลิกปุ่มสั่งซื้อ รันคำสั่ง หรือรวมโค้ดเข้าสู่โครงการ

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

ในกรณีของ Web Agent หน้าต่างยืนยันอาจแจ้งเพียงว่า Agent ต้องการคลิกองค์ประกอบหนึ่งบนหน้าเว็บ แต่ไม่ได้อธิบายอย่างชัดเจนว่าปุ่มดังกล่าวคืออะไร มีข้อความว่าอย่างไร และเหตุใด Agent จึงต้องคลิก

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

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

โมเดล AI หลายค่ายพบความเสี่ยงจาก ADI

งานวิจัยระบุว่าโมเดลจากหลายผู้พัฒนาแสดงพฤติกรรมที่สามารถถูกโจมตีด้วยวิธีดังกล่าวได้ โดยมีการทดสอบกับโมเดลจาก OpenAI, Anthropic และ Google

โมเดลที่ถูกระบุในงานวิจัยประกอบด้วย

OpenAI GPT-5.2
OpenAI GPT-5-mini
Anthropic Claude Opus 4.5
Anthropic Claude Sonnet 4.5
Google Gemini 3 Pro
Google Gemini 3 Flash

จากการทดสอบ การโจมตีข้อมูลแบบมีโครงสร้างประสบความสำเร็จประมาณ 31% ถึง 43% ขณะที่การโจมตีผ่านข้อมูลบนหน้าเว็บมีอัตราความสำเร็จตั้งแต่ประมาณหนึ่งในสามไปจนถึงเกือบทุกครั้งในบางรูปแบบการทดสอบ

เมื่อนำไปทดสอบกับระบบป้องกัน Prompt Injection ที่ออกแบบมาโดยเฉพาะ การโจมตีแบบซ่อนคำสั่งทั่วไปถูกป้องกันได้เกือบทั้งหมด แต่ ADI ยังสามารถทำงานสำเร็จได้สูงสุดประมาณ 50%

สาเหตุคือระบบป้องกันส่วนใหญ่มุ่งตรวจหาข้อความที่มีลักษณะเป็นคำสั่งอันตราย แต่ ADI ไม่จำเป็นต้องใช้คำสั่งตรง ๆ ผู้โจมตีเพียงเปลี่ยนข้อมูลที่ Agent ใช้ประกอบการตัดสินใจ

วิธีป้องกัน Agent Data Injection

งานวิจัยได้ทดลองแนวทางป้องกันหลายรูปแบบ โดยแต่ละวิธีมีข้อดีและข้อจำกัดแตกต่างกัน

ใช้รหัสองค์ประกอบแบบสุ่ม

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

เมื่อรหัสไม่สามารถคาดเดาได้ ผู้โจมตีจะปลอมหมายเลขให้ตรงกับปุ่มเป้าหมายได้ยากขึ้น

นักวิจัยยังทดลองเพิ่มรหัสสุ่มขนาดสั้นไว้กับชื่อฟิลด์ ซึ่งช่วยลดอัตราความสำเร็จของการโจมตีจากประมาณ 49% เหลือประมาณ 29% โดยยังคงรักษาความสามารถของ Agent ในการทำงานทั่วไปได้

ติดตามแหล่งที่มาของข้อมูล

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

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

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

ลบเครื่องหมายที่ใช้แบ่งข้อมูล

การลบหรือกรองเครื่องหมายวรรคตอนบางประเภทสามารถลดโอกาสที่ AI จะตีความข้อมูลปลอมเป็นโครงสร้างจริง

อย่างไรก็ตาม วิธีนี้อาจทำลายข้อมูลที่จำเป็น เช่น

ลิงก์เว็บไซต์
พาธของไฟล์
โค้ดโปรแกรม
JSON หรือ XML
ข้อความที่ต้องใช้เครื่องหมายคำพูด
คำสั่งในระบบปฏิบัติการ

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

แสดงรายละเอียดก่อนขออนุมัติ

ระบบควรแสดงข้อมูลที่ผู้ใช้สามารถตรวจสอบได้ก่อนอนุมัติ เช่น

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

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

เงื่อนไขที่ทำให้การโจมตีเกิดขึ้นได้

Agent Data Injection ต้องอาศัยองค์ประกอบหลายอย่างร่วมกัน

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

เว็บไซต์ อีเมล GitHub Issue Pull Request รีวิวสินค้า และข้อความจากระบบภายนอกจึงเป็นพื้นที่เสี่ยง เพราะข้อมูลเหล่านี้สามารถถูกสร้างหรือแก้ไขโดยบุคคลที่ระบบไม่ควรเชื่อถือโดยอัตโนมัติ

ผู้โจมตีรู้รูปแบบข้อมูลของ Agent ได้อย่างไร

สำหรับเครื่องมือโอเพนซอร์สหรือระบบที่ติดตั้งบนเครื่อง ผู้โจมตีสามารถศึกษารูปแบบข้อมูลได้จากซอร์สโค้ด การตรวจสอบไฟล์ หรือการวิเคราะห์พฤติกรรมของระบบ

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

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

ความเชื่อมโยงกับ EchoLeak และการโจมตีผ่าน GitHub

ปัญหาความน่าเชื่อถือของข้อมูลใน AI Agent เคยปรากฏให้เห็นผ่านช่องโหว่อื่นมาก่อน

ในเดือนมิถุนายน 2025 มีการเปิดเผย EchoLeak หรือ CVE-2025-32711 ซึ่งเกี่ยวข้องกับ Microsoft 365 Copilot ผู้โจมตีสามารถสร้างอีเมลที่ทำให้ระบบเปิดเผยข้อมูลภายในได้โดยไม่ต้องให้ผู้ใช้คลิกลิงก์

EchoLeak ใช้วิธีซ่อนคำสั่งไว้ในข้อมูล ขณะที่ Agent Data Injection เปลี่ยนไปปลอมข้อเท็จจริงที่ระบบเชื่อถือ เช่น ใครเป็นผู้ส่ง ข้อมูลมาจากแหล่งใด หรือเครื่องมือเคยทำอะไรไปแล้ว

นอกจากนี้ ยังเคยมีการสาธิตว่าข้อความใน GitHub Issue และ Pull Request สามารถชักนำ Coding Agent ให้เข้าถึงข้อมูลจาก Repository ส่วนตัว หรือเปิดเผยข้อมูลสำคัญได้

ความแตกต่างสำคัญคือการโจมตีเดิมพยายามสั่ง Agent โดยตรง แต่ ADI ทำให้ Agent เข้าใจสถานการณ์ผิด แล้วปล่อยให้ระบบดำเนินงานเดิมต่อไปเอง

นักพัฒนา AI Agent ควรเตรียมรับมืออย่างไร

การป้องกัน ADI ไม่ควรพึ่งการกรอง Prompt Injection เพียงอย่างเดียว แต่ต้องออกแบบระบบให้แยกข้อมูลตามระดับความน่าเชื่อถืออย่างชัดเจน

แนวทางที่ควรนำไปพิจารณา ได้แก่

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

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

สรุป Agent Data Injection สะท้อนปัญหาความน่าเชื่อถือของข้อมูลใน AI Agent

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

Agent อาจยังคงทำงานตามคำขอของผู้ใช้ทุกขั้นตอน แต่เลือกปุ่มผิด เชื่อผู้ส่งผิด รันคำสั่งผิด หรืออนุมัติโค้ดผิด เพราะข้อมูลพื้นฐานที่ใช้ตัดสินใจถูกผู้โจมตีแทรกแซง

ระบบป้องกัน Prompt Injection แบบเดิมจึงอาจไม่เพียงพอสำหรับ Agent ที่สามารถดำเนินการจริง นักพัฒนาต้องแยกข้อมูลที่ระบบรับรองออกจากข้อมูลภายนอก ติดตามแหล่งที่มา ใช้รหัสที่คาดเดาไม่ได้ และแสดงรายละเอียดที่ตรวจสอบได้ก่อนขออนุมัติ

เมื่อ AI Agent ได้รับสิทธิ์เข้าถึงเบราว์เซอร์ คอมพิวเตอร์ Repository และข้อมูลภายในองค์กรมากขึ้น การออกแบบขอบเขตความน่าเชื่อถือของข้อมูลจะกลายเป็นส่วนสำคัญของระบบรักษาความปลอดภัย ไม่ต่างจากการแยกโค้ดออกจากข้อมูลในซอฟต์แวร์แบบดั้งเดิม

ที่มา thehackernews

SiamGeek