{
  "schemaVersion": "1.0",
  "type": "research-article",
  "runtimeAvailable": false,
  "id": "proof21:journal:let-agents-explain-let-controls-decide:th",
  "inLanguage": "th",
  "slug": "let-agents-explain-let-controls-decide",
  "title": "ให้เอเจนต์อธิบาย ให้ระบบควบคุมตัดสินใจ",
  "description": "คำอธิบายที่อ่านง่ายมีประโยชน์ แต่สิทธิ์ การตรวจหลักฐาน และการกระทำที่ย้อนกลับไม่ได้ต้องถูกบังคับใช้อย่างชัดเจนนอกเรื่องเล่า",
  "datePublished": "2026-09-07",
  "dateModified": "2026-09-07",
  "url": "https://proof21.xyz/th/journal/let-agents-explain-let-controls-decide/",
  "markdownUrl": "https://proof21.xyz/th/journal/let-agents-explain-let-controls-decide/article.md",
  "markdown": "# ให้เอเจนต์อธิบาย ให้ระบบควบคุมตัดสินใจ\n\n**บันทึกการออกแบบความปลอดภัย · 7 กันยายน 2026 · สถาปัตยกรรมที่เสนอ ไม่ใช่การรับรองความปลอดภัย**\n\nเอเจนต์อธิบายได้ว่าทำไมรายงานจึงดูตรงคำขอ คำอธิบายนั้นอาจมีประโยชน์จริง แต่ยังไม่ใช่การตรวจไบต์ที่รับรองแล้วของรายงาน การเปรียบเทียบฟิลด์ธุรกรรมที่แน่นอน หรือการอนุญาตโอน ระบบที่ให้ถ้อยคำชวนเชื่อทำหน้าที่แทนการตรวจเหล่านี้วางขอบเขตการตัดสินใจผิดที่\n\nบทบาทที่เสนอของ Proof21 คือหลักฐาน ไม่ใช่การถือทรัพย์หรือการรันอย่างไร้ข้อจำกัด รายงานควรทำให้การตรวจเฉพาะทำซ้ำง่ายขึ้น นโยบายผู้ใช้ผลแยกต่างหากตัดสินว่าหลักฐานอนุญาตอะไรต่อได้ วิธีนี้เปิดพื้นที่ให้เอเจนต์ที่เก่ง โดยไม่ให้โมเดลภาษาเป็นผู้เฝ้าเงิน ข้อมูลรับรอง หรือการตั้งค่าระบบจริงเพียงรายเดียว\n\n## ถือเนื้อหาที่ดึงมาเป็นข้อมูล แม้ฟังดูมีอำนาจ\n\nเอกสารที่ค้นมา การตอบของเครื่องมือ หรืออินสคริปชันอาจมีข้อความที่ดูเหมือนคำสั่ง ความมั่นใจหรือรูปแบบไม่ได้ให้อำนาจเหนือคำขอผู้ใช้ แนวทางป้องกัน prompt injection ของ OWASP มองเนื้อหาทางอ้อมและผลผ่านเครื่องมือเป็นพื้นผิวโจมตีสำคัญ และแนะนำการควบคุมหลายชั้นแทนการพึ่งพรอมป์ต์ที่ฟังดูอุ่นใจเพียงชุดเดียว [1]\n\nในเวิร์กโฟลว์ตรวจสอบที่เสนอ คำอธิบายของผู้จัดทำเป็นส่วนของหลักฐานที่ถูกประเมิน ต้องไม่เปลี่ยนผู้รับที่เชื่อถือ เกณฑ์นโยบาย รายชื่อโฮสต์ที่อนุญาต หรือข้อกำหนดการอนุมัติของผู้ใช้ผล เก็บคำสั่งผู้ใช้ต้นฉบับและนโยบายที่ตั้งไว้แยกจากวัสดุที่ฝ่ายถูกประเมินส่งมา\n\nงานวิจัยอย่าง CaMeL สำรวจการแยกโฟลว์ควบคุมกับโฟลว์ข้อมูลในระดับสถาปัตยกรรม และข้อจำกัดแบบ capability รอบการใช้เครื่องมือของโมเดล เป็นงานอ้างอิงที่มีประโยชน์ ไม่ใช่หลักฐานว่า Proof21 สร้างระบบนั้นแล้วหรือได้รับการรับประกันที่งานวิจัยประเมิน ต้องตัดสินแบบออกแบบจากการติดตั้งและการทดสอบของตัวเอง [2]\n\n## แยกการอ่าน ตรวจ อนุมัติ และลงมือ\n\nพิจารณาผู้ช่วยบัญชีเจ้าหนี้สมมติ งานแรกคืออ่านใบแจ้งหนี้และหลักฐานที่เกี่ยวข้อง จากนั้นตัวตรวจเปรียบเทียบฟิลด์ที่รองรับกับคำสั่งที่อนุญาต ตัวควบคุมประเมินว่าผลเพียงพอหรือไม่ และระบบดำเนินการที่มีสิทธิ์จึงทำได้หลังการอนุมัติที่จำเป็น นี่เป็นคนละขั้น แม้ผู้ใช้เห็นอินเทอร์เฟซกะทัดรัดก็ตาม\n\nขั้นอ่านไม่ควรต้องมีกุญแจลงนามจ่ายเงิน ขั้นตรวจไม่ควรได้สิทธิ์ส่งเงินเงียบ ๆ เพราะพบความไม่ตรง ขั้นอธิบายไม่ควรแก้คำสั่งต้นฉบับ หากทำได้ ให้แยกข้อมูลรับรองและกระบวนการเพื่อให้ระบบบังคับขอบเขตจริง ไม่ใช่เพียงขอไว้ในถ้อยคำ\n\nตัวการกระทำต้องแน่นอนด้วย การอนุมัติผู้รับ สินทรัพย์ เครือข่าย และจำนวนเต็มชุดหนึ่งต้องไม่กลายเป็นอนุมัติข้อมูลที่แก้ทีหลัง ผูกการดำเนินการที่ตรวจแล้วกับเงื่อนไขหมดอายุหรือความใหม่และการกระทำสุดท้าย ตรวจสถานะสำคัญใหม่เมื่อมันเปลี่ยนได้ระหว่างทบทวนกับลงมือ การอนุมัติเก่าต้องไม่เป็นใบผ่านทางไม่มีกำหนด\n\n## ผลที่ยังไม่คลี่คลายไม่ใช่สิทธิ์ด้นสด\n\nเมื่อหลักฐานจำเป็นไม่พร้อม ตัวตรวจควรรายงาน `INDETERMINATE` พร้อมสิ่งที่ขาด ขั้นต่อไปอาจเป็นรอ ขอหลักฐานเพิ่ม หรือส่งต่อผู้มีอำนาจ ไม่ควรเป็นเอเจนต์แอบเปลี่ยนผู้ให้บริการ เปลี่ยนนโยบาย หรือทำการกระทำย้อนกลับไม่ได้ซ้ำ เพียงเพื่อให้ได้ผลที่ดูบวก\n\nเช่นเดียวกัน รายงานเชิงลบที่แท้จริงอาจมีประโยชน์ ตัวควบคุมอาจรับไว้เพื่อติดตามหรือสืบสวน แต่ปฏิเสธการเงินขั้นถัดไป การแยกความสมบูรณ์สิ่งส่งมอบ การประเมินข้อกล่าวอ้าง และการยอมรับตามนโยบายไม่ใช่ภาระราชการ แต่ป้องกันลายเซ็นถูกต้องกลายเป็นสิทธิ์ที่ไม่ได้ตั้งใจ\n\nการเข้าถึงเครือข่ายต้องมีขอบเขตเช่นกัน อย่าดึง URL หลักฐานพร้อมข้อมูลรับรองในสภาพแวดล้อมแบบไร้ข้อจำกัด จำกัดปลายทาง การเปลี่ยนเส้นทาง ขนาดคำตอบ และเวลา และกันความลับออกจากล็อกและสิ่งที่โมเดลเห็น คำแนะนำความปลอดภัย MCP กล่าวถึงการส่งโทเคนผ่านและความเสี่ยงตัวกลาง การเชื่อมต่อต้องคงผู้รับเป้าหมายและอำนาจของข้อมูลรับรอง [3]\n\n## การอนุมัติของมนุษย์ควรแสดงการตัดสินใจ ไม่ใช่ซ่อน\n\nหน้าขออนุมัติที่มีประโยชน์ระบุการกระทำที่แน่นอนและความต่างสำคัญจากคำสั่งต้นฉบับ แสดงผู้รับ เครือข่าย สินทรัพย์ จำนวน สถานะหลักฐาน และผลนโยบายในรูปที่ตรวจได้ อย่าขอให้คนอนุมัติข้อความคลุมเครืออย่าง “ทำเวิร์กโฟลว์ให้เสร็จ” ขณะซ่อนข้อมูลจริงไว้หลังสรุปที่เป็นมิตร\n\nการอนุมัติต้องมีขอบเขต การอ่านรายงานไม่ใช่อนุมัติให้เผยแพร่ การรันเดโมออฟไลน์ไม่ใช่อนุมัติเชื่อมกระเป๋าเงิน การทบทวนรุ่นเผยแพร่ไม่ใช่อนุมัติเปลี่ยน DNS การเรียกเก็บเงิน การมองเห็นรีโพซิทอรี หรือดีพลอยระบบจริง ตัวควบคุมที่ดีส่งต่อความต่างเหล่านี้ไปจนถึงเครื่องมือที่ทำงาน\n\nเส้นทางปฏิเสธต้องใช้งานได้ ผู้ทบทวนต้องปฏิเสธหรือขอคำชี้แจงได้โดยแอปไม่ย้ำว่าการกระทำเดิมหลีกเลี่ยงไม่ได้ บันทึกการตัดสินใจและบริบทโดยหลีกเลี่ยงเก็บข้อมูลอ่อนไหวเกินจำเป็น ร่องรอยตรวจสอบที่อ่านง่ายมีประโยชน์เมื่ออธิบายสิ่งที่เกิดจริงเท่านั้น\n\n## ทดสอบขอบเขต ไม่ใช่คำโฆษณา\n\nการนำร่องควรใส่คำสั่งชวนเข้าใจผิดในหลักฐานสังเคราะห์ แล้วตรวจว่ามันเปลี่ยนนโยบายหรือขอบเขตการกระทำไม่ได้ ทดสอบผู้รับถูกแก้หลังอนุมัติ การอนุมัติหมดอายุ ตัวระบุการดำเนินการผิด เวอร์ชันรายงานไม่รองรับ และการดึงหลักฐานล้มเหลว รวมกรณีถูกต้องที่สำเร็จด้วย เพื่อไม่เข้าใจผิดว่าระบบปฏิเสธทุกอย่างเป็นวิธีแก้ที่ใช้ได้\n\nวัดการกระทำไร้สิทธิ์ที่ถูกหยุด งานถูกต้องที่ทำเสร็จ กรณียังไม่คลี่คลายที่ส่งต่อ และความพยายามในการเข้าใจคำตัดสิน แยกผลชุดทดสอบจากการสังเกตระบบจริง ไม่มีชุดทดสอบจำกัดใดพิสูจน์ภูมิคุ้มกันต่อ prompt injection ทุกแบบได้ และ guardrail ที่ใช้โมเดลก็ยังเป็นส่วนประกอบที่ต้องมีแบบจำลองภัยคุกคามของตน\n\nเดโมออฟไลน์ Proof21 ปัจจุบันตั้งใจไม่ใช้กระเป๋าเงิน การเรียกเครือข่าย หรือเงินจริง จึงเป็นจุดเริ่มเรียนรู้ที่ปลอดภัยกว่า ไม่ใช่ระบบควบคุมการผลิตที่เสร็จแล้ว การสร้างขั้นต่อไปควรรักษาขอบเขตชัดเหล่านี้ พร้อมเพิ่มความสามารถที่ตรวจทานทีละอย่าง มีหลักฐานทำซ้ำได้ และให้ผู้ใช้ผลคงอำนาจไว้\n\n## คำถามที่พบบ่อย\n\n### LLM ควรเป็นตัวตรวจสิ่งส่งมอบเข้ารหัสเพียงตัวเดียวหรือไม่?\n\nไม่ ควรใช้การแยกวิเคราะห์เชิงกำหนด การตรวจเข้ารหัส และการตรวจนโยบายที่รองรับสำหรับข้อกล่าวอ้างแน่นอน โมเดลอธิบายผลและช่วยนำทางหลักฐานได้ แต่เรื่องเล่าของมันแทนการตรวจเหล่านั้นไม่ได้\n\n### การตรวจไม่ผ่านอนุญาตให้เอเจนต์แก้การจ่ายเงินหรือไม่?\n\nไม่ ความไม่ตรงเป็นหลักฐาน ไม่ใช่สิทธิ์ การแก้ต้องได้รับอนุญาตจากแอป ตรวจข้อมูลการกระทำที่แน่นอน และมีมาตรการกันการกระทำซ้ำหรือไม่ตั้งใจ\n\n### การควบคุมนี้รับประกันว่า prompt injection เป็นไปไม่ได้หรือไม่?\n\nไม่มีคำรับประกันเช่นนั้น มันกำหนดขอบเขตที่ทดสอบได้และการป้องกันหลายชั้น ประสิทธิผลขึ้นกับการสร้างจริง การติดตั้ง แบบจำลองภัยคุกคามที่รองรับ และการทบทวนต่อเนื่อง\n\n## เอกสารต้นทางและงานวิชาการ\n\n- [1: OWASP — แนวทางป้องกัน LLM Prompt Injection](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)\n- [2: Debenedetti และคณะ — Defeating Prompt Injections by Design](https://arxiv.org/abs/2503.18813)\n- [3: MCP — แนวปฏิบัติความปลอดภัย](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices)\n- [ขอบเขตความปลอดภัย Proof21](https://proof21.xyz/th/docs/protocol/security/)\n- [เดโมออฟไลน์และข้อจำกัด](https://proof21.xyz/th/docs/start/offline-demo/)\n",
  "articleBody": "บันทึกการออกแบบความปลอดภัย · 7 กันยายน 2026 · สถาปัตยกรรมที่เสนอ ไม่ใช่การรับรองความปลอดภัย เอเจนต์อธิบายได้ว่าทำไมรายงานจึงดูตรงคำขอ คำอธิบายนั้นอาจมีประโยชน์จริง แต่ยังไม่ใช่การตรวจไบต์ที่รับรองแล้วของรายงาน การเปรียบเทียบฟิลด์ธุรกรรมที่แน่นอน หรือการอนุญาตโอน ระบบที่ให้ถ้อยคำชวนเชื่อทำหน้าที่แทนการตรวจเหล่านี้วางขอบเขตการตัดสินใจผิดที่ บทบาทที่เสนอของ Proof21 คือหลักฐาน ไม่ใช่การถือทรัพย์หรือการรันอย่างไร้ข้อจำกัด รายงานควรทำให้การตรวจเฉพาะทำซ้ำง่ายขึ้น นโยบายผู้ใช้ผลแยกต่างหากตัดสินว่าหลักฐานอนุญาตอะไรต่อได้ วิธีนี้เปิดพื้นที่ให้เอเจนต์ที่เก่ง โดยไม่ให้โมเดลภาษาเป็นผู้เฝ้าเงิน ข้อมูลรับรอง หรือการตั้งค่าระบบจริงเพียงรายเดียว ถือเนื้อหาที่ดึงมาเป็นข้อมูล แม้ฟังดูมีอำนาจ เอกสารที่ค้นมา การตอบของเครื่องมือ หรืออินสคริปชันอาจมีข้อความที่ดูเหมือนคำสั่ง ความมั่นใจหรือรูปแบบไม่ได้ให้อำนาจเหนือคำขอผู้ใช้ แนวทางป้องกัน prompt injection ของ OWASP มองเนื้อหาทางอ้อมและผลผ่านเครื่องมือเป็นพื้นผิวโจมตีสำคัญ และแนะนำการควบคุมหลายชั้นแทนการพึ่งพรอมป์ต์ที่ฟังดูอุ่นใจเพียงชุดเดียว [1] ในเวิร์กโฟลว์ตรวจสอบที่เสนอ คำอธิบายของผู้จัดทำเป็นส่วนของหลักฐานที่ถูกประเมิน ต้องไม่เปลี่ยนผู้รับที่เชื่อถือ เกณฑ์นโยบาย รายชื่อโฮสต์ที่อนุญาต หรือข้อกำหนดการอนุมัติของผู้ใช้ผล เก็บคำสั่งผู้ใช้ต้นฉบับและนโยบายที่ตั้งไว้แยกจากวัสดุที่ฝ่ายถูกประเมินส่งมา งานวิจัยอย่าง CaMeL สำรวจการแยกโฟลว์ควบคุมกับโฟลว์ข้อมูลในระดับสถาปัตยกรรม และข้อจำกัดแบบ capability รอบการใช้เครื่องมือของโมเดล เป็นงานอ้างอิงที่มีประโยชน์ ไม่ใช่หลักฐานว่า Proof21 สร้างระบบนั้นแล้วหรือได้รับการรับประกันที่งานวิจัยประเมิน ต้องตัดสินแบบออกแบบจากการติดตั้งและการทดสอบของตัวเอง [2] แยกการอ่าน ตรวจ อนุมัติ และลงมือ พิจารณาผู้ช่วยบัญชีเจ้าหนี้สมมติ งานแรกคืออ่านใบแจ้งหนี้และหลักฐานที่เกี่ยวข้อง จากนั้นตัวตรวจเปรียบเทียบฟิลด์ที่รองรับกับคำสั่งที่อนุญาต ตัวควบคุมประเมินว่าผลเพียงพอหรือไม่ และระบบดำเนินการที่มีสิทธิ์จึงทำได้หลังการอนุมัติที่จำเป็น นี่เป็นคนละขั้น แม้ผู้ใช้เห็นอินเทอร์เฟซกะทัดรัดก็ตาม ขั้นอ่านไม่ควรต้องมีกุญแจลงนามจ่ายเงิน ขั้นตรวจไม่ควรได้สิทธิ์ส่งเงินเงียบ ๆ เพราะพบความไม่ตรง ขั้นอธิบายไม่ควรแก้คำสั่งต้นฉบับ หากทำได้ ให้แยกข้อมูลรับรองและกระบวนการเพื่อให้ระบบบังคับขอบเขตจริง ไม่ใช่เพียงขอไว้ในถ้อยคำ ตัวการกระทำต้องแน่นอนด้วย การอนุมัติผู้รับ สินทรัพย์ เครือข่าย และจำนวนเต็มชุดหนึ่งต้องไม่กลายเป็นอนุมัติข้อมูลที่แก้ทีหลัง ผูกการดำเนินการที่ตรวจแล้วกับเงื่อนไขหมดอายุหรือความใหม่และการกระทำสุดท้าย ตรวจสถานะสำคัญใหม่เมื่อมันเปลี่ยนได้ระหว่างทบทวนกับลงมือ การอนุมัติเก่าต้องไม่เป็นใบผ่านทางไม่มีกำหนด ผลที่ยังไม่คลี่คลายไม่ใช่สิทธิ์ด้นสด เมื่อหลักฐานจำเป็นไม่พร้อม ตัวตรวจควรรายงาน INDETERMINATE พร้อมสิ่งที่ขาด ขั้นต่อไปอาจเป็นรอ ขอหลักฐานเพิ่ม หรือส่งต่อผู้มีอำนาจ ไม่ควรเป็นเอเจนต์แอบเปลี่ยนผู้ให้บริการ เปลี่ยนนโยบาย หรือทำการกระทำย้อนกลับไม่ได้ซ้ำ เพียงเพื่อให้ได้ผลที่ดูบวก เช่นเดียวกัน รายงานเชิงลบที่แท้จริงอาจมีประโยชน์ ตัวควบคุมอาจรับไว้เพื่อติดตามหรือสืบสวน แต่ปฏิเสธการเงินขั้นถัดไป การแยกความสมบูรณ์สิ่งส่งมอบ การประเมินข้อกล่าวอ้าง และการยอมรับตามนโยบายไม่ใช่ภาระราชการ แต่ป้องกันลายเซ็นถูกต้องกลายเป็นสิทธิ์ที่ไม่ได้ตั้งใจ การเข้าถึงเครือข่ายต้องมีขอบเขตเช่นกัน อย่าดึง URL หลักฐานพร้อมข้อมูลรับรองในสภาพแวดล้อมแบบไร้ข้อจำกัด จำกัดปลายทาง การเปลี่ยนเส้นทาง ขนาดคำตอบ และเวลา และกันความลับออกจากล็อกและสิ่งที่โมเดลเห็น คำแนะนำความปลอดภัย MCP กล่าวถึงการส่งโทเคนผ่านและความเสี่ยงตัวกลาง การเชื่อมต่อต้องคงผู้รับเป้าหมายและอำนาจของข้อมูลรับรอง [3] การอนุมัติของมนุษย์ควรแสดงการตัดสินใจ ไม่ใช่ซ่อน หน้าขออนุมัติที่มีประโยชน์ระบุการกระทำที่แน่นอนและความต่างสำคัญจากคำสั่งต้นฉบับ แสดงผู้รับ เครือข่าย สินทรัพย์ จำนวน สถานะหลักฐาน และผลนโยบายในรูปที่ตรวจได้ อย่าขอให้คนอนุมัติข้อความคลุมเครืออย่าง “ทำเวิร์กโฟลว์ให้เสร็จ” ขณะซ่อนข้อมูลจริงไว้หลังสรุปที่เป็นมิตร การอนุมัติต้องมีขอบเขต การอ่านรายงานไม่ใช่อนุมัติให้เผยแพร่ การรันเดโมออฟไลน์ไม่ใช่อนุมัติเชื่อมกระเป๋าเงิน การทบทวนรุ่นเผยแพร่ไม่ใช่อนุมัติเปลี่ยน DNS การเรียกเก็บเงิน การมองเห็นรีโพซิทอรี หรือดีพลอยระบบจริง ตัวควบคุมที่ดีส่งต่อความต่างเหล่านี้ไปจนถึงเครื่องมือที่ทำงาน เส้นทางปฏิเสธต้องใช้งานได้ ผู้ทบทวนต้องปฏิเสธหรือขอคำชี้แจงได้โดยแอปไม่ย้ำว่าการกระทำเดิมหลีกเลี่ยงไม่ได้ บันทึกการตัดสินใจและบริบทโดยหลีกเลี่ยงเก็บข้อมูลอ่อนไหวเกินจำเป็น ร่องรอยตรวจสอบที่อ่านง่ายมีประโยชน์เมื่ออธิบายสิ่งที่เกิดจริงเท่านั้น ทดสอบขอบเขต ไม่ใช่คำโฆษณา การนำร่องควรใส่คำสั่งชวนเข้าใจผิดในหลักฐานสังเคราะห์ แล้วตรวจว่ามันเปลี่ยนนโยบายหรือขอบเขตการกระทำไม่ได้ ทดสอบผู้รับถูกแก้หลังอนุมัติ การอนุมัติหมดอายุ ตัวระบุการดำเนินการผิด เวอร์ชันรายงานไม่รองรับ และการดึงหลักฐานล้มเหลว รวมกรณีถูกต้องที่สำเร็จด้วย เพื่อไม่เข้าใจผิดว่าระบบปฏิเสธทุกอย่างเป็นวิธีแก้ที่ใช้ได้ วัดการกระทำไร้สิทธิ์ที่ถูกหยุด งานถูกต้องที่ทำเสร็จ กรณียังไม่คลี่คลายที่ส่งต่อ และความพยายามในการเข้าใจคำตัดสิน แยกผลชุดทดสอบจากการสังเกตระบบจริง ไม่มีชุดทดสอบจำกัดใดพิสูจน์ภูมิคุ้มกันต่อ prompt injection ทุกแบบได้ และ guardrail ที่ใช้โมเดลก็ยังเป็นส่วนประกอบที่ต้องมีแบบจำลองภัยคุกคามของตน เดโมออฟไลน์ Proof21 ปัจจุบันตั้งใจไม่ใช้กระเป๋าเงิน การเรียกเครือข่าย หรือเงินจริง จึงเป็นจุดเริ่มเรียนรู้ที่ปลอดภัยกว่า ไม่ใช่ระบบควบคุมการผลิตที่เสร็จแล้ว การสร้างขั้นต่อไปควรรักษาขอบเขตชัดเหล่านี้ พร้อมเพิ่มความสามารถที่ตรวจทานทีละอย่าง มีหลักฐานทำซ้ำได้ และให้ผู้ใช้ผลคงอำนาจไว้ คำถามที่พบบ่อย LLM ควรเป็นตัวตรวจสิ่งส่งมอบเข้ารหัสเพียงตัวเดียวหรือไม่? ไม่ ควรใช้การแยกวิเคราะห์เชิงกำหนด การตรวจเข้ารหัส และการตรวจนโยบายที่รองรับสำหรับข้อกล่าวอ้างแน่นอน โมเดลอธิบายผลและช่วยนำทางหลักฐานได้ แต่เรื่องเล่าของมันแทนการตรวจเหล่านั้นไม่ได้ การตรวจไม่ผ่านอนุญาตให้เอเจนต์แก้การจ่ายเงินหรือไม่? ไม่ ความไม่ตรงเป็นหลักฐาน ไม่ใช่สิทธิ์ การแก้ต้องได้รับอนุญาตจากแอป ตรวจข้อมูลการกระทำที่แน่นอน และมีมาตรการกันการกระทำซ้ำหรือไม่ตั้งใจ การควบคุมนี้รับประกันว่า prompt injection เป็นไปไม่ได้หรือไม่? ไม่มีคำรับประกันเช่นนั้น มันกำหนดขอบเขตที่ทดสอบได้และการป้องกันหลายชั้น ประสิทธิผลขึ้นกับการสร้างจริง การติดตั้ง แบบจำลองภัยคุกคามที่รองรับ และการทบทวนต่อเนื่อง เอกสารต้นทางและงานวิชาการ 1: OWASP — แนวทางป้องกัน LLM Prompt Injection 2: Debenedetti และคณะ — Defeating Prompt Injections by Design 3: MCP — แนวปฏิบัติความปลอดภัย ขอบเขตความปลอดภัย Proof21 เดโมออฟไลน์และข้อจำกัด",
  "citations": [
    "https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html",
    "https://arxiv.org/abs/2503.18813",
    "https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices"
  ],
  "faq": [
    {
      "question": "LLM ควรเป็นตัวตรวจสิ่งส่งมอบเข้ารหัสเพียงตัวเดียวหรือไม่?",
      "answer": "ไม่ ควรใช้การแยกวิเคราะห์เชิงกำหนด การตรวจเข้ารหัส และการตรวจนโยบายที่รองรับสำหรับข้อกล่าวอ้างแน่นอน โมเดลอธิบายผลและช่วยนำทางหลักฐานได้ แต่เรื่องเล่าของมันแทนการตรวจเหล่านั้นไม่ได้"
    },
    {
      "question": "การตรวจไม่ผ่านอนุญาตให้เอเจนต์แก้การจ่ายเงินหรือไม่?",
      "answer": "ไม่ ความไม่ตรงเป็นหลักฐาน ไม่ใช่สิทธิ์ การแก้ต้องได้รับอนุญาตจากแอป ตรวจข้อมูลการกระทำที่แน่นอน และมีมาตรการกันการกระทำซ้ำหรือไม่ตั้งใจ"
    },
    {
      "question": "การควบคุมนี้รับประกันว่า prompt injection เป็นไปไม่ได้หรือไม่?",
      "answer": "ไม่มีคำรับประกันเช่นนั้น มันกำหนดขอบเขตที่ทดสอบได้และการป้องกันหลายชั้น ประสิทธิผลขึ้นกับการสร้างจริง การติดตั้ง แบบจำลองภัยคุกคามที่รองรับ และการทบทวนต่อเนื่อง"
    }
  ],
  "sourceSha256": "620bfa2b797d21c7230f5cf6c3bec6e064f078da92d3ed80a4218d1d8039fddd",
  "markdownSha256": "f39104c1a1dfe0680aa466f043db7ebdcb9fb1385d855b2c84abd8a4e92d7764",
  "translationReview": "คำแปลภาษาไทยฉบับเต็มจัดเตรียมด้วย AI และยังไม่ได้รับการทบทวนทางเทคนิคโดยผู้เชี่ยวชาญภาษาไทยอิสระ หากมีความกำกวมให้ยึดข้อกำหนดภาษาอังกฤษ โค้ด ฟิลด์ และสิทธิ์ไม่เปลี่ยนตามภาษา",
  "image": {
    "url": "https://proof21.xyz/assets/journal/controls.png",
    "caption": "เส้นทางที่มีขอบเขตผ่านประตูควบคุมแยกต่างหาก ภาพแทนขอบเขตการอนุญาต ไม่ใช่คำรับประกันว่าโมเดลถูกชักจูงไม่ได้",
    "sha256": "c913abbd7a46f1fb738f737ea2b8ed40f5e7d6f6b90f5aae228d4b5f46563a39"
  },
  "motion": {
    "url": "https://proof21.xyz/assets/journal/controls.mp4",
    "engine": "Remotion",
    "sourceSha256": "13a909f4267d8147386045cbd90df732a42679342c16e04c5725e09e953d3728",
    "sha256": "f3dd827ef5b2c1e4be140bf39b779e01db82ac23f4aaf058d43e92265d6d22d8",
    "seconds": 7.2,
    "loop": true,
    "audio": false
  },
  "availableLanguages": [
    "en",
    "zh-Hans",
    "th",
    "ar"
  ],
  "editions": {
    "en": "https://proof21.xyz/journal/let-agents-explain-let-controls-decide/",
    "zh-Hans": "https://proof21.xyz/zh-hans/journal/let-agents-explain-let-controls-decide/",
    "th": "https://proof21.xyz/th/journal/let-agents-explain-let-controls-decide/",
    "ar": "https://proof21.xyz/ar/journal/let-agents-explain-let-controls-decide/"
  }
}