วาง Guardrail ให้ AI agent ผิดชั้น เครื่องมืออาจทำงานก่อนถูกสกัด

|ผู้เขียน: กองบรรณาธิการ QUASA|2 นาทีในการอ่าน
วาง Guardrail ให้ AI agent ผิดชั้น เครื่องมืออาจทำงานก่อนถูกสกัด

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

ตาม คู่มือ guardrails ของ OpenAI Agents SDK การตรวจอินพุตระดับเอเจนต์ใช้กับเอเจนต์ตัวแรก การตรวจเอาต์พุตใช้กับตัวที่สร้างคำตอบสุดท้าย และโหมดตรวจอินพุตแบบขนานซึ่งเป็นค่าเริ่มต้นอาจปล่อยให้เครื่องมือทำงานก่อนผลตรวจสั่งหยุด หากเงื่อนไขใดต้องหยุดงานก่อนเริ่ม ให้ใช้การตรวจอินพุตแบบบล็อกด้วย run_in_parallel=False; สำหรับ FunctionTool ที่ติดตั้ง tool guardrail ให้ตรวจคำสั่งก่อนเครื่องมือทำงานทุกครั้งที่เรียกใช้ กลไก tool guardrail นี้ไม่ครอบคลุม hosted tools และ built-in execution tools จึงต้องตรวจทางผ่านและสิทธิ์ของเครื่องมือเหล่านั้นแยกต่างหาก

จุดตรวจแต่ละชั้นหยุดอะไรได้

คำอธิบาย rail ของ NVIDIA NeMo Guardrails แยกจุดตรวจเป็น input, retrieval, dialog, execution และ output ตามช่วงของงาน การแบ่งนี้ช่วยตอบคำถามสำคัญกว่าการนับจำนวนกฎ: ข้อมูลหรือการกระทำใดจะผ่านจุดตรวจไปแล้วเมื่อกฎตัดสินว่าไม่อนุญาต

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

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

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

จับคู่ผลกระทบกับจุดบล็อก

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

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

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

ลำดับตัวอย่างจากคำขอถึงการลงมือ

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

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

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

บังคับสิทธิ์ที่ทางผ่านของเครื่องมือ

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

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

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

เช็กลิสต์ทดสอบว่าบล็อกทันจังหวะหรือไม่

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

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

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

แชร์:

สมัครรับจดหมายข่าวของเรา

รับข่าวสารล่าสุดเกี่ยวกับ Web3, AI และคริปโตส่งตรงถึงกล่องจดหมายของคุณ

0