Authorization ในแอปพลิเคชัน LLM

• โมเดลภาษาขนาดใหญ่ (LLM) เป็นระบบที่คาดเดาไม่ได้ซึ่งต้องรับมือกับอินพุตที่ไม่แน่นอนจากผู้ใช้ ดังนั้นการใช้หลักสิทธิ์น้อยที่สุด (least privilege) จึงเป็นสิ่งจำเป็น
• ในทางปฏิบัติ LLM ถูกนำไปใช้กับงานหลากหลาย เช่น การค้นหาภายในและระบบอัตโนมัติ จึงต้องทำงานได้เฉพาะภายใต้ “สิทธิ์ที่มีผลจริง (effective permissions)” ซึ่งให้เพียงสิทธิ์ขั้นต่ำเท่านั้น เพื่อป้องกันเหตุการณ์ด้านความปลอดภัยและการใช้งานผิดวัตถุประสงค์
• ในสถาปัตยกรรม RAG (Retrieval-Augmented Generation) จำเป็นต้องแยก data embedding และการตรวจสอบสิทธิ์ออกจากแหล่งข้อมูล และต้องมีการควบคุมสิทธิ์อย่างละเอียดในระดับรีซอร์ส
• ยิ่งมีการใช้งานซับซ้อนมากขึ้น เช่น ข้อมูล/RAG จากภายนอก (3rd party), Agent, MCP ตำแหน่งและวิธีบังคับใช้สิทธิ์จริงก็ยิ่งกลายเป็นประเด็นหลักด้านความปลอดภัย
• การยืนยันตัวตนแบบใช้โทเค็น เช่น OAuth มีข้อจำกัดในการควบคุมสิทธิ์แบบละเอียดในระดับรีซอร์ส ดังนั้นตรรกะสิทธิ์จริงจึงต้องนำไปทำในชั้นแอปพลิเคชันโดยตรง

---

คำศัพท์และแนวคิดพื้นฐาน

• Prompt: คำขอของผู้ใช้ที่ส่งไปยัง LLM (เช่น คำสั่งหรือคำถาม)
• RAG (Retrieval-Augmented Generation): เวิร์กโฟลว์ที่แนบข้อมูลเพิ่มเติมเข้าไปในพรอมป์ต์เพื่อเพิ่มความแม่นยำของคำตอบจาก LLM (เช่น แนบรายการวันลาของบริษัทโดยอัตโนมัติ)
• Context: ข้อมูลเสริมที่แนบไปกับพรอมป์ต์ (เช่น เอกสารที่ค้นเจอและเกี่ยวข้อง)
• Embedding: การแทนข้อความในรูปเวกเตอร์เชิงตัวเลข ใช้สำหรับการค้นหา/จับคู่ข้อมูล
• Agent: เอนจินการทำงานที่อิง LLM ซึ่งดำเนินการตามพรอมป์ต์ (เช่น เรียกใช้เครื่องมืออัตโนมัติ)
• Tool: ความสามารถภายนอก เช่น API/แอปพลิเคชัน ที่ LLM สามารถเรียกใช้ได้โดยตรง
• Model Context Protocol (MCP): โปรโตคอลมาตรฐานสำหรับการเข้าถึงเครื่องมือของ LLM ที่เสนอโดย Anthropic

หลักการสำคัญของโมเดลสิทธิ์สำหรับ LLM

• กฎทอง (Golden Rule):
  > LLM ควรทำงานด้วย สิทธิ์ขั้นต่ำ ที่จำเป็นต่อการประมวลผลคำขอของผู้ใช้เท่านั้น
• สำหรับผู้ใช้มนุษย์ อาจยอมรับการมี “สิทธิ์เกินความจำเป็นตามธรรมเนียมปฏิบัติ” ได้บ้าง แต่ LLM คาดเดาไม่ได้ ทำงานรวดเร็ว และหากผิดพลาดอาจสร้างความเสียหายในวงกว้าง
  → “สิทธิ์ที่มีผลจริง (effective permissions)” ของ LLM ต้องถูกจำกัดให้อยู่ในส่วนตัดกันของสิทธิ์ของผู้ใช้, LLM และงานที่ร้องขอ

การคำนวณสิทธิ์ที่มีผลจริง (effective permissions)

• สิทธิ์ที่มีผลจริงของแอปพลิเคชัน LLM =
  1. สิทธิ์ที่ LLM มี
  2. สิทธิ์ที่ผู้ใช้มี
  3. สิทธิ์ที่จำเป็นสำหรับงานที่ร้องขอ
     คือส่วนตัดกันของทั้งสามอย่างนี้
• ผู้ใช้ “มอบหมายบทบาท” ของตนให้ LLM (เช่น แชตบอต) ผ่านการ impersonation แต่
  LLM ต้องไม่ก้าวข้ามขอบเขตสิทธิ์ที่ทั้งผู้ใช้และ LLM มีอยู่
• อธิบายได้อย่างเข้าใจง่ายด้วย แผนภาพเวนน์ของสิทธิ์
  • อนุญาตให้ทำงานได้ก็ต่อเมื่อสิทธิ์ที่งานต้องการอยู่ภายในส่วนตัดกันทั้งหมดเท่านั้น

RAG (Retrieval-Augmented Generation) และการจัดการสิทธิ์

1. RAG กับข้อมูล 1st Party (ข้อมูลขององค์กรเอง)

• ตัวอย่าง: แชตบอตภายในองค์กรค้นหา “ไฟล์ที่มี secret key” จากซอร์สโค้ดภายใน
• Embedding: แปลงไฟล์ทั้งหมดเป็นเวกเตอร์แล้วเก็บในฐานข้อมูล และแปลงพรอมป์ต์เป็นเวกเตอร์เพื่อจับคู่ตามความคล้ายคลึง
• ตำแหน่งที่บังคับใช้สิทธิ์:
  • ตรวจสอบทันทีว่า “ไฟล์” ที่ถูกส่งกลับมาเป็นผลลัพธ์การค้นหานั้นมีองค์กรเจ้าของ ประเภท รีโพซิทอรี และสิทธิ์ของผู้ใช้จริงอย่างไร
  • ตรวจสอบว่าผู้ใช้สามารถเข้าถึงไฟล์นั้นได้หรือไม่ (สิทธิ์ระดับรีซอร์ส)
  • ระหว่างกระบวนการเชื่อม embedding กลับไปยังข้อมูลต้นทาง ต้องมี การตรวจสอบสิทธิ์ในชั้นแอปพลิเคชัน
• การใส่ตรรกะสิทธิ์ไว้ในตัว LLM เองไม่เสถียร (เนื่องจากคุณสมบัติแบบ probabilistic จึงรับประกันไม่ได้)
• สรุป:
  • หัวใจของ RAG คือ หลังจากเชื่อม embedding กับข้อมูลต้นฉบับแล้ว ต้อง บังคับใช้สิทธิ์ตามผู้ใช้/ตามรีซอร์สอย่างเข้มงวด

2. RAG กับข้อมูล 3rd Party (ข้อมูลภายนอก)

• ใช้ข้อมูลจาก API/ระบบภายนอก (เช่น วิกิ ระบบตั๋ว ฯลฯ) มาทำ embedding แล้วนำไปใช้งาน
• ปัญหา: embedding กับข้อมูลต้นทางอยู่กันคนละระบบ → ตำแหน่งที่จะบังคับใช้สิทธิ์ไม่ชัดเจน
• มี 3 วิธีในการจัดการสิทธิ์
  1. มอบหมายการตรวจสิทธิ์ให้ระบบภายนอก (ตรวจสิทธิ์จริงทุกครั้งที่เรียก API รายการเดียว แต่จะช้าและติดปัญหา rate limit)
  2. ซิงก์ ACL (รายการควบคุมการเข้าถึง) เข้ามาในแอปพลิเคชัน (แม่นยำ/เชื่อถือได้สูง แต่ต้นทุนการจัดการและซิงก์ ACL เพิ่มขึ้น)
  3. นำตรรกะสิทธิ์ของระบบภายนอกมาสร้างใหม่ภายใน (ภาระด้านการจัดการ/ซิงก์เพิ่มขึ้น และตรรกะซับซ้อนมากขึ้น)
• ข้อสรุป: trade-off ของ “ตำแหน่งที่บังคับใช้สิทธิ์” และวิธีการเป็นเรื่องสำคัญตามสถานการณ์จริง
  (เช่น ต้องเลือกระหว่างประสิทธิภาพ-ความเรียบง่าย ต้นทุนการดูแล-ความละเอียดแม่นยำ)

LLM แบบ Agent (AI Agent) และสิทธิ์

• ตัวอย่าง: แชตบอตทำงานบำรุงรักษาอัตโนมัติ เช่น ลบรีโพซิทอรีบรันช์หรือปิด issue
• ใช้ MCP (Model Context Protocol) เพื่อ เปิดเผยเครื่องมือ (ฟังก์ชัน/API) ให้ LLM ใช้งานด้วยวิธีมาตรฐาน
• ทุกคำขอใน MCP ต้องใช้ โมเดลสิทธิ์ที่มีผลจริง
  (คือส่วนตัดกันของสิทธิ์ของผู้ใช้/เอเจนต์/งาน)
• ข้อจำกัดของการยืนยันตัวตนแบบใช้โทเค็น เช่น OAuth
  • แม้ข้อมูลสิทธิ์จะอยู่ในโทเค็น แต่ไม่ครอบคลุมสิทธิ์แบบเรียลไทม์ในระดับทรัพยากร/รีซอร์ส
  • ในทางปฏิบัติจะใส่ข้อมูลบางส่วนไว้ในโทเค็น และส่วนที่เหลือต้อง ทำตรรกะสิทธิ์แยกในชั้นแอปพลิเคชัน

บทสรุปและสรุปสำหรับการทำงานจริง

• ในสภาพแวดล้อม LLM/RAG/Agent หัวใจของการจัดการสิทธิ์คือการเลือก “ตำแหน่งและวิธีบังคับใช้สิทธิ์”

• ใช้ โมเดลสิทธิ์ที่มีผลจริง เพื่อจำกัดให้ LLM ทำงานได้เฉพาะภายในส่วนตัดกันของ “ผู้ใช้ + LLM + งาน”

• ใช้โทเค็นยืนยันตัวตน เช่น OAuth เพื่อระบุเพียงว่า “ใครเป็นผู้ส่งคำขอ” เท่านั้น
  ส่วนการตรวจสอบสิทธิ์จริงในแต่ละรีซอร์สต้องทำในแอปพลิเคชันเสมอ

• เมื่อต้องเชื่อมต่อกับระบบภายนอก
  จำเป็นต้องออกแบบโดยพิจารณา trade-off หลายด้าน เช่น
  1) มอบหมายสิทธิ์ให้ระบบภายนอก (ประสิทธิภาพลดลง), 2) ซิงก์ ACL (การดำเนินงานซับซ้อน), 3) สร้างตรรกะสิทธิ์ใหม่เอง (ภาระการบำรุงรักษาสูง)

• สรุปสุดท้าย:
  > LLM ควรทำงานได้เฉพาะภายใต้สิทธิ์ขั้นต่ำที่จำเป็นต่อการประมวลผลคำขอของผู้ใช้เท่านั้น
  > โดยนิยามสิทธิ์ที่มีผลจริง (effective permissions) เป็นส่วนตัดกันของสิทธิ์ของ LLM, ผู้ใช้ และงาน
  > และต้องตรวจสอบสิทธิ์จริงในระดับรีซอร์ส ภายในชั้นแอปพลิเคชันเสมอ