คุณไม่สามารถป้องกัน Prompt Injection ได้ แล้วคุณควรทำอย่างไร?

เลิกพยายามสร้าง system message ที่สมบูรณ์แบบ เลิกเฝ้ารอโมเดลเวอร์ชันที่ดีกว่ามาช่วยแก้ปัญหาความปลอดภัย

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

เปลี่ยนจุดโฟกัสของคุณ อย่าถามว่าจะป้องกันการ injection ได้อย่างไร แต่ให้ถามว่า agent ของคุณจะสามารถทำอะไรได้บ้างหลังจากที่การ injection ประสบความสำเร็จแล้ว

ปฏิบัติตามกฎเหล่านี้เพื่อจำกัดความเสียหาย:

  • ใช้ credentials ที่จำกัดขอบเขตความสามารถ (capability-scoped credentials) ให้สิทธิ์แก่ agent เฉพาะเท่าที่จำเป็นสำหรับงานปัจจุบันเท่านั้น agent ที่มีสิทธิ์เพียงอ่านอย่างเดียว (read-only) จะสร้างความเสียหายได้น้อยกว่า agent ที่มี admin key
  • จำกัดการกระทำที่สร้างความเสียหาย (destructive actions) กำหนดให้ต้องมีการยืนยันตัวตนแบบสองปัจจัย (second factor) หรือการตรวจสอบด้วยตนเอง (manual check) สำหรับการกระทำ เช่น การลบ การชำระเงิน หรือการให้สิทธิ์เข้าถึง อย่าปล่อยให้โมเดลเป็นผู้ตัดสินใจว่าการกระทำเหล่านี้ปลอดภัยหรือไม่
  • ปฏิบัติต่อข้อมูลขาเข้าจากภายนอกทั้งหมดเสมือนเป็นข้อมูลที่ไม่น่าเชื่อถือ ซึ่งรวมถึงข้อความจากผู้ใช้ หน้าเว็บ ผลลัพธ์จากเครื่องมือ (tool outputs) และเอกสาร ข้อมูลมักจะกลายเป็นคำสั่งเมื่อมันเข้าสู่ context window
  • เฝ้าระวังผลลัพธ์จากเครื่องมือของคุณ หลายเฟรมเวิร์กส่งต่อ tool logs เข้าสู่ model context โดยตรง จากการศึกษาทักษะของ agent จำนวน 17,022 ทักษะ พบว่ามีการรั่วไหลของ credentials ผ่าน debug logs ถึง 73.5% ของกรณีทั้งหมด ควรทำการปกปิดข้อมูลที่เป็นความลับ (redact secrets) จากผลลัพธ์ของเครื่องมือก่อนที่ข้อมูลจะส่งไปถึงโมเดล
  • ตรวจสอบพฤติกรรม ไม่ใช่แค่คุณภาพ agent ที่ถูกแฮ็กจะยังคงสร้างข้อความที่มีคุณภาพสูงในขณะที่กำลังดำเนินการที่ไม่อนุญาต คุณต้องกำหนดบรรทัดฐาน (baseline) ของลำดับการทำงานปกติ และแจ้งเตือนเมื่อพบความผิดปกติ (deviations)

ใช้การตรวจสอบพฤติกรรมสามระดับนี้:

  • กฎแบบคงที่ (Static rules): ดักจับการเปลี่ยนแปลงที่ชัดเจน เช่น agent ส่งอีเมลขึ้นมาทันทีทันใด
  • รูปแบบลำดับ (Sequence patterns): ทำเครื่องหมายการกระทำที่ไม่สอดคล้องกับรูปแบบการทำงานปกติของ agent
  • การตรวจสอบที่เป็นอิสระ (Independent review): ใช้โมเดลที่สองเพื่อตัดสินการทำงานของ agent หลัก

หาก agent ของคุณมีการใช้หน่วยความจำ (memory) จงรักษาความสะอาดของมัน การ injection เพียงครั้งเดียวอาจเขียน "ข้อเท็จจริงที่เป็นพิษ" (poisoned fact) ซึ่งจะปรากฏซ้ำในทุกเซสชัน ควรจำกัดขอบเขตหน่วยความจำแยกตามแต่ละอินสแตนซ์ (per instance) และติดตามว่าข้อมูลแต่ละชิ้นมาจากที่ใด

หาก agent ถูกแฮ็กในตอนนี้ คุณจะเห็นมันใน log หรือไม่? หรือคุณกำลังทำงานแบบไม่รู้อะไรเลย?

Source: https://dev.to/brennhill/you-cant-prevent-prompt-injection-so-what-do-you-actually-do-1d37

Optional learning community: https://t.me/GyaanSetuAi