「最小権限（Least Privilege）」とは、AIエージェントが目的を達成するために必要な最低限のツール実行権限およびAPIスコープのみを付与し、それ以外を一切遮断するという設計原則です。

本記事は、LLMベースのエージェントを本番環境に展開するエンジニアや、セキュリティ要件を満たしながら自律的な業務自動化を推進したいアーキテクトを対象としています。ツールホワイトリストの設計から、APIスコープの最小化、HITL（Human-in-the-Loop）承認フローの組み込み、そして監査ログと異常検知の実装まで、実装手順を順を追って解説します。

記事を読み終えると、過剰エージェント権限（Excessive Agency）によるリスクを体系的に抑制し、NIST SP 800-53のAC-6準拠を意識した権限設計を自社の開発フローに組み込めるようになります。

การออกแบบสิทธิ์ (Permission Design) ควรเริ่มต้นจากการกำหนดให้ชัดเจนว่า "จะให้ทำอะไร" หากดำเนินการโดยที่วัตถุประสงค์ยังไม่ชัดเจน มักจะนำไปสู่การให้สิทธิ์ที่มากเกินไปหรือการตกหล่นในการออกแบบ ก่อนที่จะเริ่มกำหนดสิทธิ์ขั้นต่ำ (Least Privilege) สำหรับการเรียกใช้เครื่องมือหรือ API จำเป็นต้องจัดระเบียบใน 3 ประเด็น ได้แก่ หน้าที่ความรับผิดชอบของ Agent, การจำแนกความเสี่ยงของเครื่องมือที่มีอยู่ และข้อกำหนดในการตรวจสอบ (Audit Requirements) การใช้วิธี "ให้สิทธิ์กว้างๆ ไว้ก่อนเพื่อให้ใช้งานได้" มักเป็นบ่อเกิดของปัญหาการให้สิทธิ์ Agent มากเกินไป (Excessive Agency) ต่อไปนี้จะอธิบายขั้นตอนการจัดระเบียบในแต่ละส่วน

บทสรุป: ก่อนที่จะมอบอำนาจให้กับเอเจนต์ การจำกัดขอบเขตหน้าที่ให้ชัดเจนจนสามารถอธิบายได้ในประโยคเดียวว่า "เอเจนต์นี้ทำหน้าที่อะไร" คือจุดเริ่มต้นของการออกแบบตามหลักการสิทธิ์ขั้นต่ำ (Principle of Least Privilege)

หากตัดสินใจว่า "ดูสะดวกดี เลยให้เครื่องมือไปทั้งหมดเลย" โดยที่หน้าที่ยังไม่ชัดเจน จะกลายเป็นการสร้างแหล่งเพาะเชื้อของสภาวะการให้อำนาจเอเจนต์เกินความจำเป็น (Excessive Agency) การกำหนดหน้าที่ควรระบุรายละเอียดดังนี้:

• วัตถุประสงค์ (What): อธิบายเป้าหมายทางธุรกิจในประโยคเดียว (ตัวอย่าง: "ตอบคำถามสำหรับ FAQ ภายในองค์กร")
• ขอบเขต (Boundary): ระบุรายการระบบและข้อมูลที่สามารถเข้าถึงหรือจัดการได้
• เงื่อนไขการทำงาน (When): กำหนดเงื่อนไขการเริ่มทำงานและเงื่อนไขการสิ้นสุดการทำงาน

หน้าที่ดังกล่าวจะถูกแปลงเป็น "ชุดของเครื่องมือและ API ที่เรียกใช้ได้" หรือก็คือ Scope โดยพารามิเตอร์ scope ใน RFC 6749 (OAuth 2.0) เป็นตัวอย่างของการนำไปใช้งาน ซึ่งสามารถตั้งค่าความละเอียดได้ในระดับย่อย เช่น read:faq ทั้งนี้ ขอให้ตรวจสอบว่าการเรียกใช้เครื่องมือแต่ละอย่างนั้นจำเป็นต่อการบรรลุวัตถุประสงค์โดยตรงหรือไม่ โดยยึดตามหลักการของ NIST SP 800-53 AC-6 ที่ว่า "ให้สิทธิ์เฉพาะสิ่งที่จำเป็นต่อการปฏิบัติงานเท่านั้น"

ระบุเครื่องมือและ API ทั้งหมดที่เอเจนต์อาจเข้าถึงได้ แล้วจำแนกความเสี่ยงโดยใช้ 2 แกนหลัก ได้แก่ ขอบเขตผลกระทบ (Impact Scope) และความสามารถในการย้อนกลับ (Reversibility)

ตัวอย่างการจำแนกประเภทระดับความเสี่ยง

• ความเสี่ยงสูง (ต้องได้รับการอนุมัติ): API ประเภทลบ/เขียนข้อมูล, การส่งข้อมูลออกภายนอก, การดำเนินการด้านการเรียกเก็บเงิน, การเข้าถึงข้อมูลรับรอง (Credentials)
• ความเสี่ยงปานกลาง (ต้องบันทึก Log): API ประเภทอ่าน/ค้นหาข้อมูล, การเรียกใช้บริการภายใน, การสร้างไฟล์
• ความเสี่ยงต่ำ (อนุญาตตามปกติ): การอ้างอิงข้อมูลคงที่, เครื่องมือคำนวณ/แปลงข้อมูล, การดึงข้อมูล Metadata แบบอ่านอย่างเดียว

NIST SP 800-53 Rev.5 หัวข้อ AC-6 (Least Privilege) ได้นำเสนอแนวทางว่า "ให้ยึดตามสิทธิ์ที่จำกัดที่สุดเป็นจุดเริ่มต้น และจะขยายสิทธิ์ก็ต่อเมื่อมีการพิสูจน์ความจำเป็นทางธุรกิจแล้วเท่านั้น" โดยให้กำหนดค่าเริ่มต้นเป็นความเสี่ยงสูง และจะลดระดับความเสี่ยงลงก็ต่อเมื่อมีเหตุผลรองรับเพียงพอ แม้จะเป็นเครื่องมือเดียวกัน แต่ความเสี่ยงอาจแตกต่างกันไปตาม Endpoint (เช่น การอ่านเป็นความเสี่ยงปานกลาง การลบเป็นความเสี่ยงสูง) ให้จำแนกตามระดับ Method และ Endpoint โดยจัดการผลลัพธ์ในรูปแบบ YAML หรือสเปรดชีต เพื่อนำไปใช้เป็นข้อมูลตั้งต้นสำหรับการออกแบบรายการอนุญาต (Whitelist) และการออกแบบบันทึกการตรวจสอบ (Audit Log) ต่อไป

ก่อนที่จะกำหนดการออกแบบสิทธิ์ (Permission Design) ให้ตัดสินใจก่อนว่า "จะบันทึกอะไร แค่ไหน และเก็บรักษาไว้นานเท่าใด" ไม่ใช่เรื่องแปลกที่การสอบสวนจะหยุดชะงักหลังจากเกิดเหตุการณ์ไม่พึงประสงค์ (Incident) เนื่องจากไม่มีหลักฐานหลงเหลืออยู่

มาตรฐานที่ใช้เป็นเกณฑ์คือ NIST SP 800-53 Rev.5 ในส่วน AU-2 (Audit Events) และ AU-6 (Audit Review) โดยให้รวมถึงการออกแบบบันทึกการทำงานของเครื่องมือ (Tool Execution Log) ของ Agent ไว้ในกรอบการทำงานนี้ด้วย

สิ่งที่ต้องบันทึก ได้แก่ การเริ่มต้น การเสร็จสิ้น และความล้มเหลวของการเรียกใช้เครื่องมือ, การร้องขอและให้สิทธิ์ API Scope, รวมถึงผลการอนุมัติแบบ HITL (Human-in-the-loop) สำหรับระยะเวลาการจัดเก็บนั้นจะขึ้นอยู่กับนโยบายภายในหรือกฎระเบียบของอุตสาหกรรม แต่ในอุตสาหกรรมที่มีการกำกับดูแล เช่น การเงินหรือการแพทย์ อาจจำเป็นต้องจัดเก็บข้อมูลนานกว่าเกณฑ์มาตรฐานทั่วไป (90 วัน ถึง 1 ปี)

เพื่อป้องกันการแก้ไขข้อมูล จะต้องไม่ให้สิทธิ์ในการเขียนข้อมูลแก่ตัว Agent เอง โดยให้ใช้ที่จัดเก็บข้อมูลแบบ Append-only หรือบันทึกที่มีลายเซ็นดิจิทัล (Signed Logs) และดำเนินการโดยใช้การแจ้งเตือนอัตโนมัติควบคู่ไปกับการสุ่มตรวจสอบโดยมนุษย์ตามมาตรฐาน AU-6

บทสรุป: การทำ Tool Whitelist ควรออกแบบโดยยึดหลัก "อนุญาตเฉพาะสิ่งที่จำเป็นขั้นต่ำ" ไม่ใช่ "การรวบรวมรายการสิ่งที่ใช้งานได้ทั้งหมด"

ยิ่งอนุญาตเครื่องมือมากเท่าใด พื้นที่ในการถูกโจมตี (Attack Surface) ก็จะยิ่งกว้างขึ้น ดังนั้นแนวคิด "ใส่ทุกเครื่องมือไว้ก่อน" จึงไม่สามารถใช้ได้ในสภาพแวดล้อมการทำงานจริง (Production) ในส่วนนี้จะอธิบายถึงการกำหนดชุดเครื่องมือขั้นต่ำที่จำเป็น การเลือกใช้ระหว่าง Dynamic Resolution กับ Static Whitelist และการออกแบบ Rate Limiting

บทสรุป: เครื่องมือที่ได้รับอนุญาตจะต้องพิจารณาจากหน้าที่ความรับผิดชอบ โดยให้เหลือไว้เฉพาะสิ่งที่ "หากไม่ใช้จะไม่สามารถปฏิบัติหน้าที่ได้" เท่านั้น ไม่ใช่สิ่งที่ "อาจจะได้ใช้"

การสะสมเครื่องมือโดยคิดว่า "อาจจะได้ใช้ในอนาคต" จะเป็นการเพิ่มพื้นที่การโจมตี (Attack Surface) จากเครื่องมือที่อยู่นอกเหนือขอบเขตความรับผิดชอบเท่านั้น ขั้นตอนการกำหนดชุดเครื่องมือขั้นต่ำมีดังนี้:

• เขียนคำแถลงหน้าที่ความรับผิดชอบ (Responsibility Statement) ให้จบใน 1 ประโยค: เช่น "แจ้งเตือนข้อมูลคำสั่งซื้อไปยัง Slack" การดำเนินการใดๆ ที่ไม่ปรากฏในประโยคนี้ถือเป็นตัวเลือกที่จะถูกตัดออก
• จำแนกเครื่องมือเป็น "จำเป็น / ทดแทนได้ / ไม่จำเป็น": พิจารณาว่าสามารถเปลี่ยนจาก Generic HTTP Client ไปใช้ API สำหรับอ่านข้อมูลโดยเฉพาะได้หรือไม่
• ให้เหตุผลแยกเป็นรายกรณีสำหรับเครื่องมือประเภทเขียนข้อมูล (Write): หากสามารถปฏิบัติหน้าที่ได้ด้วยการอ่านข้อมูลเพียงอย่างเดียว ก็ไม่ควรให้สิทธิ์ในการเขียนข้อมูล (NIST SP 800-53 AC-6)

หากเป็นเจ้าหน้าที่ฝ่ายสนับสนุนลูกค้า (Customer Support Agent) แล้วเครื่องมือ "ดูข้อมูลตั๋ว", "ค้นหา FAQ" และ "ส่งการตอบกลับ" เพียงพอต่อการทำงาน ก็ให้ตัดเครื่องมือ "ลบตั๋ว" และ "อัปเดตข้อมูลผู้ใช้" ออกไป เมื่อกำหนดชุดเครื่องมือขั้นต่ำได้แล้ว ให้ตั้งกฎว่าการเพิ่มเครื่องมือใหม่จะต้องมีการระบุเหตุผลประกอบ เพื่อป้องกันปัญหาการขยายสิทธิ์เกินความจำเป็น (Permission Creep)

หากไม่มีการใช้ Static Whitelist เป็นพื้นฐาน ขอบเขตของสิทธิ์มักจะมีความคลุมเครือได้ง่าย

Static Whitelist คือวิธีการกำหนดเครื่องมือที่สามารถเรียกใช้งานได้ให้ชัดเจนตั้งแต่ขั้นตอนการ Deploy การเปลี่ยนแปลงใดๆ จะต้องผ่านกระบวนการ Code Review และขั้นตอนการอนุมัติ ซึ่งช่วยขจัดความเสี่ยงจากการเพิ่มเครื่องมือที่ไม่รู้จักในขณะรันไทม์ และสอดคล้องกับมาตรฐาน NIST SP 800-53 AC-6

Dynamic Tool Resolution คือวิธีการอ้างอิงจากแคตตาล็อกในขณะรันไทม์ ซึ่งมีประสิทธิภาพในช่วงที่มีการเพิ่มเครื่องมือใหม่บ่อยครั้ง แต่หากอนุญาตโดยไม่มีการจำกัด จะเพิ่มความเสี่ยงจากการที่ Agent มีสิทธิ์มากเกินไป (Excessive Agent Permissions)

การประยุกต์ใช้ในทางปฏิบัติ:

• Production Environment: ยึดหลักการใช้ Static Whitelist โดยการเพิ่มหรือลบเครื่องมือต้องผ่านจุดอนุมัติใน CI/CD
• Staging / PoC: อนุญาตให้ใช้ Dynamic Resolution ได้ แต่ต้องจำกัดตัวแคตตาล็อกด้วย Whitelist อีกชั้นหนึ่ง
• Multi-Agent: กำหนด Static Whitelist แยกตาม Sub-agent โดยให้ชั้น Orchestrator เป็นผู้จัดสรรแบบไดนามิก

ในกรณีที่เลือกใช้ Dynamic Resolution ต้องกำหนดกฎว่า "ห้ามออกนอกแคตตาล็อกโดยเด็ดขาด" พร้อมทั้งทำ Version Control ให้กับแคตตาล็อกและบันทึกความเปลี่ยนแปลงลงใน Audit Log

แม้จะจำกัดเครื่องมือที่อนุญาตด้วย Whitelist แต่หากไม่จำกัดความถี่ในการเรียกใช้งานก็ไม่มีความหมาย หากเกิดการทำ Indirect Injection หรือการทำงานแบบวนซ้ำ (Loop) การเรียกใช้งานแบบไม่จำกัดอาจนำไปสู่ระบบล่มหรือค่าใช้จ่ายที่พุ่งสูงขึ้นได้

การกำหนด Rate Limit และการจำกัดจำนวนครั้งควรใช้ 3 แกนหลักร่วมกันดังนี้:

• Rate Limit: กำหนด "N ครั้งต่อนาที" สำหรับเครื่องมือแต่ละตัว โดยเฉพาะ API ภายนอกควรจำกัดให้เข้มงวดเป็นพิเศษ
• Budget Limit: จำกัดจำนวนครั้งการเรียกใช้งานรวมภายใน 1 เซสชัน และหยุดการทำงานเมื่อถึงขีดจำกัด
• Cost Budget: กำหนดเพดานค่าใช้จ่ายสำหรับ API แบบเสียเงิน ทั้งนี้ NIST AI 600-1 ได้ระบุว่าการใช้ทรัพยากรแบบไม่จำกัด (Unbounded Consumption) เป็นหนึ่งในรายการความเสี่ยงด้วยเช่นกัน

ตัวอย่างการนำไปใช้งานจริง เช่น การเขียนไฟล์อาจกำหนดไว้ที่ "20 ครั้งต่อเซสชัน และ 5 ครั้งต่อนาที" ส่วน HTTP ภายนอกอาจกำหนดที่ "10 ครั้งต่อเซสชัน และ 2 ครั้งต่อนาที" โดยปรับเปลี่ยนตามระดับความเสี่ยง เมื่อเกินขีดจำกัด แทนที่จะปล่อยให้ล้มเหลวแบบเงียบๆ (Silent Failure) ควรใช้การบันทึก Log แบบมีโครงสร้างควบคู่ไปกับการแจ้งเตือน และจัดการการทำ Throttling แบบรวมศูนย์ผ่าน Middleware ฝั่ง Agent

บทสรุป: การจำกัดขอบเขต (Scope) ของ API Key ให้เหลือน้อยที่สุด คือวิธีที่ตรงจุดที่สุดในการลดขอบเขตความเสียหายเมื่อเกิดการบุกรุกเอเจนต์

แม้จะมีการจำกัดว่า "เรียกใช้คำสั่งใดได้บ้าง" ด้วยไวท์ลิสต์ แต่หากตัว API Key เองมีสิทธิ์มากเกินไป ผลกระทบเมื่อถูกบุกรุกก็จะขยายเป็นวงกว้าง การออกแบบ Scope ตามมาตรฐาน RFC 6749 (OAuth 2.0) เป็นแนวทางแก้ไขปัญหาที่เป็นแบบฉบับที่สุด โดยการแบ่ง Credential ที่มอบให้เอเจนต์แยกตามวัตถุประสงค์การใช้งาน ในส่วนนี้จะอธิบายถึงการออกแบบขอบเขตสำหรับการแยกการอ่าน/เขียน (Read/Write separation), การแยกเทนแนนท์ (Tenant separation) และการฉีดซีเคร็ต (Secret injection)

บทสรุป: ให้ยึดหลักการใช้ API Key แบบ "อ่านอย่างเดียว" (read-only) เป็นพื้นฐาน และมอบสิทธิ์การเขียนเฉพาะเครื่องมือที่สามารถพิสูจน์ความจำเป็นได้เท่านั้น

กรณีการใช้งานที่ทำได้เพียงแค่อ่านข้อมูลนั้นมีมากกว่าที่คิด

• ค่าเริ่มต้นคือ read-only: งานหลักส่วนใหญ่ เช่น การรวบรวมข้อมูล การสรุปผล และการสร้างรายงาน สามารถทำงานได้ด้วยสิทธิ์การอ่าน
• การเขียนต้องผ่านการพิสูจน์เป็นรายกรณี: ต้องระบุ "เหตุผลที่เครื่องมือนี้จำเป็นต้องมีการเขียน" ให้ชัดเจนและผ่านการตรวจสอบก่อนมอบสิทธิ์
• ลดระดับความละเอียดของสิทธิ์ (Granularity): หากเป็น GitHub API ให้จำกัดสิทธิ์ตามหน่วยการทำงาน เช่น ใช้ contents:read หรือ pull_requests:write แทนการใช้ repo ทั้งหมด

พารามิเตอร์ scope ใน RFC 6749 (OAuth 2.0) เป็นมาตรฐานสำหรับการแยกสิทธิ์ดังกล่าว และ NIST SP 800-53 AC-6 ยังกำหนดให้จำกัดการเข้าถึงไว้เฉพาะการอนุมัติที่ชัดเจนเท่านั้น

ในเชิงการนำไปใช้งานจริง มีประเด็นสำคัญ 3 ประการคือ การออกคีย์แยกตามวัตถุประสงค์ (กำหนดให้ Agent ใช้เฉพาะคีย์สำหรับอ่านเป็นค่าเริ่มต้น), การออกคีย์สำหรับการเขียนเป็น Token ระยะสั้นหลังจากผ่านการอนุมัติแบบ HITL (Human-in-the-loop) และการตรวจสอบสิทธิ์ที่ไม่ได้ใช้งานเป็นประจำเพื่อเพิกถอนสิทธิ์นั้นทันที

บทสรุป: ในสภาพแวดล้อมแบบมัลติเทนเนนต์ (Multi-tenant) หากไม่มีการแยก API Key, Scope และข้อมูลระหว่างเทนเนนต์อย่างเคร่งครัด จะเกิดปัญหา "การรั่วไหลข้ามเทนเนนต์" (Cross-tenant leakage)

สาเหตุส่วนใหญ่ของอุบัติเหตุเกิดจากการนำตัวระบุเทนเนนต์ (Tenant Identifier) ไปใช้ซ้ำโดยไม่ได้ผูกเข้ากับข้อมูลประจำตัว (Credential)

• การออก API Key แยกตามเทนเนนต์: ห้ามใช้คีย์ร่วมกัน ให้ใช้วิธีออก API Key แยกเฉพาะ พร้อมแนบ tenant_id ลงใน Metadata เพื่อตรวจสอบ
• การผูก Scope เข้ากับขอบเขตของเทนเนนต์: รวมตัวระบุ เช่น tenant:{id}:read ไว้ใน Scope ของ OAuth 2.0 (ตามมาตรฐาน RFC 6749, Section 3.3)
• การบังคับตรวจสอบ Request Header: กำหนดให้ X-Tenant-ID เป็นค่าบังคับ และนำไปตรวจสอบเทียบกับ Claim ใน Token หากไม่ตรงกันให้ปฏิเสธทันที
• การแยก Namespace ใน Storage และ Cache: ใส่ Prefix เป็น tenant_id ใน Vector DB หรือ Cache Key

จำเป็นต้องมีการแยกส่วนอย่างอิสระในทุกเลเยอร์ ทั้ง API Gateway, Storage และ Log โดยอ้างอิงตามหลักการ "การตรวจสอบสิทธิ์และการอนุญาตในระดับทรัพยากร" (Resource-level authentication and authorization) ของ NIST SP 800-207 (Zero Trust)

หลักการพื้นฐานของการจัดการความลับ (Secrets) เช่น API Key หรือข้อมูลรับรอง (Credentials) คือห้ามส่งเข้าไปใน Context Window ของ Agent โดยตรง แต่ให้ใช้วิธีฉีด (Inject) เข้าไปในขอบเขตที่จำกัดที่สุดก่อนการเรียกใช้งานจริงเท่านั้น

การฝัง API Key หรือ OAuth Token ไว้ใน System Prompt มีความเสี่ยงที่จะเกิดการรั่วไหลผ่าน Prompt Leaking หรือการทำ Indirect Injection ดังนั้น ควรจัดการกับความลับเหล่านี้ในฐานะ "สิ่งที่ Agent ไม่จำเป็นต้องรู้"

วิธีการฉีดข้อมูลมี 3 รูปแบบ ได้แก่: การฉีดผ่านตัวแปรสภาพแวดล้อม (Environment Variable Injection) (แนะนำ) คือการดึงข้อมูลจาก AWS Secrets Manager หรือ HashiCorp Vault ในขณะที่ Container เริ่มทำงานแล้วส่งผ่านเป็นตัวแปรสภาพแวดล้อม ซึ่งวิธีนี้จะไม่รวมอยู่ใน Context ของ LLM, รูปแบบ Sidecar คือการให้ Wrapper ของการเรียกใช้เครื่องมือ (Tool) เป็นผู้ถือความลับไว้ โดยที่ LLM จะได้รับเพียงชื่อเครื่องมือและอาร์กิวเมนต์เท่านั้น และ การเขียนลงใน System Prompt โดยตรง ซึ่งเป็นวิธีที่ไม่แนะนำ

ประเด็นสำคัญในการออกแบบขอบเขต (Boundary Design) มี 3 ข้อ คือ การแบ่งขอบเขตตามหน่วยของเครื่องมือและไม่ใช้ Key ร่วมกัน, การกำหนดอายุการใช้งานของ Token ให้สั้นลงและออกเป็น Token ระยะสั้น (การใช้ร่วมกับ RFC 6749 จะมีประสิทธิภาพ), และการรวมระบบ Masking ความลับขณะแสดงผล Log เข้าไว้ในเลเยอร์ของการฉีดข้อมูล

แม้จะจำกัดสิทธิ์แล้ว แต่ความเสี่ยงที่เอเจนต์จะ "ตัดสินใจผิดพลาดภายในขอบเขตที่ได้รับอนุญาต" ก็ไม่สามารถลดลงจนเป็นศูนย์ได้ สำหรับการดำเนินการที่ยกเลิกได้ยาก เช่น การลบไฟล์ การส่งข้อมูลออกภายนอก หรือการประมวลผลการชำระเงิน คุณสามารถใช้กระบวนการอนุมัติแบบ HITL (Human-in-the-Loop) เพื่อเป็นกลไกความปลอดภัยขั้นสุดท้ายได้ ต่อจากนี้จะอธิบายขั้นตอนการนำไปใช้งานจริงโดยละเอียด ตั้งแต่การออกแบบตัวกระตุ้นการอนุมัติ (Approval Trigger) ไปจนถึงการจัดการ UI, การตั้งค่าเวลาหมดอายุ (Timeout) และการยกระดับการแจ้งเตือนอัตโนมัติ (Automatic Escalation)

หากทุกการกระทำต้องผ่านการอนุมัติจากมนุษย์ การทำระบบอัตโนมัติก็คงไม่มีความหมาย การออกแบบทริกเกอร์ (trigger) ตามระดับความเสี่ยงจะเป็นตัวกำหนดความสมดุลระหว่างความเร็วและความปลอดภัย

หากกำหนดให้ "ทุกการดำเนินการต้องผ่านการอนุมัติ" จะนำไปสู่ภาวะความเหนื่อยล้าจากการอนุมัติ (approval fatigue) ซึ่งจะทำให้ผู้รับผิดชอบกดอนุมัติโดยไม่ได้ตรวจสอบเนื้อหา

ในการตัดสินใจ การให้คะแนน (scoring) โดยใช้ 3 แกนหลัก ได้แก่ ความไม่สามารถย้อนกลับได้ (Irreversibility), ขอบเขตของผลกระทบ (Impact Scope) และการยกระดับสิทธิ์ (Privilege Escalation) ถือว่ามีประสิทธิภาพ โดยความไม่สามารถย้อนกลับได้หมายถึงการดำเนินการที่ยกเลิกยาก เช่น การลบข้อมูลหรือการส่งอีเมล, ขอบเขตของผลกระทบหมายถึงการดำเนินการที่ส่งผลต่อเรคคอร์ดเดียวหรือลุกลามไปถึงหลายเทนแนนท์ (tenant), และการยกระดับสิทธิ์หมายถึงการเข้าถึงที่อยู่นอกเหนือขอบเขตปกติ หากข้อใดข้อหนึ่งมีคะแนนสูง จะต้องทริกเกอร์การอนุมัติแบบ HITL (Human-in-the-loop)

ตัวอย่างที่เป็นรูปธรรม เช่น การเรียกใช้งานที่ทำลายข้อมูลอย่าง DELETE /users/{id}, การส่งอีเมลจำนวนมากเกิน 100 ฉบับ หรือการใช้ OAuth token ที่อยู่นอกเหนือขอบเขตแบบอ่านอย่างเดียว (read-only) จำเป็นต้องได้รับการอนุมัติเสมอ และหากมีการเรียกใช้ API เดียวกันติดต่อกันเกิน 10 ครั้ง ให้ตั้งค่าสถานะ (flag) อัตโนมัติ

NIST SP 800-53 AC-6(1) คือหลักเกณฑ์พื้นฐานสำหรับการอนุมัติโดยมนุษย์ โดยเงื่อนไขของทริกเกอร์ควรแยกออกมาไว้ในรูปแบบ YAML หรือไฟล์ภายนอกอื่น ๆ

บทสรุป: UI การอนุมัติควรสรุป "สิ่งที่ต้องอนุมัติและเหตุผล" ไว้ในหน้าเดียว และหากหมดเวลา (Timeout) ให้ตั้งค่าเป็นปฏิเสธเสมอ

องค์ประกอบที่ต้องมีในหน้าจอการอนุมัติมี 4 ประการ:

• สรุปการดำเนินการ: ระบุประธาน วัตถุประสงค์ และเป้าหมายให้ชัดเจน (เช่น "ส่งข้อมูลคำสั่งซื้อของ Customer ID ×××× ไปยัง External API")
• ขอบเขตผลกระทบ: แยกสีการอ่าน/เขียน/ลบ (การดำเนินการที่ทำลายข้อมูลให้ใช้ป้ายสีแดง)
• แหล่งที่มาของคำขอ: Trace ID ที่ระบุว่าเริ่มต้นจาก Agent หรือ Task ใด
• วันหมดอายุ: แสดงเวลาที่เหลือของหน้าต่างการอนุมัติให้เห็นชัดเจน

หลักการของ Timeout คือ "ปฏิเสธโดยค่าเริ่มต้น" (Default Deny)

ควรใช้การแจ้งเตือนบนมือถือควบคู่กับ Web UI แต่เนื่องจากการแจ้งเตือนที่มากเกินไปจะทำให้เกิด "ความเหนื่อยล้าจากการแจ้งเตือน" (Notification Fatigue) จนอาจมองข้ามไปได้ จึงควรจำกัดเฉพาะการดำเนินการที่มีความเสี่ยงสูงเท่านั้น

เพื่อเตรียมพร้อมสำหรับสถานการณ์ที่ผู้อนุมัติไม่ตอบสนองหรือมีความเสี่ยงพุ่งสูงขึ้น ระบบจะทำการยกระดับ (Escalation) โดยอัตโนมัติ การพึ่งพาเพียงแค่ "การตรวจสอบโดยมนุษย์" เพียงอย่างเดียวจะทำให้เกิดทางเลือกเพียงสองทางหลังจากหมดเวลา คือการหยุดชะงักของงานหรือการดำเนินการต่อโดยไม่ได้รับอนุมัติ

เงื่อนไขการทริกเกอร์สำหรับการยกระดับอัตโนมัติมี 3 ประการ:

• หมดเวลา (Timeout Exceeded): หากผู้อนุมัติลำดับแรกไม่ตอบสนองภายในเวลาที่กำหนด (เช่น 15 นาที) ระบบจะส่งต่อคำขอไปยังบทบาทที่สูงกว่าโดยอัตโนมัติ
• คะแนนความเสี่ยงเพิ่มสูงขึ้น (Risk Score Increase): หากคะแนนความเสี่ยงก่อนการดำเนินการเกินค่าเกณฑ์ที่กำหนด ระบบจะเรียกขอสิทธิ์การอนุมัติในระดับที่สูงขึ้น
• ความล้มเหลวต่อเนื่อง (Consecutive Failures): หากมีการปฏิเสธการอนุมัติ 2 ครั้งขึ้นไปภายในเซสชันเดียวกัน ระบบจะระงับเซสชันชั่วคราวและบันทึกเป็นเหตุการณ์ (Incident)

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

เมื่อเกิดเหตุการณ์ขึ้น ระบบจะบันทึกเหตุผล, เวลา (Timestamp) และการดำเนินการที่เกี่ยวข้องลงในบันทึกที่มีโครงสร้าง (Structured Log) เพื่อให้เป็นไปตามหลักฐานการตรวจสอบ (Audit Trail) ที่ NIST SP 800-53 AU-2 กำหนด โดยประวัติเหล่านี้จะถูกจัดเก็บเป็นข้อมูลเพื่อนำไปใช้ในการทบทวนการออกแบบสิทธิ์ในอนาคต

แม้จะมีการออกแบบ Tool Whitelist และ API Scope ไว้อย่างรอบคอบ แต่หากไม่มีการบันทึกและตรวจสอบการเรียกใช้งานจริง ก็จะไม่สามารถตรวจพบการใช้งานที่ผิดปกติได้ การออกแบบสิทธิ์เข้าถึงไม่ใช่สิ่งที่ "ทำเสร็จแล้วจบไป" แต่จะใช้งานได้จริงก็ต่อเมื่อมีการตรวจสอบบันทึกการทำงาน (Execution Log) อย่างต่อเนื่องเท่านั้น ทั้งนี้ NIST SP 800-53 ในหัวข้อ AU-2 และ AU-6 ได้ระบุให้การกำหนดเหตุการณ์สำหรับการตรวจสอบ (Audit Events) และการทบทวนเป็นระยะ เป็นข้อกำหนดในการควบคุม (Control Requirements) ที่ชัดเจน ในส่วนนี้จะอธิบายถึงการออกแบบ Schema สำหรับ Structured Log, กฎการตรวจจับการใช้สิทธิ์ที่ผิดปกติ และการติดตั้ง Kill Switch ตามลำดับ

ฟิลด์ของบันทึกการตรวจสอบ (Audit Log) มีดังนี้ (เป็นไปตามมาตรฐาน NIST SP 800-53 AU-2/AU-6)

• timestamp: การประทับเวลา UTC ในรูปแบบ ISO 8601
• agent_id: ตัวระบุเฉพาะของอินสแตนซ์เอเจนต์
• tool_name: ชื่อของเครื่องมือหรือ API endpoint ที่ถูกเรียกใช้งาน
• action_type: การจำแนกประเภทระหว่าง read / write / delete / invoke
• requested_scope: ขอบเขตที่ร้องขอ
• granted_scope: ขอบเขตที่ได้รับอนุญาตจริง
• resource_id: ตัวระบุของทรัพยากรที่ถูกดำเนินการ
• result_status: success / denied / error
• session_id: คีย์สำหรับเชื่อมโยงกับขั้นตอนการอนุมัติแบบ HITL (Human-in-the-loop)

คุณสามารถตรวจจับสัญญาณของการละเมิดสิทธิ์ได้โดยอัตโนมัติจากความแตกต่างระหว่าง requested_scope และ granted_scope โดยแนะนำให้ใช้รูปแบบเอาต์พุตเป็น JSON Lines และเมื่อจัดเก็บข้อมูล ให้โอนย้ายไปยังที่จัดเก็บแบบ Write-once (เขียนได้อย่างเดียว/เพิ่มข้อมูลได้เท่านั้น)

บทสรุป: การตรวจจับการใช้อำนาจเกินขอบเขต (権限逸脱) มีประสิทธิภาพสูงสุดเมื่อใช้การผสมผสานระหว่างการตรวจจับแบบอิงกฎ (Rule-based) และการตรวจจับความผิดปกติทางสถิติ (Statistical Anomaly Detection) เนื่องจากวิธีใดวิธีหนึ่งเพียงอย่างเดียวมักทำให้เกิดการตรวจจับพลาด จึงควรมีการเฝ้าระวังแบบหลายชั้น (Multi-layer)

รูปแบบหลักของการตรวจจับแบบอิงกฎ (Rule-based)

• การเรียกใช้ API นอกขอบเขต: บล็อกและแจ้งเตือนทันทีเมื่อมีการร้องขอไปยัง Endpoint ที่ไม่อยู่ในรายการอนุญาต (Whitelist)
• การใช้งานเกินอัตรา (Rate Limit): ติดธงทันทีเมื่อจำนวนการเรียกใช้ต่อหน่วยเวลาเกินค่าเกณฑ์ที่กำหนด
• ความพยายามยกระดับสิทธิ์: ตรวจจับด้วยการจับคู่รูปแบบ (Pattern Matching) เช่น การเขียนข้อมูลด้วยคีย์แบบ Read-only หรือการเรียกใช้ API สำหรับผู้ดูแลระบบ
• การเข้าถึงในช่วงเวลาที่ผิดปกติ: จัดประเภทการทำงานนอกเวลาทำการปกติไว้ในบันทึกที่ต้องเฝ้าระวังเป็นพิเศษ

การตรวจจับความผิดปกติทางสถิติ

กฎเพียงอย่างเดียวอาจไม่สามารถตรวจจับกรณีที่ "ดูเหมือนปกติแต่มีปริมาณผิดปกติ" ได้ จึงต้องมีการคำนวณ Baseline จากประวัติย้อนหลัง และสั่งการแจ้งเตือนเมื่อค่าเบี่ยงเบนเกินกว่าค่าเบี่ยงเบนมาตรฐาน (Standard Deviation) ตามจำนวนเท่าที่กำหนด (NIST SP 800-53 AU-6 กำหนดให้มีการวิเคราะห์อย่างต่อเนื่อง) ทั้งนี้ หากความแม่นยำต่ำ ทีมปฏิบัติการอาจเริ่มเพิกเฉยต่อการแจ้งเตือน ดังนั้นในช่วงแรกควรตั้งค่าเป็นการแจ้งเตือนเพียงอย่างเดียวเพื่อวัดอัตราการตรวจจับผิดพลาด (False Positive) ก่อนที่จะเปลี่ยนไปใช้การบล็อกจริง

บทสรุป: kill switch ไม่ได้มีไว้เพียงเพื่อ "หยุด" เท่านั้น แต่จำเป็นต้องออกแบบให้ "หยุดได้อย่างปลอดภัย" หากไม่มีการออกแบบขั้นตอนการขัดจังหวะงานที่กำลังดำเนินการอยู่ อาจมีความเสี่ยงที่ข้อมูลจะเสียหายได้

การยกเลิก API key เพียงอย่างเดียวจะทำให้การเรียกใช้งานที่ค้างอยู่ทำงานจนเสร็จสิ้น ซึ่งอาจส่งผลให้เกิดการเขียนข้อมูลหรือการส่งข้อมูลออกภายนอกโดยไม่ตั้งใจ การออกแบบ kill switch จึงควรแบ่งเป็น 3 เลเยอร์:

• เลเยอร์ 1 — การหยุดเซสชัน (Session termination): ใช้แฟล็กการหยุดเพื่อบล็อกการเรียกใช้งานใหม่ และส่งสัญญาณยกเลิกไปยังการเรียกใช้งานที่กำลังดำเนินการอยู่ทันที
• เลเยอร์ 2 — การยกเลิกการยืนยันตัวตน (Authentication invalidation): ทำการหมุนเวียน (Rotate) หรือเพิกถอน OAuth token หรือ API key (ตามขอบเขตของ RFC 6749)
• เลเยอร์ 3 — การตัดการเชื่อมต่อเครือข่าย (Network isolation): ปฏิเสธการส่งข้อมูลทันทีด้วยนโยบายของ ZTNA

ควรออกแบบให้เป็นปฏิบัติการแบบ Idempotent เพื่อไม่ให้เกิดผลข้างเคียงหากมีการเรียกใช้งานซ้ำ และหลังจากหยุดการทำงานแล้ว ให้เปลี่ยนโหมดการเก็บรักษาบันทึก (Log) ตามมาตรฐาน NIST SP 800-53 AU-6 สำหรับการสั่งงานอัตโนมัติ ให้ใช้การตรวจพบการละเมิดสิทธิ์หรือการหมดเวลาของ HITL (Human-in-the-loop) เป็นตัวกระตุ้น และควรจัดเตรียม Endpoint สำหรับการสั่งงานด้วยตนเองแยกไว้ต่างหาก

บทสรุป: ความล้มเหลวส่วนใหญ่มีสาเหตุมาจากการตัดสินใจในช่วงเริ่มต้นที่ว่า "ให้สิทธิ์กว้างๆ ไว้ก่อน"

ความล้มเหลวที่ 1: การอนุญาตให้ใช้เครื่องมือทั้งหมดพร้อมกัน กรณีที่นำสถานะจาก PoC ไปใช้ในระบบงานจริง (Production) โดยตรง ควรสร้างกระบวนการจำกัดขอบเขตสิทธิ์ก่อนเริ่มใช้งานจริง

ความล้มเหลวที่ 2: ไม่แยกสิทธิ์ read/write เนื่องจากความเสียหายจากการโจมตีแบบ Prompt Injection จะขยายวงกว้างขึ้น จึงควรกำหนดให้ใช้ read-only key เป็นหลัก

ความล้มเหลวที่ 3: การข้ามขั้นตอนการอนุมัติแบบ HITL (Human-in-the-Loop) การจัดการข้อยกเว้น (Exception handling) หรือการลองใหม่ (Retry) อาจทำให้ขั้นตอนการอนุมัติถูกข้ามไปได้ ควรวางระบบตรวจสอบการอนุมัติไว้ภายนอกส่วนการจัดการข้อยกเว้น

ความล้มเหลวที่ 4: การเก็บ Audit Log ไว้ "เพียงอย่างเดียว" หากไม่มีกฎการแจ้งเตือน (Alert rules) ความผิดปกติจะถูกมองข้ามไป ควรติดตั้งระบบจัดเก็บ Log ควบคู่ไปกับกฎการตรวจจับเสมอ

ความล้มเหลวที่ 5: การ Hardcode ข้อมูลลับ (Secrets) ควรใช้การย้ายข้อมูลลับไปไว้ในบริการจัดการข้อมูลลับ (Secret management service) ควบคู่ไปกับการทำสแกนอัตโนมัติระหว่างการรีวิวโค้ด

ปัญหาเหล่านี้สามารถแก้ไขได้อย่างเป็นระบบเมื่อนำไปใช้ร่วมกับแนวทาง "การป้องกันเชิงโครงสร้าง" ในบทความ Harness Engineering คืออะไร? วิธีการออกแบบเพื่อป้องกันความผิดพลาดของ AI Agent ด้วยโครงสร้าง

Q1. สิทธิ์ขั้นต่ำ (Least Privilege) จะทำให้ฟังก์ชันการทำงานถูกจำกัดมากเกินไปหรือไม่? การออกแบบขอบเขต (Scope) ที่เหมาะสมสามารถสร้างสมดุลระหว่างฟังก์ชันการทำงานและความปลอดภัยได้ การ "เริ่มต้นจากวงจำกัดแล้วค่อยขยายตามความจำเป็น" จะช่วยลดความเสี่ยงในการพบปัญหาในภายหลังได้ดีกว่า

Q2. HITL (Human-in-the-Loop) จะทำให้ความเร็วในการประมวลผลลดลงหรือไม่? หากจำกัดเฉพาะการดำเนินการที่มีความเสี่ยงสูง การดำเนินการที่มีความเสี่ยงต่ำในชีวิตประจำวันก็จะสามารถประมวลผลแบบอัตโนมัติได้ นอกจากนี้ การตั้งค่า Timeout และการยกระดับความสำคัญโดยอัตโนมัติ (Automatic Escalation) ยังช่วยลดความล่าช้าให้เหลือน้อยที่สุดได้อีกด้วย

Q3. ควรเก็บรักษาบันทึกการตรวจสอบ (Audit Log) ไว้นานเท่าใด? มาตรฐาน NIST SP 800-53 หัวข้อ AU-2 และ AU-6 กำหนดให้มีการตั้งค่าระยะเวลาการจัดเก็บตามโปรไฟล์ความเสี่ยงขององค์กร แม้ว่ากฎระเบียบของแต่ละอุตสาหกรรมจะมีความสำคัญสูงสุด แต่ขอแนะนำให้เก็บรักษาไว้อย่างน้อย 90 วันขึ้นไป

Q4. การออกแบบสิทธิ์จะเปลี่ยนไปอย่างไรในโครงสร้างแบบ Multi-agent? หลักการพื้นฐานคือ "การแบ่งมอบสิทธิ์" (Delegated Authority) โดยไม่มอบสิทธิ์ทั้งหมดของ Parent Agent ให้ แต่จะมอบเฉพาะสิทธิ์ที่จำเป็นสำหรับแต่ละงานเท่านั้น โปรดดูข้อมูลเพิ่มเติมที่ Multi-agent AI คืออะไร? ตั้งแต่รูปแบบการออกแบบไปจนถึงจุดสำคัญในการนำไปใช้งานจริง

สรุป: ออกแบบโดยใช้เกณฑ์ "จะใช้งานได้อย่างปลอดภัยอย่างไร" ไม่ใช่แค่ "ใช้งานได้หรือไม่"

ทบทวนประเด็นสำคัญของแต่ละขั้นตอน:

• เงื่อนไขเบื้องต้น: ระบุหน้าที่และขอบเขตให้ชัดเจน พร้อมจำแนกประเภทความเสี่ยงของเครื่องมือและ API
• ขั้นตอนที่ 1: กำหนดชุดเครื่องมือที่ได้รับอนุญาตขั้นต่ำแบบคงที่ (Static) และใช้การจำกัดอัตรา (Rate Limit) ร่วมกับการจำกัดจำนวนครั้ง
• ขั้นตอนที่ 2: ให้ความสำคัญกับคีย์แบบอ่านอย่างเดียว (Read-only) และกำหนดขอบเขตของการแยก Tenant และการฉีด Secret ให้ชัดเจน
• ขั้นตอนที่ 3: กำหนดจุดอนุมัติโดยมนุษย์ (Human-in-the-loop) สำหรับการดำเนินการที่มีความเสี่ยงสูง พร้อมใส่ระบบ Timeout และการยกระดับความสำคัญอัตโนมัติ (Escalation)
• ขั้นตอนที่ 4: ตรวจจับการใช้อำนาจเกินขอบเขตด้วย Structured Log และระงับการทำงานด้วย Kill switch

แนวทางที่ใช้งานได้จริงคือการเริ่มต้นจาก PoC โดยใช้ Whitelist และขอบเขตแบบอ่านอย่างเดียว พร้อมเริ่มใช้งานด้วยโครงสร้างขั้นต่ำที่มีการตรวจสอบโดยมนุษย์ (HITL) สำหรับการออกแบบความปลอดภัยของ AI Agent โดยรวม สามารถศึกษาเพิ่มเติมได้จาก AI Governance คืออะไร? คู่มือปฏิบัติงานตั้งแต่การรองรับ EU AI Act ไปจนถึงการจัดทำกฎระเบียบภายในองค์กร