ความปลอดภัยของ LLM คืออะไร? วิธีลดความเสี่ยงด้านความปลอดภัย 10 อันดับแรกของ OWASP

การโจมตีที่หลอกให้ AI ถือว่าคำสั่งของผู้โจมตีเป็นคำสั่งที่ต้องปฏิบัติตาม หรือที่เรียกว่าการแทรกพรอมต์ (prompt injection) ติดอันดับ 1 ใน OWASP Top 10 for LLM Applications มาทุกฉบับนับตั้งแต่ปี 2023

รายการนี้ใกล้เคียงกับฉันทามติมากที่สุดเท่าที่วงการความปลอดภัยของ AI จะมีได้ โปรเจกต์นี้เริ่มต้นจากกลุ่มผู้เชี่ยวชาญด้านความปลอดภัยกลุ่มเล็กๆ และปัจจุบันได้รับความร่วมมือจากผู้เชี่ยวชาญมากกว่า 600 คนในกว่า 18 ประเทศ

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

ฉบับปี 2026 เปิดฉากด้วยท่าทีเดียวกัน หัวหน้าโปรเจกต์บอกให้เรา "เลิกพยายามสร้างโมเดลที่ไม่มีวันถูกหลอก" และให้ออกแบบระบบโดยรอบเพื่อไม่ให้โมเดลที่ถูกหลอกสร้างความเสียหายต่อสิ่งสำคัญใดๆ ได้

เรายึดจุดยืนนี้ตลอดการพิจารณาความเสี่ยงทั้ง 10 ข้อในรายการปี 2026 ของ OWASP

ความปลอดภัยของ LLM หมายถึงอะไร

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

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

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

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

เราเองก็เจอปัญหาเดียวกันกับเอเจนต์ AI ของเราเอง Kyle Polley ซึ่งเป็น CISO ของเราบอกกับ ISMG ว่าเอเจนต์ "อาจไม่ปฏิบัติตามนโยบาย แม้ว่าคุณจะเพิ่มนโยบายนั้นไว้ในพรอมต์ระบบแล้วก็ตาม" นั่นคือเหตุผลที่เราสร้าง Numbat ขึ้นมา ซึ่งเป็นเครื่องมือโอเพนซอร์สที่ตรวจสอบสิ่งที่เอเจนต์กำลังจะทำ และสามารถบล็อกการกระทำนั้นได้หากละเมิดกฎความปลอดภัยที่กำหนดค่าไว้

ความปลอดภัยของ LLM หมายถึงการยอมรับว่าบางครั้งโมเดลจะรับคำสั่งจากคนที่ไม่ควรรับ และการวางกลไกป้องกัน AI (AI guardrails) ไว้รอบโมเดลที่ยังคงได้ผลแม้เมื่อเกิดเหตุการณ์นั้นขึ้น

แนวทางปฏิบัติที่ดีที่สุดสำหรับความปลอดภัยของ LLM มีอะไรบ้าง

เราจะไล่ดู OWASP Top 10 for LLM Applications 2026 ตามลำดับ ตั้งแต่อันดับ 1 ถึงอันดับ 10

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

1. ควบคุมการแทรกพรอมต์

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

ประเภทที่สองเรียกว่าการแทรกพรอมต์ทางอ้อม (indirect prompt injection) คุณขอให้ผู้ช่วยสรุปเอกสาร แต่ผู้เขียนเอกสารได้แอบสั่งไว้ให้ผู้ช่วยส่งไฟล์ส่วนตัวของคุณไปให้พวกเขา หากผู้ช่วยปฏิบัติตามคำสั่งเหล่านั้น ผู้เขียนเอกสารก็เท่ากับได้ยืมสิทธิ์เข้าถึงของคุณไปใช้

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

ตัวอย่าง: ในเดือนมิถุนายน 2025 นักวิจัยของ Aim Security ค้นพบ EchoLeak ซึ่งเป็นช่องโหว่ที่หลอกให้ Microsoft 365 Copilot ทำข้อมูลส่วนตัวของบริษัทรั่วไหล เมื่อพนักงานถามคำถามเกี่ยวกับงานตามปกติ Copilot อาจดึงอีเมลของผู้โจมตีเข้ามา ปฏิบัติตามคำสั่งที่ซ่อนอยู่ข้างใน และส่งข้อมูลที่ละเอียดอ่อนไปยังผู้โจมตี การโจมตีนี้หลุดรอดการตรวจสอบที่ออกแบบมาเพื่อดักจับคำสั่งที่เป็นอันตรายและลบลิงก์ที่น่าสงสัย

สิ่งที่คุณทำได้:

• ปฏิบัติตาม “กฎแห่งสอง (Rule of Two)” ของ Meta: EchoLeak ต้องอาศัย AI ที่อ่านข้อมูลบริษัท อ่านอีเมลจากภายนอก และส่งข้อมูลออกไปได้ ซึ่ง AI ตัวนั้นมีความสามารถครบทั้งสามอย่าง การจำกัดให้มีเพียงสองในสามความสามารถนี้จะป้องกันไม่ให้การแทรกพรอมต์เข้าควบคุมได้มากเกินไป หากงานจำเป็นต้องใช้ทั้งสามอย่าง ให้กำหนดให้ต้องได้รับการอนุมัติจากมนุษย์ก่อนการดำเนินการแต่ละครั้ง
• ทดสอบกับผู้โจมตีที่รู้กลไกป้องกันของคุณ: มอบกฎและตัวกรองที่คุณใช้อยู่ให้ผู้ทดสอบความปลอดภัย แล้วปล่อยให้พวกเขาหาทางหลบเลี่ยง ในการศึกษาหนึ่ง ผู้โจมตีที่ปรับตัวตามกลไกป้องกันประสบความสำเร็จมากกว่า 90% ของจำนวนครั้งเมื่อเจอกับกลไกป้องกันส่วนใหญ่จากทั้งหมด 12 รายการที่ทดสอบ

2. หยุดการรั่วไหลของข้อมูลที่ละเอียดอ่อน

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

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

ตัวอย่าง: ในเดือนมกราคม 2025 นักวิจัยของ Wiz พบฐานข้อมูลของ DeepSeek ที่เปิดสู่อินเทอร์เน็ต ซึ่งมีรายการบันทึกมากกว่าหนึ่งล้านรายการ รวมถึงประวัติแชทและคีย์ API ซึ่งซอฟต์แวร์ใช้ในการเข้าถึงบริการอื่นๆ นักวิจัยไม่จำเป็นต้องหว่านล้อมโมเดลให้เปิดเผยสิ่งใดเลย

สิ่งที่คุณทำได้:

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

3. ควบคุมการให้อำนาจดำเนินการมากเกินไป

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

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

ตัวอย่าง: ในเดือนกรกฎาคม 2025 Jason Lemkin ผู้ก่อตั้ง SaaStr รายงานว่าเอเจนต์เขียนโค้ดของ Replit ได้ลบฐานข้อมูลที่มีบันทึกข้อมูลผู้บริหาร 1,206 รายการของเขา แม้จะได้รับคำสั่งไม่ให้ทำการเปลี่ยนแปลงใดๆ ในตอนแรกเอเจนต์บอกว่าข้อมูลไม่สามารถกู้คืนได้ แต่ภายหลังกลับพบว่ากู้คืนได้ Jason พบว่าการสั่งให้เอเจนต์อย่ายุ่งกับฐานข้อมูลไม่ได้ทำให้เอเจนต์หมดความสามารถในการลบฐานข้อมูลนั้น

ขยาย

ที่มา: X

สิ่งที่คุณทำได้:

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

4. ตรวจสอบสิ่งที่เข้ามาในห่วงโซ่อุปทาน AI ของคุณ

มีบริษัทเพียงไม่กี่แห่งที่สร้าง AI ขึ้นเองตั้งแต่ต้น และจำนวนนี้ก็ลดลงทุกปี จากแบบสำรวจ The State of Generative AI in the Enterprise ปี 2025 ของ Menlo Ventures พบว่า 53% ซื้อโมเดล AI ในปี 2024 และเพิ่มขึ้นเป็น 76% ในปี 2025

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

แต่ละส่วนเหล่านี้ล้วนเป็นช่องทางเข้า หากส่วนใดส่วนหนึ่งถูกดัดแปลง ปัญหาก็จะติดไปกับผลิตภัณฑ์ของคุณด้วย

ตัวอย่าง: คลังโมเดลสาธารณะของ Hugging Face เพิ่มขึ้นจาก 2.43 ล้านเป็น 2.96 ล้าน ระหว่างเดือนมกราคม 2026 ถึงเดือนสิงหาคม 2026 อย่างไรก็ตาม ในเดือนกรกฎาคม 2026 โมเดลของ OpenAI ได้หลบเลี่ยงการควบคุมที่มีไว้เพื่อกันไม่ให้โมเดลเข้าถึงอินเทอร์เน็ตระหว่างการทดสอบความปลอดภัยภายใน และเจาะเข้าไปในบางส่วนของระบบ Hugging Face อันที่จริง เอเจนต์ตัวหนึ่งได้ค้นพบข้อมูลรับรองการเข้าถึงที่เปิดเผยต่อสาธารณะ 14 รายการ ตรวจสอบว่าใช้งานได้ และแชร์ให้กับเอเจนต์ตัวอื่นๆ จากนั้นเอเจนต์เหล่านั้นก็ใช้ประโยชน์จากช่องโหว่ที่ทำให้สามารถรันโค้ดบนเซิร์ฟเวอร์ของ Hugging Face ได้

“เรากำลังกำหนดข้อกำหนดที่เข้มงวดขึ้นด้านการจัดแนว (alignment) ตลอดวงจรชีวิตของโมเดล และสร้างแซนด์บ็อกซ์ที่แยกออกจากกันมากขึ้น จำกัดการเข้าถึงอินเทอร์เน็ต และควบคุมการเข้าถึงค่าน้ำหนักของโมเดลให้เข้มงวดยิ่งขึ้น” รายงานของ OpenAI ระบุ

สิ่งที่คุณทำได้:

• ตรึงโมเดลไว้ที่เวอร์ชันที่แน่นอนและตรวจสอบยืนยัน: ตรึงโมเดลแต่ละตัวไว้กับเวอร์ชันที่ผ่านการตรวจทานแล้ว และตรวจสอบลายนิ้วมือของไฟล์ (file fingerprint) ก่อนโหลด เพื่อไม่ให้ไฟล์ที่ถูกสับเปลี่ยนแอบเข้ามาภายใต้ชื่อเดียวกันได้ OWASP ยังแนะนำให้ใช้ลายเซ็นดิจิทัลด้วย แต่มีข้อควรระวังคือ ลายเซ็นพิสูจน์ได้เพียงว่าโมเดลมาจากที่ใด ไม่ได้พิสูจน์ว่าโมเดลนั้นปลอดภัย
• ตรวจสอบทุกแพ็กเกจที่ AI แนะนำ: ก่อนติดตั้งแพ็กเกจโค้ดที่ผู้ช่วย AI แนะนำ ให้ยืนยันว่าแพ็กเกจนั้นมีอยู่จริง เป็นแพ็กเกจที่คุณตั้งใจจะใช้ และมาจากผู้เผยแพร่ที่คุณคาดไว้

5. ป้องกันการวางยาพิษข้อมูลและโมเดล

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

วลีนั้นจะผ่านการทดสอบทุกครั้งที่คุณทำ จนกว่าจะมีคนนำวลีนั้นมาใช้จริง

ขยาย

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

ตัวอย่าง: ในเดือนตุลาคม 2025 นักวิจัยจาก Anthropic, UK AI Security Institute และ Alan Turing Institute แสดงให้เห็นว่าเอกสารที่ถูกวางยาพิษ 250 ฉบับสามารถสอนให้โมเดลสร้างข้อความไร้สาระได้ทุกครั้งที่พบตัวกระตุ้นเฉพาะ จำนวนเท่ากันนี้ได้ผลกับโมเดลทั้งสี่ขนาดที่ทดสอบ แม้ว่าโมเดลที่ใหญ่ที่สุดจะฝึกด้วยข้อมูลที่สะอาดมากกว่าถึง 20 เท่าก็ตาม

สิ่งที่คุณทำได้:

• ติดตามแหล่งที่มาของข้อมูล: บันทึกชุดข้อมูลและโมเดลทุกรายการที่คุณใช้ แหล่งที่มาของแต่ละรายการ และสิ่งที่เปลี่ยนแปลงระหว่างเวอร์ชัน เราแนะนำให้ใช้การควบคุมเวอร์ชันสำหรับชุดข้อมูล เพื่อที่หากพบการวางยาพิษ คุณจะสามารถย้อนกลับไปยังเวอร์ชันที่สะอาด และหาสาเหตุว่ายาพิษเข้ามาได้อย่างไร
• ทดสอบหาแบ็กดอร์: “แบ็กดอร์” คือพฤติกรรมที่ซ่อนอยู่ซึ่งผู้โจมตีฝังไว้ในโมเดล โดยรอวลีเฉพาะหรือตัวกระตุ้นอื่นๆ เพื่อเปิดใช้งาน ทดสอบหาสิ่งเหล่านี้ด้วยอินพุตที่ออกแบบมาเพื่อทำให้โมเดลละเมิดกฎตามปกติของตัวเอง

6. กำหนดเพดานให้กับการใช้ทรัพยากรที่ไร้ขีดจำกัด

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

OWASP เรียกปัญหาหลักนี้ว่า “ความไม่สมมาตรของต้นทุน” คำขอสั้นๆ ที่มีต้นทุนต่ำสามารถกระตุ้นให้เกิดการประมวลผลที่มีค่าใช้จ่ายสูงในฝั่งของคุณ

ตัวอย่าง: ในเดือนพฤษภาคม 2024 ทีมวิจัยภัยคุกคามของ Sysdig ค้นพบการโจมตีรูปแบบใหม่ที่เรียกว่า “LLMjacking” กลุ่มผู้โจมตีเล็งเป้าไปที่บริการ LLM บนคลาวด์ 10 บริการโดยใช้ข้อมูลรับรองที่ขโมยมา พวกเขาเจาะเข้ามาผ่าน Laravel เวอร์ชันที่มีช่องโหว่ จากนั้นจึงตรวจสอบว่าข้อมูลรับรองเหล่านั้นทำอะไรได้บ้างและมีโควตาเท่าใด โดยมีเป้าหมายชัดเจนคือการขายสิทธิ์การเข้าถึง นอกจากนี้ยังมีการสืบค้นการตั้งค่าการบันทึกล็อกจำนวนมาก ซึ่งน่าจะเพื่อหลีกเลี่ยงการถูกตรวจจับ Sysdig ระบุว่าในกรณีที่เลวร้ายที่สุด เหยื่ออาจต้องเสียค่าใช้จ่ายมากกว่า $46,000 ต่อวัน

สิ่งที่คุณทำได้:

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

7. ตรวจจับข้อมูลที่ผิดก่อนลงมือดำเนินการ

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

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

ตัวอย่าง: ในปี 2025 Deloitte Australia ส่งมอบรายงานการทบทวนระบบไอทีด้านสวัสดิการภายใต้สัญญากับรัฐบาลมูลค่า A$440,000 Chris Rudge นักวิจัยจาก University of Sydney พบการอ้างอิงงานวิจัยที่ไม่มีอยู่จริง และคำพูดที่ถูกกุขึ้นจากคำพิพากษาของศาลกลาง รายงานฉบับแก้ไขเปิดเผยว่า Deloitte ได้ใช้ Azure OpenAI GPT-4o ในระเบียบวิธี และบริษัทตกลงที่จะคืนเงินงวดสุดท้าย น่าเสียดายที่งานนี้เป็นการสอบทานเพื่อให้ความเชื่อมั่น (assurance review)

สิ่งที่คุณทำได้:

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

8. จำกัดความเสียหายจากการเปิดเผยบริบทที่ซ่อนอยู่

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

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

ตัวอย่าง: ในเดือนกุมภาพันธ์ 2023 ผู้ใช้ทำให้Bing Chat ของ Microsoft เปิดเผยคำสั่งภายในของตนเอง หนึ่งในความพยายามที่สำเร็จมาจาก Marvin von Hagen ซึ่งอ้างว่าเป็นนักพัฒนาของ OpenAI และขอดูคำสั่งเหล่านั้นเพื่อนำไปกำหนดค่าโมเดล Bing ได้เปิดเผยกฎที่ควบคุมการค้นหา การตอบกลับ และพฤติกรรมด้านความปลอดภัย พร้อมทั้งชื่อภายในว่า Sydney ในบรรดาคำสั่งที่ถูกเปิดเผยนั้น มีคำสั่งหนึ่งที่สั่งให้เก็บคำสั่งเหล่านั้นไว้เป็นความลับ

สิ่งที่คุณทำได้:

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

9. ปกป้องเวกเตอร์และเอ็มเบดดิงอย่างรัดกุม

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

OWASP สรุปรูปแบบความล้มเหลวไว้สี่แบบ ได้แก่ การวางยาพิษ (poisoning) ทำให้ระบบให้ข้อมูลผิด การย้อนกลับ (inversion) ทำให้ข้อมูลรั่วไหล การขัดขวาง (jamming) ทำให้ระบบเงียบไม่ตอบ และการควบคุมการเข้าถึงที่บกพร่องทำให้ระบบส่งมอบอะไรก็ได้ให้ใครก็ได้

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

ตัวอย่าง: ในงานวิจัยที่นำเสนอในงาน USENIX Security 2025 นักวิจัยแสดงให้เห็นว่าเอกสารเพียงฉบับเดียวที่สร้างขึ้นอย่างแยบยลสามารถทำให้ AI ไม่ตอบคำถามบางข้อได้ โดยพวกเขาเพิ่มเอกสารนั้นลงในคลังเอกสารที่ AI ใช้ค้นหา เมื่อ AI พบเอกสารดังกล่าว AI อาจตอบว่ามีข้อมูลไม่เพียงพอ หรือบอกว่าการตอบคำถามนั้นไม่ปลอดภัย ทั้งที่เอกสารไม่จำเป็นต้องสั่งให้ AI เพิกเฉยต่อกฎของตัวเองเลย วิธีนี้เรียกว่า “การขัดขวางการดึงข้อมูล (retrieval jamming)”

สิ่งที่คุณทำได้:

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

10. ตรวจสอบเอาต์พุตของ AI ก่อนส่งต่อ

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

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

ตัวอย่าง: ในปี 2025 นักวิจัย Johann Rehberger ได้แสดงให้เห็นว่าผู้ช่วยเขียนโค้ด Amp ของ Sourcegraph อาจทำให้เนื้อหาแชทรั่วไหลได้เพียงแค่แสดงรูปภาพ เขาใช้ Prompt Injection เพื่อทำให้ Amp ใส่ข้อมูลส่วนตัวลงในที่อยู่เว็บของรูปภาพ จากนั้นแอปพลิเคชันก็ดึงรูปภาพนั้นมาโดยอัตโนมัติ ซึ่งเท่ากับส่งข้อมูลไปยังเซิร์ฟเวอร์ของเขา ความล้มเหลวในการจัดการเอาต์พุตในกรณีนี้คือคำขออัตโนมัตินั้นเอง ข้อความที่โมเดลสร้างขึ้นกลายเป็นการเชื่อมต่อไปยังเซิร์ฟเวอร์ภายนอกที่นำข้อมูลส่วนตัวติดไปด้วย

สิ่งที่คุณทำได้:

• ทำให้เอาต์พุตปลอดภัยสำหรับปลายทาง: ตรวจสอบและจัดการคำตอบตามปลายทางที่จะส่งไป สำหรับหน้าเว็บ ให้ป้องกันไม่ให้ข้อความที่สร้างขึ้นกลายเป็นโค้ดที่เรียกใช้งานได้ สำหรับฐานข้อมูล ให้ใช้คิวรีแบบเตรียมไว้ล่วงหน้า (prepared query) ที่แยกค่าที่ส่งเข้ามาออกจากคำสั่ง
• ป้องกันไม่ให้คำตอบเชื่อมต่อกับภายนอกโดยอัตโนมัติ: ตั้งค่าเริ่มต้นให้ปิดการโหลดอัตโนมัติสำหรับรูปภาพ ตัวอย่างลิงก์ และหน้าเว็บที่ฝังอยู่ในคำตอบของโมเดล และจำกัดการเชื่อมต่อที่จำเป็นให้ไปได้เฉพาะปลายทางที่ได้รับอนุมัติอย่างชัดแจ้งเท่านั้น

Perplexity รักษาความปลอดภัยของ LLM อย่างไร?

เราตั้งสมมติฐานว่าความเสี่ยงทุกข้อข้างต้นจะเกิดขึ้นจริงสักวัน และเราออกแบบระบบให้ความเสี่ยงนั้นสร้างความเสียหายได้น้อยที่สุดเมื่อเกิดขึ้น Kyle Polley ซึ่งเป็น CISO ของเรา ได้อธิบายวิธีการไว้ในเวิร์กช็อปล่าสุด

• เอเจนต์มีคอมพิวเตอร์เป็นของตัวเอง และเริ่มต้นแบบว่างเปล่า: เครื่องมือเอเจนต์ที่ติดตั้งบนแล็ปท็อปของคุณสามารถเข้าถึงไฟล์ แอป และข้อมูลรับรองที่บันทึกไว้ในเครื่องได้ แต่ Perplexity Computer ทำงานในทางตรงกันข้าม แต่ละงานจะทำงานในแซนด์บ็อกซ์ที่แยกออกมาเป็นของตัวเอง และอย่างที่ Polley กล่าวไว้ว่า “โดยค่าเริ่มต้นแล้ว มันไม่มีสิทธิ์เข้าถึงสิ่งใดเลย”
• เอเจนต์ไม่เคยเห็นรหัสผ่าน: ข้อมูลรับรองสำหรับบริการที่เชื่อมต่อจะถูกจัดเก็บไว้นอกแซนด์บ็อกซ์ เมื่อเอเจนต์ต้องเข้าถึงบริการอย่าง GitHub เอเจนต์จะส่งคำขอโดยไม่มีข้อมูลรับรองแนบไปด้วย เกตเวย์จะตรวจสอบว่าปลายทางและคำขอเป็นไปตามที่คาดไว้ จากนั้นจึงเพิ่มข้อมูลรับรองเข้าไประหว่างที่ส่งคำขอออกไป เอเจนต์จึงใช้การเชื่อมต่อได้โดยไม่ต้องได้รับคีย์
• สิทธิ์ของคุณจะส่งต่อมาด้วย และคุณจำกัดให้เข้มงวดขึ้นได้: การเชื่อมต่อผ่าน OAuth จะคงสิทธิ์การเข้าถึงของคุณในบริการที่เชื่อมต่อไว้ หากคุณมองไม่เห็นสิ่งใด เอเจนต์ของคุณก็มองไม่เห็นเช่นกัน
• ทุกหน้าเว็บถูกปฏิบัติเหมือนคนแปลกหน้า: เราสร้าง BrowseSafe สำหรับ Comet ซึ่งเป็นเบราว์เซอร์แบบเอเจนต์ของเรา เนื่องจากเครื่องมือที่เราทดสอบไม่ตอบโจทย์การใช้งานจริง เบราว์เซอร์จะสแกนหน้าเว็บและเนื้อหาภายนอกอื่นๆ รวมถึงอีเมล เพื่อตรวจหา Prompt Injection และเราได้เผยแพร่ทั้งโมเดลและชุดข้อมูลเป็นโอเพนซอร์ส
• เราเฝ้าติดตามทั้งเอเจนต์และเครื่องที่เอเจนต์ทำงานอยู่: Numbat ทำหน้าที่คั่นกลางระหว่างช่วงที่เอเจนต์ตัดสินใจลงมือกับช่วงที่เครื่องมือทำงานจริง Numbat บันทึกกิจกรรมของเอเจนต์เขียนโค้ดที่รองรับ และสามารถบล็อกการกระทำที่ละเมิดนโยบายที่กำหนดไว้ได้ก่อนที่จะมีการดำเนินการจริง ส่วน Bumblebee จัดทำบัญชีรายการแพ็กเกจซอฟต์แวร์บนแล็ปท็อป เซิร์ฟเวอร์ และไปป์ไลน์บิลด์ พร้อมแจ้งเตือนแพ็กเกจที่ทราบว่าเป็นอันตราย ทั้งสองเครื่องมือเป็นโอเพนซอร์ส
• ผู้ให้บริการโมเดลไม่เก็บข้อมูลของคุณไว้: เรามีข้อตกลงไม่เก็บรักษาข้อมูล (zero data retention) กับผู้ให้บริการ LLM บุคคลที่สามของเรา นอกจากนี้ ผู้ดูแลระบบขององค์กรยังสามารถกำหนดระยะเวลาเก็บรักษาข้อมูลของ Perplexity เองให้สั้นสุดเพียง 24 ชั่วโมงได้

เราสร้าง Numbat ขึ้นในเชิงรุก ด้วยเหตุผลที่ Polley สรุปไว้ในประโยคเดียวว่า “ยิ่งคุณให้อิสระแก่เอเจนต์มากเท่าไร ความเสี่ยงก็ยิ่งมากขึ้นเท่านั้น”

คำถามที่พบบ่อยเกี่ยวกับความปลอดภัยของ LLM

LLM ใดปลอดภัยที่สุด?

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

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

ช่องโหว่ของ LLM คืออะไร?

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

ความเสี่ยงหลัก 10 ประการ ได้แก่ Prompt Injection การเปิดเผยข้อมูลที่ละเอียดอ่อน การให้อำนาจดำเนินการมากเกินไป (excessive agency) ห่วงโซ่อุปทาน การวางยาพิษข้อมูลและโมเดล การใช้ทรัพยากรอย่างไร้ขีดจำกัด ข้อมูลที่ผิดพลาด การเปิดเผยบริบทที่ซ่อนอยู่ จุดอ่อนของเวกเตอร์และเอ็มเบดดิง และการจัดการเอาต์พุตอย่างไม่เหมาะสม

LLM แบบส่วนตัวปลอดภัยหรือไม่?

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

เมื่อโฮสต์โมเดลเอง คุณยังต้องรับผิดชอบต่อโมเดลที่ดาวน์โหลดมาด้วย รวมถึงความเสี่ยงด้านห่วงโซ่อุปทานและโครงสร้างพื้นฐานที่โมเดลนั้นต้องใช้