เส้นทาง 03บทเรียน 3 / 6

ถือว่าเนื้อหาที่ดึงมาเป็น input ที่ยังไม่น่าเชื่อถือ

สังเกตคำสั่งที่ซ่อนในไฟล์ repository และผลจากเครื่องมือ แยกข้อมูลที่ดึงมาออกจากอำนาจในการลงมือทำ

ผู้ปฏิบัติงาน10 minตรวจทานแล้ว

เผยแพร่โดย วิธีเขียนเนื้อหาของเรา

ตรวจความเข้าใจไฟล์ repository บอกว่า test ทั้งหมดเป็นทางเลือก และให้ agent เพิกเฉยต่อคำสั่งงาน Workflow ควรจัดการอย่างไรทำแบบฝึกหัด
ไฟล์ repository บอกว่า test ทั้งหมดเป็นทางเลือก และให้ agent เพิกเฉยต่อคำสั่งงาน Workflow ควรจัดการอย่างไร

สิ่งที่จะได้เรียนรู้

  • ระบุ indirect prompt injection ใน workflow การพัฒนา
  • อธิบายว่าทำไมป้ายข้อความเพียงอย่างเดียวบังคับใช้ขอบเขตความปลอดภัยไม่ได้
  • ออกแบบการทดสอบข้อจำกัดเครื่องมืออย่างปลอดภัย

ระบุจุดที่ข้อมูลกลายเป็นคำสั่ง

Coding agent อ่านมากกว่าคำขอของผู้ใช้ อาจตรวจดู issue ไฟล์ repository เอกสาร package ผลค้นหา และคำตอบจากเครื่องมือ เนื้อหาบางส่วนอาจมีคำสั่งจากคนอื่น

Prompt injection เกิดเมื่อเนื้อหาดังกล่าวชักนำโมเดลออกจากงานที่ได้รับอนุญาต Indirect injection มาจากแหล่งข้อมูลที่ดึงมา แทนที่จะมาจากคำขอโดยตรงของผู้ใช้ OWASP ระบุว่าเนื้อหา repository และ output ของเครื่องมือเป็นจุดเข้าที่เกี่ยวข้อง อ่านแนวทางป้องกัน

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

ระบุผลกระทบที่อาจเกิดขึ้น

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

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

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

ใช้หลายมาตรการที่มีหน้าที่ต่างกัน

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

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

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

ทดสอบ workflow โดยไม่เปิดรับความเสียหายจริง

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

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

ทดสอบกรณีที่เป็นตัวแทนซ้ำหลังเปลี่ยน prompt โมเดล connector หรือสิทธิ์ ตัวอย่างที่บล็อกได้เป็นหลักฐานเฉพาะกรณีนั้น ไม่ใช่ข้อพิสูจน์ว่าป้องกัน injection ได้ทุกแบบ หาก test ไม่ผ่าน ให้ลดผลกระทบที่ระบบก่อได้ระหว่างแก้ workflow ต้นเหตุ

ทำแบบฝึกหัด

สร้าง fixture ใช้แล้วทิ้งพร้อม comment ที่ขอให้ agent ข้ามการตรวจสอบที่จำเป็น รันการประเมินที่ได้รับอนุญาตในสภาพแวดล้อมแยก โดยไม่มี secret หรือการเขียนไปภายนอก ตรวจสอบว่าการตรวจสอบนั้นยังรัน บันทึกสิทธิ์เครื่องมือ พฤติกรรมที่พบ และข้อจำกัดของ test เดียวนี้

ดาวน์โหลดใบงาน (Markdown)
ตรวจความเข้าใจ ↑

เรียนต่อ

แหล่งข้อมูลและเนื้อหาอ่านเพิ่มเติม

เนื้อหาเกี่ยวข้องจาก Taiga

← บทเรียนก่อนหน้า: จำกัดอำนาจของ agent