Name: รากฐาน AI Security: เข้าใจความเสี่ยงและกรอบ OWASP LLM Top 10 2025 · หลักสูตร AI Security อย่างมืออาชีพ
Author: จักริน นพรุจนธาดา

1.1

โมดูล 1.1

ภาพรวม AI Security และขอบเขตการป้องกัน (defensive)

แยกให้ชัดระหว่าง Security OF AI และ AI FOR Security พร้อมเส้นแบ่งเชิงป้องกัน

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนบ้านหลังหนึ่งที่ต้องคิดสองเรื่อง คือ 'ล็อกประตูป้องกันขโมยเข้าบ้าน' (ปกป้อง AI ของเรา) กับ 'ติดกล้องวงจรปิดที่ฉลาดช่วยจับขโมย' (ใช้ AI มาช่วยป้องกัน) เป็นคนละหน้าที่กันแต่ทำให้บ้านปลอดภัยเหมือนกัน

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

บอกได้ว่าการปกป้องตัวระบบ AI (Security of AI) กับการเอา AI มาช่วยป้องกันองค์กร (AI for Security) ต่างกันยังไง
รู้ขอบเขตของงานฝั่งป้องกัน และเส้นแบ่งเรื่องจริยธรรมกับกฎหมาย (จะทดสอบได้เฉพาะระบบที่เราเป็นเจ้าของหรือได้รับอนุญาตเท่านั้น)
อธิบายได้ว่าทำไมเราต้องมองทั้งสิ่งที่เราพิมพ์ให้ AI (input) และคำตอบที่ AI พ่นออกมา (output) ว่าเชื่อไม่ได้ (untrusted) ไว้ก่อน

เนื้อหา

โมดูลนี้เป็นการวางกรอบคิดของทั้งหลักสูตร โดยแบ่งเรื่องความปลอดภัยของ AI ออกเป็นสองด้านให้ชัด: (1) การปกป้องตัว AI ของเราเอง (Security OF AI) คือดูแลแอป AI ที่เราสร้างไม่ให้ถูกโจมตี ตามแนวทาง OWASP LLM Top 10 2025 และ (2) การเอา AI มาช่วยป้องกัน (AI FOR Security) คือใช้ AI มาเป็นผู้ช่วยทีมป้องกันภัย (blue-team) พอเรียนจบคุณจะเข้าใจว่าหลักสูตรนี้เน้นฝั่งป้องกัน (defensive) อย่างเดียว ไม่มีสอนวิธีโจมตี ส่วนมุมของคนโจมตี เช่น การแอบยัดคำสั่งเข้าไปหลอก AI (prompt injection) เราพูดถึงแค่เท่าที่จำเป็นเพื่อเอาไปตั้งรับเท่านั้น หลักคิดสำคัญที่อยากให้จำตั้งแต่ต้นคือ คนต้องเป็นผู้รับผิดชอบเสมอ (human accountability — คนที่มีความรู้ต้องรับผิดชอบทุกการตัดสินใจ ไม่ใช่โยนให้ AI) และให้ถือไว้ก่อนว่าทั้งสิ่งที่เราป้อนเข้าไปและคำตอบที่ AI ให้กลับมานั้นเชื่อไม่ได้ จนกว่าจะตรวจสอบแล้ว

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Security OF AIการปกป้องตัวระบบ AI ของเราเองไม่ให้ถูกโจมตีหรือหลอก

AI FOR Securityการเอา AI มาเป็นผู้ช่วยทีมป้องกันภัย เช่น ช่วยจับความผิดปกติ

Defensiveเชิงป้องกันเท่านั้น คือสอนวิธีตั้งรับ ไม่สอนวิธีโจมตี

Blue-teamทีมฝ่ายป้องกันในองค์กร คนที่คอยเฝ้าและกันภัยไซเบอร์

LLMโมเดลภาษาขนาดใหญ่ สมองของ AI แบบ ChatGPT ที่เข้าใจและตอบเป็นภาษาคน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

จัดหมวดความเสี่ยงจากสถานการณ์งานจริง

ทีมเราจะเปิดใช้ chatbot ช่วยตอบลูกค้าที่ดึงข้อมูลจากฐานความรู้ภายใน (RAG) ช่วยจัดหมวดว่าความเสี่ยงข้อใดเป็น 'Security OF AI' และข้อใดเป็น 'AI FOR Security': (1) ลูกค้าป้อนข้อความหลอกให้บอทเปิดเผยข้อมูลภายใน (2) เราอยากใช้ AI ช่วยสรุป alert ใน SOC

✅ ผลลัพธ์ที่ได้

ข้อ (1) เป็น Security OF AI เพราะเป็นการปกป้องแอป LLM ของเราเอง ตรงกับ OWASP LLM01 Prompt Injection และ LLM02 Sensitive Information Disclosure ส่วนข้อ (2) เป็น AI FOR Security คือการนำ AI มาช่วยงาน blue-team (alert triage)

💡 จุดสอน

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

แบบฝึกหัดท้ายโมดูล

วาดแผนภาพระบบ AI สักระบบหนึ่งในองค์กรของคุณ แล้วชี้ว่าจุดไหนเป็นการปกป้อง AI ของเราเอง (Security OF AI) และจุดไหนเป็นการเอา AI มาช่วยป้องกัน (AI FOR Security)
เขียนสักย่อหน้าอธิบายว่าทำไมเราต้องมองคำตอบของ AI ว่าเชื่อไม่ได้ (untrusted) พร้อมยกตัวอย่างว่าถ้าไม่ทำแบบนี้จะเกิดผลเสียอะไรได้บ้าง

1.2

โมดูล 1.2

OWASP Top 10 for LLM Apps 2025 ภาพรวม

รู้จักกรอบ anchor ของหลักสูตร LLM01 ถึง LLM10 และสิ่งที่เปลี่ยนจากรุ่น 2023

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือน 'สิบอันดับโรคที่พบบ่อยที่สุด' ที่หมอทุกคนต้องรู้ไว้ก่อน OWASP Top 10 คือบัญชีรายชื่อภัยยอดฮิตของแอป AI ที่ทุกคนควรจำให้ขึ้นใจ

🎯

ทำไมต้องรู้: แทนที่จะเดาว่าอันตรายอยู่ตรงไหน เรามีรายการมาตรฐานที่ผู้เชี่ยวชาญทั่วโลกยอมรับ ทำให้รู้ว่าต้องเช็กอะไรบ้างและเถียงกับทีมได้ด้วยหลักเดียวกัน

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

เล่าได้ว่ารายการนี้มาจากไหน ใครดูแล และตอนนี้เป็นรุ่นปี 2025 (v2.0) ที่จัดทำโดย OWASP Gen AI Security Project
แยกแยะภัยทั้ง 10 ข้อ (LLM01-LLM10) ได้ และรู้ว่าแต่ละข้อมีหัวใจของการป้องกันอยู่ตรงไหน
บอกได้ว่าปี 2025 มีหมวดไหนเพิ่มเข้ามาใหม่ และมีอะไรเปลี่ยนไปบ้างเมื่อเทียบกับรุ่นปี 2023

เนื้อหา

OWASP Top 10 for LLM Applications 2025 คือกรอบหลัก (anchor) ที่ทั้งหลักสูตรนี้ยึดเป็นแกน ดูแลโดย OWASP Gen AI Security Project (genai.owasp.org) รุ่นปี 2025 (v2.0) เผยแพร่จริงเมื่อ 18 พฤศจิกายน 2024 ใช้รหัสเรียกภัยแต่ละข้อว่า LLM01:2025 ไปจนถึง LLM10:2025 (ระวังนิดหนึ่ง: บางหน้าของ OWASP ขึ้นวันที่ 12 มีนาคม 2025 แต่นั่นเป็นวันที่แปลหรือเผยแพร่ซ้ำ ไม่ใช่วันออกจริง ให้ยึดว่า 'รุ่น 2025 ออกเมื่อ พ.ย. 2024' เป็นหลัก) สิ่งที่เปลี่ยนไปจากรุ่นปี 2023 ก็คือ เพิ่มเรื่องความลับในคำสั่งเบื้องหลังรั่ว (System Prompt Leakage, LLM07) และช่องโหว่ในระบบค้นข้อมูลแบบเวกเตอร์ (Vector and Embedding Weaknesses, LLM08) เข้ามา ขยายหมวดเดิมที่เคยชื่อ Denial of Service ให้กลายเป็นการถูกใช้งานหนักไม่จำกัด (Unbounded Consumption, LLM10) แล้วก็ปรับหรือเปลี่ยนชื่อหมวดต่างๆ อีกหลายจุด นอกจากนี้ทาง Gen AI Security Project ยังมีคู่มือเสริมอีก เช่น เรื่องภัยจาก AI ที่ทำงานเองอัตโนมัติ (agentic AI threats) แนวทางการทดสอบเจาะระบบเชิงป้องกัน (red-teaming) และภาพรวมของเครื่องมือในตลาด (solutions landscape)

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

OWASPองค์กรอาสาสมัครระดับโลกที่รวบรวมความรู้ด้านความปลอดภัยซอฟต์แวร์แบบเปิดฟรี

Top 10รายชื่อ 10 อันดับภัยที่พบบ่อยและอันตรายที่สุด ใช้เป็นเช็กลิสต์

anchorกรอบหลักที่ยึดเป็นแกนกลางของทั้งหลักสูตร ทุกอย่างอ้างอิงกลับมาที่นี่

LLM01 ถึง LLM10รหัสเรียกภัยแต่ละข้อ เหมือนเลขหน้าให้อ้างอิงง่าย

v2.0 / รุ่น 2025เวอร์ชันปรับปรุงใหม่ล่าสุดของรายการ ที่อัปเดตภัยให้ทันสมัย

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

แมปเหตุการณ์เข้าหมวด OWASP

ช่วยแมปเหตุการณ์ต่อไปนี้เข้ากับหมวด OWASP LLM Top 10 2025 ที่ถูกต้อง: 'ระบบ RAG ของเราถูกใส่เอกสารปลอมเข้าไปใน vector store ทำให้ตอบผิด และมี tenant อื่นเห็นข้อมูลข้าม'

✅ ผลลัพธ์ที่ได้

ตรงกับ LLM08:2025 Vector and Embedding Weaknesses (RAG poisoning และ cross-tenant leakage) การป้องกันคือทำ access control บน vector DB และ data partitioning หากคำตอบผิดถูกนำไปใช้จนเกิดผลเสียก็เกี่ยวกับ LLM09 Misinformation ด้วย

💡 จุดสอน

เหตุการณ์จริงมักแตะหลายหมวด การแมปให้ครบช่วยให้วางมาตรการป้องกันแบบ layered ได้

แบบฝึกหัดท้ายโมดูล

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

1.3

โมดูล 1.3

Prompt Injection และ Sensitive Information Disclosure (LLM01, LLM02)

ป้องกันการถูกครอบงำคำสั่งและการรั่วไหลของข้อมูลอ่อนไหว

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: Prompt Injection เหมือนมีคนแอบกระซิบสั่งลูกน้องของเราให้ทำนอกหน้าที่ ส่วน Sensitive Disclosure เหมือนลูกน้องเผลอพูดความลับบริษัทให้คนนอกฟัง เราต้องสอนให้ลูกน้อง (AI) ไม่หลงเชื่อคำสั่งแปลกและไม่ปากโป้ง

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบายได้ว่าการแอบยัดคำสั่ง (prompt injection) ทำงานยังไง เท่าที่จำเป็นต่อการเอาไปป้องกัน (LLM01)
ออกแบบด่านตรวจข้อความก่อนเข้าและก่อนออก (input/output guardrails) การแบ่งสิทธิ์ (privilege separation) และการให้ AI มีอำนาจน้อยที่สุด (least-agency) ได้
กันข้อมูลรั่วได้ ด้วยการเก็บข้อมูลเท่าที่จำเป็น (data minimization) กรองคำตอบ และปิดบังข้อมูลส่วนตัว (PII redaction) (LLM02)

เนื้อหา

LLM01 การแอบยัดคำสั่ง (Prompt Injection) คือเวลาที่ข้อความจากผู้ใช้หรือคนอื่นเข้ามากลบคำสั่งเดิมที่เราตั้งไว้ ทำให้ AI หันไปทำตามคนร้ายแทน วิธีตั้งรับก็มี ด่านตรวจข้อความก่อนเข้าและก่อนออก (input/output guardrails) การแบ่งสิทธิ์ให้แต่ละส่วนทำได้เท่าที่จำเป็น (privilege separation) การออกแบบให้ AI มีอำนาจตัดสินใจน้อยที่สุด (least-agency) และการมองว่าคำตอบทุกอย่างของ AI เชื่อไม่ได้ (untrusted) ไว้ก่อน (ซึ่งไปโยงกับ LLM05) โมดูลนี้เล่ากลไกแค่เท่าที่จำเป็นต่อการป้องกันเท่านั้น ไม่มีสูตรโจมตีให้ ส่วน LLM02 ข้อมูลอ่อนไหวรั่ว (Sensitive Information Disclosure) คือเวลาที่ AI เผลอพูดข้อมูลส่วนตัว (PII) ความลับ หรือข้อมูลทางธุรกิจออกมา กันได้ด้วยการเก็บข้อมูลเท่าที่จำเป็น (data minimization) การกรองคำตอบก่อนส่ง และการปิดบังข้อมูลส่วนตัว (redaction) รวมถึงต้องล้างข้อมูลที่เอาไปฝึกโมเดลและข้อมูลในระบบค้นข้อมูล (RAG) ให้สะอาดด้วย

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Prompt Injectionการแอบยัดคำสั่งเข้าไปในข้อความ เพื่อหลอกให้ AI ทำตามคนร้ายแทนเรา

Input/Output guardrailsด่านตรวจข้อความก่อนเข้าและก่อนออกจาก AI เหมือนยามหน้าประตูสองชั้น

Privilege separationการแบ่งสิทธิ์ ให้แต่ละส่วนทำได้เฉพาะเท่าที่จำเป็น ไม่ให้ใครถืออำนาจครบ

Least-agencyให้ AI มีอำนาจตัดสินใจและลงมือน้อยที่สุดเท่าที่งานต้องใช้

Untrustedถือว่าไว้ใจไม่ได้ ต้องตรวจก่อนเสมอ ในที่นี้คือคำตอบที่ AI พ่นออกมา

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ออกแบบ output filter สำหรับ PII

ผู้ช่วย AI ภายในของเราอาจดึงข้อมูลพนักงานมาตอบ ช่วยร่างหลักการกรอง output เพื่อลดความเสี่ยง LLM02 ก่อนส่งข้อความถึงผู้ใช้

✅ ผลลัพธ์ที่ได้

หลักการ: (1) ตรวจจับและปิดบังข้อมูลส่วนตัว (PII detection/redaction) ในคำตอบก่อนแสดงผล เช่น เลขบัตรประชาชน อีเมล เบอร์โทร (2) เก็บข้อมูลเท่าที่จำเป็น (data minimization) ให้ระบบค้นข้อมูล (RAG) คืนกลับมาเฉพาะช่องข้อมูลที่ต้องใช้จริง (3) บังคับการควบคุมสิทธิ์เข้าถึง (access control) ตามสิทธิ์ของคนที่ถาม ไม่พึ่งแค่ prompt (4) เก็บบันทึกการเข้าถึง (audit log) ทุกครั้งที่มีการแตะข้อมูลอ่อนไหว

💡 จุดสอน

การกรองต้องทำที่ชั้นคำตอบ (output) ซึ่งอยู่นอกตัวโมเดล อย่าไปหวังพึ่งแค่การสั่งใน prompt อย่างเดียว เพราะด่านตรวจที่ใช้ตัวจำแนก (classifier) นั้นมีโอกาสถูกหลบเลี่ยงได้

แบบฝึกหัดท้ายโมดูล

ร่างมาตรการป้องกัน LLM01 อย่างน้อย 4 ข้อ สำหรับ chatbot ที่รับข้อความจากผู้ใช้ภายนอก
ออกแบบเช็กลิสต์การกรองคำตอบ (output-filtering) เพื่อป้องกัน LLM02 ในระบบที่เข้าถึงข้อมูลฝ่ายบุคคล (HR)

1.4

โมดูล 1.4

Supply Chain และ Data/Model Poisoning (LLM03, LLM04)

ปกป้องห่วงโซ่ที่มาของโมเดลและข้อมูล (ML supply chain) ด้วยการตรวจที่มา (provenance) บัญชีส่วนประกอบ (AI-BOM) และการสแกนโมเดล (model scanning)

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

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

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

ชี้ความเสี่ยงจากห่วงโซ่ที่มา (supply chain) ของโมเดล ชุดข้อมูล ปลั๊กอิน (plugin) และไลบรารีที่พึ่งพา (dependency) ได้ (LLM03)
อธิบายได้ว่าการวางยาข้อมูลและโมเดล (data/model poisoning) เกิดขึ้นได้ยังไงในตอนฝึกโมเดล ทั้งขั้นฝึกตั้งต้น (pre-training) ปรับจูน (fine-tuning) และแปลงข้อความเป็นเวกเตอร์ (embeddings) (LLM04)
เอาการตรวจที่มาของโมเดล (model provenance) บัญชีส่วนประกอบ (AI-BOM) ไฟล์ที่มีลายเซ็นรับรอง (signed artifacts) และการจับความผิดปกติ (anomaly detection) ไปใช้จริงได้

เนื้อหา

LLM03 ห่วงโซ่ที่มา (Supply Chain) รวมความเสี่ยงจากการที่โมเดล ชุดข้อมูล ปลั๊กอิน หรือไลบรารีที่เราหยิบมาใช้ (dependency) โดนแอบแก้ไข กันได้ด้วยการตรวจที่มาของโมเดล (model provenance) การทำบัญชีส่วนประกอบ AI (AI-BOM หรือ AI Bill of Materials เหมือนฉลากบอกส่วนผสม) การสแกนโมเดล (model scanning) และไฟล์ที่มีลายเซ็นรับรอง (signed artifacts) ส่วน LLM04 การวางยาข้อมูลและโมเดล (Data and Model Poisoning) คือการที่มีคนแอบใส่ข้อมูลร้ายจนทำให้ข้อมูลตอนฝึกตั้งต้น ปรับจูน หรือแปลงเป็นเวกเตอร์เสียหาย กันได้ด้วยการตรวจสอบความถูกต้องของข้อมูล (data validation) การตามรอยที่มา (provenance tracking) และการจับความผิดปกติ (anomaly detection) โมดูลนี้ยังโยงไปถึงเครื่องมือดูแลห่วงโซ่ที่มาจริงในตลาด เช่น Protect AI (ตอนนี้อยู่ภายใต้ Palo Alto Networks Prisma AIRS) ที่เด่นเรื่องการสแกนโมเดลหาโค้ดอันตราย (malicious code) และการตามรอยไฟล์ (artifact tracking) รวมถึง HiddenLayer ที่มีเครื่องมือดูสายพันธุ์โมเดล (Model Genealogy) และทำ AI-BOM ได้

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Supply Chainห่วงโซ่ของชิ้นส่วนทั้งหมดที่เราเอามาประกอบเป็นระบบ ตั้งแต่โมเดล ข้อมูล ไปจนถึงปลั๊กอิน

Poisoningการวางยา คือแอบใส่ข้อมูลร้ายให้ AI เรียนรู้ผิดๆ จนทำงานเพี้ยน

Provenanceประวัติที่มา หลักฐานว่าโมเดลหรือข้อมูลนี้มาจากใครและผ่านมืออะไรมาบ้าง

AI-BOMบัญชีรายการส่วนประกอบ AI เหมือนฉลากบอกส่วนผสมข้างซองอาหาร

Signed artifactsไฟล์ที่มีลายเซ็นดิจิทัลรับรองว่าของแท้ ไม่ถูกแก้ไขระหว่างทาง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

จัดทำ AI-BOM เบื้องต้น

เราดาวน์โหลดโมเดล open-weight มาใช้ในผลิตภัณฑ์ ช่วยระบุว่าควรบันทึกอะไรบ้างใน AI-BOM เพื่อลดความเสี่ยง LLM03/LLM04

✅ ผลลัพธ์ที่ได้

AI-BOM ควรบันทึก: ชื่อและเวอร์ชันโมเดล, แหล่งที่มา (provenance) และคนที่เผยแพร่, สัญญาอนุญาตใช้งาน (license), ค่าแฮชหรือลายเซ็นของไฟล์ (artifact) ไว้ยืนยันว่าไม่ถูกแก้, ชุดข้อมูลที่ใช้ฝึก (เท่าที่รู้), ไลบรารีและปลั๊กอินที่เกี่ยวข้อง, ผลการสแกนโมเดลหาโค้ดอันตราย (malicious code) พร้อมวันที่ตรวจ

💡 จุดสอน

AI-BOM คือหลักฐานไว้ตามรอยที่มา (provenance) และใช้ตอบเวลาถูกตรวจสอบ (audit) พอเจอช่องโหว่ในโมเดลหรือชุดข้อมูลไหน เราก็สาวกลับได้ทันทีว่ามันกระทบระบบไหนบ้าง

แบบฝึกหัดท้ายโมดูล

ร่างแบบฟอร์ม AI-BOM สำหรับโมเดลที่องค์กรใช้ พร้อมช่องข้อมูลที่จำเป็นต่อการตามรอยที่มา (provenance)
อธิบายว่าความเสี่ยงจากห่วงโซ่ที่มา (LLM03) กับการวางยา (LLM04) ต่างกันยังไง พร้อมบอกมาตรการป้องกันของแต่ละหมวด

1.5

โมดูล 1.5

Improper Output Handling และ Excessive Agency (LLM05, LLM06)

อย่าให้ระบบปลายทางเชื่อคำตอบดิบๆ จาก AI และอย่าให้ตัวแทน AI ที่ทำงานเอง (agent) มีสิทธิ์มากเกินไป

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: Improper Output Handling เหมือนเชื่อทุกอย่างที่คนแปลกหน้าบอกแล้วทำตามทันทีโดยไม่ตรวจสอบ ส่วน Excessive Agency เหมือนมอบกุญแจบ้าน กุญแจรถ และบัตรเครดิตให้ผู้ช่วยคนเดียวถือหมด ทั้งที่เขาแค่ต้องรดน้ำต้นไม้

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

อธิบายได้ว่าคำตอบที่ยังไม่ได้ทำความสะอาด (sanitize) อาจพาไปสู่ช่องโหว่ในแอปที่เอาไปใช้ต่อ เช่น XSS, SSRF หรือการถูกสั่งรันโค้ด (code exec) (LLM05)
ออกแบบการเข้ารหัสและตรวจคำตอบให้ปลอดภัย (output encoding/validation) ก่อนส่งต่อให้ระบบปลายทางได้
เอาหลักให้สิทธิ์น้อยที่สุด (least privilege) การให้คนคอยอนุมัติในจังหวะสำคัญ (human-in-the-loop) และการจำกัดขอบเขตเครื่องมือ (scoped tool access) ไปใช้กับตัวแทน AI (agent) ได้ (LLM06)

เนื้อหา

LLM05 การจัดการคำตอบไม่รัดกุม (Improper Output Handling) เกิดขึ้นเมื่อระบบปลายทางเชื่อคำตอบของ AI แล้วเอาไปใช้เลยโดยไม่ทำความสะอาดก่อน จนเปิดช่องโหว่ เช่น XSS (แอบฝังโค้ดร้ายในหน้าเว็บ) SSRF (หลอกให้เซิร์ฟเวอร์ของเราไปเรียกที่ที่ไม่ควร) หรือการถูกสั่งรันโค้ด (code execution) ในแอปที่เอาคำตอบไปใช้ กันได้ด้วยการเข้ารหัสและตรวจคำตอบให้ปลอดภัย (output encoding/validation) ก่อนใช้เสมอ ส่วน LLM06 ให้อำนาจมากเกินไป (Excessive Agency) คือการปล่อยให้ตัวแทน AI (agent) มีสิทธิ์ มีอิสระ หรือมีเครื่องมือมากเกินความจำเป็น กันได้ด้วยหลักให้สิทธิ์น้อยที่สุด (least privilege) การให้คนคอยอนุมัติในจังหวะสำคัญ (human-in-the-loop) สำหรับงานที่ผลกระทบสูง และการจำกัดขอบเขตเครื่องมือ (scoped tool access) สองหมวดนี้ยิ่งสำคัญมากในยุคที่ AI ทำงานเองอัตโนมัติ (agentic AI) มากขึ้นเรื่อยๆ

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

Output Handlingวิธีจัดการคำตอบที่ AI พ่นออกมา ก่อนเอาไปใช้งานต่อ

XSSช่องโหว่ที่คนร้ายแอบฝังโค้ดอันตรายในหน้าเว็บเพื่อเล่นงานผู้ใช้คนอื่น

SSRFการหลอกให้เซิร์ฟเวอร์ของเราไปเรียกไปที่ที่ไม่ควร เพื่อล้วงข้อมูลภายใน

Excessive Agencyการให้ AI มีอำนาจ เครื่องมือ หรืออิสระในการลงมือมากเกินความจำเป็น

Output encoding/validationการทำความสะอาดและตรวจคำตอบให้ปลอดภัยก่อนนำไปใช้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ประเมิน tool access ของ agent

agent ของเราเชื่อมกับเครื่องมือ 5 อย่าง: อ่านอีเมล, ส่งอีเมล, ลบไฟล์, โอนเงิน, ค้นเว็บ ช่วยประเมินตามหลัก least-agency ว่าอะไรควรมี human-in-the-loop

✅ ผลลัพธ์ที่ได้

จัดตามระดับผลกระทบ: งานที่ผลกระทบสูง (ส่งอีเมลออกไปข้างนอก, ลบไฟล์, โอนเงิน) ต้องมีคนคอยอนุมัติ (human-in-the-loop) และการโอนเงินอาจต้องให้สองคนอนุมัติร่วมกัน (dual-authorization) ส่วนอ่านอีเมลกับค้นเว็บเสี่ยงน้อยกว่า แต่ก็ควรจำกัดสิทธิ์ให้แคบไว้ และควรถอดสิทธิ์ที่ไม่จำเป็นออกให้หมด ตามหลักให้สิทธิ์น้อยที่สุด (least privilege)

💡 จุดสอน

หลักการให้ AI มีอำนาจน้อยที่สุด (least-agency) ก็คือ ให้ตัวแทน AI (agent) มีสิทธิ์และเครื่องมือน้อยที่สุดเท่าที่งานจำเป็นต้องใช้ และให้คนเป็นคนอนุมัติทุกครั้งที่เป็นงานสำคัญ

แบบฝึกหัดท้ายโมดูล

ออกแบบขั้นตอนตรวจคำตอบ (output validation pipeline) สำหรับ AI ที่คำตอบจะถูกเอาไปแสดงบนหน้าเว็บ (เพื่อกัน XSS)
ทำตารางจัดระดับเครื่องมือของตัวแทน AI (agent) ตามผลกระทบ แล้วชี้ว่าจุดไหนต้องมีคนคอยอนุมัติ (human-in-the-loop)

1.6

โมดูล 1.6

System Prompt Leakage, Vector Weaknesses, Misinformation, Unbounded Consumption (LLM07-LLM10)

ปิดช่องหมวดใหม่ปี 2025 และความเสี่ยงระดับระบบที่เหลือ

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน

💡

เปรียบง่าย ๆ: เหมือนปิดหน้าต่างบานเล็กๆ ที่เหลือทั่วบ้าน ก่อนออกไปเที่ยว โมดูลนี้เก็บกวาดช่องโหว่ที่เหลือให้ครบ เช่น อย่าเขียนรหัสผ่านแปะไว้บนกระดาน (System Prompt) และอย่าให้แขกกินบุฟเฟต์ไม่อั้นจนของหมด (Unbounded Consumption)

🎯

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

กันไม่ให้คำสั่งเบื้องหลังรั่ว (System Prompt Leakage) ด้วยการไม่เอาความลับไปใส่ใน prompt และไปบังคับการควบคุมไว้นอกตัวโมเดลแทน (LLM07)
กันการวางยาในระบบค้นข้อมูล (RAG poisoning) และการที่ข้อมูลของลูกค้ารายหนึ่งไปโผล่ให้อีกรายเห็น (cross-tenant leakage) ด้วยการควบคุมสิทธิ์เข้าถึง (access control) และการแบ่งกั้นข้อมูล (data partitioning) (LLM08)
ลดข้อมูลผิด (Misinformation) ด้วยการอิงข้อมูลจริง (grounding/RAG) การอ้างอิงแหล่งที่มา (citations) และการให้คนช่วยตรวจ (human review) รวมถึงกันการถูกใช้งานหนักไม่จำกัด (Unbounded Consumption) ด้วยการจำกัดจำนวนครั้งและโควตา (rate limiting/quotas) (LLM09, LLM10)

เนื้อหา

โมดูลปิดท้ายของระดับ Foundation เก็บครบทั้งสี่หมวดที่เหลือ LLM07 คำสั่งเบื้องหลังรั่ว (System Prompt Leakage — เพิ่มใหม่ปี 2025) คือการที่คำสั่งลับที่เราตั้งไว้กำกับ AI (system prompt) หลุดออกไปจนคนเห็นตรรกะการทำงานหรือความลับข้างใน กันได้ด้วยการไม่เอาความลับไปใส่ใน prompt ตั้งแต่แรก แล้วไปบังคับการควบคุมไว้นอก prompt แทน LLM08 ช่องโหว่ระบบค้นข้อมูลแบบเวกเตอร์ (Vector and Embedding Weaknesses — เพิ่มใหม่ปี 2025 เน้นเรื่อง RAG) คือช่องโหว่ในการแปลงข้อความเป็นเวกเตอร์และคลังเก็บเวกเตอร์ (vector store) เช่น การวางยาในระบบค้นข้อมูล (RAG poisoning) และการที่ข้อมูลของลูกค้ารายหนึ่งไปโผล่ให้อีกรายเห็น (cross-tenant leakage) กันได้ด้วยการควบคุมสิทธิ์เข้าถึงในฐานข้อมูลเวกเตอร์ (access control บน vector DB) และการแบ่งกั้นข้อมูล (data partitioning) LLM09 ข้อมูลผิด (Misinformation) คือการที่ AI มั่วข้อมูลหรือแต่งเรื่องขึ้นเอง (hallucination/confabulation) ซึ่งจะก่ออันตรายเมื่อถูกเอาไปใช้จริง กันได้ด้วยการอิงข้อมูลจริง (grounding/RAG) การอ้างอิงแหล่งที่มา (citations) การให้คนช่วยตรวจ (human review) และการส่งสัญญาณให้ผู้ใช้รู้ว่าคำตอบนี้ยังไม่แน่ใจ และ LLM10 ถูกใช้งานหนักไม่จำกัด (Unbounded Consumption) คือการถูกใช้จนทรัพยากรหมดหรือค่าใช้จ่ายบานปลาย (denial-of-wallet) หรือถูกดูดโมเดลออกไป (model extraction) กันได้ด้วยการจำกัดจำนวนครั้งที่เรียกใช้ (rate limiting) การตั้งโควตา (quotas) และการเฝ้าดูระบบ (monitoring)

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)

System Promptคำสั่งลับที่เราตั้งไว้กำกับ AI เบื้องหลัง ผู้ใช้ปกติไม่ควรเห็น

Leakageการรั่วไหล คือความลับหลุดออกไปให้คนที่ไม่ควรเห็น

Vector / Embeddingการแปลงข้อความเป็นตัวเลขให้ AI ค้นหาเรื่องที่เกี่ยวข้องได้ หัวใจของระบบ RAG

Misinformationข้อมูลผิดหรือ AI มั่ว (hallucination) ที่ฟังดูน่าเชื่อแต่ไม่จริง

Unbounded Consumptionการถูกใช้งานหนักไม่จำกัด จนระบบช้า ล่ม หรือค่าใช้จ่ายพุ่ง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตรวจ system prompt หาความลับ

ช่วยตรวจว่าแนวปฏิบัตินี้ผิดหลัก LLM07 หรือไม่: ทีมเก็บ API key ของฐานข้อมูลไว้ใน system prompt เพื่อให้บอทเรียกใช้ได้สะดวก

✅ ผลลัพธ์ที่ได้

ผิดหลัก LLM07 เต็มๆ ห้ามเอาความลับ (API key, ข้อมูลล็อกอินต่างๆ) ไปใส่ใน system prompt เด็ดขาด เพราะถ้า prompt รั่วเมื่อไหร่ ก็เท่ากับความลับรั่วตามไปด้วย ควรเก็บ key ไว้ในที่เก็บความลับโดยเฉพาะ (secret manager) แล้วไปบังคับการตรวจสิทธิ์ (authorization) ไว้นอกตัวโมเดล ให้ระบบเบื้องหลัง (backend) เป็นคนเรียกฐานข้อมูลแทน ไม่ใช่ปล่อยให้โมเดลถือ key เอง

💡 จุดสอน

หลักสำคัญคือ ต้องบังคับการควบคุมและเก็บความลับไว้นอก prompt เสมอ ให้ถือไว้ก่อนว่า prompt มีโอกาสถูกเปิดเผยออกไปได้เสมอ

แบบฝึกหัดท้ายโมดูล

ลองตรวจ system prompt ตัวอย่างสักอัน แล้วชี้ว่ามีอะไรที่ผิดหลัก LLM07 บ้าง พร้อมเสนอวิธีแก้
ออกแบบมาตรการจำกัดจำนวนครั้ง (rate limiting) และโควตา (quota) สำหรับ LLM API เพื่อกัน LLM10 พร้อมบอกว่ามีตัวเลข (metric) ไหนบ้างที่ต้องคอยเฝ้าดู

🎯 Mini-project: จัดทำ AI Risk Register ตาม OWASP LLM Top 10 2025

เลือกระบบ AI/LLM จริงมาสักระบบ (หรือจะสมมติขึ้นจากองค์กรของคุณก็ได้) แล้วเขียนอธิบายโครงสร้างระบบ (สถาปัตยกรรม) แบบย่อๆ
ทำทะเบียนความเสี่ยง (risk register) โดยแมปความเสี่ยงเข้ากับ LLM01-LLM10 ให้ครบทุกหมวดที่เกี่ยวข้อง พร้อมระบุระดับความเสี่ยง
กำหนดมาตรการป้องกันฝั่งตั้งรับ (defensive) อย่างน้อยความเสี่ยงละ 1 มาตรการ โดยอิงจากหัวใจการป้องกันของ OWASP
ทำ AI-BOM เบื้องต้นของโมเดลและชุดข้อมูลที่ระบบใช้
ชี้จุดที่ต้องมีคนคอยอนุมัติ (human-in-the-loop) และย้ำหลักการที่ว่าคำตอบของ AI เชื่อไม่ได้ (untrusted) จนกว่าจะตรวจ
นำเสนอทะเบียนความเสี่ยง พร้อมอธิบายว่าทำไมด่านป้องกัน (guardrail) ตัวเดียวถึงไม่พอ ต้องซ้อนหลายชั้น (defense-in-depth)

ก้าวต่อไป

ลงมือป้องกัน: Guardrails, AI-SPM, Red-teaming เชิงป้องกัน และ AI สำหรับ Blue-team

ไปต่อ →