AI อ่านเอกสารแล้วทำตามคำสั่งแฝงได้ไหม? ตรวจ Prompt Injection ก่อนเปิด Automation

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

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

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

แยกปัญหานี้ออกจาก AI สรุปผิดทั่วไป

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

OWASP LLM01:2025 แยกการชักนำผ่านข้อมูลภายนอก เช่น เว็บไซต์หรือไฟล์ เป็น Indirect Prompt Injection และระบุว่า RAG ไม่ได้กำจัดความเสี่ยงนี้ทั้งหมด ดังนั้นการนำเอกสารเข้าไปค้นคืนก่อนให้ AI ตอบ ไม่ใช่หลักฐานว่าข้อความในเอกสารถูกอนุมัติให้สั่งงานระบบแล้ว

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

วาดเส้นทางข้อมูลหนึ่งงานก่อนเลือกเครื่องมือป้องกัน

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

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

ตัวอย่างสมมติ: ระบุขอบเขตของงานสรุปคำขอ

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

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

ทำข้อตกลงว่าข้อมูลภายนอกเปลี่ยนอะไรไม่ได้บ้าง

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

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

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

ตรวจคำเสนอจาก AI ก่อนแปลงเป็นการกระทำ

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

OWASP เรื่อง Improper Output Handling อธิบายความเสี่ยงของการส่งผลจากโมเดลไปยังส่วนอื่นโดยตรวจไม่พอ สำหรับงานนี้ คำตอบที่เป็น JSON ถูกโครงสร้างก็ยังอาจมีค่าผิดหรือเกินสิทธิ์ได้ ต้องตรวจความหมายของฟิลด์สำคัญก่อนใช้งาน ไม่ใช่ตรวจเพียงว่าเปิดไฟล์ได้หรือไม่

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

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

ปุ่มอนุมัติต้องบอกว่าจะเกิดอะไรขึ้นจริง

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

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

สำหรับหลักการเลือกจุดตรวจ อ่าน Human Approval สำหรับ Workflow ธุรกิจ ประกอบ ส่วนการทดสอบรอบนี้ให้เน้นว่าปุ่มนั้นควบคุมการกระทำปลายทางจริง ไม่ใช่แค่เปลี่ยนป้ายบนหน้าจอ

ใช้กรณีทดสอบที่พิสูจน์ขอบเขต โดยไม่แตะข้อมูลจริง

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

กรณีทดสอบป้องกันที่เสนอสำหรับ Workflow อ่านเอกสาร

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

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

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

ทำไมกรองคำต้องห้ามอย่างเดียวจึงยังไม่พอ

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

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

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

เมื่อพบพฤติกรรมเกินขอบเขต ให้หยุดที่การกระทำ

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

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

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

คำถามที่พบบ่อย

ใช้ RAG อ่านเฉพาะเอกสารบริษัท ยังต้องระวังไหม?

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

บอก AI ว่าอย่าทำตามคำสั่งในไฟล์ เพียงพอหรือไม่?

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

ระบบอ่านอย่างเดียวมีความเสี่ยงเป็นศูนย์ไหม?

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

จะรู้ได้อย่างไรว่าผู้ให้บริการทดสอบเรื่องนี้แล้วจริง?

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

แหล่งอ้างอิง

• OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. นิยามและความเสี่ยงจากข้อมูลภายนอก ตรวจเมื่อ 3 พฤศจิกายน 2026.
• OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. ขอบเขตเครื่องมือและสิทธิ์ ตรวจเมื่อ 3 พฤศจิกายน 2026.
• OWASP Gen AI Security Project. LLM05:2025 Improper Output Handling. การตรวจผลก่อนส่งให้ระบบอื่น ตรวจเมื่อ 3 พฤศจิกายน 2026.
• National Cyber Security Centre. Prompt injection is not SQL injection (it may be worse). ข้อจำกัดของการป้องกันและการลดผลกระทบ ตรวจเมื่อ 3 พฤศจิกายน 2026.