CAPMAS เป็นความร่วมมือระหว่าง EPFL และ Swisscom ช่วยให้นักพัฒนาสามารถมอบสิทธิ์การใช้งานที่มีขอบเขตจำกัด (narrowly scoped permissions) ให้กับ AI child agents ผ่าน macaroons ซึ่งช่วยลดความหน่วง (latency) ในการจัดการ token ลงถึง 30 เท่า และป้องกันไม่ให้ agent เข้าถึง JWT ของผู้ใช้แบบเต็มรูปแบบได้

ทำไมการเปลี่ยนแปลงนี้จึงสำคัญ

เมื่อ LLM ทำหน้าที่ควบคุมเครื่องมือต่างๆ (downstream tools) ทีมพัฒนามักจะส่งมอบ JWT ตัวเดียวกับที่ผู้ใช้ใช้ล็อกอินให้กับ "child" agent ที่ถูกสร้างขึ้นมา โดย JWT คือข้อมูลชุดหนึ่งที่มีการลงลายมือชื่อดิจิทัล (signed blob) ซึ่งระบุสิทธิ์ทั้งหมดที่ผู้ใช้มี เช่น ข้อมูล HR, ไฟล์โครงการ, สิทธิ์แอดมิน และอื่นๆ หากโมเดลเกิดอาการหลอน (hallucinate) และสร้างคำสั่งที่ก่อให้เกิดความเสียหาย child agent ก็จะสามารถรันคำสั่งนั้นได้ด้วยอำนาจเต็มของผู้ใช้ ความผิดพลาดเพียงครั้งเดียวอาจทำให้ข้อมูลของทั้งองค์กรถูกเปิดเผยได้

ข้อบกพร่องของวิธีการแก้ไขปัญหาในปัจจุบัน

การสร้าง token ที่มีขอบเขตจำกัดตามความต้องการ (on demand) ด้วยกระบวนการ RFC 8693 token-exchange จะทำให้ต้องมีการรับส่งข้อมูลกับระบบ IAM หลายรอบ (round-trips) ซึ่งเป็นการเพิ่มปริมาณการรับส่งข้อมูลในเครือข่าย (network traffic) และทำให้เกิดความหน่วงที่สังเกตเห็นได้ชัดเจน สำหรับทีมที่ต้องสร้าง agent จำนวนมากที่มีอายุการใช้งานสั้น (short-lived agents) จะพบว่าภาระงานส่วนเกิน (overhead) นี้ส่งผลกระทบอย่างรุนแรง

CAPMAS ทำงานอย่างไร

CAPMAS แบ่งการมอบสิทธิ์ออกเป็นสองขั้นตอน:

  1. การเข้ารหัสฝั่ง IAM (IAM-side encoding) – บริการ IAM จะรันตัวเข้ารหัส (encoder) ที่แปลงคำขอในรูปแบบภาษาธรรมชาติ (เช่น “list files in the finance folder”) ให้กลายเป็นชุดของสิทธิ์ที่สอดคล้องกัน
  2. การสร้าง Macaroon (Macaroon creation) – สิทธิ์เหล่านั้นจะกลายเป็น caveats (ข้อกำหนดเพิ่มเติม) ภายใน macaroon ซึ่งเป็นรูปแบบ token ที่มีความยืดหยุ่น ช่วยให้ agent ที่ทำงานต่อจากนั้นสามารถเพิ่มข้อจำกัดได้มากขึ้น แต่ไม่สามารถลบข้อจำกัดที่มีอยู่เดิมออกได้

เมื่อ agent ได้รับ macaroon มันสามารถจำกัดขอบเขตให้แคบลงได้ เช่น จำกัดการขอรายการไฟล์ให้เหลือเพียงในโฟลเดอร์ย่อย แต่ไม่สามารถขยายขอบเขตให้กว้างขึ้นได้ ในทุกๆ ขั้นตอน (hop) บริการ IAM จะตรวจสอบจุดร่วม (intersection) ของ caveats ทั้งหมด เพื่อรับประกันว่าไม่มี agent ใดใช้งานเกินกว่าสิทธิ์ที่ได้รับอนุญาตไว้ตั้งแต่แรก

ตัวเลขประสิทธิภาพที่พิสูจน์ได้ด้วยตัวเอง

  • ความเร็ว (Speed) – CAPMAS ประมวลผลคำขอสิทธิ์ได้ภายในเวลาไม่ถึง 20 ms ซึ่งเร็วกว่าการแลกเปลี่ยนแบบ RFC 8693 ประมาณ 30 เท่า
  • ความแม่นยำ (Accuracy) – จากการทดสอบมาตรฐาน (benchmark) กับรายการเครื่องมือจำนวนมาก พบว่า LLM มาตรฐานพลาดสิทธิ์ที่จำเป็นไปถึง 53% ในขณะที่ CAPMAS ทำความแม่นยำได้ถึง 90.9% โดยมีอัตราการพลาดเพียง 2.1% เท่านั้น
  • แบนด์วิดท์ (Bandwidth) – เนื่องจาก macaroon บรรจุเฉพาะชุด caveats สุดท้าย ข้อมูลที่รับส่งกันจึงเป็นเพียงเศษเสี้ยวของสิ่งที่กระบวนการ token-exchange แบบเต็มรูปแบบต้องใช้

ขั้นตอนการนำไปใช้งานจริง

  1. กรองคำขอก่อน (Pre-filter the request) – แปลงเจตนาในรูปแบบภาษาธรรมชาติของผู้ใช้ให้เป็นรายการอนุญาต (allowlist) แบบ top-k ก่อนที่ตัวควบคุม (orchestrator) จะเข้าถึงรายการเครื่องมือ
  2. ปิดผนึกรายการอนุญาต (Seal the allowlist) – เข้ารหัสรายการอนุญาตนั้นลงใน macaroon ซึ่ง child agent ไม่สามารถขยายขอบเขตได้
  3. ตรวจสอบที่บริการปลายทาง (Verify at the service) – ให้บริการเป้าหมายสอบถาม IAM เพื่อคำนวณจุดร่วมของ caveats ทั้งหมดก่อนที่จะดำเนินการตามคำขอ

ขั้นตอนเหล่านี้จะเปลี่ยนรูปแบบจาก "การมอบกุญแจบ้านทั้งหลังให้แก่ child agent" เป็นโมเดล "การส่งมอบกุญแจที่ใช้ได้ครั้งเดียวและมีขอบเขตจำกัด" แทน

สิ่งที่ CAPMAS ไม่ได้แก้ไข

เฟรมเวิร์กนี้ไม่ได้หยุดยั้งการโจมตีแบบ prompt-injection ซึ่งผู้โจมตีจะป้อนคำสั่งที่บิดเบือน prompt ของ LLM เพื่อแทรกคำสั่งที่เป็นอันตราย การป้องกันของ CAPMAS ครอบคลุมถึง agent ที่ทำงานอย่างซื่อสัตย์แต่พยายามสอดรู้สอดเห็น (honest-but-curious agents) และ LLM ที่ไม่น่าเชื่อถือซึ่งอาจดำเนินการตามสิทธิ์ใน JWT แบบเต็มรูปแบบได้ อย่างไรก็ตาม ทีมพัฒนายังคงต้องมีมาตรการป้องกันแยกต่างหาก เช่น การทำ input sanitisation, การทำ sandboxing หรือการใช้ guardrails ในระดับโมเดล เพื่อจัดการกับภัยคุกคามที่มาจาก prompt

ใครจะได้รับประโยชน์

  • นักพัฒนาในระดับองค์กร (Enterprise developers) ที่กำลังสร้างผู้ช่วยที่ขับเคลื่อนด้วย AI ซึ่งต้องเรียกใช้งาน internal APIs
  • ทีมความปลอดภัย (Security teams) ที่ต้องการลดขอบเขตความเสียหาย (blast radius) หากโมเดลถูกเจาะระบบ
  • เจ้าของผลิตภัณฑ์ (Product owners) ที่ต้องการการตรวจสอบสิทธิ์ที่รวดเร็วและเชื่อถือได้ สำหรับการสร้าง agent จำนวนมากในความถี่สูง

ขั้นตอนต่อไป

CAPMAS เป็นเพียงการออกแบบที่นำเสนอขึ้นมา

สรุปสาระสำคัญ (Takeaway): การเปลี่ยนจาก JWT ของผู้ใช้แบบเต็มรูปแบบมาเป็น macaroon ที่มีขอบเขตจำกัด ช่วยให้นักพัฒนาสามารถควบคุมให้ AI agent ทำงานอย่างถูกต้องโดยไม่ต้องแลกด้วยความหน่วงของกระบวนการ token-exchange แบบดั้งเดิม อย่างไรก็ตาม ข้อแลกเปลี่ยนที่ยังคงอยู่คือความจำเป็นในการมีมาตรการป้องกัน prompt-injection ต่อไป