กำลังเตรียมประสบการณ์ดิจิทัล
พนักงานเชื่อม AI agent เข้ากับเครื่องมือภายในองค์กรได้ด้วยการตั้งค่าเพียงบรรทัดเดียว ทำให้เกิด Shadow MCP ที่ฝ่ายไอทีมองไม่เห็น บทความนี้สรุปวิธีตรวจจับทราฟฟิก MCP ความเสี่ยงที่ต่างจากผู้ใช้ที่เป็นมนุษย์ และแนวทางไล่จากการมองเห็นไปสู่การกำกับดูแล
พนักงานเชื่อม AI agent เข้ากับเครื่องมือภายในองค์กรได้ด้วยการตั้งค่าเพียงบรรทัดเดียว ทำให้เกิด Shadow MCP ที่ฝ่ายไอทีมองไม่เห็น บทความนี้สรุปวิธีตรวจจับทราฟฟิก MCP ความเสี่ยงที่ต่างจากผู้ใช้ที่เป็นมนุษย์ และแนวทางไล่จากการมองเห็นไปสู่การกำกับดูแล
Model Context Protocol หรือ MCP คือมาตรฐานที่ให้ AI agent ค้นหาและเรียกใช้เครื่องมือได้ ทั้งบริการ SaaS ของบุคคลที่สาม แอปพลิเคชันภายในองค์กร และ API ต่าง ๆ จุดที่ทำให้เกิดปัญหาคือการเชื่อมเอเจนต์เข้ากับเครื่องมือหนึ่งตัวใช้การตั้งค่าเพียงบรรทัดเดียว พนักงานจึงชี้ Claude, Cursor, VS Code หรือเครื่องมือคล้ายกันไปยังเซิร์ฟเวอร์ MCP ได้เองโดยไม่ผ่านการกำกับดูแลด้านความปลอดภัย
รูปแบบนี้คือ Shadow IT ในโฉมใหม่ ต่างกันตรงที่คราวนี้สิ่งที่เข้าถึงระบบภายในไม่ใช่แอปที่พนักงานติดตั้ง แต่เป็นเอเจนต์ที่ทำงานแทนพนักงานได้ต่อเนื่อง
AI agent ต่างจากคนตรงที่ไม่เหนื่อย ใช้วิจารณญาณแบบไม่คงที่ และทำงานเดิมซ้ำได้ไม่จำกัด ผลคือการตัดสินใจผิดเพียงครั้งเดียวสามารถกลายเป็นการกระทำที่ผิดนับพันครั้งก่อนที่มนุษย์จะทันสังเกต ความเสี่ยงจึงไม่ได้อยู่ที่ความรุนแรงของแต่ละเหตุการณ์ แต่อยู่ที่ความเร็วในการขยายผล
ภัยหลักที่รายงานฉบับนี้แยกไว้มีสองแบบ แบบแรกคือ Shadow MCP หมายถึงเซิร์ฟเวอร์ที่ยังไม่ได้รับอนุมัติซึ่งพนักงานไปค้นเจอเอง แบบที่สองคือ Portal Bypass หมายถึงการเชื่อมตรงเข้าเซิร์ฟเวอร์ที่ได้รับอนุมัติแล้วโดยข้ามชั้นควบคุม ทั้งสองแบบต้องใช้วิธีจัดการต่างกัน
Cloudflare Gateway ใช้การตรวจจับที่ระดับโปรโตคอลแทนการไล่จับรูปแบบ URL โดยอาศัยเฮดเดอร์ MCP-Protocol-Version ที่ไคลเอนต์ MCP รุ่นใหม่ส่งมาหลังเริ่มเชื่อมต่อ ส่วนสเปกเวอร์ชัน 2026-07-28 ยังเพิ่มเฮดเดอร์ Mcp-Method และ Mcp-Name ทำให้ระบุประเภทของคำขอได้แม่นขึ้น จากนั้นจึงจำแนกทราฟฟิกด้วยตัวเลือกใหม่ experimental.is_mcp == true
ข้อดีของวิธีนี้คือไม่ต้องคอยดูแลรายชื่อโดเมนที่อนุญาตหรือปิดกั้น ซึ่งเป็นงานที่ตามไม่ทันอยู่แล้วเมื่อจำนวนเซิร์ฟเวอร์ MCP เพิ่มขึ้นทุกสัปดาห์
หนึ่งคือการระบุทราฟฟิก MCP ในบันทึกของ Gateway ผ่านตัวเลือกแบบบูลีน สองคือแดชบอร์ดทราฟฟิก MCP ที่แสดงปริมาณคำขอ จำนวนเซิร์ฟเวอร์และผู้ใช้ที่ไม่ซ้ำ สัดส่วนการเชื่อมต่อผ่าน Portal เทียบกับการเชื่อมตรง และชี้จุดที่เกิด Shadow MCP สามคือการบังคับตามแหล่งที่มาของทราฟฟิก ซึ่งเปิดให้เขียนนโยบายแบบ "บล็อกทราฟฟิก MCP ทั้งหมดที่ไม่ได้มาจาก mcp_portal"
ขั้นแรกคือสร้างการมองเห็นก่อน ตรวจดูว่ามีทราฟฟิก MCP ใดวิ่งผ่านระบบบ้าง แล้วเทียบปลายทางกับรายชื่อเซิร์ฟเวอร์ที่องค์กรอนุมัติ ขั้นที่สองคือย้ายเซิร์ฟเวอร์ที่อนุมัติแล้วไปอยู่หลังชั้นควบคุมกลาง เพื่อรวมการจัดการสิทธิ์ไว้ที่เดียว ขั้นที่สามจึงบังคับขอบเขตด้วยนโยบายที่ผสมการตรวจจับ MCP เข้ากับเงื่อนไขแหล่งที่มา เพื่อปิดการเชื่อมตรงจากอุปกรณ์ที่องค์กรดูแล
สำหรับองค์กรไทยที่เพิ่งเริ่มให้พนักงานใช้เครื่องมือ AI สิ่งที่ควรทำก่อนคือมองเห็นให้ครบว่าใครต่อกับอะไรอยู่ แล้วค่อยตั้งกติกา การออกนโยบายห้ามโดยที่ยังมองไม่เห็นทราฟฟิกจริงมักได้ผลตรงข้าม คือพนักงานย้ายไปใช้ช่องทางที่ตรวจสอบยากกว่าเดิม
บทความอื่นที่เกี่ยวข้อง
ยุคที่พนักงานทำงานจากทุกที่และระบบกระจายอยู่หลายคลาวด์ กำแพงเครือข่ายแบบเดิมไม่พออีกต่อไป บทความนี้อธิบายสถาปัตยกรรม Zero Trust ตามเอกสาร NIST SP 800-207 หลักการ Never Trust, Always Verify องค์ประกอบหลัก และแผนการเปลี่ยนผ่านที่องค์กรไทยเริ่มได้เป็นขั้นตอน
อ่านบทความ
Cloudflare กลายเป็นชั้นหน้าบ้านของเว็บจำนวนมากทั่วโลก แต่เมนูตั้งค่าหลายร้อยรายการทำให้ผู้เริ่มต้นถอดใจ บทความนี้สรุปแนวคิดหลักจากเอกสารทางการของ Cloudflare อธิบาย DNS, Proxy, Cache, WAF และ Workers ด้วยภาษาที่เข้าใจง่าย พร้อมคำแนะนำว่าเว็บแบบไหนควรใช้หรือยังไม่จำเป็น
อ่านบทความ
Microservices ไม่ใช่คำตอบของทุกระบบ Martin Fowler เตือนไว้ชัดเจนว่าอย่าเริ่มโปรเจกต์ใหม่ด้วย Microservices ทันที บทความนี้อธิบายว่าสถาปัตยกรรมนี้คืออะไร เหมาะกับใคร พร้อมแพตเทิร์นสำคัญอย่าง API Gateway, Database per Service และ Circuit Breaker
อ่านบทความตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย
