MCP ได้เผยแพร่ข้อกำหนด "Enterprise-Managed Authorization" ที่มีความเสถียรแล้ว ส่วนร่างมาตรฐานอัตลักษณ์แบบ machine-to-machine อื่นๆ ซึ่งรวมถึงร่าง OAuth client-credentials และข้อเสนอแบบเปิดอีกสองรายการ ยังคงไม่เสร็จสมบูรณ์ สำหรับใครก็ตามที่พยายามรัน autonomous agents ด้วย Model Context Protocol นั่นหมายความว่าโปรโตคอลในปัจจุบันสามารถตรวจสอบตัวตนของผู้ใช้ที่เป็นมนุษย์ได้ แต่ยังไม่มีวิธีที่พร้อมใช้งานในการพิสูจน์ว่ากระบวนการที่ทำงานโดยไม่มีผู้ควบคุม (unattended process) นั้นเป็นตัวตนที่มันกล่าวอ้างจริงหรือไม่
ทำไม roadmap ถึงมีความสำคัญ
Roadmap ของ Model Context Protocol (MCP) ได้จัดให้เรื่องอัตลักษณ์ (identity) และความปลอดภัยของ agent เป็นหนึ่งในลำดับความสำคัญสูงสุด โดยมี 4 รายการที่กำหนดไว้ว่าจะเปิดตัว ได้แก่ human-centric browser flow, OAuth client-credentials flow สำหรับบริการต่างๆ, การผูก token ด้วย DPoP (DPoP-based token binding) และกลไก workload-identity federation โดยมีเพียงรายการแรกเท่านั้นคือ Enterprise-Managed Authorization ที่บรรลุสถานะที่มีความเสถียรแล้ว
ข้อกำหนดที่เสถียรแล้วนี้ทำอะไรได้บ้าง
Enterprise-Managed Authorization ช่วยให้ผู้ดูแลระบบ IT สามารถอนุญาตการเข้าถึงเซิร์ฟเวอร์ได้จากคอนโซลเดียว แทนที่จะต้องให้พนักงานแต่ละคนอนุมัติทุกการเชื่อมต่อ โดยกระบวนการนี้จะใช้การ redirect ผ่านเบราว์เซอร์และการเข้าสู่ระบบของผู้ใช้ ดังนั้นบุคคลที่ใช้งานผ่านแล็ปท็อปจึงสามารถยืนยันตัวตนได้ และหลังจากนั้นเซิร์ฟเวอร์จะเชื่อถือ session ของผู้ใช้รายนั้น
ข้อจำกัดนั้นชัดเจนมาก นั่นคือกระบวนการนี้ต้องการมนุษย์มาคอยกดคีย์บอร์ด ส่วน agent ที่ทำงานข้ามคืน ประมวลผลข้อมูล หรือตอบสนองต่อการแจ้งเตือนนั้น ไม่มีใครมาคอยคลิกปุ่มเข้าสู่ระบบให้ ดังนั้น การปรับใช้ (deployment) ใดๆ ที่ต้องพึ่งพา unattended agents จึงไม่สามารถใช้ข้อกำหนดเพียงหนึ่งเดียวที่ MCP รับรองอยู่ในขณะนี้ได้
ตัวเลือกที่เป็นร่างมาตรฐานและข้อเสียของมัน
ส่วนขยายที่เป็นร่างมาตรฐานสองรายการมีเป้าหมายเพื่อให้ agent มีอัตลักษณ์เป็นของตัวเอง:
- SEP-1932 (DPoP) – ผูก token เข้ากับคู่กุญแจสาธารณะและส่วนตัว (public-private key pair) ทำให้ token ที่ถูกขโมยไปใช้งานไม่ได้
- SEP-1933 (Workload Identity Federation) – ช่วยให้ agent สามารถสืบทอดอัตลักษณ์ที่ถูกจัดเตรียมไว้แล้วในแพลตฟอร์มคลาวด์ได้
ทั้งสองรายการยังคงอยู่ในสถานะ open pull request และยังไม่มีรายการใดถูกรวมเข้ากับข้อกำหนดอย่างเป็นทางการ ในระหว่างนี้ ตัวเลือกอื่นเพียงอย่างเดียวที่มีการบันทึกไว้คือ OAuth client-credentials flow ซึ่งต้องใช้ความลับ (secrets) ที่ลงทะเบียนไว้ล่วงหน้า การเก็บความลับเหล่านั้นไว้ในที่ที่ agent สามารถอ่านได้จะสร้างช่องโหว่ในการโจมตี (attack surface) แบบคลาสสิก นั่นคือหากความลับรั่วไหล ผู้โจมตีคนใดก็ได้จะสามารถปลอมแปลงเป็น agent ได้
ขั้นตอนที่นำไปใช้ได้จริงสำหรับการใช้งานในระดับ production วันนี้
เนื่องจากโปรโตคอลยังไม่มีการระบุอัตลักษณ์ของ agent โดยตรง ทีมงานจึงยังสามารถรักษาความปลอดภัยให้กับ agent ได้โดยการย้ายการจัดการอัตลักษณ์ออกไปนอก MCP:
- ออกอัตลักษณ์ที่ตรวจสอบได้ในระดับ workload ระบบอย่าง SPIRE จะสร้างใบรับรอง (certificates) ที่มีอายุการใช้งานสั้นและผูกติดกับรากความเชื่อถือ (trust root) ของโฮสต์ ซึ่งช่วยกำจัด static secrets
- สิ้นสุดการใช้ credentials ที่ gateway ให้บริการส่วนหน้า (front-end service) เป็นผู้ถือ API key หรือ token และส่งต่อคำขอในนามของ agent เพื่อเก็บความลับไว้ให้พ้นจากสภาพแวดล้อมขณะทำงาน (runtime environment)
- อนุญาตสิทธิ์ตามอัตลักษณ์ที่ได้รับการตรวจสอบ ไม่ใช่ตามเนื้อหาของ token แยกการยืนยันตัวตน (authentication - ใครเป็นผู้เรียก) ออกจากการอนุญาตสิทธิ์ (authorization - ทำอะไรได้บ้าง) เพื่อให้สามารถบังคับใช้โยบายได้แม้ว่าวิธีการยืนยันตัวตนจะเปลี่ยนไป
สิ่งที่ควรจับตามองต่อไป
Open pull request ทั้งสองรายการ – DPoP binding และ workload-identity federation – คือหนทางเดียวที่จะไปสู่มาตรฐานอัตลักษณ์แบบ machine-to-machine ที่แท้จริงภายใน MCP หากชุมชนนักพัฒนาทำการรวม (merge) รายการเหล่านี้เข้าด้วยกัน agent จะสามารถพิสูจน์การครอบครองกุญแจส่วนตัวหรือสืบทอดอัตลักษณ์ที่ออกโดยคลาวด์ได้โดยไม่ต้องเปิดเผยความลับ จนกว่าจะถึงเวลานั้น การปรับใช้ในระดับ production ใดๆ จะต้องพึ่งพากรอบการทำงานด้านอัตลักษณ์ภายนอก หรือยอมรับความเสี่ยงจากการใช้ static credentials
บทสรุปนั้นชัดเจน: ปัจจุบัน MCP สามารถยืนยันตัวตนของบุคคลที่อยู่เบื้องหลังคำขอได้ แต่ยังไม่สามารถยืนยันตัวตนของซอฟต์แวร์ที่ส่งคำขอนั้นได้ ทีมที่ต้องการใช้งาน autonomous agents อย่างปลอดภัยไม่ควรรอให้ข้อกำหนดเสร็จสมบูรณ์ แต่ควรสร้างระบบอัตลักษณ์ในระดับ workload ตั้งแต่วันนี้ และคอยติดตามข้อเสนอ DPoP และ federation ที่กำลังรอการพิจารณาอยู่