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

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

ผู้ช่วยควรได้รับอนุญาตให้ทำอะไรบ้าง

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

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

แต่ละความสามารถใช้ข้อมูลใดได้

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

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

ตัวตน เครื่องมือ และสิทธิ์ควรบังคับใช้ขอบเขตอย่างไร

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

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

บทสนทนาอาจต่อเนื่องเป็นเรื่องเดียว แต่อำนาจของมันควรถูกแบ่งเป็นความสามารถเล็ก ๆ ที่บังคับใช้แยกจากกัน

แต่ละความสามารถควรลงมือได้ไกลเพียงใด

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

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

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

เมื่อผู้ช่วยชนขอบเขตควรเกิดอะไรขึ้น

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

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

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

ทีมจะเปลี่ยนขอบเขตให้เป็นแบบปฏิบัติการได้อย่างไร

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

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

ต้องมีหลักฐานใดก่อนเปิดใช้และระหว่างให้บริการ

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

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

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