การโจมตีรูปแบบนี้เรียกว่า 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.

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

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

AI Coding Agent ทำอะไรจนถูกมองว่าเป็นการโจมตี

Sophos วิเคราะห์ข้อมูลจากระบบตรวจจับพฤติกรรมบน Windows เป็นระยะเวลา 7 วันในเดือนมิถุนายน 2026 โดยนับจากจำนวนเครื่องที่พบพฤติกรรม ไม่ได้นับจากจำนวนเหตุการณ์ทั้งหมด

ผลการวิเคราะห์พบว่ากิจกรรมที่ถูกบล็อกแบ่งออกเป็นกลุ่มสำคัญ ได้แก่

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

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

การเข้าถึงข้อมูลในเบราว์เซอร์ทำให้ระบบแจ้งเตือน

หนึ่งในกฎตรวจจับที่ทำงานบ่อยที่สุดเกี่ยวข้องกับการใช้ Windows Data Protection API หรือ DPAPI เพื่อถอดรหัสข้อมูลที่ถูกจัดเก็บไว้ในเบราว์เซอร์

กฎนี้คิดเป็น 42.6 เปอร์เซ็นต์ของกลุ่มพฤติกรรมเข้าถึงข้อมูลรับรอง โดยปกติแล้ว DPAPI ถูกใช้เพื่อปกป้องข้อมูลสำคัญ เช่น รหัสผ่าน คุกกี้ และข้อมูลการเข้าสู่ระบบ

Sophos พบว่า Claude Code ซึ่งใช้งานชุดความสามารถ GStack สามารถเรียกฟังก์ชันสำหรับควบคุมเบราว์เซอร์ โดยมีการใช้ PowerShell ติดต่อกับ DPAPI เพื่อปลดล็อกข้อมูลที่เบราว์เซอร์จัดเก็บไว้

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

Claude Code ตรวจสอบ Credential Manager ของ Windows

Sophos ยังพบเหตุการณ์ที่ Claude Code ปิดเบราว์เซอร์ซึ่งกำลังทำงานอยู่ ก่อนเรียกใช้สคริปต์ Python เพื่ออ่านข้อมูลจากพื้นที่จัดเก็บข้อมูลรับรองของเบราว์เซอร์

ในอีกเหตุการณ์หนึ่ง Claude Code ใช้คำสั่งต่อไปนี้เพื่อตรวจสอบข้อมูลที่ Windows Credential Manager จัดเก็บไว้

cmdkey /list

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

Sophos ระบุว่า Claude Code ในเหตุการณ์นี้ทำงานร่วมกับตัวเลือก --dangerously-skip-permissions ซึ่งเป็นโหมดที่ลดขั้นตอนการขออนุญาตก่อนดำเนินการบางอย่าง

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

OpenAI Codex เปลี่ยนวิธีดาวน์โหลดไฟล์เมื่อถูกบล็อก

OpenAI Codex ถูกตรวจพบว่าพยายามดาวน์โหลดตัวติดตั้ง Python จากเว็บไซต์ python.org โดยเริ่มจากการใช้คำสั่ง certutil

เมื่อระบบรักษาความปลอดภัยบล็อกคำสั่งดังกล่าว Codex จึงเปลี่ยนไปใช้ bitsadmin เพื่อดาวน์โหลดไฟล์แทน

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

พฤติกรรมลักษณะนี้มักถูกเรียกว่า Living off the Land หรือการใช้เครื่องมือที่มีอยู่ในระบบปฏิบัติการเพื่อดำเนินกิจกรรมบางอย่าง

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

Cursor สร้างสคริปต์ในโฟลเดอร์ Startup

Cursor ถูกตรวจพบว่าใช้ PowerShell เพื่อเขียนไฟล์สคริปต์ลงในโฟลเดอร์ Startup ของ Windows

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

Sophos ไม่สามารถยืนยันได้ว่าสคริปต์ดังกล่าวมีหน้าที่อะไร แต่การเขียนไฟล์ลงใน Startup โดยกระบวนการที่ไม่ใช่โปรแกรมติดตั้งที่เชื่อถือได้ ถือเป็นพฤติกรรมที่ฝ่ายรักษาความปลอดภัยต้องตรวจสอบ

AI Agent อาจเป็นทั้งเครื่องมือพัฒนาและเครื่องมือโจมตี

ปัญหานี้ไม่ได้อยู่ที่ AI Coding Agent ฝั่งนักพัฒนาเพียงอย่างเดียว เพราะผู้โจมตีก็สามารถใช้ AI Agent เพื่อช่วยสร้าง ทดสอบ และปรับปรุงมัลแวร์ได้เช่นกัน

Sophos เคยพบผู้โจมตีใช้ AI Agent เพื่อพัฒนาเครื่องมือและทดสอบการหลบเลี่ยงระบบ Endpoint Detection and Response หรือ EDR โดยมีการใช้ Claude Opus 4.5 ช่วยประสานขั้นตอนการทำงาน

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

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

พฤติกรรมเดียวกันอาจมาจากหลายสถานการณ์

การเรียกใช้ DPAPI การดาวน์โหลดไฟล์ผ่านเครื่องมือของ Windows หรือการเขียนไฟล์ลงใน Startup ไม่ได้บ่งชี้เจตนาได้ชัดเจนเหมือนในอดีต

พฤติกรรมเดียวกันอาจเกิดจากหลายกรณี ได้แก่

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

ข้อมูลจาก CrowdStrike Global Threat Report 2026 ระบุว่า 82 เปอร์เซ็นต์ของเหตุการณ์ที่ตรวจพบในปี 2025 เป็นการโจมตีที่ไม่ใช้มัลแวร์โดยตรง

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

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

แนวทางลดการแจ้งเตือนจาก AI Coding Agent

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

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

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

การกำหนดเงื่อนไขเหล่านี้ช่วยลดการแจ้งเตือนที่ไม่จำเป็น โดยไม่ต้องยกเว้นการตรวจสอบ AI Agent ทั้งหมด

การเข้าถึงข้อมูลรับรองไม่ควรถูกอนุญาตแบบครอบคลุม

Sophos เน้นว่าพฤติกรรมเกี่ยวกับข้อมูลรับรองควรถูกจัดการอย่างเข้มงวดกว่ากิจกรรมประเภทอื่น

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

แนวทางที่องค์กรควรนำไปใช้ ได้แก่

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

องค์กรต้องกำหนดขอบเขตการทำงานของ AI Agent

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

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

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

สรุป

AI Coding Agent อย่าง Claude Code, Cursor และ OpenAI Codex ไม่ได้เป็นมัลแวร์ แต่รูปแบบการทำงานของเครื่องมือเหล่านี้เริ่มคล้ายกับเทคนิคที่ผู้โจมตีใช้มากขึ้น

การถอดรหัสข้อมูลในเบราว์เซอร์ การตรวจสอบ Credential Manager การดาวน์โหลดไฟล์ผ่าน certutil หรือ bitsadmin และการสร้างไฟล์ใน Startup ล้วนเป็นพฤติกรรมที่ระบบรักษาความปลอดภัยมีเหตุผลเพียงพอที่จะตรวจจับ

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

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

ที่มา thehackernews

SiamGeek

The post AI Coding Agent ทำระบบรักษาความปลอดภัยแจ้งเตือน หลังพฤติกรรมคล้ายแฮกเกอร์ appeared first on SiamByte.

เหตุการณ์นี้ได้รับความสนใจอย่างมาก เพราะที่ผ่านมาอุตสาหกรรมเทคโนโลยีมักพบข่าวบริษัทในสหรัฐฯ จำกัดการใช้งานฮาร์ดแวร์และซอฟต์แวร์จากจีนด้วยเหตุผลด้านความมั่นคงและความปลอดภัยของข้อมูล แต่กรณีของ Alibaba กลับเป็นสถานการณ์ในทิศทางตรงกันข้าม

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

Alibaba วางแผนห้ามใช้ Claude Code ภายในบริษัท

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

มีรายงานว่า Alibaba กังวลว่าการใช้ Claude Code ภายในองค์กรอาจทำให้ข้อมูลสำคัญ เช่น ซอร์สโค้ด โครงสร้างระบบ เอกสารทางเทคนิค หรือข้อมูลการพัฒนาผลิตภัณฑ์ ถูกส่งออกไปประมวลผลบนระบบภายนอก

มาตรการที่มีการกล่าวถึงประกอบด้วย

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

นักวิจัยพบระบบติดตามผู้ใช้งานจากประเทศจีน

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

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

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

อย่างไรก็ตาม การมีระบบตรวจสอบตำแหน่งหรือภูมิภาคของผู้ใช้งานไม่ได้หมายความว่าจะมีการส่งมอบข้อมูลให้หน่วยงานรัฐบาลโดยอัตโนมัติ และยังไม่มีหลักฐานยืนยันว่าข้อมูลภายในของ Alibaba รั่วไหลผ่าน Claude

Anthropic ระบุว่าเป็นมาตรการป้องกันการใช้งานโดยไม่ได้รับอนุญาต

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

หนึ่งในประเด็นที่บริษัท AI ให้ความสำคัญคือกระบวนการ Model Distillation ซึ่งผู้พัฒนาอาจส่งคำถามจำนวนมากไปยังโมเดลที่มีความสามารถสูง จากนั้นนำคำตอบที่ได้รับไปใช้เป็นข้อมูลสำหรับฝึกโมเดลของตนเอง

Anthropic กังวลว่ากระบวนการดังกล่าวอาจทำให้บริษัทอื่นสามารถถ่ายทอดความสามารถบางส่วนของ Claude ไปยังโมเดลคู่แข่ง โดยไม่ต้องลงทุนด้านข้อมูลและการฝึกโมเดลในระดับเดียวกัน

Alibaba เคยถูกกล่าวถึงในประเด็นการฝึกโมเดล Qwen

Alibaba เป็นผู้พัฒนาโมเดลภาษาขนาดใหญ่ในตระกูล Qwen ซึ่งได้รับความนิยมทั้งในจีนและตลาดนักพัฒนาแบบโอเพนซอร์ส

ที่ผ่านมา Anthropic เคยกล่าวถึงความพยายามของบริษัท AI บางแห่งในการใช้คำตอบจาก Claude เพื่อพัฒนาโมเดลของตนเอง โดย Alibaba และโมเดล Qwen เป็นหนึ่งในชื่อที่ปรากฏอยู่ในการรายงานเกี่ยวกับประเด็นนี้

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

Alibaba จะผลักดัน Qoder เป็นทางเลือกแทน Claude Code

มีรายงานว่า Alibaba จะแนะนำให้พนักงานใช้ Qoder ซึ่งเป็นเครื่องมือ AI สำหรับช่วยเขียนโค้ดที่บริษัทพัฒนาขึ้นเองแทน Claude Code

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

ข้อได้เปรียบของการใช้ AI ที่องค์กรพัฒนาหรือควบคุมเอง ได้แก่

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

ความกังวลเรื่องรัฐบาลสหรัฐฯ ควบคุมโมเดล AI

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

กรณีที่เกี่ยวข้องกับโมเดล Mythos และ Fable 5 ถูกนำมาใช้เป็นตัวอย่างว่าบริษัท AI ในสหรัฐฯ อาจต้องปรับเปลี่ยนหรือจำกัดการให้บริการตามคำสั่ง มาตรการ หรือกฎหมายของรัฐบาลสหรัฐฯ

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

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

บริษัททั่วโลกเริ่มควบคุมการใช้ AI เขียนโค้ด

กรณีของ Alibaba สะท้อนให้เห็นแนวโน้มที่หลายองค์กรเริ่มกำหนดนโยบายควบคุมการใช้ Generative AI และเครื่องมือ AI เขียนโค้ดอย่างจริงจัง

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

• ซอร์สโค้ดที่เป็นความลับของบริษัท
• API Key และรหัสผ่านของระบบ
• ข้อมูลลูกค้าและข้อมูลส่วนบุคคล
• โครงสร้างฐานข้อมูล
• ช่องโหว่ด้านความปลอดภัย
• เอกสารการออกแบบระบบภายใน
• แผนพัฒนาผลิตภัณฑ์ที่ยังไม่เปิดเผย

หลายบริษัทจึงเลือกอนุญาตเฉพาะเครื่องมือ AI ที่ผ่านการตรวจสอบ หรือใช้งานโมเดลภายในระบบ Private Cloud และ On-Premise เพื่อป้องกันข้อมูลออกจากเครือข่ายองค์กร

สรุป Alibaba วางแผนแบน Claude Code

มีรายงานว่า Alibaba วางแผนห้ามพนักงานใช้ Claude Code และจะให้ลบเครื่องมือที่เกี่ยวข้องกับ Claude ออกจากคอมพิวเตอร์ของบริษัท หลังเกิดความกังวลเกี่ยวกับระบบตรวจสอบผู้ใช้งานจากประเทศจีนและความเสี่ยงที่ข้อมูลภายในอาจถูกประมวลผลโดยบริษัทจากสหรัฐฯ

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

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

ที่มา The Next Web

MiloMeowTech

The post Alibaba วางแผนห้ามพนักงานใช้ Claude Code หวั่นข้อมูลบริษัทรั่วไหลไปยังสหรัฐฯ appeared first on SiamByte.

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

GLM-5.2 คืออะไร

GLM-5.2 เป็นโมเดลปัญญาประดิษฐ์รุ่นใหม่จาก Z.ai ที่เปิดให้ใช้งานในรูปแบบโอเพนซอร์ส โดยเน้นความสามารถด้านการประมวลผลงานที่มีความซับซ้อนและใช้เวลานานมากกว่าการตอบคำถามสั้น ๆ ทั่วไป

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

จุดเด่นของ GLM-5.2

GLM-5.2 มาพร้อมจุดเด่นหลายด้านที่ทำให้โมเดลนี้น่าสนใจ โดยเฉพาะสำหรับนักพัฒนาและองค์กรที่ต้องการใช้งาน AI แบบจริงจัง

• รองรับ Context ขนาดใหญ่สูงสุด 1 ล้านโทเค็น
• ออกแบบมาเพื่อทำงานแบบ Long-Horizon Task
• พัฒนาต่อจาก GLM-5.1 ที่รองรับการทำงานต่อเนื่องได้นาน 8 ชั่วโมง
• มีประสิทธิภาพสูงในการทดสอบด้านงานเขียนโค้ดและงานหลังการฝึกโมเดล
• รองรับการเลือกระดับการคิดแบบ High และ Max
• ใช้เทคนิค IndexShare เพื่อลดต้นทุนการประมวลผล
• เปิดให้ใช้งานผ่าน Z.ai และ GLM Coding Plan
• รองรับการดาวน์โหลดไปรันแบบ Local ผ่าน HuggingFace และ ModelScope

รองรับ Context สูงสุด 1 ล้านโทเค็น

หนึ่งในจุดขายสำคัญของ GLM-5.2 คือการรองรับ Context ขนาดใหญ่ระดับ 1 ล้านโทเค็น ซึ่งเพิ่มขึ้นจากรุ่นก่อนหน้าที่รองรับสูงสุด 2 แสนโทเค็น

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

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

เน้นงาน Long-Horizon Task สำหรับงานต่อเนื่องระยะยาว

Z.ai วางตำแหน่ง GLM-5.2 ให้เป็นโมเดลที่เหมาะกับงาน Long-Horizon Task หรืองานที่ต้องทำต่อเนื่องเป็นเวลานาน โดยเฉพาะงานที่ต้องใช้การวางแผนหลายขั้นตอน

ตัวอย่างงานที่เหมาะกับ GLM-5.2 ได้แก่

• งานเขียนโค้ดและแก้ไขโปรเจกต์ขนาดใหญ่
• งานวิเคราะห์เอกสารหรือฐานข้อมูลจำนวนมาก
• งาน Automation ที่ต้องทำหลายขั้นตอน
• งาน Agentic AI ที่ต้องวางแผนและดำเนินการต่อเนื่อง
• งานตรวจสอบโค้ดและปรับปรุงระบบ
• งานวิจัยหรือสรุปข้อมูลที่มีเนื้อหายาวมาก

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

ผลทดสอบ FrontierSWE และ PostTrainBench

เพื่อเน้นจุดขายด้าน Long-Horizon Task มีรายงานว่า GLM-5.2 ถูกนำไปทดสอบกับ FrontierSWE และ PostTrainBench ซึ่งเป็นชุดทดสอบที่เกี่ยวข้องกับความสามารถในการทำงานที่ซับซ้อนและต่อเนื่อง

ผลการทดสอบระบุว่า GLM-5.2 ทำคะแนนได้น้อยกว่าเฉพาะ Opus 4.8 เท่านั้น แต่สามารถทำคะแนนได้สูงกว่า GPT-5.5 แม้ว่า GLM-5.2 จะเป็นโมเดลโอเพนซอร์สก็ตาม

ผลลัพธ์นี้ทำให้ GLM-5.2 กลายเป็นหนึ่งในโมเดลโอเพนซอร์สที่น่าจับตามอง โดยเฉพาะในกลุ่มงานเขียนโค้ด งานวิศวกรรมซอฟต์แวร์ และงานที่ต้องอาศัยการคิดหลายขั้นตอน

เลือกระดับการคิด High และ Max ได้

อีกหนึ่งจุดเด่นของ GLM-5.2 คือการจัดการต้นทุนในการประมวลผล โดยเฉพาะงานด้านการเขียนโค้ดที่มักใช้ทรัพยากรสูง

ผู้ใช้งานสามารถเลือกระดับการคิดของโมเดลได้ เช่น

• High: เหมาะกับงานที่ต้องการความเร็วและต้นทุนประมวลผลที่เหมาะสม
• Max: เหมาะกับงานที่ซับซ้อน ต้องการความละเอียดสูง และยอมแลกกับการใช้ทรัพยากรมากขึ้น

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

เทคโนโลยี IndexShare ลด FLOP ต่อโทเค็น

GLM-5.2 ยังมาพร้อมเทคนิคที่เรียกว่า IndexShare ซึ่งช่วยเพิ่มประสิทธิภาพการประมวลผล โดยมีรายงานว่าสามารถลด FLOP ต่อโทเค็นลงได้ 2.9 เท่า และช่วยให้ประสิทธิภาพการถอดรหัสดีขึ้นประมาณ 20%

การลดต้นทุนการประมวลผลต่อโทเค็นมีความสำคัญมากสำหรับโมเดลที่รองรับ Context ขนาดใหญ่ เพราะยิ่งโมเดลต้องประมวลผลข้อมูลจำนวนมาก ต้นทุนด้านเวลาและทรัพยากรก็ยิ่งสูงขึ้น ดังนั้นเทคนิคอย่าง IndexShare จึงเป็นส่วนสำคัญที่ช่วยให้ GLM-5.2 เหมาะกับงานระยะยาวมากขึ้น

ช่องทางใช้งาน GLM-5.2

GLM-5.2 เปิดให้ใช้งานแล้วผ่านแพลตฟอร์มและเครื่องมือต่าง ๆ ของ Z.ai รวมถึงรองรับการใช้งานในเครื่องมือเขียนโค้ดยอดนิยม

ช่องทางที่รองรับ ได้แก่

• Z.ai
• GLM Coding Plan
• ZCode
• Claude Code
• OpenCode
• HuggingFace
• ModelScope

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

GLM-5.2 เหมาะกับใคร

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

กลุ่มผู้ใช้งานที่น่าจะได้ประโยชน์จาก GLM-5.2 ได้แก่

• นักพัฒนาซอฟต์แวร์
• ทีม DevOps และ Automation
• นักวิจัยด้าน AI
• องค์กรที่ต้องการใช้โมเดลโอเพนซอร์ส
• ผู้ใช้งานที่ต้องวิเคราะห์เอกสารขนาดใหญ่
• ทีมที่ต้องการสร้าง AI Agent สำหรับงานหลายขั้นตอน
• ผู้ที่ต้องการรันโมเดล AI แบบ Local

สรุป

GLM-5.2 เป็นโมเดล AI โอเพนซอร์สรุ่นใหม่จาก Z.ai ที่น่าสนใจอย่างมาก โดยเฉพาะจุดเด่นด้าน Long-Horizon Task และการรองรับ Context ขนาดใหญ่สูงสุด 1 ล้านโทเค็น ทำให้เหมาะกับงานที่ต้องใช้ข้อมูลจำนวนมากและทำงานต่อเนื่องเป็นเวลานาน

นอกจากนี้ GLM-5.2 ยังมีระบบเลือกระดับการคิดแบบ High และ Max เพื่อช่วยบริหารต้นทุนและความเร็วในการประมวลผล พร้อมเทคนิค IndexShare ที่ช่วยลด FLOP ต่อโทเค็นและเพิ่มประสิทธิภาพการถอดรหัส

ด้วยความสามารถเหล่านี้ GLM-5.2 จึงเป็นอีกหนึ่งโมเดลโอเพนซอร์สที่น่าจับตาในปีนี้ โดยเฉพาะสำหรับนักพัฒนา ทีมซอฟต์แวร์ และองค์กรที่ต้องการนำ AI มาใช้กับงานเขียนโค้ด งานวิเคราะห์ข้อมูล และงาน Agentic AI ระยะยาว

ที่มา Z.ai

Mochi Cat

The post Z.ai เปิดตัว GLM-5.2 โมเดล AI โอเพนซอร์สใหม่ รองรับ Context 1 ล้านโทเค็น เน้นงาน Long-Horizon และเขียนโค้ดระยะยาว appeared first on SiamByte.