Agent อ่าน PDF ของผู้ขายเพื่อเทียบเงื่อนไขส่งของ แต่ในเอกสารมีข้อความบอกให้ผู้ช่วยเลิกทำตามคำขอทีมจัดซื้อ แล้วส่งข้อมูลภายในไปที่อื่น ข้อความนั้นเป็นส่วนหนึ่งของเอกสารที่กำลังวิเคราะห์ ไม่ใช่คำสั่งจากคนที่อนุญาตให้ทำงาน
Prompt Injection พยายามข้ามเส้นแบ่งนี้ โดยทำให้เนื้อหาภายนอกกลายเป็นอำนาจสั่ง Agent ผลกระทบจะมากขึ้นเมื่อผู้ช่วยส่งข้อความ แก้รายการ หรือเรียกเครื่องมือที่ทำงานสำคัญได้ การป้องกันจึงต้องจำกัดทั้งสิ่งที่เนื้อหาภายนอกชี้นำได้ และสิ่งที่ตัวแอปยอมให้ทำจริง
ตามเส้นทางจากเอกสารไปจนถึงคำสั่ง
ในตัวอย่างสมมติของผู้ช่วยจัดซื้อ ข้อมูลภายนอกอาจมาจาก PDF เว็บไซต์ อีเมล หรือผลเครื่องมือที่อ่านข้อความจากไฟล์ จากนั้นผ่านการสรุป ดัชนีค้น หรือ Agent อีกตัว ก่อนถึงส่วนที่เตรียมคำสั่งธุรกิจ การเชื่อมผ่านเครื่องมือที่เชื่อถือได้ไม่ได้ทำให้เอกสารทุกชิ้นที่เครื่องมือนั้นส่งกลับมาน่าเชื่อถือทั้งหมด
แจกแจงเส้นทางเหล่านี้และงานที่ทำได้ในแต่ละจุด การอ่านเงื่อนไขส่งของใช้สิทธิ์ต่างจากการแก้บัญชีผู้ขายหรือส่งตารางเปรียบเทียบภายใน หาก Agent ตัวเดียวทำได้ครบทุกอย่าง ความผิดพลาดในการตีความจะส่งผลได้ไกลขึ้น
OWASP อธิบาย Prompt Injection ทั้งทางตรงและผ่านเนื้อหาภายนอก รวมความเสี่ยงจากข้อมูลหลายรูปแบบ และเสนอการลดความเสี่ยงหลายชั้น เช่น จำกัดสิทธิ์ แยกเนื้อหาภายนอก และให้คนอนุมัติงานที่มีผลสำคัญ โดยไม่ได้เสนอวิธีที่รับประกันป้องกันได้ทุกกรณี แนวทาง Prompt Injection ของ OWASP
ให้ข้อความภายนอกเป็นหลักฐานสำหรับงานที่ขอ เก็บที่มา ตัวตนเอกสาร และขอบเขตการเข้าถึงตลอดทาง ข้อความสรุปคำสั่งแปลก ๆ ยังคงเป็นข้อมูลที่ไม่ควรเชื่อเป็นคำสั่ง การสรุปไม่ได้เปลี่ยนเนื้อหานั้นให้เป็นนโยบายของธุรกิจ
เก็บอำนาจสั่งงานไว้นอกข้อมูลที่ค้นมา
คำขอของผู้ใช้ กฎของแอป และสิทธิ์ต้องมาจากช่องทางที่ควบคุมได้ อย่านำหน้าเว็บที่ดาวน์โหลดมาต่อเข้าเป็นข้อความสั่งงานระดับสูง ระบุให้ชัดว่าต้องดึงข้อมูลอะไร และส่งเนื้อหาภายนอกด้วยรูปแบบข้อความที่เอกสารของผู้ให้บริการและ API นั้นรองรับ
แนวทางความปลอดภัยของ OpenAI เตือนไม่ให้นำตัวแปรจากแหล่งที่ไม่เชื่อถือใส่ใน Developer message และอธิบายการจำกัดข้อมูลที่ส่งระหว่างขั้นตอน หลักคิดนี้ใช้ประกอบการออกแบบได้ แม้แอปจะมี Workflow ของตัวเองแทนผลิตภัณฑ์ที่ใช้สาธิตในคู่มือ แนวทางสร้าง Agent ของ OpenAI
Anthropic มีคำแนะนำให้ระบุเนื้อหาบุคคลที่สามเป็นข้อมูลที่ไม่เชื่อถือ พร้อมแนวทางเฉพาะเรื่องการใส่ในผลเครื่องมือและการเข้ารหัสแบบมีโครงสร้าง ควรทำตามข้อตกลงของ API ที่ใช้ ไม่สมมติว่าบทบาทข้อความทำงานเหมือนกันทุกผู้ให้บริการ แนวทางลด Prompt Injection ของ Anthropic
สำหรับผู้ช่วยจัดซื้อ อาจกำหนดให้ดึงเพียงรหัสสินค้า ช่วงเวลาส่งที่ผู้ขายระบุ และเงื่อนไขเสนอราคา พร้อมจุดอ้างอิง ตรวจชนิดและความหมายทางธุรกิจก่อนส่งต่อ แม้ข้อมูลจะเป็น JSON ที่ถูกโครงสร้าง ก็ยังอาจมีบัญชีผิด ค่าที่แต่งขึ้น หรือข้อความชี้นำอยู่ในช่องได้ โครงสร้างจึงเป็นเพียงส่วนหนึ่งของการป้องกัน
ให้สิทธิ์เครื่องมือน้อยกว่าสิ่งที่บทสนทนาอาจร้องขอ
เครื่องมืออ่านเอกสารผู้ขายที่ได้รับอนุญาตไม่ควรส่งอีเมลไปที่ใดก็ได้หรือแก้รายละเอียดการจ่ายเงินไปด้วย แยกความสามารถและตรวจสิทธิ์ฝั่งเซิร์ฟเวอร์ตามผู้ใช้กับขอบเขตงาน รหัสลูกค้าที่โมเดลเสนอเป็นข้อมูลให้ตรวจ ไม่ใช่คำตัดสินว่ามีสิทธิ์
เก็บรหัสและกุญแจเข้าถึงในแอปหรือสภาพแวดล้อมทำงาน แทนการใส่ไว้ในข้อความที่โมเดลอ่านตามปกติ ใช้คำสั่งที่มีขอบเขตเท่าที่ทำได้ เช่น เตรียมร่างเปรียบเทียบ ขอข้อมูลรายการที่อนุญาต หรือเสนอการแก้เพื่อรอตรวจ ไม่จำเป็นต้องเปิดเครื่องมือสั่งงานทั่วไปที่ทำได้ทุกอย่าง หากคำสั่งเฉพาะครอบคลุมงานแล้ว
คำสั่งส่งออกต้องตรวจปลายทาง ผู้รับและไฟล์แนบควรมาจากข้อมูลธุรกิจที่ยืนยันแล้วกับคำขอปัจจุบัน การพบอีเมลหนึ่งใน PDF ของผู้ขายยังไม่ใช่เหตุผลเพียงพอให้ส่งไฟล์ภายในไปที่อีเมลนั้น
ดูการนำข้อความไปใช้ต่อด้วย ข้อมูลจากเอกสารอาจไปอยู่ใน HTML ตารางคำนวณ หรือคำสั่งฐานข้อมูล ต้องใช้การเข้ารหัสอักขระ การส่งพารามิเตอร์ และการตรวจค่าที่เหมาะกับปลายทาง การป้องกัน Prompt Injection ไม่ได้แทนความปลอดภัยของแอปส่วนอื่น
ทำให้การอนุมัติเป็นการตรวจที่มีข้อมูล
คำถามว่า “อนุญาตให้ Agent ทำต่อหรือไม่” ให้ข้อมูลผู้ตรวจน้อยเกินไป ควรแสดงงานที่จะทำ ผู้รับจริง รายการข้อมูล เนื้อหาที่จะส่ง และเหตุผลที่ต้องทำ ระบุด้วยว่าส่วนใดมาจากเอกสารภายนอกและยังต้องยืนยัน
ผูกการอนุมัติกับข้อมูลคำสั่งและรุ่นที่เตรียมไว้ หาก Agent เปลี่ยนผู้รับหรือไฟล์แนบหลังอนุมัติ การอนุมัติเดิมต้องไม่ครอบคลุมคำสั่งใหม่ ตรวจสิทธิ์อีกครั้งตอนลงมือด้วย เพราะสิทธิ์ผู้ใช้อาจเปลี่ยนระหว่างรอ
ออกแบบให้เหมาะกับผลกระทบ การอ่านข้อความภายในขอบเขตที่อนุญาตแล้วอาจไม่ต้องถามซ้ำทุกครั้ง แต่งานส่งข้อมูลภายในหรือแก้รายการสำคัญต้องมีขอบเขตอีกแบบ การให้คนคลิกทุกขั้นที่ไม่เสี่ยงอาจทำให้เคยชินกับการกดยอมรับโดยไม่อ่าน
เมื่อระบบระงับคำสั่ง ให้บอกว่าหยุดอะไรไว้และคนจะแก้อย่างไร ควรเก็บผลงานเปรียบเทียบที่ถูกต้องไว้ แล้วแยกส่วนที่น่าสงสัยออก ข้อความล้มเหลวแบบไม่บอกเหตุอาจทำให้พนักงานเลิกใช้ระบบและหาทางข้ามขั้นตอนเอง
ทดสอบเส้นแบ่ง รวมถึงทางอ้อม
ใช้สภาพแวดล้อมแยกกับข้อมูลทดสอบที่ไม่อ่อนไหว ใส่ข้อความลักษณะคำสั่งในไฟล์ตัวอย่าง หน้าเว็บ และผลเครื่องมือที่อนุญาต แล้วตรวจว่า Agent ยังทำงานในขอบเขตเดิมหรือไม่ รวมกรณีข้อความอ้างว่าเป็นนโยบายใหม่ หรือฝาก Agent อีกตัวส่งคำสั่งต่อ
ตรวจคำขอใช้เครื่องมือและรายการปลายทางจริง การตอบว่าไม่ทำตามคำสั่งแฝงยังไม่พอ หากผู้ช่วยเปลี่ยนผู้รับ แนบไฟล์ที่ไม่เกี่ยว หรือเขียนค่าที่ยังไม่ตรวจอยู่ดี ต้องพิสูจน์ด้วยว่าเซิร์ฟเวอร์ปฏิเสธงานที่ห้ามได้โดยไม่ขึ้นกับคำตอบโมเดล
ดูการปฏิเสธผิดด้วย เอกสารอาจพูดถึงคำสั่ง นโยบาย หรือเหตุการณ์ความปลอดภัยอย่างถูกต้อง ผลิตภัณฑ์ควรสรุปสิ่งเหล่านี้เป็นเนื้อหาได้ โดยไม่รับมาเป็นคำสั่งและไม่ปฏิเสธงานทั้งหมดโดยไม่จำเป็น
เก็บหลักฐานเหตุผิดปกติที่ช่วยตรวจสอบได้ โดยไม่กระจายข้อมูลอ่อนไหวลงบันทึกที่ทุกคนอ่าน กำหนดคนดูรายการที่ถูกระงับ เงื่อนไขหยุดตัวเชื่อมหรือ Workflow และวิธีเพิ่มกรณีที่แก้แล้วกลับเข้าชุดทดสอบ ตรวจซ้ำเมื่อเปลี่ยนโมเดล เครื่องมือ การอ่านไฟล์ หรือ Memory เพราะอาจเปิดทางให้เนื้อหาภายนอกไหลไปถึงคำสั่งได้อีก
อ่านกรอบสิทธิ์ภาพรวมได้จาก สิทธิ์และจุดอนุมัติของ Agent และนำกรณีเหล่านี้ไปรวมกับ Evals ที่ตรวจผลทางธุรกิจจริง เพื่อดูว่ามาตรการทำงานครบทั้งระบบหรือไม่
Talvyn Labs ช่วยพัฒนา AI Product ที่แบ่งขอบเขตข้อมูล จำกัดเครื่องมือ มีหน้าตรวจอนุมัติที่เข้าใจได้ และทดสอบจากเอกสารที่ทีมพบจริง นำ Workflow กับคำสั่งที่ต้องการให้ Agent ทำมาเริ่มกำหนดจุดควบคุม เพื่อให้ระบบทำงานที่เป็นประโยชน์ได้โดยไม่ต้องเชื่อทุกประโยคที่อ่านเจอ
เชื่อม Agent กับงานจริงโดยมีขอบเขตที่ตรวจสอบได้
ให้ Talvyn Labs วางสิทธิ์เครื่องมือ การส่งข้อมูล และจุดอนุมัติจาก Workflow ของคุณ พร้อมทดสอบคำสั่งแฝงก่อนเปิดใช้ AI Product
พัฒนา Agent พร้อมจุดควบคุม