การโจมตีรูปแบบนี้เรียกว่า 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 นำวิธีแก้ไขจากผู้ดูแลโครงการไปใช้ ระบบอาจเชื่อว่าคำสั่งของผู้โจมตีเป็นคำแนะนำจากผู้ดูแลจริง และเสนอให้รันคำสั่งดังกล่าวบนคอมพิวเตอร์ของนักพัฒนา

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

• Claude Code
• OpenAI Codex
• Google Gemini CLI

แม้ระบบจะขอให้ผู้ใช้กดยืนยันก่อนรันคำสั่ง แต่คำอธิบายที่แสดงอาจดูเป็นขั้นตอนปกติ เนื่องจากเหตุผลของ 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

The post Agent Data Injection ภัยโจมตี AI Agent รูปแบบใหม่ที่ปลอมข้อมูลให้ระบบตัดสินใจผิด appeared first on SiamByte.

AIR ระบุว่า Skill ดังกล่าวสามารถเข้าถึง AI Agent ได้ประมาณ 26,000 ราย รวมถึงเอเจนต์บางส่วนที่เชื่อมโยงกับบัญชีขององค์กร แม้เครื่องมือตรวจสอบความปลอดภัยทุกตัวที่บริษัทนำมาทดสอบจะรายงานว่าแพ็กเกจนี้ปลอดภัยก็ตาม

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

AI Agent Skill คืออะไร และทำไมจึงมีความเสี่ยง

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

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

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

AIR สร้าง Skill ปลอมให้ดูน่าเชื่อถืออย่างไร

Skill ที่ AIR ใช้ในการทดลองมีชื่อว่า “brand-landingpage” โดยอ้างว่าสามารถช่วยสร้างหน้า Landing Page ผ่านเครื่องมือออกแบบ Google Stitch กลุ่มเป้าหมายหลักคือผู้ใช้งานทั่วไปที่ไม่มีความรู้ด้านการเขียนโปรแกรม เช่น นักการตลาด ฝ่ายขาย และนักออกแบบ

เพื่อทำให้ Skill ดูน่าเชื่อถือ AIR วางแผนใช้สัญญาณความน่าเชื่อถือที่ผู้ใช้งานมักพิจารณาก่อนติดตั้ง ได้แก่

• จำนวนดาวบน GitHub
• การอยู่ใน Repository ที่ได้รับความนิยม
• ผลการสแกนความปลอดภัยที่ระบุว่าปลอดภัย
• ชื่อเครื่องมือที่คล้ายกับบริการจากบริษัทเทคโนโลยีรายใหญ่
• โฆษณาที่นำเสนอว่าเป็นเครื่องมือช่วยเพิ่มประสิทธิภาพการทำงาน

AIR ส่ง Pull Request เข้าไปยัง Repository ตลาด Skill แห่งหนึ่งที่มีดาวบน GitHub ประมาณ 36,000 ดาว และรวบรวม Skill อยู่ประมาณ 156 รายการ

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

จากนั้นบริษัทซื้อโฆษณาบน Instagram โดยกำหนดกลุ่มเป้าหมายเป็นนักการตลาด ฝ่ายขาย และนักออกแบบ เพื่อชักชวนให้ผู้ใช้ติดตั้งและใช้งาน Skill ดังกล่าว

ทำไมระบบสแกน AI Skill จึงตรวจไม่พบ

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

AIR ระบุว่าได้ทดสอบ Skill กับเครื่องมือตรวจสอบหลายระบบ รวมถึงเครื่องมือที่เกี่ยวข้องกับ Cisco, NVIDIA และระบบที่เชื่อมต่ออยู่กับแพลตฟอร์ม skills.sh แต่เครื่องมือทั้งหมดรายงานว่า Skill ปลอดภัย

สาเหตุที่ระบบตรวจไม่พบความเสี่ยงมีดังนี้

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

ใช้โดเมนปลอมเลียนแบบ Google Stitch

ภายใน Skill ไม่มีขั้นตอนการติดตั้งซอฟต์แวร์ที่ชัดเจน แต่สั่งให้ AI Agent ไปอ่านเอกสารการติดตั้ง “Stitch SDK” จากเว็บไซต์ stitch-design.ai ซึ่งเป็นโดเมนที่ AIR ควบคุมเอง

โดเมนดังกล่าวไม่ได้เป็นเว็บไซต์อย่างเป็นทางการของ Google Stitch เนื่องจากบริการจริงของ Google ใช้งานผ่านโดเมน stitch.withgoogle.com

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

หลังจาก Skill ถูกติดตั้งในวงกว้าง AIR เปลี่ยนเนื้อหาบนเว็บไซต์ภายนอกให้สั่ง AI Agent ดาวน์โหลดและเรียกใช้สคริปต์เพิ่มเติม

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

การทดลองเก็บเพียงอีเมล แต่ความเสี่ยงอาจรุนแรงกว่านั้น

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

บริษัทระบุว่าการทดลองเข้าถึงเอเจนต์ได้ประมาณ 26,000 ราย แต่ตัวเลขนี้มาจากข้อมูลของ AIR เพียงฝ่ายเดียว และยังไม่มีหน่วยงานอิสระยืนยัน

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

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

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

ช่องโหว่เกิดจากการตรวจสอบเพียงครั้งเดียว

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

สถานการณ์ที่เกิดขึ้นจึงมีลักษณะดังนี้

1. ผู้พัฒนาส่ง Skill ที่ไม่มีโค้ดอันตรายเข้าสู่ระบบตรวจสอบ
2. Skill เชื่อมโยงไปยังเว็บไซต์ภายนอกที่ดูปลอดภัย
3. ระบบสแกนรายงานว่าแพ็กเกจไม่มีความเสี่ยง
4. ผู้ใช้งานจำนวนมากติดตั้ง Skill
5. ผู้ควบคุมเว็บไซต์เปลี่ยนเนื้อหาเป็นคำสั่งที่มีความเสี่ยง
6. AI Agent ดึงคำสั่งเวอร์ชันใหม่และปฏิบัติตามโดยอัตโนมัติ

วิธีนี้คล้ายกับการโจมตีแบบ Time-of-Check to Time-of-Use หรือ TOCTOU ซึ่งข้อมูลในช่วงตรวจสอบแตกต่างจากข้อมูลที่ถูกใช้งานจริงในภายหลัง

งานวิจัยก่อนหน้านี้พบปัญหาในลักษณะเดียวกัน

AIR ไม่ใช่หน่วยงานแรกที่แสดงให้เห็นว่าเครื่องมือตรวจสอบ AI Skill สามารถถูกหลีกเลี่ยงได้

ก่อนหน้านี้ Trail of Bits ได้ทดสอบระบบตรวจจับ Skill ที่เป็นอันตรายบนแพลตฟอร์ม ClawHub รวมถึงเครื่องมือของ Cisco และเครื่องมือสแกนที่เชื่อมต่ออยู่กับ skills.sh

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

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

เอกสารของ Anthropic ยังเตือนถึงความเสี่ยงจาก Skill ที่ดึงข้อมูลจาก URL ภายนอก เนื่องจากเนื้อหาบนเว็บไซต์สามารถเปลี่ยนแปลงได้หลังจากผ่านกระบวนการตรวจสอบแล้ว

GitHub Stars และผลสแกนปลอดภัยอาจไม่เพียงพอ

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

จำนวนดาวบน GitHub สามารถถูกยืมความน่าเชื่อถือ

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

ผู้ใช้งานจึงไม่ควรประเมิน Skill จากจำนวนดาวของ Repository เพียงอย่างเดียว แต่ควรตรวจสอบประวัติของผู้พัฒนา การเปลี่ยนแปลงใน Pull Request และคำสั่งที่ Skill จะเรียกใช้งาน

ผลสแกนสะท้อนเพียงข้อมูลในช่วงเวลานั้น

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

หาก Skill เชื่อมต่อกับไฟล์ URL หรือเซิร์ฟเวอร์ภายนอก พฤติกรรมของ Skill อาจเปลี่ยนโดยที่ตัวแพ็กเกจไม่ถูกแก้ไขเลย

โอเพนซอร์สไม่ได้รับประกันความปลอดภัยเสมอไป

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

โดยเฉพาะ Skill ที่มีจำนวนมากและถูกเพิ่มเข้ามาอย่างต่อเนื่อง การตรวจสอบด้วยมนุษย์อาจไม่ครอบคลุมทุกการเปลี่ยนแปลง

แนวทางป้องกัน AI Agent Skill ที่ไม่ปลอดภัย

องค์กรควรจัดการ AI Agent Skill ในลักษณะเดียวกับซอฟต์แวร์หรือแพ็กเกจจากบุคคลภายนอก ไม่ควรมองว่าเป็นเพียงไฟล์ข้อความหรือชุด Prompt ทั่วไป

แนวทางที่ควรดำเนินการมีดังนี้

• ตรวจสอบ Skill ที่ติดตั้งอยู่ในระบบทั้งหมด
• จำกัดแหล่งติดตั้งให้มาจาก Repository หรือ Marketplace ที่องค์กรควบคุม
• ตรวจสอบ URL ภายนอกที่ Skill เรียกใช้งาน
• บันทึกและติดตามการเปลี่ยนแปลงของเนื้อหาจากเว็บไซต์ภายนอก
• กำหนดเวอร์ชันของ Skill และ Dependency ให้ชัดเจน
• ตรวจสอบ Skill ใหม่เมื่อไฟล์หรือแหล่งข้อมูลที่เชื่อมโยงมีการเปลี่ยนแปลง
• จำกัดสิทธิ์ AI Agent ตามหลัก Least Privilege
• แยกข้อมูลสำคัญออกจากสภาพแวดล้อมที่เอเจนต์สามารถเข้าถึง
• บล็อกการดาวน์โหลดหรือเรียกใช้สคริปต์จากโดเมนที่ไม่ได้รับอนุญาต
• บันทึก Log การเข้าถึงเว็บไซต์ การดาวน์โหลดไฟล์ และการเรียกใช้คำสั่งของเอเจนต์

องค์กรควรตรวจสอบอะไรบ้างก่อนอนุญาตให้ใช้ Skill

ก่อนอนุญาตให้ติดตั้ง AI Agent Skill ฝ่ายไอทีและทีมความปลอดภัยควรตรวจสอบอย่างน้อยในประเด็นต่อไปนี้

แหล่งที่มาของ Skill

ตรวจสอบชื่อผู้พัฒนา ประวัติการเผยแพร่ อายุบัญชี Repository ต้นทาง และบุคคลที่อนุมัติการนำ Skill เข้าสู่ระบบ

สิทธิ์ที่ Skill ต้องใช้

พิจารณาว่า Skill จำเป็นต้องอ่านไฟล์ เข้าถึงอีเมล เชื่อมต่อฐานข้อมูล หรือเรียกใช้คำสั่งในระบบปฏิบัติการจริงหรือไม่

การเชื่อมต่อไปยังเว็บไซต์ภายนอก

ตรวจสอบทุกโดเมนที่ Skill เรียกใช้งาน รวมถึง Redirect, ไฟล์ดาวน์โหลด และ API Endpoint โดยไม่ควรเชื่อถือโดเมนจากชื่อที่ดูคล้ายบริการจริงเพียงอย่างเดียว

ความสามารถในการเปลี่ยนคำสั่งภายหลัง

หาก Skill โหลดเอกสารหรือคำสั่งจากระยะไกล ควรมีระบบตรวจสอบ Hash, Digital Signature หรือการกำหนดเวอร์ชัน เพื่อป้องกันการเปลี่ยนเนื้อหาโดยไม่ได้รับอนุญาต

พฤติกรรมขณะทำงาน

ควรตรวจสอบพฤติกรรมจริงในสภาพแวดล้อม Sandbox ไม่ใช่วิเคราะห์เฉพาะไฟล์แบบ Static Scan เพราะคำสั่งบางส่วนจะปรากฏเฉพาะเมื่อ Skill เริ่มทำงานแล้ว

ตัวเลข 26,000 รายยังต้องอ่านอย่างระมัดระวัง

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

ดังนั้น ตัวเลข 26,000 รายและขอบเขตการเข้าถึงระบบควรถูกพิจารณาอย่างระมัดระวัง เนื่องจากยังไม่มีการตรวจสอบโดยหน่วยงานอิสระ

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

สรุป

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

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

องค์กรที่นำ AI Agent มาใช้งานจึงควรปฏิบัติต่อ Skill เหมือนซอฟต์แวร์จากบุคคลภายนอก ตรวจสอบทั้งตัวแพ็กเกจ เว็บไซต์ที่เชื่อมโยง พฤติกรรมขณะทำงาน และสิทธิ์ที่เอเจนต์ได้รับ

ไม่ว่าจำนวนเอเจนต์ที่เข้าถึงได้จริงจะเป็น 26,000 รายหรือน้อยกว่านั้น วิธีการทดลองได้สะท้อนให้เห็นถึงปัญหาเชิงโครงสร้างของระบบนิเวศ AI Agent Skill ที่ยังต้องได้รับการแก้ไข ทั้งในด้านการตรวจสอบแบบต่อเนื่อง การควบคุมแหล่งติดตั้ง และการจำกัดสิทธิ์ของเอเจนต์

ที่มา thehackernews

SiamGeek

The post นักวิจัยสร้าง AI Agent Skill ปลอม เจาะช่องโหว่ระบบสแกน เข้าถึงเอเจนต์กว่า 26,000 ราย appeared first on SiamByte.