บทวิจารณ์เชิงลึกของสเปคการให้สิทธิ์ MCP (ฉบับวันที่ 2025-03-26)

MCP (โมเดลโปรโตคอลบริบท) เป็นมาตรฐานเปิดที่ช่วยให้โมเดล AI สามารถโต้ตอบกับเครื่องมือและบริการภายนอกได้ เป็นที่ยอมรับอย่างกว้างขวางในอุตสาหกรรม เนื่องจาก MCP สนับสนุนวิธีการขนส่งตาม HTTP ทำให้เซิร์ฟเวอร์ MCP ระยะไกลจะมีบทบาทสำคัญยิ่งขึ้นในระบบนิเวศ MCP

ต่างจากเซิร์ฟเวอร์ MCP ในเครื่อง ที่อนุญาตให้ผู้ใช้แต่ละคนเรียกใช้เซิร์ฟเวอร์อินสแตนซ์ของตนเอง เซิร์ฟเวอร์ MCP ระยะไกลต้องการให้ผู้ใช้ทุกคนแชร์บริการเซิร์ฟเวอร์ MCP เดียวกัน สิ่งนี้ทำให้เกิดปัญหาหลักที่ สเปคการให้สิทธิ์ MCP มุ่งหมายที่จะไข: วิธีที่อนุญาตให้เซิร์ฟเวอร์ MCP เข้าถึงทรัพยากรของผู้ใช้ในนามของผู้ใช้

บทความนี้จะวิเคราะห์ สเปคการให้สิทธิ์ MCP อย่างละเอียด จะช่วยให้คุณเข้าใจหลักการออกแบบของสเปคการให้สิทธิ์ MCP และทิศทางบางประการในการนำ MCP Authorization ไปใช้ เนื่องจาก Spec ยังอยู่ในระหว่างการพัฒนา ข้าพเจ้าจะขอแบ่งปันความคิดเห็นบางอย่างโดยอิงจากประสบการณ์ส่วนตัวในการนำ Authenticator ไปใช้ รวมถึง:

• ข้อดีและข้อจำกัดของ OAuth 2.1 ในฐานะกรอบการทำงานการให้สิทธิ์
• ความท้าทายของบทบาทสองของเซิร์ฟเวอร์ MCP ในฐานะทั้งเซิร์ฟเวอร์การให้สิทธิ์และเซิร์ฟเวอร์ทรัพยากร
• ความซับซ้อนเชิงปฏิบัติของการนำเซิร์ฟเวอร์การให้สิทธิ์ไปใช้อย่างเต็มรูปแบบ
• การวิเคราะห์สถานการณ์ที่เหมาะสมสำหรับการอนุญาตบุคคลที่สาม
• การแลกเปลี่ยนการปฏิบัติของการลงทะเบียนลูกค้าแบบไดนามิก
• ความสำคัญของการกำหนดขอบเขตทรัพยากรของเซิร์ฟเวอร์ MCP อย่างชัดเจน

ภาพรวมของสเปคการให้สิทธิ์ MCP#

สเปคการให้สิทธิ์ MCP](https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization) กำหนดกระบวนการรับรองความถูกต้องระหว่างเซิร์ฟเวอร์ MCP (ระยะไกล) และไคลเอนต์ MCP

ข้าเจ้าคิดว่าการปรับฐาน Spec นี้บน OAuth 2.1 เป็นทางเลือกที่สมเหตุสมผลมาก OAuth ในฐานะกรอบโปรโตคอลการให้สิทธิ์แก้ปัญหาวิธีการอนุญาตให้ผู้ใช้แอปพลิเคชันบุคคลที่สามเข้าถึงทรัพยากรของผู้ใช้ในนามของพวกเขา ถ้าคุณยังไม่คุ้นเคยกับ OAuth คุณสามารถตรวจสอบที่ AuthWiki-OAuth สำหรับข้อมูลเพิ่มเติม.

ในสถานการณ์ของไคลเอนต์ MCP และเซิร์ฟเวอร์ MCP, เป็นเรื่องของ "ผู้ใช้งานอนุญาตให้ไคลเอนต์ MCP เข้าถึงทรัพยากรของผู้ใช้บนเซิร์ฟเวอร์ MCP" บริเวณนี้ "ทรัพยากรของผู้ใช้บนเซิร์ฟเวอร์ MCP" ปัจจุบันมักหมายถึงเครื่องมือที่ให้โดย MCP Server หรือทรัพยากรที่ให้โดยบริการ backend ของ MCP Server

ในการนำกระบวนการรับรองความถูกต้อง OAuth 2.1 มาใช้ โปรโตคอลต้องการให้เซิร์ฟเวอร์ MCP ให้ส่วนต่อประสานต่อไปนี้เพื่อทำงานร่วมกับไคลเอนต์ MCP เพื่อทำกระบวนการรับรองความถูกต้อง OAuth 2.1 ให้เสร็จสมบูรณ์:

• /.well-known/oauth-authorization-server: เมตาดาต้าเซิร์ฟเวอร์ OAuth
• /authorize: จุดสิ้นสุดของการให้สิทธิ์ ใช้สำหรับคำขอการให้สิทธิ์
• /token: จุดสิ้นสุดของโทเค็น ใช้สำหรับการแลกเปลี่ยนและรีเฟรชโทเค็น
• /register: จุดสิ้นสุดการลงทะเบียนลูกค้า ใช้สำหรับการลงทะเบียนลูกค้าแบบไดนามิก

กระบวนการรับรองความถูกต้องมีดังนี้:

Spec กำหนดด้วยว่าเซิร์ฟเวอร์ MCP สนับสนุนการอนุญาตแบบมอบหมายผ่านเซิร์ฟเวอร์การอนุญาตบุคคลที่สามอย่างไร

ตัวอย่างการไหลใน Spec มีดังนี้ (จากเนื้อหา Spec):

ในสถานการณ์นี้ แม้ว่า MCP Server จะมอบสิทธิ์ให้เซิร์ฟเวอร์การอนุญาตบุคคลที่สาม แต่ MCP Server ยังทำหน้าที่เป็นเซิร์ฟเวอร์การอนุญาตสำหรับลูกค้า MCP เนื่องจาก MCP Server จำเป็นต้องออกโทเค็นการเข้าถึงของตัวเองให้กับลูกค้า MCP

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

โดยสรุป ตามโปรโตคอล MCP Server มีบทบาททั้งในฐานะเซิร์ฟเวอร์การอนุญาตและเซิร์ฟเวอร์ทรัพยากรใน OAuth

ต่อไป มาลงรายละเอียดความรับผิดชอบของ MCP Server เนื่องจากเซิร์ฟเวอร์การอนุญาตและเซิร์ฟเวอร์ทรัพยากร

MCP Server ในฐานะบริการการให้สิทธิ์#

เมื่อ MCP Server ทำหน้าที่เป็นเซิร์ฟเวอร์การอนุญาต หมายความว่าผู้ใช้ปลายทางของไคลเอนต์ MCP มีอัตลักษณ์ของตนเองใน MCP Server MCP Server มีหน้าที่รับรองความถูกต้องของผู้ใช้ปลายทางนี้และออกโทเค็นการเข้าถึงให้ผู้ใช้ปลายทางนี้เพื่อเข้าถึงทรัพยากรของ MCP Server

ส่วนต่อประสานที่เกี่ยวข้องกับการอนุญาตที่ระบุใน Spec การอนุญาต MCP ข้างต้นหมายความว่า MCP Server ต้องให้การใช้งานของเซิร์ฟเวอร์การอนุญาต

อย่างไรก็ตาม การใช้งานการทำงานของเซิร์ฟเวอร์การอนุญาตบน MCP Server นับเป็นความท้าทายที่สำคัญสำหรับนักพัฒนา ในด้านหนึ่ง นักพัฒนาส่วนใหญ่อาจไม่คุ้นเคยกับแนวคิดที่เกี่ยวข้องกับ OAuth ส่วนอีกด้านมีรายละเอียดมากมายที่ต้องพิจารณาเมื่อใช้งานเซิร์ฟเวอร์การอนุญาต หากนักพัฒนาไม่ได้อยู่ในสาขาที่เกี่ยวข้อง พวกเขาอาจเปิดเผยปัญหาด้านความปลอดภัยต่าง ๆ ในระหว่างการใช้งาน

แต่โปรโตคอลเองไม่ได้จำกัดว่า MCP Server ต้องใช้งานฟังก์ชันการทำงานของเซิร์ฟเวอร์การอนุญาตเพียงลำพัง นักพัฒนาสามารถเปลี่ยนเส้นทางหรือเป็นพร็อกซีของ endpoint ที่เกี่ยวข้องกับการอนุญาตเหล่านี้ไปยังเซิร์ฟเวอร์การอนุญาตอื่น ๆ ก็ได้ ไม่มีความแตกต่างของลูกค้า MCP มากไปกว่าการที่ MCP Server ใช้ฟังก์ชันการทำงานของเซิร์ฟเวอร์การอนุญาตเพียงลำพัง

คุณอาจสงสัย ว่าควรใช้วิธีการอนุญาตบุคคลที่สามแบบมอบหมายที่กล่าวถึงข้างต้นแทนหรือไม่?

จากมุมมองของข้าพเจ้า วิธีนี้ขึ้นอยู่กับว่าผู้ใช้ของบริการอนุญาตบุคคลที่สามที่คุณพึ่งพาเป็ผู้ใช้ปลายทางเดียวกันกับ MCP Server หรือไม่ หมายความว่าโทเค็นการเข้าถึงที่ออกให้โดยบริการการอนุญาตบุคคลที่สามจะถูกใช้โดยตรงกับ MCP Server ของคุณ

• ถ้าใช่ คุณสามารถส่งต่ออินเทอร์เฟซที่เกี่ยวข้องกับการตรวจสอบรับรองใน MCP Server ของคุณไปยังบริการการอนุญาตบุคคลที่สามได้ทั้งหมด

• ถ้าไม่ คุณควรใช้วิธีการมอบหมายการอนุญาตบุคคลที่สามตามที่ระบุใน Spec คุณจำเป็นต้องรักษาความสัมพันธ์แมปปิงระหว่างโทเค็นการเข้าถึงที่ออกให้โดย MCP Server เองและโทเค็นการเข้าถึงที่ออกโดยบริการการอนุญาตบุคคลที่สามใน MCP Server

ข้าพเจ้ามองว่าวิธีการมอบหมายการอนุญาตบุคคลที่สามตามโปรโตคอลนั้นค่อนข้างคลุมเครือในแง่สถานการณ์การใช้งานจริง โปรโตคอลดูเหมือนจะให้บุคคลที่สามช่วย MCP Server ทำกระบวนการอนุญาตให้เสร็จ แต่ยังคงกำหนดให้ MCP Server ออก Access token เอง ซึ่งจริง ๆ แล้วหมายความว่า MCP Server ยังคงต้องรับภาระในการออก Access tokens ในฐานะเซิร์ฟเวอร์การอนุญาต ซึ่งไม่ได้ช่วยให้สะดวกยิ่งขึ้นสำหรับนักพัฒนา ข้าพเจ้าคิดว่าเป็นเพราะผู้เขียนโปรโตคอลพิจารณาว่าการส่งคืนโทเค็นการเข้าถึงบุคคลที่สามให้กับไคลเอนต์ MCP โดยตรงจะนำมาซึ่งปัญหาด้านความปลอดภัย (เช่น การรั่วไหล/การใช้งานในทางที่ผิด ฯลฯ)

จากประสบการณ์ของข้าพเจ้า สถานการณ์ที่เหมาะสมที่สุดสำหรับการอนุญาตบุคคลที่สามในโปรโตคอลที่ระบุจริง ๆ ควรเป็นสถานการณ์ของ "ผู้อนุญาต MCP Server เพื่อเข้าถึงทรัพยากรของบุคคลที่สาม" ตัวอย่างเช่น MCP Server ต้องเข้าถึงรีโปรของผู้ใช้ใน Github และปรับใช้รหัสรีโปไปยังแพลตฟอร์มการจัดส่งโค้ด ในกรณีนี้ผู้ใช้จำเป็นต้องอนุญาต MCP Server ให้เข้าถึงรีโปร Github ของพวกเขาและเข้าถึงแพลตฟอร์มการจัดส่งโค้ด

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

ดังนั้นการอนุญาตบุคคลที่สามในโปรโตคอลที่ระบุควรแก้ปัญหาของ "วิธีที่ผู้ปลายทางอนุญาตให้เซิร์ฟเวอร์ MCP เข้าถึงทรัพยากรผู้ใช้บนเซิร์ฟเวอร์ทรัพยากรบุคคลที่สาม"

MCP Server ในฐานะเซิร์ฟเวอร์ทรัพยากร#

เมื่อ MCP Server ทำหน้าที่เป็นเซิร์ฟเวอร์ทรัพยากร MCP Server จำเป็นต้องตรวจสอบว่าคำขอของไคลเอนต์ MCP นำโทเค็นการเข้าถึงที่ถูกต้องมาหรือไม่ MCP Server จะตัดสินใจว่าจะอนุญาตให้ไคลเอนต์ MCP เข้าถึงทรัพยากรเฉพาะใด ๆ ขึ้นอยู่กับขอบเขตของโทเค็นการเข้าถึง

จากการนิยามของ MCP ทรัพยากรที่เซิร์ฟเวอร์ MCP มอบให้ควรจะเป็นเครื่องมือให้ไคลเอนต์ MCP ใช้ ในสถานการณ์นี้ MCP Server จำเป็นเพียงแค่ตัดสินใจว่าจะให้สิทธิ์การเข้าถึงเครื่องมือบางอย่างแก่ผู้ใช้หรือไม่

แต่ในสถานการณ์จริง เครื่องมือเหล่านี้ที่เซิร์ฟเวอร์ MCP มอบให้จะต้องมีการอินเตอร์แอคชั่นกับเซิร์ฟเวอร์ทรัพยากรของผู้ให้บริการเซิร์ฟเวอร์ MCP เองด้วย ในเวลานี้ โทเค็นการเข้าถึงที่ได้จากคำขอของไคลเอนต์ MCP Server จะต้องถูกนำไปใช้เพื่อเข้าถึงเซิร์ฟเวอร์ทรัพยากรของตนเอง ในกรณีส่วนใหญ่ MCP Server และเซิร์ฟเวอร์ทรัพยากรที่อยู่เบื้องหลังเครื่องมือเป็นนักพัฒนาคนเดียวกัน MCP Server เพียงแค่มอบอินเตอร์เฟซที่มีอยู่ในทรัพยากร backend ของตนเองให้ไคลเอค MCP ใช้ ในตอนนี้ MCP Server สามารถแชร์โทเค็นการเข้าถึงที่ออกให้โดยเซิร์ฟเวอร์การอนุญาตกับทรัพยากร backend ที่มีอยู่ของตนเองให้ด้วย

ในกรณีนี้ แทนที่จะกล่าวว่าเซิร์ฟเวอร์ MCP เป็นเซิร์ฟเวอร์ทรัพยากรที่มอบเครื่องมือและทรัพยากรของเซอร์วิสของตนเองไปให้ พูดได้ดีกว่าคือเซิร์ฟเวอร์ทรัพยากรที่มีอยู่กลายเป็นเซิร์ฟเวอร์ MCP โดยให้เครื่องมือแก่ไคลเอนต์ MCP ใช้

การรวมทรัพยากรที่จัดให้โดยเซิร์ฟเวอร์ทรัพยากรกับเครื่องมือที่จัดให้โดยเซิร์ฟเวอร์ MCP นั้นเป็นการพิจารณาถึงสถานการณ์จริง แต่ส่วนตัวข้าพเจ้ายังคงชอบให้ทรัพยากรที่จัดให้โดยเซิร์ฟเวอร์ MCP เพียงเป็นเครื่องมือที่ใช้โดยลูกค้า MCP และทรัพยากรที่เครื่องมือพึ่งพาควรเป็นทรัพยากรที่ได้่รับโดย MCP Server จากเซิร์ฟเวอร์ทรัพยากรอื่น (รวมสินค้าแรกและสินค้าอื่น) แบบนี้สถานการณ์จริงทั้งหมดสามารถครอบคลุมได้

วิธีการทำงานของการอนุญาต MCP#

หลังจากเข้าใจความรับผิดชอบของเซิร์ฟเวอร์ MCP ในฐานะเซิร์ฟเวอร์การอนุญาตและเซิร์ฟเวอร์ทรัพยากรแล้ว เราสามารถรู้ได้ว่าการอนุญาต MCP ทำงานอย่างไรบ้าง:

การลงทะเบียนลูกค้าแบบไดนามิก#

Spec ยังมีการนิยามวิธีการที่เซิร์ฟเวอร์การอนุญาตจะระบุตัวตนของลูกค้า OAuth 2.1 ให้โปรโตคอลลงทะเบียนลูกค้าแบบไดนามิก อนุญาตให้ไคลเอนต์ MCP สามารถรับ ID ลูกค้า OAuth โดยอัตโนมัติโดยไม่ต้องมีการแทรกในด้วยมือ

ตาม Spec, MCP Server ควรสนับสนุนโปรโตคอลการลงทะเบียนลูกค้าแบบไดนามิกของ OAuth 2.0 ดังนี้ไคลเอนต์ MCP สามารถลงทะเบียนกับเซิร์ฟเวอร์ใหม่โดยอัตโนมัติเพื่อรับ ID ลูกค้า OAuth วิธีการนี้แนะนำในสถานการณ์ MCP เป็นหลักเนื่องจาก:

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

อย่างไรก็ตาม จากมุมมองทางปฏิบัติ ข้าพเจ้ามีข้อคิดบางประการเกี่ยวกับการใช้งานการลงทะเบียนลูกค้าแบบไดนามิกในสถานการณ์ MCP:

• ในการฝึกหัดการทำบริการ OAuth จริง มีการเชื่อมโยงลูกค้าโดยตรงไปยังแอปพลิเคชันธุรกิจจริง การสร้างลูกค้าแบบไดนามิกอาจไม่ช่วยให้มีการจัดการทรัพยากรที่เกี่ยวข้อง (ผู้ใช้ แอปพลิเคชัน ฯลฯ) ในบริการ OAuth อย่างมีประสิทธิภาพ ผู้ให้บริการ OAuth มักจะต้องการควบคุมลูกค้าที่ติดต่ออย่างชัดเจนมากกว่าการให้ลูกค้าลงทะเบียนเป็นลูกค้าได้ตามอำเภอใจ
• บริการ OAuth ส่วนใหญ่ไม่แนะนำหรืออนุญาตให้ผู้ใช้สร้างลูกค้าใหม่แบบไดนามิกเพราะอาจนำไปสู่การใช้งานที่ผิดพลาดหรือฉ้อฉล บริการ OAuth ที่เป็นที่ยอมรับมากมาย (เช่น GitHub, Google เป็นต้น) ต้องการให้นักพัฒนาลงทะเบียนลูกค้าผ่านคอนโซลผู้พัฒนา และอาจจำเป็นต้องมอบข้อมูลรายละเอียดเกี่ยวกับแอปพลิเคชันเช่น URL คาลลัคแบ็ค เป็นต้น
• การลงทะเบียน OAuth Client แบบด้วยมือในความเป็นจริงเป็นงานที่ทำครั้งเดียวในระหว่างการพัฒนา ไม่ใช่สิ่งที่ผู้ใช้ปลายทางทุกคนต้องทำ จะไม่เป็นภาระหนักสำหรับนักพัฒนา
• สำหรับลูกค้าสาธารณะ (เช่น แอปพลิเคชัน native, แอปพลิเคชันหน้าเดียว ฯลฯ) เรามีวิธีที่ปลอดภัยกว่าในการทำโฟลว์ OAuth โดยไม่ต้องการการลงทะเบียนแบบไดนามิก คอมโบโอเน็ต Client ID กับ PKCE (Proof Key for Code Exchange) สามารถให้โฟลว์ OAuth ที่ปลอดภัยพอสำหรับลูกค้าสาธารณะที่ต้องการ
• แม้ว่าโปรโตคอลระบุว่าการใช้การลงทะเบียนลูกค้าแบบไดนามิกสามารถโอนไคลเอ็นต์ไม่ต้องทราบ Client ID ล่วงหน้า แต่ในความจริงแล้ว ไคลเอ็นต์ MCP ต้องทราบอย่าล่วงหน้าที่อยู่เซิร์ฟเวอร์ MCP ระยะไกล หากเป็นเช่นนั้น, การระบุ Client ID ระหว่างส่งข้อมูลที่อยู่ MCP ระยะไกลจะไม่สร้างปัญหาเพิ่มเติมอย่างมากเลย หรือเรายังสามารถสร้างข้อตกลงว่าไคลเอ็นต์ MCP สามารถขอ Client ID จากเซิร์ฟเวอร์ MCP ที่ไม่ยากเช่นกัน

แม้ว่าโปรโตคอลการลงทะเบียนลูกค้าแบบไดนามิกจะให้ความยืดหยุ่นแก่ระบบนิเวศ MCP ในทฤษฎีจริง ในการใช้งานจริง, เราอาจจำเป็นต้องพิจารณาว่าเราจำเป็นต้องใช้กลไกการลงทะเบียนแบบไดนามิกนี้หรือไม่ ในผลิตภัณฑ์บริการส่วน ตรวจสอบเงินในมือถือแบบด้วยมือและควบคุม OAuth Client อาจเป็นวิธีการที่สามารถสัมผัสได้และปลอดภัยมากกว่า

สรุป#

บทความนี้ได้วิเคราะห์อย่างละเอียดเกี่ยวกับปรัชญาการออกแบบและความท้าทายในการใช้งานของ Spec การอนุญาต MCP ในฐานะกรอบการทำงานการอนุญาตที่ใช้ OAuth 2.1 เป้าหมายของ Spec นี้คือการไขปัญหาหลักของวิธีที่เซิร์ฟเวอร์ MCP ระยะไกลสามารถเข้าถึงทรัพยากรของผู้ใช้ในนามของพวกเขาได้อย่างไร

ผ่านการอภิปรายละเอียดเกี่ยวกับบทบาทของ MCP Server ในฐานะเซิร์ฟเวอร์การอนุญาตและเซิร์ฟเวอร์ทรัพยากร รวมถึงข้อดีและข้อเสียของกลไกเช่นการลงทะเบียนลูกค้าแบบไดนามิกและการมอบหมายการอนุญาตบุคคลที่สาม บทความนี้ได้เสนอมุมมองและข้อเสนอแนะจากประสบการณ์ส่วนตัวในการนำ Authenticator ไปใช้

น่าทำความเข้าใจว่า Spec การอนุญาต MCP ยังคงมีการพัฒนาอยู่ ในฐานะสมาชิกของทีม Logto พวกเราจะเฝ้าติดตามการพัฒนาใหม่ ๆ ของ Spec นี้อย่างต่อเนื่องและปรับปรุงโซลูชันการใช้งานของพวกเราในทางปฏิบัติเพื่อสนับสนุนการโต้ตอบที่ปลอดภัยระหว่างโมเดล AI และบริการภายนอกให้ดียิ่งขึ้น