ไทย
English
Generative AI กำลังเปลี่ยนจากเครื่องมือสำหรับช่วยตอบไปสู่ระบบที่สามารถช่วยทำได้มากขึ้น ไม่ว่าจะเป็นการค้นเอกสารภายในองค์กร วิเคราะห์ข้อมูล เขียนโค้ด เชื่อมต่อกับ Cloud เรียกใช้ API หรือทำงานผ่าน AI Agent แบบอัตโนมัติ
ความสามารถที่เพิ่มขึ้นนี้ช่วยให้องค์กรทำงานได้เร็วขึ้น แต่ในอีกด้านหนึ่งก็ทำให้ Attack Surface หรือพื้นที่ที่อาจถูกโจมตีขยายกว้างขึ้น เช่นกัน เพราะเมื่อ AI สามารถเข้าถึงข้อมูลและระบบจริงได้ ความผิดพลาดอาจไม่ได้จบเพียงคำตอบที่ไม่ถูกต้อง แต่อาจนำไปสู่ข้อมูลรั่วไหล การใช้สิทธิ์เกินขอบเขต การดำเนินการที่ไม่ได้รับอนุญาต หรือแม้แต่ค่าใช้จ่ายจากระบบ AI ที่เพิ่มขึ้นจนควบคุมไม่ได้
เพื่อช่วยให้องค์กรเข้าใจและรับมือกับความเสี่ยงเหล่านี้ OWASP หรือองค์กรไม่แสวงหาผลกำไรระดับโลกที่พัฒนาแนวทางและองค์ความรู้ด้าน Application Security และ Cybersecurity ร่วมกับชุมชนผู้เชี่ยวชาญระดับโลก ได้มีการจัดทำ OWASP Top 10 for LLM Applications 2026 ผ่านโครงการ OWASP GenAI Security Project เพื่อรวบรวม 10 ความเสี่ยงสำคัญที่องค์กรและทีม Security ควรคำนึงถึงเมื่อนำ LLM มาใช้งานจริง
Table of Contents
Key Takeaways
- Prompt Injection ยังเป็นความเสี่ยงอันดับหนึ่งและคำสั่งโจมตีไม่ได้มาจากผู้ใช้โดยตรงเท่านั้น แต่อาจซ่อนอยู่ในเว็บไซต์ เอกสาร อีเมล รูปภาพ เสียง Tool Output หรือข้อมูลที่ RAG ดึงมาให้ AI อ่าน
- สิทธิ์ของ AI สำคัญพอ ๆ กับความสามารถของ AI ยิ่ง AI เข้าถึงข้อมูลและ Tool ได้มาก ความเสียหายจากการถูกหลอกหรือทำงานผิดพลาดก็ยิ่งสูงขึ้น
- ข้อมูลอ่อนไหวไม่ได้รั่วผ่านคำตอบเพียงช่องทางเดียวแต่สามารถอยู่ใน Prompt, Log, Trace, Tool Call, RAG, Memory, Embedding และ Vector Database ได้
- อย่าใช้ System Prompt เป็น Security Boundary Password, API Key, Authorization Rule หรือ Security Policy ที่สำคัญควรถูกควบคุมจากระบบภายนอก
- คำตอบที่ดูมั่นใจไม่ได้แปลว่าถูกต้อง โดยเฉพาะข้อมูลที่นำไปสู่การตัดสินใจหรือการดำเนินการในระบบจริง
- Cost Control กลายเป็น Security Control ระบบ AI ควรมี Token Limit, Spending Cap, Time Limit และ Step Limit เพื่อป้องกันการใช้งานทรัพยากรเกินขอบเขต
LLM คืออะไร?
LLM หรือ Large Language Model คือโมเดล AI ที่ได้รับการฝึกจากข้อมูลจำนวนมาก เพื่อให้สามารถเข้าใจและสร้างภาษาที่ใกล้เคียงกับมนุษย์ สามารถนำมาใช้ตอบคำถาม สรุปเอกสาร วิเคราะห์ข้อมูล สร้างเนื้อหา หรือช่วยเขียนโค้ดได้
แต่ LLM ในองค์กรปัจจุบันไม่ได้อยู่แค่ใน Chatbot หลายระบบเริ่มเชื่อม AI เข้ากับ RAG, ฐานข้อมูล, Email, Cloud, API และเครื่องมือภายในองค์กร รวมถึงพัฒนาไปสู่ AI Agent ที่สามารถเลือก Tool และดำเนินงานหลายขั้นตอนได้เอง ทำให้ AI Security เริ่มกลายเป็นส่วนหนึ่งของ Cybersecurity โดยตรง เพราะสิ่งที่ต้องป้องกันไม่ได้มีแค่ตัวโมเดล แต่รวมถึง Identity, Data, Application, Infrastructure และระบบที่ AI เชื่อมต่ออยู่ด้วย
OWASP Top 10 ปี 2026 มีอะไรใหม่?
หนึ่งในการเปลี่ยนแปลงสำคัญของฉบับปี 2026 คือ OWASP ไม่ได้จัดอันดับจากความคิดเห็นของผู้เชี่ยวชาญเพียงอย่างเดียว แต่เพิ่มข้อมูลจากเหตุการณ์ที่เกิดขึ้นจริงเข้ามาประกอบด้วย
OWASP รวบรวมเหตุการณ์ทั้งหมด 7,714 รายการ จากฐานข้อมูลช่องโหว่สาธารณะและฐานข้อมูลเหตุการณ์ที่เกี่ยวข้องกับ AI โดย 6,639 รายการ มีข้อมูลเพียงพอสำหรับนำมาจัดหมวดหมู่
อันดับสุดท้ายจึงมาจาก:
- 75% การลงคะแนนจากผู้เชี่ยวชาญและชุมชน
- 25% หลักฐานจากเหตุการณ์ที่เกิดขึ้นจริง
นอกจากนี้ OWASP ยังขยายขอบเขตหลายหัวข้อให้ครอบคลุมรูปแบบการใช้งาน AI ในปัจจุบันมากขึ้น เช่น Prompt Injection ผ่านภาพและเสียง ความเสี่ยงจาก AI Agent, Model Supply Chain, RAG, Embedding รวมถึงการสร้างโค้ดที่ไม่ปลอดภัยโดย AI
การเปลี่ยนแปลงอันดับ OWASP GenAI/LLM Top 10 จากปี 2025 สู่ปี 2026
OWASP Top 10 for LLM Applications ปี 2026 ยังคงมีความเสี่ยงหลัก 10 รายการเท่าเดิม แต่มีการปรับลำดับความสำคัญหลายหัวข้อ เพื่อสะท้อนรูปแบบการใช้งาน LLM และ AI Agent ที่เปลี่ยนไป
ทำไมบางความเสี่ยงถึงขยับอันดับ?
Excessive Agency ขยับจากอันดับ 6 ขึ้นมาเป็นอันดับ 3 เพราะระบบแบบ Agentic AI กำลังถูกนำมาใช้งานมากขึ้น เมื่อ AI ไม่ได้สร้างเพียงคำตอบ แต่สามารถเรียก Tool เข้าถึงข้อมูล ส่งอีเมล แก้ไขไฟล์ หรือดำเนินการในระบบอื่นได้ ความผิดพลาดจาก Hallucination หรือ Prompt Injection จึงอาจกลายเป็นการกระทำที่สร้างผลกระทบจริง โดยเฉพาะหาก AI ได้รับ Permission หรือ Autonomy มากเกินความจำเป็น
Unbounded Consumption ขยับจากอันดับ 10 มาเป็นอันดับ 6 แสดงความสำคัญของการควบคุมทรัพยากรและค่าใช้จ่าย โดยเฉพาะ Reasoning Model, Multimodal Model และ AI Agent ที่คำขอเพียงครั้งเดียวอาจขยายเป็นการประมวลผลหลายขั้นตอน ใช้ Token จำนวนมาก หรือเรียก Tool ต่อเนื่องจนเกิดทั้ง Denial of Service และ Denial of Wallet
ส่วน Improper Output Handling ลดจากอันดับ 5 มาอยู่ที่อันดับ 10 ซึ่งเป็นหัวข้อที่ลดอันดับมากที่สุด แต่ไม่ได้หมายความว่าความเสี่ยงนี้หายไป เพราะ OWASP ยังขยายขอบเขตให้ครอบคลุมถึงโค้ดที่ AI สร้างขึ้นอย่างไม่ปลอดภัยด้วย
อีกจุดที่น่าสนใจคือ System Prompt Leakage ถูกเปลี่ยนชื่อเป็น Hidden Context Exposure เพื่อให้ครอบคลุมมากกว่า System Prompt เช่น Developer Instruction, Tool Schema, Internal Policy, Permission และ Workflow Logic
ภาพรวมของการเปลี่ยนแปลงในปี 2026 สะท้อนว่า ความเสี่ยงของ LLM กำลังขยับจากเรื่อง AI ตอบอะไร ไปสู่เรื่อง AI สามารถทำอะไรต่อจากคำตอบนั้นได้บ้าง
10 ความเสี่ยงปัจจุบันไม่ได้แยกออกจากกัน การโจมตีอาจเริ่มจาก Prompt Injection หรือ Supply Chain ก่อนขยายผลผ่านสิทธิ์ที่มากเกินไป และสุดท้ายกลายเป็นข้อมูลรั่วไหล ค่าใช้จ่ายที่เพิ่มขึ้น หรือการดำเนินการที่ผิดพลาดในระบบจริง
10 ความเสี่ยงสำคัญของ LLM Applications ปี 2026
1. LLM01:2026 Prompt Injection
Prompt Injection คือการที่ข้อมูลหรือคำสั่งที่เข้าสู่ LLM ส่งผลให้โมเดลทำงานหรือแสดงพฤติกรรมต่างไปจากที่ผู้พัฒนาตั้งใจไว้ การโจมตีไม่ได้เกิดจากข้อความที่ผู้ใช้พิมพ์เข้าไปโดยตรงเท่านั้น แต่คำสั่งที่เป็นอันตรายอาจแฝงอยู่ใน เว็บไซต์ เอกสาร อีเมล รูปภาพ เสียง วิดีโอ Tool Output ข้อมูลจาก RAG หรือ Persistent Memory และส่งผลต่อโมเดลได้โดยที่ผู้ใช้อาจไม่เห็นคำสั่งเหล่านั้นเลย
สาเหตุสำคัญคือ LLM ประมวลผลทั้ง คำสั่ง (Instruction) และ ข้อมูล (Data) อยู่ใน Context เดียวกัน โดยไม่มีขอบเขตความน่าเชื่อถือที่แยกออกจากกันอย่างเด็ดขาด จึงเปิดโอกาสให้ข้อมูลจากแหล่งที่ไม่น่าเชื่อถือเข้ามามีอิทธิพลต่อการทำงานของโมเดลได้
หาก Prompt Injection สำเร็จ ผลกระทบอาจมีตั้งแต่การทำให้ AI ตอบไปในทิศทางที่ผู้โจมตีต้องการ การเปิดเผยข้อมูลสำคัญ ไปจนถึงการเรียกใช้ Tool หรือดำเนินการกับระบบอื่นโดยไม่ได้ตั้งใจ โดยเฉพาะเมื่อ AI เชื่อมต่อกับ Email, File System, Cloud API หรือระบบภายในองค์กร
องค์กรควรทำอย่างไร: ควรออกแบบระบบโดยตั้งสมมติฐานว่า Prompt Injection อาจเกิดขึ้นได้ จึงไม่ควรพึ่งการป้องกันที่ตัว Prompt เพียงอย่างเดียว แต่ควร จำกัดสิทธิ์และความสามารถของ AI ตามหลัก Least Privilege เก็บ Credential และสิทธิ์ในการเปลี่ยนแปลงข้อมูลไว้ใน Application Code และให้มีการยืนยันจากผู้ใช้ก่อนดำเนินการที่สำคัญหรือไม่สามารถย้อนกลับได้
2. LLM02:2026 Sensitive Information Disclosure
Sensitive Information Disclosure คือความเสี่ยงที่ระบบ LLM เปิดเผยข้อมูลสำคัญหรือข้อมูลอ่อนไหวให้กับผู้ที่ไม่ได้รับอนุญาต ไม่ว่าจะเป็น ข้อมูลส่วนบุคคล ข้อมูลทางการเงิน Credential, API Key, ข้อมูลภายในองค์กร หรือทรัพย์สินทางปัญญา
ข้อมูลอาจไม่ได้รั่วผ่านเฉพาะคำตอบที่ AI แสดงให้ผู้ใช้เห็นเท่านั้น แต่ยังสามารถรั่วผ่าน Tool Call, ข้อมูลที่ระบบ RAG ดึงมา, Log, Trace, Telemetry หรือ Embedding ที่เกิดขึ้นระหว่างการทำงานของระบบได้
อีกประเด็นที่ OWASP ให้ความสำคัญคือ Embedding ก็ถือเป็นข้อมูลที่ต้องปกป้อง แม้จะอยู่ในรูปของชุดตัวเลข เพราะเทคนิค Embedding Inversion สามารถนำข้อมูลเหล่านี้มาสร้างเนื้อหาต้นฉบับกลับคืนมาได้ ดังนั้นการรั่วไหลของ Vector Database หรือ Backup ที่เก็บ Embedding อาจนำไปสู่การเปิดเผยข้อมูลต้นฉบับได้เช่นกัน
องค์กรควรทำอย่างไร: ส่งเฉพาะข้อมูลที่จำเป็นให้ LLM (Data Minimization) ตรวจสอบสิทธิ์ของผู้ใช้ ก่อนที่ระบบจะดึงข้อมูลจาก RAG หรือ Vector Database กำหนด Access Control ในระดับ Document และ Chunk และดูแล Log, Trace, Embedding รวมถึง Backup ให้เหมาะสมกับระดับความอ่อนไหวของข้อมูล
3. LLM03:2026 Excessive Agency
Excessive Agency คือความเสี่ยงที่เกิดขึ้นเมื่อ LLM หรือ AI Agent ได้รับ ความสามารถ สิทธิ์ หรืออิสระในการตัดสินใจมากเกินกว่าที่จำเป็นต่อหน้าที่ของระบบ
ตัวอย่างเช่น AI ที่มีหน้าที่สรุปอีเมลต้องการเพียงสิทธิ์ในการ “อ่าน” ข้อความ แต่ Tool ที่เชื่อมต่อกลับสามารถส่งหรือลบอีเมลได้ด้วย หาก AI ถูก Prompt Injection หรือทำงานผิดพลาด ความสามารถส่วนเกินเหล่านี้อาจถูกนำไปใช้ในทางที่ไม่ได้ตั้งใจ เช่น ส่งข้อมูลสำคัญออกไปยังบุคคลภายนอก
OWASP ระบุว่าความเสี่ยงนี้มักเกิดจาก 3 สาเหตุหลัก คือ มี Function มากเกินไป (Excessive Functionality), มี Permission มากเกินไป (Excessive Permissions) และมี Autonomy มากเกินไป (Excessive Autonomy) ซึ่งยิ่ง AI เชื่อมต่อกับระบบสำคัญมากเท่าใด ผลกระทบก็ยิ่งขยายวงกว้างขึ้น
องค์กรควรทำอย่างไร: ใช้หลัก Least Privilege ให้ AI เข้าถึงเฉพาะ Tool และ Permission ที่จำเป็น หลีกเลี่ยง Tool ที่มีความสามารถกว้างเกินไป และกำหนดให้มี Human Approval ก่อนดำเนินการที่มีผลกระทบสูงหรือไม่สามารถย้อนกลับได้
4. LLM04:2026 Supply Chain
Supply Chain ของระบบ AI มีขอบเขตกว้างกว่าซอฟต์แวร์ทั่วไป เพราะไม่ได้ครอบคลุมเพียง Library หรือ Package แต่ยังรวมถึง Training Data, Model, Adapter, Conversion Pipeline และ Deployment Platform ซึ่งแต่ละจุดสามารถกลายเป็นช่องทางของความเสี่ยงได้ เช่น
- Model
- Dataset
- LoRA และ Adapter
- Model Hub
- Serving Framework
- Model Conversion
- Quantization
- Build และ Deployment Pipeline
ความเสี่ยงสามารถเกิดขึ้นได้ตั้งแต่การนำ Model หรือ Adapter จากแหล่งที่ไม่น่าเชื่อถือมาใช้งาน ไปจนถึงการที่ Artifact ถูกแก้ไขหรือสับเปลี่ยน ระหว่างการจัดเก็บ การแปลง Model หรือกระบวนการก่อนนำขึ้น Production ซึ่งอาจทำให้องค์กรได้รับ Model ที่มี Backdoor หรือพฤติกรรมที่ไม่พึงประสงค์โดยไม่รู้ตัว
OWASP ยังกล่าวถึงความเสี่ยงที่เรียกว่า Slopsquatting ซึ่งเกิดขึ้นเมื่อ AI Coding Assistant แนะนำชื่อ Package ที่ดูน่าเชื่อถือแต่ไม่มีอยู่จริง ผู้โจมตีอาจจดทะเบียน Package ภายใต้ชื่อนั้นและใส่โค้ดอันตรายไว้ เพื่อรอให้ Developer ดาวน์โหลดไปใช้งานโดยไม่ได้ตรวจสอบ
ภาพรวมของ Attack Surface ตลอด Supply Chain ของ LLM แสดงในรูปด้านล่าง
องค์กรควรทำอย่างไร: ตรวจสอบแหล่งที่มาและ Supplier ของ Model, Dataset และ Component ต่าง ๆ จัดทำ SBOM, AIBOM หรือ ML-BOM ใช้ Hash และ Digital Signature เพื่อตรวจสอบ Artifact และประเมินพฤติกรรมของ Model ก่อนนำเข้าสู่ Production
ทั้งนี้ Digital Signature ช่วยยืนยันแหล่งที่มาและความสมบูรณ์ (Integrity) ของ Artifact แต่ไม่ได้ยืนยันว่า Model นั้นปลอดภัยหรือไม่มี Backdoor จึงควรใช้ควบคู่กับการทดสอบและประเมินพฤติกรรมของ Model ก่อนใช้งานจริง
5. LLM05:2026 Data and Model Poisoning
Data and Model Poisoning คือการที่ข้อมูลหรือ Model Artifact ถูกแทรก แก้ไข หรือปนเปื้อน จนทำให้ AI เรียนรู้หรือแสดงพฤติกรรมที่ผิดไปจากที่ควรจะเป็น เช่น เกิด Bias, Backdoor หรือช่องโหว่ที่สามารถถูกนำไปใช้โจมตีได้
ความเสี่ยงนี้สามารถเกิดขึ้นได้ในหลายช่วงของระบบ AI ตั้งแต่ Pre-training, Fine-tuning, การสร้าง Embedding, RAG, Model Distribution ไปจนถึง Continuous Learning และ Feedback Loop และอาจเกิดได้ทั้งจากการโจมตีโดยตั้งใจหรือจากการจัดการข้อมูลที่ไม่เหมาะสม
สิ่งที่ทำให้ Poisoning น่ากังวลคือ ระบบอาจยังดูเหมือนทำงานได้ตามปกติ แต่มี Backdoor หรือ Trigger ซ่อนอยู่ และจะเปลี่ยนพฤติกรรมเมื่อเจอเงื่อนไขที่กำหนด ทำให้การทดสอบทั่วไปอาจตรวจไม่พบ
องค์กรควรทำอย่างไร: เก็บประวัติแหล่งที่มาและการเปลี่ยนแปลงของ Dataset และ Model (Lineage) ตรวจสอบข้อมูลก่อนนำเข้า ทำ Version Control แยก Trusted และ Untrusted Data และทดสอบ Model อย่างต่อเนื่องเพื่อค้นหา Trigger หรือ Backdoor ที่ซ่อนอยู่
6. LLM06:2026 Unbounded Consumption
Unbounded Consumption คือความเสี่ยงที่เกิดขึ้นเมื่อระบบ LLM ไม่มีการควบคุมการใช้ทรัพยากรอย่างเพียงพอ ทำให้คำขอหรือWorkflow สามารถใช้ Token, Compute, Memory หรือ Tool Call จำนวนมากเกินความจำเป็น จนกระทบทั้งความพร้อมใช้งานของระบบและค่าใช้จ่ายขององค์กร
ความเสี่ยงนี้ยิ่งชัดขึ้นใน Reasoning Model, Multimodal Model และ AI Agent เพราะคำขอเพียงครั้งเดียวอาจนำไปสู่การประมวลผลหลายรอบ ใช้ Context ขนาดใหญ่ หรือเกิด Tool Call แบบต่อเนื่องและวนซ้ำ ทำให้ใช้ทรัพยากรเพิ่มขึ้นอย่างรวดเร็ว
ผลกระทบอาจเกิดเป็น Denial of Service (DoS) ทำให้ระบบช้าหรือไม่สามารถให้บริการได้ และ Denial of Wallet (DoW) ที่ทำให้ค่าใช้จ่ายจาก Cloud หรือบริการ AI เพิ่มสูงจนเกินควบคุม นอกจากนี้ OWASP ยังครอบคลุมความเสี่ยงจากการ Query จำนวนมากเพื่อทำ Model Extraction หรือสร้างโมเดลเลียนแบบด้วย
องค์กรควรทำอย่างไร: ไม่ควรจำกัดเพียงจำนวน Request แต่ควรกำหนด Token Limit, Spending Cap, Step Limit, Recursion Limit และ Time Limit พร้อมใช้ Circuit Breaker เพื่อหยุด Agent Workflow ที่ทำงานวนซ้ำหรือใช้ทรัพยากรผิดปกติ
7. LLM07:2026 Misinformation
Misinformation คือความเสี่ยงที่เกิดขึ้นเมื่อ LLM สร้างข้อมูลที่ ไม่ถูกต้อง ไม่ครบ ไม่มีหลักฐานรองรับ หรือทำให้เข้าใจผิด แต่ถูกนำเสนอในลักษณะที่ดูน่าเชื่อถือ จนผู้ใช้หรือระบบอื่นนำข้อมูลนั้นไปตัดสินใจหรือดำเนินการต่อ ซึ่งความเสี่ยงจึงเกิดขึ้นเมื่อคำตอบที่ผิดนั้นถูกนำไปใช้จริง เช่น ตีความ Policy ผิด แนะนำ Package ที่ไม่มีอยู่จริง สรุปข้อมูลโดยตกหล่นประเด็นสำคัญ หรือรายงานว่างานเสร็จแล้วทั้งที่ยังไม่ได้ดำเนินการ ซึ่งอาจนำไปสู่ความเสียหายด้านการเงิน Security หรือการดำเนินงานได้
องค์กรควรทำอย่างไร: ใช้แนวคิด Claim–Check–Act โดยแยกขั้นตอนการสร้างคำตอบออกจากการดำเนินการ ตรวจสอบข้อมูลกับแหล่งที่เชื่อถือได้และสถานะของระบบจริงก่อนนำไปใช้ โดย ไม่ควรใช้ความมั่นใจของโมเดลเพียงอย่างเดียวเป็นหลักฐานว่าข้อมูลนั้นถูกต้อง
8. LLM08:2026 Hidden Context Exposure
Hidden Context Exposure คือความเสี่ยงที่ข้อมูลภายในซึ่งไม่ได้มีไว้ให้ผู้ใช้เห็น ถูกเปิดเผย ถูกคาดเดา หรือถูกสร้างขึ้นใหม่จากการโต้ตอบกับ LLM
ในปี 2026 OWASP เปลี่ยนชื่อจาก System Prompt Leakage เป็น Hidden Context Exposure เพื่อขยายขอบเขตให้ครอบคลุมข้อมูลภายในมากกว่า System Prompt เช่น
- System Prompt
- Developer Instructions
- Tool และ Function Schema
- Internal Policy
- User Role และ Permission
- Workflow Logic
- Refusal และ Filtering Rules
ข้อมูลเหล่านี้อาจช่วยให้ผู้โจมตีเข้าใจโครงสร้าง วิธีทำงาน หรือข้อจำกัดของระบบ และนำไปใช้วางแผน Prompt Injection หรือการโจมตีในขั้นต่อไปได้
แนวคิดสำคัญของ OWASP คือ ควรออกแบบระบบโดยถือว่าข้อมูลทุกอย่างที่ใส่ไว้ใน Context ของ LLM มีโอกาสถูกค้นพบหรือเปิดเผยได้ ดังนั้นความปลอดภัยของระบบไม่ควรขึ้นอยู่กับการเก็บ Context เหล่านี้เป็นความลับเพียงอย่างเดียว
องค์กรควรทำอย่างไร: ไม่ควรใส่ Password, API Key, Token หรือ Connection String ลงใน Context และไม่ควรใช้ System Prompt เป็นกลไกหลักในการควบคุมสิทธิ์หรือ Security Policy แต่ควรบังคับใช้ Authorization และ Access Control ผ่านระบบภายนอกตัว LLM ที่สามารถตรวจสอบและควบคุมได้อย่างชัดเจน
9. LLM09:2026 Vector and Embedding Weaknesses
Vector and Embedding Weaknesses คือความเสี่ยงที่เกิดขึ้นในระบบที่แปลงข้อความ รูปภาพ โค้ด หรือเสียงให้อยู่ในรูป Embedding และใช้ Similarity Search เพื่อค้นหาข้อมูลที่เกี่ยวข้องก่อนส่งต่อให้ LLM โดยระบบ RAG (Retrieval-Augmented Generation) เป็นหนึ่งในตัวอย่างที่พบได้บ่อยที่สุด
หากกระบวนการค้นหาและจัดเก็บ Embedding ถูกออกแบบไม่เหมาะสม อาจเกิดความเสี่ยง เช่น Cross-Tenant Leakage, Embedding Inversion, Retrieval Poisoning, Retrieval Jamming, Membership Inference และ Semantic Cache Poisoning ซึ่งอาจทำให้ข้อมูลรั่ว ถูกบิดเบือน หรือระบบค้นคืนข้อมูลทำงานผิดปกติได้
ตัวอย่างเช่น ในระบบที่หลาย Tenant ใช้ Shared Vector Index หากระบบทำ Similarity Search กับข้อมูลทั้งหมดก่อน แล้วค่อยตรวจสอบสิทธิ์ภายหลัง ผู้โจมตีอาจใช้จำนวนผลลัพธ์ คะแนนความคล้ายคลึง หรือระยะเวลาตอบกลับเพื่อ อนุมานว่ามีข้อมูลของ Tenant อื่นอยู่ รวมถึงหัวข้อหรือปริมาณโดยประมาณ แม้จะไม่ได้เห็นเอกสารนั้นโดยตรงก็ตาม
อีกความเสี่ยงที่สำคัญคือ Embedding Inversion ซึ่งสามารถนำ Embedding ที่รั่วไหลมาสร้างเนื้อหาต้นฉบับกลับคืนมาได้ ดังนั้น Vector Database และ Backup ที่เก็บ Embedding จึงควรถูกปกป้องในระดับเดียวกับข้อมูลต้นฉบับ
องค์กรควรทำอย่างไร: บังคับใช้ Tenant Scope และ Permission ภายในขั้นตอน Retrieval ไม่ใช่กรองภายหลัง ใช้ Access Control ระดับ Chunk แยก Index ตาม Tenant หรือระดับความอ่อนไหวของข้อมูล และปกป้อง Vector Database รวมถึง Backup ด้วยการเข้ารหัส การควบคุมสิทธิ์ และ Monitoring ที่เหมาะสม
10. LLM10:2026 Improper Output Handling
Improper Output Handling คือความเสี่ยงที่เกิดขึ้นเมื่อผลลัพธ์จาก LLM ถูกนำไปใช้ต่อในระบบอื่นโดยไม่มีการตรวจสอบ กรอง หรือจัดการให้เหมาะสมก่อน เช่น ส่งต่อไปยัง Browser, SQL Database, Shell, File System, Email, IDE หรือ API
หากระบบปลายทางนำ Output ของ AI ไปประมวลผลหรือ Execute โดยตรง อาจนำไปสู่ช่องโหว่ เช่น XSS, SQL Injection, Path Traversal, Remote Code Execution หรือ Data Exfiltration ได้ ตัวอย่างเช่น AI สร้าง SQL Query แล้วระบบนำไปรันทันที หรือสร้าง JavaScript/Markdown ที่ Browser นำไปแสดงผลโดยไม่มีการกรอง
หลักสำคัญคือ ควรปฏิบัติต่อ Output จาก LLM เหมือนข้อมูลจากแหล่งที่ยังไม่เชื่อถือ (Untrusted Input) และต้องตรวจสอบก่อนส่งต่อไปยังระบบอื่น เพราะแม้ Output จะมีรูปแบบถูกต้องตาม Schema ก็ไม่ได้หมายความว่าเนื้อหาภายในจะปลอดภัยเสมอไป
องค์กรควรทำอย่างไร: ตรวจสอบและ Validate Output ก่อนใช้งาน ใช้ Context-Specific Encoding, Parameterized Query หรือPrepared Statement และ Content Security Policy (CSP) ตามระบบปลายทาง รวมถึงไม่ควร Compile หรือ Deploy Code ที่ AI สร้างขึ้นโดยอัตโนมัติโดยไม่มีการ Review และ Security Testing ก่อน
สรุปสาระสำคัญ
OWASP Top 10 for LLM Applications 2026 ช่วยให้เห็นว่าความเสียหายส่วนใหญ่มักเกิดขึ้นเมื่อ AI เชื่อมต่อกับข้อมูล สิทธิ์ Tool และระบบจริงขององค์กร
ดังนั้น การเตรียมความพร้อมควรครอบคลุมตั้งแต่ Identity & Access Management, Data Protection, Application Security, Supply Chain, Monitoring, Incident Response ไปจนถึง Cost Control
องค์กรไม่จำเป็นต้องหยุดใช้ AI เพราะมีความเสี่ยง แต่ควรรู้ว่า AI เข้าถึงอะไร ทำอะไรได้ และมี Security Control ใดคอยจำกัดผลกระทบหากโมเดลทำงานผิดพลาด
องค์กรของคุณพร้อมแค่ไหนสำหรับ AI Security?
หากองค์กรกำลังเริ่มนำ Generative AI, RAG, Copilot หรือ AI Agent มาเชื่อมต่อกับข้อมูลและระบบภายใน นี่เป็นช่วงเวลาที่เหมาะในการทบทวนว่า Security Control ที่มีอยู่ครอบคลุม AI Workflow แล้วหรือยัง
BMSP ให้บริการ Cybersecurity และ IT Managed Services แบบ End-to-End ครอบคลุม AI Security, Identity & Access Security, Data Security, WAF & API Security, Cloud Security, Vulnerability Management และ CSOC 24/7
พูดคุยกับทีม BMSP เพื่อทบทวน Cybersecurity Readiness ขององค์กร และวางแนวทางลดความเสี่ยงก่อนเชื่อม AI เข้ากับระบบสำคัญของธุรกิจ
อ้างอิง
Source: OWASP GenAI Security Project – OWASP Top 10 for LLM Applications 2026
License: CC BY-SA 4.0
