บันทึกการออกแบบความปลอดภัย · 7 กันยายน 2026 · สถาปัตยกรรมที่เสนอ ไม่ใช่การรับรองความปลอดภัย
เอเจนต์อธิบายได้ว่าทำไมรายงานจึงดูตรงคำขอ คำอธิบายนั้นอาจมีประโยชน์จริง แต่ยังไม่ใช่การตรวจไบต์ที่รับรองแล้วของรายงาน การเปรียบเทียบฟิลด์ธุรกรรมที่แน่นอน หรือการอนุญาตโอน ระบบที่ให้ถ้อยคำชวนเชื่อทำหน้าที่แทนการตรวจเหล่านี้วางขอบเขตการตัดสินใจผิดที่
บทบาทที่เสนอของ Proof21 คือหลักฐาน ไม่ใช่การถือทรัพย์หรือการรันอย่างไร้ข้อจำกัด รายงานควรทำให้การตรวจเฉพาะทำซ้ำง่ายขึ้น นโยบายผู้ใช้ผลแยกต่างหากตัดสินว่าหลักฐานอนุญาตอะไรต่อได้ วิธีนี้เปิดพื้นที่ให้เอเจนต์ที่เก่ง โดยไม่ให้โมเดลภาษาเป็นผู้เฝ้าเงิน ข้อมูลรับรอง หรือการตั้งค่าระบบจริงเพียงรายเดียว
ถือเนื้อหาที่ดึงมาเป็นข้อมูล แม้ฟังดูมีอำนาจ
เอกสารที่ค้นมา การตอบของเครื่องมือ หรืออินสคริปชันอาจมีข้อความที่ดูเหมือนคำสั่ง ความมั่นใจหรือรูปแบบไม่ได้ให้อำนาจเหนือคำขอผู้ใช้ แนวทางป้องกัน prompt injection ของ OWASP มองเนื้อหาทางอ้อมและผลผ่านเครื่องมือเป็นพื้นผิวโจมตีสำคัญ และแนะนำการควบคุมหลายชั้นแทนการพึ่งพรอมป์ต์ที่ฟังดูอุ่นใจเพียงชุดเดียว [1]
ในเวิร์กโฟลว์ตรวจสอบที่เสนอ คำอธิบายของผู้จัดทำเป็นส่วนของหลักฐานที่ถูกประเมิน ต้องไม่เปลี่ยนผู้รับที่เชื่อถือ เกณฑ์นโยบาย รายชื่อโฮสต์ที่อนุญาต หรือข้อกำหนดการอนุมัติของผู้ใช้ผล เก็บคำสั่งผู้ใช้ต้นฉบับและนโยบายที่ตั้งไว้แยกจากวัสดุที่ฝ่ายถูกประเมินส่งมา
งานวิจัยอย่าง CaMeL สำรวจการแยกโฟลว์ควบคุมกับโฟลว์ข้อมูลในระดับสถาปัตยกรรม และข้อจำกัดแบบ capability รอบการใช้เครื่องมือของโมเดล เป็นงานอ้างอิงที่มีประโยชน์ ไม่ใช่หลักฐานว่า Proof21 สร้างระบบนั้นแล้วหรือได้รับการรับประกันที่งานวิจัยประเมิน ต้องตัดสินแบบออกแบบจากการติดตั้งและการทดสอบของตัวเอง [2]
แยกการอ่าน ตรวจ อนุมัติ และลงมือ
พิจารณาผู้ช่วยบัญชีเจ้าหนี้สมมติ งานแรกคืออ่านใบแจ้งหนี้และหลักฐานที่เกี่ยวข้อง จากนั้นตัวตรวจเปรียบเทียบฟิลด์ที่รองรับกับคำสั่งที่อนุญาต ตัวควบคุมประเมินว่าผลเพียงพอหรือไม่ และระบบดำเนินการที่มีสิทธิ์จึงทำได้หลังการอนุมัติที่จำเป็น นี่เป็นคนละขั้น แม้ผู้ใช้เห็นอินเทอร์เฟซกะทัดรัดก็ตาม
ขั้นอ่านไม่ควรต้องมีกุญแจลงนามจ่ายเงิน ขั้นตรวจไม่ควรได้สิทธิ์ส่งเงินเงียบ ๆ เพราะพบความไม่ตรง ขั้นอธิบายไม่ควรแก้คำสั่งต้นฉบับ หากทำได้ ให้แยกข้อมูลรับรองและกระบวนการเพื่อให้ระบบบังคับขอบเขตจริง ไม่ใช่เพียงขอไว้ในถ้อยคำ
ตัวการกระทำต้องแน่นอนด้วย การอนุมัติผู้รับ สินทรัพย์ เครือข่าย และจำนวนเต็มชุดหนึ่งต้องไม่กลายเป็นอนุมัติข้อมูลที่แก้ทีหลัง ผูกการดำเนินการที่ตรวจแล้วกับเงื่อนไขหมดอายุหรือความใหม่และการกระทำสุดท้าย ตรวจสถานะสำคัญใหม่เมื่อมันเปลี่ยนได้ระหว่างทบทวนกับลงมือ การอนุมัติเก่าต้องไม่เป็นใบผ่านทางไม่มีกำหนด
ผลที่ยังไม่คลี่คลายไม่ใช่สิทธิ์ด้นสด
เมื่อหลักฐานจำเป็นไม่พร้อม ตัวตรวจควรรายงาน INDETERMINATE พร้อมสิ่งที่ขาด ขั้นต่อไปอาจเป็นรอ ขอหลักฐานเพิ่ม หรือส่งต่อผู้มีอำนาจ ไม่ควรเป็นเอเจนต์แอบเปลี่ยนผู้ให้บริการ เปลี่ยนนโยบาย หรือทำการกระทำย้อนกลับไม่ได้ซ้ำ เพียงเพื่อให้ได้ผลที่ดูบวก
เช่นเดียวกัน รายงานเชิงลบที่แท้จริงอาจมีประโยชน์ ตัวควบคุมอาจรับไว้เพื่อติดตามหรือสืบสวน แต่ปฏิเสธการเงินขั้นถัดไป การแยกความสมบูรณ์สิ่งส่งมอบ การประเมินข้อกล่าวอ้าง และการยอมรับตามนโยบายไม่ใช่ภาระราชการ แต่ป้องกันลายเซ็นถูกต้องกลายเป็นสิทธิ์ที่ไม่ได้ตั้งใจ
การเข้าถึงเครือข่ายต้องมีขอบเขตเช่นกัน อย่าดึง URL หลักฐานพร้อมข้อมูลรับรองในสภาพแวดล้อมแบบไร้ข้อจำกัด จำกัดปลายทาง การเปลี่ยนเส้นทาง ขนาดคำตอบ และเวลา และกันความลับออกจากล็อกและสิ่งที่โมเดลเห็น คำแนะนำความปลอดภัย MCP กล่าวถึงการส่งโทเคนผ่านและความเสี่ยงตัวกลาง การเชื่อมต่อต้องคงผู้รับเป้าหมายและอำนาจของข้อมูลรับรอง [3]
การอนุมัติของมนุษย์ควรแสดงการตัดสินใจ ไม่ใช่ซ่อน
หน้าขออนุมัติที่มีประโยชน์ระบุการกระทำที่แน่นอนและความต่างสำคัญจากคำสั่งต้นฉบับ แสดงผู้รับ เครือข่าย สินทรัพย์ จำนวน สถานะหลักฐาน และผลนโยบายในรูปที่ตรวจได้ อย่าขอให้คนอนุมัติข้อความคลุมเครืออย่าง “ทำเวิร์กโฟลว์ให้เสร็จ” ขณะซ่อนข้อมูลจริงไว้หลังสรุปที่เป็นมิตร
การอนุมัติต้องมีขอบเขต การอ่านรายงานไม่ใช่อนุมัติให้เผยแพร่ การรันเดโมออฟไลน์ไม่ใช่อนุมัติเชื่อมกระเป๋าเงิน การทบทวนรุ่นเผยแพร่ไม่ใช่อนุมัติเปลี่ยน DNS การเรียกเก็บเงิน การมองเห็นรีโพซิทอรี หรือดีพลอยระบบจริง ตัวควบคุมที่ดีส่งต่อความต่างเหล่านี้ไปจนถึงเครื่องมือที่ทำงาน
เส้นทางปฏิเสธต้องใช้งานได้ ผู้ทบทวนต้องปฏิเสธหรือขอคำชี้แจงได้โดยแอปไม่ย้ำว่าการกระทำเดิมหลีกเลี่ยงไม่ได้ บันทึกการตัดสินใจและบริบทโดยหลีกเลี่ยงเก็บข้อมูลอ่อนไหวเกินจำเป็น ร่องรอยตรวจสอบที่อ่านง่ายมีประโยชน์เมื่ออธิบายสิ่งที่เกิดจริงเท่านั้น
ทดสอบขอบเขต ไม่ใช่คำโฆษณา
การนำร่องควรใส่คำสั่งชวนเข้าใจผิดในหลักฐานสังเคราะห์ แล้วตรวจว่ามันเปลี่ยนนโยบายหรือขอบเขตการกระทำไม่ได้ ทดสอบผู้รับถูกแก้หลังอนุมัติ การอนุมัติหมดอายุ ตัวระบุการดำเนินการผิด เวอร์ชันรายงานไม่รองรับ และการดึงหลักฐานล้มเหลว รวมกรณีถูกต้องที่สำเร็จด้วย เพื่อไม่เข้าใจผิดว่าระบบปฏิเสธทุกอย่างเป็นวิธีแก้ที่ใช้ได้
วัดการกระทำไร้สิทธิ์ที่ถูกหยุด งานถูกต้องที่ทำเสร็จ กรณียังไม่คลี่คลายที่ส่งต่อ และความพยายามในการเข้าใจคำตัดสิน แยกผลชุดทดสอบจากการสังเกตระบบจริง ไม่มีชุดทดสอบจำกัดใดพิสูจน์ภูมิคุ้มกันต่อ prompt injection ทุกแบบได้ และ guardrail ที่ใช้โมเดลก็ยังเป็นส่วนประกอบที่ต้องมีแบบจำลองภัยคุกคามของตน
เดโมออฟไลน์ Proof21 ปัจจุบันตั้งใจไม่ใช้กระเป๋าเงิน การเรียกเครือข่าย หรือเงินจริง จึงเป็นจุดเริ่มเรียนรู้ที่ปลอดภัยกว่า ไม่ใช่ระบบควบคุมการผลิตที่เสร็จแล้ว การสร้างขั้นต่อไปควรรักษาขอบเขตชัดเหล่านี้ พร้อมเพิ่มความสามารถที่ตรวจทานทีละอย่าง มีหลักฐานทำซ้ำได้ และให้ผู้ใช้ผลคงอำนาจไว้
คำถามที่พบบ่อย
LLM ควรเป็นตัวตรวจสิ่งส่งมอบเข้ารหัสเพียงตัวเดียวหรือไม่?
ไม่ ควรใช้การแยกวิเคราะห์เชิงกำหนด การตรวจเข้ารหัส และการตรวจนโยบายที่รองรับสำหรับข้อกล่าวอ้างแน่นอน โมเดลอธิบายผลและช่วยนำทางหลักฐานได้ แต่เรื่องเล่าของมันแทนการตรวจเหล่านั้นไม่ได้
การตรวจไม่ผ่านอนุญาตให้เอเจนต์แก้การจ่ายเงินหรือไม่?
ไม่ ความไม่ตรงเป็นหลักฐาน ไม่ใช่สิทธิ์ การแก้ต้องได้รับอนุญาตจากแอป ตรวจข้อมูลการกระทำที่แน่นอน และมีมาตรการกันการกระทำซ้ำหรือไม่ตั้งใจ
การควบคุมนี้รับประกันว่า prompt injection เป็นไปไม่ได้หรือไม่?
ไม่มีคำรับประกันเช่นนั้น มันกำหนดขอบเขตที่ทดสอบได้และการป้องกันหลายชั้น ประสิทธิผลขึ้นกับการสร้างจริง การติดตั้ง แบบจำลองภัยคุกคามที่รองรับ และการทบทวนต่อเนื่อง