Guardrails และ Human-in-the-loop: ให้ Agent ทำงานแบบปลอดภัย

รู้จักความเสี่ยง Excessive Agency, Prompt Injection และ Lethal Trifecta พร้อมวิธีวางชั้นป้องกันและขั้นอนุมัติที่ไม่กลายเป็นคอขวด

ฝ่ายบัญชีของบริษัทจัดจำหน่ายแห่งหนึ่งอยากให้ AI Agent ช่วยงานเจ้าหนี้: อ่านใบแจ้งหนี้ที่ส่งเข้าอีเมล เทียบกับใบสั่งซื้อใน ERP แล้วตั้งรายการจ่ายเงิน ฟังดูประหยัดเวลามาก จนมีคนถามคำถามที่ควรถามตั้งแต่แรก: "ถ้ามีอีเมลปลอมแนบใบแจ้งหนี้ที่เขียนคำสั่งแฝงให้ Agent เปลี่ยนเลขบัญชีผู้รับเงินล่ะ" คำตอบของคำถามนี้คือเรื่องของ Guardrails และ Human-in-the-loop

Guardrails และ Human-in-the-loop คืออะไร

Guardrails คือชั้นป้องกันที่จำกัดว่า Agent รับอะไรเข้า ทำอะไรได้ และส่งอะไรออก ส่วน Human-in-the-loop (HITL) คือการออกแบบให้คนตัดสินใจในจุดที่เสี่ยง ก่อนที่ Agent จะทำสิ่งที่ย้อนกลับไม่ได้ ทั้งสองอย่างไม่ได้มาแทนกัน แต่ทำงานคู่กัน

ความเสี่ยงที่ต้องรู้จักก่อนออกแบบ

Excessive Agency

OWASP Top 10 for LLM Applications ปี 2025 จัด Excessive Agency ไว้เป็นข้อ LLM06 และระบุต้นเหตุ 3 อย่าง: เครื่องมือมีฟังก์ชันเกินจำเป็น สิทธิ์เกินจำเป็น และความเป็นอิสระเกินจำเป็น คือทำโดยไม่มีการตรวจสอบเพียงพอ

Prompt Injection

ข้อ LLM01 ในรายการเดียวกันคือ Prompt Injection ข้อความที่ Agent อ่าน เช่น หน้าเว็บ อีเมล หรือไฟล์แนบ อาจมีคำสั่งแฝงที่หลอกให้ Agent ทำตาม

The Lethal Trifecta

Simon Willison นักพัฒนาที่เขียนเรื่องความปลอดภัยของ LLM มาต่อเนื่อง สรุปไว้ในบทความเดือนมิถุนายน 2025 ว่า Agent อันตรายเมื่อมี 3 อย่างพร้อมกัน: เข้าถึงข้อมูลส่วนตัว ได้รับเนื้อหาที่ไม่น่าเชื่อถือ และสื่อสารออกภายนอกได้ เขายังเตือนว่าเครื่องมือกันการโจมตีที่จับได้ 95% ฟังดูดี แต่ในโลก web security นั่นถือว่า "สอบตก"

Agent เจ้าหนี้ในตัวอย่างของเรามีครบทั้ง 3 อย่าง: เห็นข้อมูลบัญชีบริษัท อ่านอีเมลจากภายนอก และส่งคำสั่งจ่ายเงินได้

วางชั้นป้องกันแบบหลายชั้น

1. จำกัดเครื่องมือและสิทธิ์: Agent อ่าน ERP ได้ แต่แก้ข้อมูลผู้ขายไม่ได้ ใช้ API key ที่สิทธิ์แคบที่สุด
2. แยกข้อมูลที่ไม่น่าเชื่อถือ: ข้อความจากอีเมลภายนอกถือเป็นข้อมูล ไม่ใช่คำสั่ง และไม่ควรเปลี่ยนเลขบัญชีจากเนื้อหาอีเมลเด็ดขาด
3. ตรวจผลลัพธ์ด้วยกฎ: ยอดเงินต้องตรงกับใบสั่งซื้อ เลขบัญชีต้องตรงกับข้อมูลผู้ขายที่ลงทะเบียนไว้ ถ้าไม่ตรงให้หยุด
4. ให้คนอนุมัติงานเสี่ยงสูง: การจ่ายเงินทุกรายการต้องผ่านคน
5. เก็บ log ทุกการกระทำ: เพื่อย้อนตรวจได้ว่าใครอนุมัติอะไร

ออกแบบ Human-in-the-loop ให้ไม่เป็นคอขวด

ถ้าให้คนกดอนุมัติทุกอย่าง ทีมจะเหนื่อยและเริ่มกดผ่านโดยไม่อ่าน วิธีที่ดีกว่าคือแบ่งตามระดับความเสี่ยง

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

เครื่องมือ no-code อย่าง n8n รองรับแนวนี้แล้ว: เอกสารของ n8n อธิบายว่าเมื่อ AI Agent จะใช้ tool ที่ตั้งให้ต้องรีวิว workflow จะหยุดรอคน ผู้อนุมัติเห็นว่า AI จะเรียก tool ไหนด้วยค่าอะไร และอนุมัติผ่านช่องทางอย่าง Slack, Microsoft Teams หรือ Gmail ถ้าปฏิเสธ action จะถูกยกเลิกและ AI ได้รับแจ้ง n8n ยังแนะนำให้เริ่มจากเปิดการรีวิวไว้ก่อน แล้วค่อยลดลงเมื่อมั่นใจ

ฝั่งผลิตภัณฑ์ใหญ่ก็ใช้แนวคิดเดียวกัน OpenAI ระบุตอนเปิดตัว ChatGPT agent (กรกฎาคม 2025) ว่า Agent ถูกฝึกให้ขออนุญาตก่อนทำสิ่งที่มีผลจริง เช่น การซื้อ และปฏิเสธงานเสี่ยงสูงอย่างการโอนเงินผ่านธนาคาร

ข้อควรระวัง

• ไม่มี guardrail ตัวไหนกันได้ 100%: ออกแบบให้ความเสียหายจำกัดแม้ถูกหลอกสำเร็จ
• Approval fatigue: ถ้าขออนุมัติบ่อยเกิน คนจะกดผ่านอัตโนมัติ ซึ่งแย่พอๆ กับไม่มี
• ข้อมูลส่วนบุคคลและข้อกำกับ: งานที่เกี่ยวกับการเงินหรือข้อมูลลูกค้าควรปรึกษาฝ่ายกฎหมายหรือผู้เชี่ยวชาญก่อนเปิดใช้จริง

ให้ Agent ทำงานเร็วได้ แต่ให้คนเป็นคนเซ็นในจุดที่ย้อนกลับไม่ได้

เริ่มต้นยังไง

1. ลิสต์ทุก tool ของ Agent แล้วติดป้ายว่าอ่าน ร่าง หรือย้อนกลับไม่ได้
2. เช็กว่า Agent มีครบ lethal trifecta หรือไม่ ถ้ามี ตัดขาใดขาหนึ่งออกหรือใส่คนคั่น
3. ลดสิทธิ์ของ API key ให้เหลือเท่าที่ใช้จริง
4. ตั้งการอนุมัติเฉพาะ tool กลุ่มเสี่ยงสูง
5. ทดสอบด้วยอีเมลหรือเอกสารที่มีคำสั่งแฝง ก่อนเปิดใช้จริง

ถ้าต้องการพื้นฐานเรื่องการให้ AI เรียกระบบจริง อ่าน Tool Calling คืออะไร และถ้าอยากลองสร้าง Agent ที่มีขั้นอนุมัติด้วยตัวเอง เริ่มได้ที่คอร์ส สร้าง AI Automation Agent ด้วย Make และ n8n