เปิด Tool ให้ Agent อ่านอย่างเดียว กับเปิดให้เขียนด้วย เสี่ยงต่างกันแค่ไหน

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

ความเสี่ยงที่เหลือมักซ่อนอยู่ในรายละเอียดที่ดูเหมือนไม่เกี่ยวกับ Security โดยตรง เช่น Tool ตัวหนึ่งเปิดให้แก้ไขข้อมูลได้กว้างแค่ไหน Resource ที่ AI อ่านได้มีข้อมูลอ่อนไหวปนอยู่หรือไม่ หรือ Server ที่เอามาใช้เขียนโดยคนนอกทีมผ่านการตรวจสอบมาแล้วจริงหรือเปล่า

บทความนี้แยกความเสี่ยงของ MCP ออกเป็นมิติต่าง ๆ ที่ทีมพัฒนาต้องตรวจให้ครบ ไม่ใช่หยุดแค่ที่ Authentication ชั้นเดียว

แผนที่ความเสี่ยงของ MCP ไม่ได้มีแค่เรื่อง Authentication อย่างเดียว

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

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

เปิด Tool อ่านอย่างเดียว กับเปิดให้เขียนด้วย เสี่ยงต่างกันแค่ไหน

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

ใช้ MCP Server ที่คนอื่นเขียนไว้แล้ว ต้องตรวจอะไรก่อนเชื่อม

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

ก่อนนำ MCP Server จากภายนอกมาใช้ ควรตรวจอย่างน้อยว่าใครเป็นผู้ดูแล มีการอัปเดตต่อเนื่องหรือไม่ ขอ Permission กว้างเกินความจำเป็นของ Use Case หรือเปล่า และถ้าเป็นไปได้ควรทดสอบใน Environment แยกก่อนเชื่อมกับระบบที่มีข้อมูลจริง เหมือนกับการตรวจสอบ Dependency ใหม่ทุกตัวก่อนติดตั้งในโปรเจกต์สำคัญ

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

Resource ที่เปิดให้ AI อ่าน อาจรั่วข้อมูลมากกว่าที่ตั้งใจได้อย่างไร

ตัวอย่างสมมติ: ทีมพัฒนาเปิด Resource ชื่อ recent_error_logs ให้ AI อ่านเพื่อช่วย Debug ปัญหา โดยตั้งใจให้เห็นแค่ข้อความ Error แต่ Log จริงในระบบมักมีรายละเอียดอื่นติดมาด้วยโดยไม่ตั้งใจ เช่น Token ภายใน ที่อยู่ IP หรือแม้แต่ข้อมูลลูกค้าบางส่วนที่หลุดเข้าไปอยู่ใน Log ตอนเกิด Error พอ Resource เปิดให้อ่านทั้งไฟล์ ข้อมูลอ่อนไหวเหล่านี้ก็ไหลเข้าไปอยู่ใน Context ของโมเดลไปด้วยโดยไม่มีใครตั้งใจ

ปัญหานี้ต่างจากการเขียน Tool ตรงที่ทีมมักไม่ได้คิดเรื่องการกรองข้อมูลตอนออกแบบ Resource เพราะมองว่าเป็นแค่การ 'อ่าน' ไม่ใช่ 'สั่งงาน' ทั้งที่ความเสี่ยงเรื่องข้อมูลรั่วสามารถเกิดจาก Resource ได้พอ ๆ กับ Tool ทางแก้คือต้องกรองหรือ Mask ข้อมูลอ่อนไหวก่อนส่งเข้า Resource เสมอ ไม่ใช่ส่งข้อมูลดิบทั้งก้อนเพราะคิดว่าสะดวกกว่า

Tool ที่ทำลายข้อมูลได้ ควรมีมนุษย์ยืนยันก่อนเสมอหรือไม่

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

รูปแบบที่ทีมส่วนใหญ่ใช้คือให้ Tool ประเภทนี้คืนค่าเป็น 'แผนการทำงาน' ก่อน ไม่ใช่ลงมือทำทันที เช่น Tool แสดงว่าจะลบรายการอะไรบ้างก่อน แล้วรอการยืนยันจากผู้ใช้อีกครั้งก่อนเรียก Tool ตัวที่ลงมือทำจริง การแยกขั้น 'วางแผน' กับ 'ลงมือทำ' ออกจากกันแบบนี้ช่วยลดความเสี่ยงได้มากโดยไม่ต้องตัดความสามารถของ Agent ออกทั้งหมด

แยก Environment ทดสอบกับ Production อย่างไรให้พังแล้วไม่ลามข้ามระบบ

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

แนวทางที่ปลอดภัยคือมี MCP Server แยกชุดสำหรับทดสอบ เชื่อมกับข้อมูลจำลองหรือ Environment แยกต่างหากเสมอ และกำหนดให้ชัดว่า Credential ของ Environment ทดสอบต้องไม่มีสิทธิ์แตะข้อมูล Production ได้เลย ไม่ใช่แค่ 'ตั้งใจ' จะไม่ใช้ผิด แต่ต้องกันไว้ในระดับสิทธิ์จริง เพื่อไม่ให้ความผิดพลาดของมนุษย์กลายเป็นความเสียหายของระบบจริง

ตัวอย่างสมมติ: ทีมพัฒนากำลังปรับคำอธิบาย Tool ชื่อ archive_old_records ให้โมเดลเข้าใจง่ายขึ้น ระหว่างทดลองหลายรอบ Agent เรียก Tool นี้ไปโดยที่ทีมยังไม่ได้ตรวจสอบ Input ให้รอบคอบพอ ถ้า Server ทดสอบเชื่อมกับข้อมูลจำลอง ผลลัพธ์ที่แย่ที่สุดคือข้อมูลจำลองเสียหาย แก้ไขใหม่ได้ทันที แต่ถ้าเผลอเชื่อมกับข้อมูล Production ตั้งแต่ต้น ข้อมูลจริงอาจถูกย้ายหรือลบไปโดยไม่ตั้งใจในระหว่างที่ยังทดลองอยู่

Log ที่ต้องมีเพื่อสืบสวนเมื่อเกิดเหตุการณ์ผิดปกติ

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

1. เก็บ Log ทุกครั้งที่มีการเรียก Tool พร้อมตัวตนของ Token หรือ Session ที่เรียก ไม่ใช่แค่ชื่อ Tool
2. เก็บ Input และผลลัพธ์ของ Tool ที่มีผลต่อการเขียนข้อมูล แยกจาก Tool ที่แค่อ่านอย่างเดียว
3. ตั้งระบบแจ้งเตือนเมื่อมีการเรียก Tool ที่มีความเสี่ยงสูงนอกเวลาทำการปกติหรือถี่ผิดปกติ
4. เก็บ Log ให้นานพอสำหรับสืบสวนย้อนหลัง ไม่ใช่ลบทิ้งเร็วเกินไปเพราะกังวลเรื่องพื้นที่จัดเก็บ

จุดพลาดด้าน Security ที่ทีมมักมองข้ามตอนเริ่มใช้ MCP

นอกจากประเด็นที่อธิบายไปแล้ว ยังมีข้อผิดพลาดเล็ก ๆ ที่สะสมกันจนกลายเป็นความเสี่ยงใหญ่ได้ ถ้าไม่มีใครในทีมคอยตรวจสอบตั้งแต่ต้น

• เปิด Tool เขียนข้อมูลทุกตัวให้ Agent ตั้งแต่วันแรก ทำแบบนี้แล้วพัง เพราะยังไม่มีข้อมูลพอจะรู้ว่าโมเดลเรียกแม่นแค่ไหน ควรเริ่มจาก Tool อ่านข้อมูลก่อนเสมอ
• เชื่อ MCP Server จากภายนอกโดยไม่อ่านโค้ดหรือตรวจผู้ดูแล ทำแบบนี้แล้วพัง เพราะ Server ตัวนั้นมีสิทธิ์เข้าถึงระบบจริงเหมือนโค้ดที่ทีมเขียนเอง แต่ไม่มีใครในทีมรับผิดชอบตรวจสอบ
• ปล่อยให้ Resource ส่งข้อมูลดิบทั้งไฟล์โดยไม่กรอง ทำแบบนี้แล้วพัง เพราะข้อมูลอ่อนไหวที่ปนอยู่ในไฟล์ Log หรือฐานข้อมูลจะไหลเข้า Context ของโมเดลโดยไม่มีใครตั้งใจ
• ใช้ Credential ชุดเดียวกันทั้ง Environment ทดสอบและ Production ทำแบบนี้แล้วพัง เพราะความผิดพลาดระหว่างทดลองจะลามไปกระทบข้อมูลจริงทันทีโดยไม่มีชั้นกันไว้เลย

สรุป

MCP Security เป็นเรื่องที่ต้องมองหลายชั้นพร้อมกัน ตั้งแต่ขอบเขตของ Tool ที่เปิดให้เรียก ข้อมูลที่ Resource เปิดเผย ความน่าเชื่อถือของ Server ที่นำมาใช้ ไปจนถึงการแยก Environment ทดสอบออกจาก Production ทีมที่ทำแค่เรื่อง Authentication แล้วหยุด มักพลาดในมิติอื่นที่ความเสียหายเกิดขึ้นได้จริงเช่นกัน

จุดเริ่มต้นที่ปลอดภัยที่สุดสำหรับทีมที่เพิ่งเริ่มใช้ MCP คือเปิด Tool อ่านข้อมูลก่อนเสมอ ตรวจสอบ Server จากภายนอกก่อนเชื่อม และแยก Environment ทดสอบให้ชัดเจนตั้งแต่วันแรก ก่อนจะขยับไปเปิด Tool ที่เขียนหรือแก้ไขข้อมูลเมื่อมั่นใจในพฤติกรรมของ Agent มากขึ้น

• Security ของ MCP มีสี่มิติหลัก คือขอบเขต Tool ข้อมูลใน Resource ความน่าเชื่อถือของ Server และการแยก Environment
• Tool ที่เขียนหรือทำลายข้อมูลย้อนกลับไม่ได้ ควรมีมนุษย์ยืนยันก่อนเสมอ ไม่ปล่อยให้ Agent ทำงานอัตโนมัติเต็มรูปแบบ
• Resource ที่เปิดให้ AI อ่านต้องกรองข้อมูลอ่อนไหวก่อนเสมอ เพราะความเสี่ยงข้อมูลรั่วไม่ได้จำกัดอยู่แค่ที่ Tool
• ต้องมี Log ครบทุกการเรียก Tool เพื่อสืบสวนย้อนหลังได้ เมื่อพบพฤติกรรมผิดปกติของ Agent

คำถามที่พบบ่อย