การรักษาความปลอดภัยให้กับ AI Agent ด้วยเครื่องมือ Laravel MCP
การให้ AI agent เข้าถึงแอปของคุณผ่าน MCP เปรียบเสมือนการยื่นพวงกุญแจให้ใครสักคน หากคุณไม่กำหนดกฎเกณฑ์ พวกเขาอาจจะเปิดประตูผิดบานได้
เมื่อเร็วๆ นี้ ผมได้สร้างเครื่องมือ MCP สำหรับแอป Laravel แบบ multi-tenant โดยมีเป้าหมายเดียวคือ: ให้ agent สามารถควบคุมแอปได้โดยไม่ยอมให้มันเห็นข้อมูลของคนอื่น
ปัญหาของเครื่องมือ MCP
เครื่องมือ MCP ทุกตัวคือ endpoint เมื่อ agent เรียกใช้เครื่องมือ เซิร์ฟเวอร์ของคุณก็จะรันโค้ด ในแอปแบบ multi-tenant เครื่องมือทุกตัวต้องตอบคำถามสองข้อ:
- คุณได้รับอนุญาตให้ทำสิ่งนี้หรือไม่?
- คุณได้รับอนุญาตให้ทำสิ่งนี้ในองค์กรที่ระบุนี้หรือไม่?
หากคุณพลาดข้อใดข้อหนึ่ง ข้อมูลจะรั่วไหลทันที
ทำไมระบบ Multi-Tenancy มาตรฐานถึงใช้ไม่ได้ในกรณีนี้
ในเว็บแอปทั่วไป คุณจะมี session คุณใช้ global scopes เพื่อกรองข้อมูลตาม organization ID ซึ่งมันใช้งานได้เพราะ "องค์กรปัจจุบัน" จะอยู่ใน session เสมอ
แต่เครื่องมือ MCP ไม่ได้ใช้ session พวกมันใช้ token และไม่มี middleware สำหรับกำหนด tenant context หากคุณพึ่งพา global scope ที่มองหา session มันจะไม่พบอะไรเลย และอาจส่งคืนข้อมูลทุกแถวในฐานข้อมูลของคุณ ซึ่งนั่นคือการรั่วไหลของข้อมูลแบบเงียบๆ (silent data leak)
ทางออก: การกรองข้อมูลแบบระบุเจาะจง (Explicit Filtering)
อย่าพึ่งพา ambient scope เมื่อใช้การยืนยันตัวตนด้วย token ให้ทำการกรองข้อมูลแบบระบุเจาะจงทุกครั้ง
ผมได้สร้าง trait ตัวเดียวเพื่อจัดการเรื่องนี้:
trait ResolvesOrgEvents
{
protected function resolveOrgEvent(Authenticatable $user, string $uuid): ?Event
{
if (empty($user->organization_id)) {
return null;
}
return Event::query()
->withOrganization($user->organization_id)
->where('uuid', $uuid)
->first();
}
}
แนวทางนี้ปฏิบัติตามกฎ 4 ข้อ:
- ใช้ UUIDs: อย่าใช้ auto-increment IDs โดยเด็ดขาด agent ไม่ควรจะสามารถเดา ID ได้จากการเปลี่ยนตัวเลข
- แหล่งข้อมูลความจริงหนึ่งเดียว (Single Source of Truth): ตัวกรององค์กรจะรวมอยู่ใน trait เดียว และเครื่องมือทุกตัวจะใช้งานมัน
- ใช้สิทธิ์เดิมที่มีอยู่: อย่าสร้าง permission ใหม่สำหรับ agent ให้ใช้ permission strings ชุดเดียวกับที่เว็บแอปของคุณใช้ เพื่อป้องกันไม่ให้ agent มีอำนาจมากกว่าผู้ใช้งานที่เป็นมนุษย์
- ระบุผลกระทบข้างเคียง (Side Effects): ใช้ annotations เพื่อแสดงว่าเครื่องมือนั้นเป็นแบบอ่านอย่างเดียว (read-only) หรือสามารถเขียนได้ (write-enabled)
การทดสอบขอบเขต
คุณต้องทดสอบกรณีที่ผิดพลาด (negative path) อย่าทดสอบแค่ว่าเครื่องมือทำงานได้หรือไม่ แต่ต้องทดสอบด้วยว่าผู้ใช้จากองค์กร A ไม่สามารถเห็นข้อมูลขององค์กร B ได้
หาก agent พยายามเข้าถึง UUID ของ tenant อื่น เครื่องมือควรส่งคืนค่า "not found" และไม่ควรบอก agent ว่าข้อมูลนั้นมีอยู่จริงแต่เป็นของคนอื่น
จงปฏิบัติกับเครื่องมือ AI ทุกตัวเหมือนเป็น endpoint ที่ไม่น่าเชื่อถือ วินัยคือวิธีเดียวที่จะรักษาความปลอดภัยของข้อมูลคุณได้
