MCP ไม่ใช่ตัวเชื่อมต่อ — เป็นช่องทางการกำกับดูแลของคุณสำหรับยุคตัวแทน

ปัญหาการจัดเฟรม: "ตัวเชื่อมต่อ" เน้นย้ำการตัดสินใจที่คุณกำลังทำอยู่

เมื่อ Anthropic เปิดตัว Model Context Protocol (MCP) ในเดือนพฤศจิกายน 2024 เพื่อเป็นมาตรฐานแบบเปิดสำหรับการเชื่อมต่อระบบ AI กับแหล่งข้อมูลและเครื่องมือทางธุรกิจ อุตสาหกรรมก็ทำสิ่งที่มักจะทำกับข้อกำหนดการผสานรวมใหม่ นั่นคือเก็บ MCP ไว้ใต้ท่อประปา อะแดปเตอร์ การขนย้าย วิธีที่เป็นระเบียบเรียบร้อยในการหยุดเขียนกาวแบบครั้งเดียวสำหรับทุกรุ่นและทุกเครื่องมือ เป็นจริงทั้งหมด และนอกประเด็นหากคุณนั่งอยู่ในเก้าอี้ CIO, CTO หรือ CISO

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

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

เหตุใด "การผสานรวมแบบกำหนดเองจำนวนมาก" จึงสร้างการกำกับดูแลขึ้นมาใหม่หลายครั้งโดยเงียบๆ

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

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

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

บริบทของข้อมูลประจำตัวและผู้เช่า: ตัดสินใจที่ประตู ไม่ใช่ในเครื่องมือ

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

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

นี่เป็นที่ที่คุณโทรออกว่าตัวแทนไม่ใช่ผู้ใช้ มนุษย์ในคอนโซลมีสายตา ความลังเล และเป็นผู้จัดการ ตัวแทนมีการวนซ้ำ ข้อมูลระบุตัวตนและบริบทที่คุณให้ควรสะท้อนให้เห็นว่าสามารถดำเนินการได้รวดเร็วและตรงตามความเป็นจริงมากกว่าบุคคลใดๆ ที่คุณจัดเตรียมไว้

การอนุญาตต่อเครื่องมือ: การเปิดเผยข้อมูลเป็นการตัดสินใจ ไม่ใช่ค่าเริ่มต้น

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

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

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

การเขียนแบบปิดไม่สำเร็จ: ความไม่สมดุลระหว่างการอ่านและการแสดง

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

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

มีมิติทางวัฒนธรรมอยู่ที่นี่ วิศวกรปรับให้เหมาะสมสำหรับสิ่งต่าง ๆ ที่ทำงาน; การรักษาความปลอดภัยจะปรับให้เหมาะสมสำหรับสิ่งต่าง ๆ ที่ไม่เสียหายในลักษณะที่เลวร้ายที่สุด พื้นผิวการกำกับดูแลคือที่ที่คุณเข้ารหัสว่าวิธีที่แย่ที่สุด — การเขียนที่ไม่ได้รับอนุญาตซึ่งดำเนินการอย่างเงียบๆ — นั้นเป็นสิ่งที่ยอมรับไม่ได้ แม้ว่าจะต้องแลกกับการปฏิเสธการเขียนเป็นครั้งคราวก็ตาม

บัญชีงบประมาณและสวิตช์ปิด: การควบคุมต้นทุนเป็นการควบคุมหลัก

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

กลไกที่เราดำเนินการคือบัญชีแยกประเภทงบประมาณที่ประเมินก่อนการใช้จ่ายใดๆ โดยมีขีดจำกัดต่อการดำเนินการ ต่อวัน และขีดจำกัด 30 วัน รวมถึงการตรวจสอบ Kill-Switch ก่อนดำเนินการ โปรดสังเกตการจัดลำดับ: งบประมาณและ Kill Switch จะได้รับการประเมินก่อนการใช้จ่าย และจะไม่กระทบยอดหลังจากนั้น การแจ้งเตือนที่บอกคุณว่าคุณใช้จ่ายเกินกำหนดถือเป็นการชันสูตรพลิกศพ บัญชีแยกประเภทที่ปฏิเสธการโทรเกินงบประมาณคือการควบคุม ขอบเขตเวลาทั้งสามมีความสำคัญเนื่องจากโหมดความล้มเหลวมีรูปร่างที่แตกต่างกัน — การวนซ้ำที่ควบคุมไม่ได้ทำให้ขีดจำกัดต่อการรัน กำหนดการที่กำหนดค่าไม่ถูกต้องจะทำให้ขีดจำกัดต่อวันลดลง และการคืบคลานที่ช้าจะแสดงเฉพาะกับกรอบเวลา 30 วันเท่านั้น

สวิตช์ปิดการทำงานสมควรได้รับบรรทัดแยกต่างหากในการออกแบบ มันคือตัวควบคุมที่คุณใช้เมื่อคุณยังไม่เข้าใจว่าเกิดอะไรขึ้นและคุณต้องการให้กิจกรรมนั้นหยุดลงทันที เมื่อได้รับการประเมินก่อนการดำเนินการ มันคือตัวตัดวงจร ไม่ใช่เครื่องมือทำความสะอาด โปรแกรมเอเจนต์ทุกโปรแกรมควรสามารถตอบคำถามหนึ่งข้อได้ทันที: เราจะหยุดมันได้อย่างไร? หากคำตอบเกี่ยวข้องกับการเรียกทีมสามทีมและเพิกถอนคีย์ด้วยตนเอง คุณไม่มีสวิตช์ปิดการทำงาน — คุณมีเพียงความหวัง

การตรวจสอบและการแก้ไข: มีขอบเขต มีกำหนดเวลา และสังเกตได้

การกำกับดูแลที่ไม่สามารถสังเกตได้นั้นไม่ใช่การกำกับดูแล แต่มันคือเจตนา ชั้นสุดท้ายของพื้นผิวคือชั้นที่ทำให้ทุกสิ่งทุกอย่างที่อยู่เหนือกว่านั้นสามารถพิสูจน์ได้ในภายหลัง คีย์ของเอเจนต์ควรถูกจำกัดขอบเขตให้เฉพาะเครื่องมือที่พวกเขาต้องการจริงๆ และกำหนดเวลาไว้ เพื่อให้รัศมีของการโจมตีของข้อมูลประจำตัวลดลงเหลือศูนย์ตามกำหนดเวลา แทนที่จะคงอยู่ตลอดไป คีย์ที่สามารถทำอะไรก็ได้ตลอดไปคือสิ่งประดิษฐ์ที่พบได้บ่อยที่สุดในซากปรักหักพังของการตรวจสอบเหตุการณ์

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

เมื่อรวมกันแล้ว คุณสมบัติเหล่านี้ เช่น คีย์ที่กำหนดขอบเขต ขอบเขตเวลา การแก้ไขต่อการโทร การตรวจสอบแบบสม่ำเสมอ ให้ CISO ตอบคำถามที่ถูกถามจริงหลังเหตุการณ์: ข้อมูลรับรองนี้ทำอะไรได้บ้าง ทำได้นานแค่ไหน จริง ๆ แล้วทำอะไร และเราสามารถพิสูจน์ได้โดยไม่ต้องรั่วไหลมากกว่านี้ในการพิสูจน์

เชื่อมโยงกับความเสี่ยงอย่างต่อเนื่อง และซื่อสัตย์เกี่ยวกับสิ่งที่เหลืออยู่

ทั้งหมดนี้ไม่ใช่การตั้งค่าเพียงครั้งเดียว กรอบการจัดการความเสี่ยงของ NIST AI (AI RMF 1.0) มีความชัดเจนว่าการจัดการความเสี่ยงของ AI เป็นกระบวนการที่ต่อเนื่อง ไม่ใช่รายการตรวจสอบที่คุณกรอกและเก็บไว้ พื้นผิวการกำกับดูแลมีคุณค่าอย่างยิ่ง เนื่องจากทำให้กระบวนการที่ต่อเนื่องมีที่เดียวในการดำเนินการ: เมื่อมีความเสี่ยงใหม่เกิดขึ้น คุณสามารถปรับการอนุญาต งบประมาณ การเปิดเผย หรือการตรวจสอบในอินเทอร์เฟซเดียว แทนที่จะไล่ตามการเปลี่ยนแปลงในการบูรณาการ N การกำหนดมาตรฐานคือสิ่งที่ทำให้การกำกับดูแลอย่างต่อเนื่องทำได้ง่าย แทนที่จะทำตามความทะเยอทะยาน นี่ยังเป็นสาเหตุที่การตัดสินใจเปิดรับแสงอย่างรอบคอบให้ผลตอบแทนสองเท่า ครั้งแรกเมื่อคุณตัดสินใจ และอีกครั้งทุกครั้งที่คุณต้องกลับมาดูอีกครั้ง

ซื่อสัตย์เกี่ยวกับความเสี่ยงคงเหลือ เพราะบอร์ดของคุณจะเป็นเช่นนั้น พื้นผิวการกำกับดูแลทำให้พื้นผิวการโจมตีแคบลงและทำให้สามารถตรวจสอบกิจกรรมได้ มันไม่ได้ทำให้ตัวแทนไม่มีข้อผิดพลาด การฉีดยาทันทียังสามารถพยายามคัดท้ายตัวแทนที่ได้รับอนุญาตอย่างถูกต้องตามกฎหมายไปสู่การใช้งานในทางที่ผิดที่ดูถูกกฎหมาย เครื่องมือที่ถูกเปิดเผยโดยเจตนายังคงสามารถนำมาใช้ในทางที่ผิดได้ภายใต้การอนุญาต งบประมาณผูกมัดต้นทุนแต่ไม่ตัดสิน การวิจัย "สถานะของ AI ในองค์กร" ของ Deloitte ได้แสดงให้เห็นซ้ำแล้วซ้ำเล่าถึงช่องว่างระหว่างความทะเยอทะยานของ AI และความพร้อมในการปฏิบัติงานเพื่อควบคุมมัน และช่องว่างนั้นเองที่ทำให้ความเสี่ยงที่เหลืออยู่เหล่านี้ยังคงอยู่ การตอบสนองที่ถูกต้องไม่ใช่การอ้างว่า Gap ปิดแล้ว แต่เพื่อทำให้ Gap มีขนาดเล็ก สังเกตได้ และจัดการอย่างต่อเนื่อง

เราได้สร้างแพลตฟอร์มของเราบนความเชื่อมั่นนี้ SocialHub.AI เปิดเผยเครื่องมือเลเยอร์ความหมายบน MCP โดยใช้การขนส่งแบบสตรีม HTTP ซึ่งสามารถเข้าถึงได้จากตัวแทนเช่น Claude, GitHub Copilot และ Microsoft 365 Copilot โดยมีการควบคุมที่อธิบายไว้ที่นี่ใช้ที่อินเทอร์เฟซแทนที่จะกระจายข้ามตัวเชื่อมต่อ: การอนุญาตแบบสามแกนพร้อมระดับจากบริบทของผู้เช่า, การเขียนที่ปิดล้มเหลว, บัญชีแยกประเภทงบประมาณต่อการดำเนินการ/ต่อวัน/30 วันพร้อม kill-switch ก่อนดำเนินการ และคีย์เอเจนต์ที่มีการกำหนดขอบเขตและมีขอบเขตเวลาพร้อมการแก้ไขและการตรวจสอบต่อการโทร วินัยในการกำกับดูแลแบบเดียวกันนี้เป็นรากฐานของงานด้านความภักดี โดยที่เราช่วยเพิ่มการมีส่วนร่วมของ GMV ของสมาชิก McDonald's China จากประมาณ 5% เป็น 85% ผลลัพธ์ในระดับนั้นจะคงอยู่ได้ก็ต่อเมื่ออินเทอร์เฟซกับข้อมูลเชื่อถือได้โดยการก่อสร้างเท่านั้น

หากคุณกำลังตัดสินใจว่าตัวแทนจะเข้าถึงระบบบันทึกข้อมูลของคุณอย่างไร คำถามที่คุณควรถามทีมของคุณไม่ใช่ "ตัวเชื่อมต่อใด" แต่เป็น "การระบุตัวตน การอนุญาต การบันทึก และต้นทุนจะถูกตัดสินใจที่ไหน และเป็นการตัดสินใจในที่เดียวหรือหลายที่" หากคุณต้องการดูว่าพื้นผิว MCP ที่เน้นการกำกับดูแลเป็นหลักนั้นมีลักษณะอย่างไรในทางปฏิบัติ จองการสาธิต หรืออ่านเพิ่มเติมเกี่ยวกับแนวทางของเราได้ที่ /platform/ai-frontier