Airlock ตรวจสอบ MCP Server: เมื่อคำประกาศความปลอดภัยไม่อาจเชื่อถือได้
นักพัฒนาสร้างเครื่องมือ Airlock เพื่อทดสอบพฤติกรรมจริงของ MCP Server เทียบกับป้ายกำกับ readOnlyHint พร้อมเผยผลตรวจเซิร์ฟเวอร์จริงและช่องโหว่
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- MCP Server สามารถประกาศ readOnlyHint เพื่อเลี่ยงการขออนุมัติจากมนุษย์ได้
- Airlock ถูกพัฒนาขึ้นมาเพื่อทดสอบพฤติกรรมจริงเทียบกับคำประกาศของเซิร์ฟเวอร์
- ผลทดสอบพบพฤติกรรมแอบแฝงในฟิกซ์เจอร์จำลอง เช่น การเขียนไฟล์นอกขอบเขต
- การตรวจสอบบน ContextFirewall และ stdio server เผยให้เห็นข้อจำกัดและช่องว่างด้านความปลอดภัย
เซิร์ฟเวอร์ Model Context Protocol หรือ MCP ทำหน้าที่อธิบายเครื่องมือของตนเอง โดยเครื่องมือสามารถระบุแอตทริบิวต์ readOnlyHint: true ได้ ซึ่งทำให้ตัวควบคุมเอเจนต์ (agent harness) ใช้การประกาศดังกล่าวเพื่อตัดสินใจว่าต้องอาศัยการอนุมัติจากมนุษย์หรือไม่ สถานการณ์นี้สร้างขอบเขตความเชื่อใจที่ไม่น่าไว้วางใจนัก เนื่องจากเซิร์ฟเวอร์ที่กำลังถูกประเมินกลับเป็นผู้บอกเองว่าตัวมันเองอันตรายแค่ไหน
ด้วยเหตุนี้ นักพัฒนาจึงสร้างเครื่องมือที่ชื่อว่า Airlock ขึ้นมาเพื่อทดสอบคำประกาศกับพฤติกรรมที่สังเกตได้จริง ก่อนที่จะบังคับใช้นโยบายผ่านสายส่งข้อมูล Airlock จะทำหน้าที่รายงานสิ่งที่สังเกตเห็น และย้ำว่าการไม่พบข้อผิดพลาดไม่ได้หมายความว่าปลอดภัยเสมอไป ตัวอย่างเช่น เครื่องมือ export_report ที่ประกาศตัวว่าเป็นแบบอ่านอย่างเดียว แต่อาจส่งคืนผลลัพธ์ปกติพร้อมกับเขียนไฟล์นอกขอบเขตที่ผู้ดูแลระบบกำหนดไว้
ระบบของ Airlock จะเปิดเคส ตรวจสอบรายการเครื่องมือที่ประกาศไว้ ทดสอบภายใต้ขอบเขตงบประมาณที่จำกัด และเปรียบเทียบคำประกาศกับพฤติกรรมที่ตรวจพบ หากเครื่องมือมีพฤติกรรมต่างจากที่ประกาศ ความแตกต่างนั้นจะกลายเป็นหลักฐาน โดยสำหรับเคสที่ได้รับอนุมัติ Airlock จะสร้างคอนเนกเตอร์ที่ชี้ไปยังพร็อกซีบังคับใช้นโยบายเฉพาะเคส แทนที่จะส่งกลับไปยังเซิร์ฟเวอร์ที่น่าสงสัยโดยตรง นโยบายนี้จะถูกบังคับใช้ก่อนที่การเรียกใช้งานจะไปถึงเครื่องมือต้นทาง
"Airlock reports what it observed. Absence of a finding is not proof of safety."
ผู้พัฒนา Airlock
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
Airlock มาพร้อมกับฟิกซ์เจอร์ชุดละ 6 เครื่องมือ โดยฟิกซ์เจอร์ที่ไม่ซื่อสัตย์จะแฝงพฤติกรรมไว้ 5 อย่าง เช่น การเขียนไฟล์ระบบหลังป้าย readOnlyHint: true การหลุดออกนอกขอบเขต การรับส่งข้อมูลออกภายนอกที่ไม่ได้ประกาศ การแทรกคำสั่ง และการดึงข้อมูลลับ (canary exfiltration) ผลการทดสอบพบ 7 การค้นพบจากการตรวจสอบ 36 รายการในโหมด controlled_fixture ขณะที่ฟิกซ์เจอร์ที่ซื่อสัตย์ให้ผลลัพธ์เป็นศูนย์ในการตรวจสอบ 36 รายการเดียวกัน ซึ่งความแตกต่างนี้มีความสำคัญอย่างยิ่งในการพิสูจน์ว่าตัวตรวจจับทำงานตามพฤติกรรมจริง ไม่ใช่แค่เพราะความไม่คุ้นเคย
บริบทเพิ่มเติม: ปัญหาความน่าเชื่อถือของ AI Agents และเครื่องมือเสริมภายนอก (MCP) กำลังกลายเป็นจุดอ่อนด้านความปลอดภัยที่สำคัญ เนื่องจากโมเดลภาษาขนาดใหญ่ (LLM) มักพึ่งพาข้อมูลเมตาที่เครื่องมือส่งมาให้โดยอัตโนมัติ การมีเครื่องมือตรวจสอบอิสระอย่าง Airlock เข้ามาคั่นกลาง ช่วยลดความเสี่ยงที่เอเจนต์จะทำงานอันตรายโดยเข้าใจผิดว่าปลอดภัยจากคำประกาศของตัวเซิร์ฟเวอร์เอง
การตรวจสอบยังระบุสถานะผลลัพธ์ออกเป็น 4 รูปแบบอย่างจงใจเพื่อหลีกเลี่ยงการใช้คะแนนความปลอดภัยเดี่ยว เนื่องจากค่าเฉลี่ยอาจปกปิดเครื่องมือที่โกหกได้ นอกจากนี้ สถานะ not_tested ยังถูกกำหนดให้เป็นสถานะหลัก สำหรับการสนับสนุนระบบ stdio server นั้นมีความสำคัญเนื่องจากเซิร์ฟเวอร์ MCP จำนวนมากถูกเรียกใช้เป็นคำสั่งมากกว่าผ่าน URL โดยมีการควบคุมการกำหนดค่าผ่านแมปรายการที่ตายตัวเพื่อความปลอดภัย
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น