Microsoft ปล่อยพิมพ์เขียว agent ที่ต้องขออนุญาตก่อนลงมือ — แยก tool อ่านออกจาก tool เขียน แล้วบังคับให้คนกดยืนยันทุกครั้งที่จะเปลี่ยนอะไร

คำถามที่ทีมองค์กรทุกทีมติดอยู่ตอนจะเอา agent ไปแตะระบบจริงคือคำถามเดียวกัน — จะให้มันทำอะไรเองได้แค่ไหน วันที่ 3 สิงหาคม 2026 Ricardo M. Martins (Principal Solutions Engineer) เขียนลงบล็อก All things Azure ของ Microsoft ตอบคำถามนี้ด้วยของที่จับต้องได้: สถาปัตยกรรมเต็มของ ops assistant พร้อมรีโปที่โคลนไปรันได้

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

หลักการเดียวที่คุมทั้งระบบ: แยกอ่านออกจากเขียน

การออกแบบทั้งหมดวางอยู่บนกฎข้อเดียว — tool ที่อ่านอย่างเดียวทำงานทันที ส่วน tool ที่เปลี่ยนอะไรก็ตาม (เช่น สร้าง incident) ไม่ทำงานเอง แต่ผลิต “pending action” ที่รอให้ผู้ใช้กดยืนยัน

ที่น่าสนใจคือรายละเอียดของขั้นตอนยืนยัน ซึ่งเป็นจุดที่ระบบส่วนใหญ่ทำพลาด บทความระบุ invariant ไว้ชัดสี่ข้อ:

1. backend รัน payload ที่เก็บไว้ ไม่ใช่ payload ที่ client ส่งมาตอนกดยืนยัน — ถ้าพลาดข้อนี้ ปุ่มยืนยันจะกลายเป็นแค่พิธีกรรม เพราะผู้โจมตีเปลี่ยนเนื้อหาตอนยืนยันได้
2. ผู้ที่กดยืนยันต้องเป็นคนเดียวกับผู้สร้าง action นั้น
3. เฉพาะ action ที่อยู่ในสถานะ pending เท่านั้นที่รันได้
4. action ID ทำหน้าที่เป็น idempotency key ข้าม retry ทั้งหมด

ภายในโปรเซสมี atomic lock กันสภาวะแข่งขันตอนพลิกสถานะจาก pending เป็น executing และผลลัพธ์ถูก cache ด้วย action ID

ฝั่งตัวตน ระบบใช้ authentication ในตัวของ Azure Container Apps ผูกกับ Microsoft Entra ID ซึ่งตรวจ token ก่อนคำขอจะถึงแอปด้วยซ้ำ แล้วอ่าน principal ID จากเฮดเดอร์ X-MS-CLIENT-PRINCIPAL-ID — ผู้เขียนเลือกใช้ principal ID เป็นตัวระบุตัวตนที่เสถียร เพราะ token แบบ app-only ไม่มีชื่อผู้ใช้ ประวัติสนทนาถูกจำกัดขอบเขตด้วยคู่ {actor_id}:{session_id} และ ถ้าไม่มีตัวตนติดมาเลย ในโปรดักชันจะตอบ 401 ทันที ไม่มีการเดา

เรื่อง credential เขาใช้ ManagedIdentityCredential บน Azure และ DefaultAzureCredential ตอนรันในเครื่อง โดยปิด local auth ทั้งบน Azure OpenAI และ Azure AI Search — ไม่มี API key ทั้งในโค้ดและใน environment variable

กับดักจริงที่คนทำ RAG เจอ: HTTP 207

ส่วนที่ผมคิดว่ามีค่าที่สุดสำหรับคนลงมือทำคือหัวข้อนี้ เพราะมันเป็นบั๊กที่เงียบและเจ็บ

ตอน ingest เอกสารเข้า Azure AI Search แบบ batch API จะคืน HTTP 207 เมื่อบางรายการสำเร็จและบางรายการล้มเหลว โค้ดที่เขียนตามสัญชาตญาณคือเรียก raise_for_status() แล้วถือว่าจบ — ซึ่ง จะมองไม่เห็น partial failure เลย เพราะ 207 ไม่ใช่สถานะ error ผลคือ index ที่ไม่ครบโดยที่ไม่มีใครรู้ และ RAG ที่ตอบผิดเพราะเอกสารหายไปเงียบ ๆ วิธีที่ถูกคือไล่ดูผลลัพธ์รายรายการ ไม่ใช่เชื่อสถานะรวม

ฝั่ง retrieval เขาใช้ text-embedding-3-small ที่ 1,536 มิติ ค้นแบบผสมทั้ง lexical และ vector แล้วผ่าน semantic ranking โดยตั้ง k=50 เพื่อให้ ranker ได้ผู้สมัครกว้าง ๆ แต่ส่งเข้าโมเดลแค่ 3 เอกสาร เพื่อกัน prompt บวม — เป็นการตั้งค่าที่สมเหตุสมผลและมักตั้งผิดกันเยอะ

แยก audit ออกจาก telemetry

อีกจุดที่ออกแบบมาดีคือการแยกสองสายข้อมูลออกจากกัน Telemetry ไปที่ Application Insights ด้วย custom span รอบ ๆ คำขอแชต การค้น RAG และการรัน tool โดย จงใจไม่เก็บข้อความของผู้ใช้ เพื่อลดการรั่วของรายละเอียดการปฏิบัติงาน ส่วน audit stream เป็นคนละสายกัน บันทึกเหตุการณ์ pending_action_created, pending_action_confirmed และ pending_action_result พร้อม actor และ action ID

ผู้เขียนเสนอให้ตั้ง retention policy ของสองสายนี้ต่างกัน ซึ่งถูกต้อง — trace ไว้ debug เก็บสั้นได้ ส่วน audit คือหลักฐานว่าใครอนุมัติอะไร ต้องเก็บยาว

สิ่งที่บทความบอกเองว่ายังไม่มี

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

ในกลไกอนุมัติเอง: ไม่มีวันหมดอายุของ pending action, ยกเลิกไม่ได้, ไม่มีการป้องกัน CSRF และไม่มี step-up authentication สำหรับงานความเสี่ยงสูง — ข้อแรกกับข้อสุดท้ายคือช่องโหว่ที่ต้องอุดก่อนใช้จริง เพราะ action ที่ค้างอยู่ได้ตลอดกาลคือระเบิดเวลา และการอนุมัติรีสตาร์ตเซิร์ฟเวอร์ไม่ควรใช้ระดับการยืนยันตัวตนเท่ากับการอ่านรายงาน

นอกกลไกอนุมัติ ที่ยังไม่มีคือ replica เดียวเก็บ state ในหน่วยความจำ, metrics และ ITSM adapter ยัง mock อยู่, ไม่มี memory ระยะยาว, ไม่มี access control ระดับเอกสาร และไม่มี rate limiting

การขาด access control ระดับเอกสารเป็นข้อที่ต้องระวังที่สุด เพราะระบบนี้ตรวจตัวตนของผู้ใช้อย่างเข้มงวดตอนอนุมัติ แต่ RAG ยังดึงจาก index เดียวกันให้ทุกคน — แปลว่าคนที่ไม่ควรเห็น runbook บางฉบับก็ยังเห็นผ่านคำตอบได้อยู่ดี

โค้ดอยู่ที่รีโป ricmmartins/agentic-infra-handbook ใต้ labs/personal-assistant มี fake mode ที่รันด้วย Python 3.12 โดยไม่ต้องมี Azure subscription และมี Bicep template ให้สำหรับคนที่จะ deploy จริง

มุมมอง AI Curator

ปี 2026 เป็นปีที่วงการเลิกเถียงว่า agent ทำงานได้ไหม แล้วย้ายไปเถียงว่า จะให้มันทำงานโดยไม่ต้องเชื่อใจมันได้ยังไง บทความนี้อยู่ในกระแสเดียวกับหลายเรื่องที่เราเขียนถึงเดือนนี้ ทั้ง worm ใน Word ที่ Copilot รันคำสั่งซ่อนในเอกสาร และ CVE ปลอมที่ไหลผ่านระบบซึ่งไม่มีใครตรวจ — บทเรียนร่วมคือปัญหาไม่ได้อยู่ที่โมเดลฉลาดพอหรือยัง แต่อยู่ที่เราสร้างระบบที่รับผลลัพธ์ของมันไปทำต่อโดยไม่มีด่าน

จุดที่ผมคิดว่าคุ้มค่าที่สุดและถอดไปใช้ได้ทันทีโดยไม่ต้องใช้ Azure เลยคือ invariant ข้อแรก — backend ต้องรัน payload ที่เก็บไว้ ไม่ใช่ที่ client ส่งกลับมา ผมเห็นทีมจำนวนมากทำ human-in-the-loop โดยส่ง action กลับไปให้หน้าเว็บแล้วรับกลับมาตอนกด confirm ซึ่งเท่ากับ ย้ายการตัดสินใจไปไว้ฝั่งที่ควบคุมไม่ได้ ปุ่ม “ยืนยัน” ที่ออกแบบแบบนั้นไม่ได้เพิ่มความปลอดภัยแม้แต่นิดเดียว มันแค่ทำให้รู้สึกปลอดภัย นี่เป็นบทเรียนที่ไม่ขึ้นกับคลาวด์เจ้าไหน จะใช้ AWS, GCP หรือรันเองก็ต้องทำเหมือนกัน

สำหรับบริบทไทย เรื่องนี้มาถูกจังหวะกับสิ่งที่กำลังเกิดจริง องค์กรใหญ่บ้านเรา — แบงก์ โรงพยาบาล โทรคมนาคม — กำลังทดลองเอา agent ไปช่วยงาน ops และ helpdesk กันเป็นแถว และสิ่งที่ทำให้โครงการเหล่านี้ตายในชั้น audit ไม่ใช่ความแม่นยำของโมเดล แต่คือคำถามว่า “ตอนระบบทำอะไรผิด ใครรับผิดชอบ และพิสูจน์ยังไงว่าใครอนุมัติ” โครงสร้าง audit stream ที่แยกจาก telemetry พร้อม actor ID ต่อทุกเหตุการณ์ คือคำตอบสำหรับคำถามนั้นในรูปแบบที่ผู้ตรวจสอบเข้าใจได้ — ทีมไทยที่จะเสนอโครงการ agent ให้ผ่าน compliance ควรออกแบบส่วนนี้ตั้งแต่วันแรก ไม่ใช่ไปเติมทีหลัง เพราะการย้อนกลับไปใส่ audit trail ในระบบที่สร้างเสร็จแล้วแทบจะแปลว่าเขียนใหม่

ข้อสังเกตสุดท้าย — การที่ Microsoft เผยแพร่ต้นแบบพร้อมรายการข้อบกพร่องของตัวเองยาวเหยียด เป็นสิ่งที่ควรชม แต่ก็เป็นเหตุผลที่ต้องอ่านให้ครบ มันคือแบบร่างสถาปัตยกรรม ไม่ใช่ของที่โคลนแล้วขึ้นโปรดักชันได้ ใครที่หยิบรีโปนี้ไปแล้วข้ามหัวข้อ “สิ่งที่ยังไม่มี” จะได้ระบบที่มีปุ่มอนุมัติสวยงามแต่ยัง deploy ด้วย replica เดียวที่เก็บ state ในหน่วยความจำ — พอ container รีสตาร์ต pending action หายเกลี้ยง

แหล่งข่าว

• Building an operations assistant on Azure that waits for approval before it acts — Microsoft All things Azure, Ricardo M. Martins (3 ส.ค. 2026)
• ricmmartins/agentic-infra-handbook — labs/personal-assistant (โค้ดและ Bicep template)
• เอกสาร Azure Container Apps authentication (Entra ID)