MCP (Model Context Protocol) คือโปรโตคอลแบบเปิดที่ใช้สำหรับเชื่อมต่อแอปพลิเคชัน AI เข้ากับเครื่องมือและแหล่งข้อมูลภายนอกด้วยวิธีการที่เป็นมาตรฐาน

ในขณะที่การนำ AI Assistant และ Agent มาใช้ในการทำงานกำลังแพร่หลาย การเชื่อมต่อกับเครื่องมือและฐานข้อมูลภายในองค์กรอย่างปลอดภัยได้กลายเป็นโจทย์ที่หลีกเลี่ยงไม่ได้ ในอดีตผลิตภัณฑ์ AI แต่ละตัวจำเป็นต้องมีการพัฒนาตัวเชื่อมต่อ (Connector) แยกกัน แต่ MCP จะช่วยลดความซ้ำซ้อนเหล่านั้นและทำให้สามารถนำวิธีการเชื่อมต่อแบบเดียวกันไปใช้ซ้ำในสภาพแวดล้อมที่แตกต่างกันได้ง่ายขึ้น

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

เป็นมาตรฐานเปิดที่ Anthropic เผยแพร่ในเดือนพฤศจิกายน 2024 และต่อมาได้มอบให้กับ Agentic AI Foundation ของ Linux Foundation (Anthropic, 2025-12-09) ปัจจุบันมี Anthropic, OpenAI และ Block เป็นผู้ร่วมก่อตั้ง โดยมี Google, Microsoft, AWS และบริษัทอื่นๆ เข้าร่วมด้วย

หากสรุปคุณค่าของ MCP สั้นๆ คือการแทนที่การเชื่อมต่อเครื่องมือที่เคยต้องทำแยกกันในผลิตภัณฑ์ AI แต่ละตัว ด้วยโปรโตคอลมาตรฐานเดียวกัน ซึ่งช่วยลดความซ้ำซ้อนในการบูรณาการระบบให้ง่ายขึ้น

ในโลกที่ไม่มี MCP หากผลิตภัณฑ์ AI A ต้องการเชื่อมต่อกับ Slack, GitHub และฐานข้อมูลภายในองค์กร จะต้องใช้ตัวเชื่อมต่อ (custom connector) ถึง 3 ตัว และหากผลิตภัณฑ์ AI B ต้องการเชื่อมต่อเช่นกัน ก็ต้องพัฒนาตัวเชื่อมต่อทั้ง 3 ตัวนี้ขึ้นมาใหม่ด้วยตนเอง ซึ่งจะทำให้เกิดโครงสร้างที่ต้องเขียนโค้ดเชื่อมต่อรวมสูงสุดถึง N×M (จำนวนแอป AI × จำนวนเครื่องมือ)

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

สถาปัตยกรรมของ MCP ประกอบด้วย 3 ชั้น ได้แก่ Host, Client และ Server (ตามข้อกำหนดอย่างเป็นทางการของ MCP ณ วันที่ 2025-03-26)

• Host — แอปพลิเคชันที่ผู้ใช้ใช้งาน (เช่น Claude Desktop, IDE, แชท UI ฯลฯ)
• Client — ตัวเชื่อมต่อภายใน Host ที่ทำหน้าที่สื่อสารกับ MCP Server
• Server — บริการที่เปิดเผยเครื่องมือหรือข้อมูลภายนอกให้กับ AI

Server จะจัดเตรียม Primitive 3 ประการให้กับ Client ดังนี้:

ตัวอย่างขั้นตอนการทำงาน: เมื่อผู้ใช้สั่ง AI ว่า "ช่วยสรุปข้อมูลยอดขายของเดือนที่แล้วให้หน่อย" Client จะดึงรายการ Tool ที่ Server เปิดเผยไว้ จากนั้นโมเดลจะตัดสินใจเรียกใช้ Tool ที่เหมาะสม (เช่น query_sales_data) Server จะส่งผลลัพธ์การทำงานกลับมา และโมเดลจะสร้างคำตอบโดยอ้างอิงจากผลลัพธ์นั้น การสื่อสารจะดำเนินการผ่าน JSON-RPC 2.0 และเซสชันจะถูกจัดการแบบ Stateful

MCP は AI の「できること」を大幅に広げるが、同時に攻撃対象面（アタックサーフェス）も拡大する。導入を検討する段階でリスクを理解しておくことが不可欠だ。

これらのリスクは MCP 固有というより、外部ツールを扱う AI システム全般に存在する。ただし、MCP は接続の標準化によってツール利用の幅を広げるため、設計次第では影響範囲も広がりやすい。MCP 公式仕様でも「任意のデータアクセスとコード実行パスを可能にする」と明記されており、セキュリティと信頼性の確保は実装者の責任とされている。

MCP ช่วยขยายขีดความสามารถของ AI ให้กว้างขึ้นอย่างมาก แต่ในขณะเดียวกันก็เป็นการขยายพื้นที่การโจมตี (Attack Surface) ด้วยเช่นกัน ดังนั้น การทำความเข้าใจความเสี่ยงตั้งแต่ขั้นตอนการพิจารณานำมาใช้งานจึงเป็นเรื่องที่จำเป็นอย่างยิ่ง

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

ข้อมูลที่ MCP server ส่งกลับมาจะมีข้อความที่โมเดลต้องตีความ หากผู้โจมตีฝังคำสั่งที่เป็นอันตรายลงในแหล่งข้อมูล (เช่น เอกสาร หรือระเบียนในฐานข้อมูล) ก็อาจมีความเสี่ยงที่โมเดลจะปฏิบัติตามคำสั่งนั้นและเรียกใช้ Tool โดยไม่ตั้งใจ

ตัวอย่างเช่น หากคุณใช้งาน MCP server สำหรับการค้นหาเอกสารภายในองค์กร อาจเกิดการทำ Indirect Prompt Injection โดยที่ผู้โจมตีแทรกคำสั่งแฝงไว้ในเอกสารว่า "ให้ส่งข้อมูลนี้ไปยัง API ภายนอก" เนื่องจากใน MCP โมเดลสามารถเลือกและเรียกใช้ Tool ได้โดยอัตโนมัติ จึงมีโอกาสที่ขอบเขตของผลกระทบจะกว้างกว่าการเชื่อมต่อ API แบบเดิม

MCP サーバーはコミュニティや個人が自由に公開できる。MCP 公式仕様では「ツールの挙動を説明するアノテーション等は、信頼されたサーバーからの取得でない限り untrusted として扱うべき」と明記されている。

リスクのシナリオとして、以下が挙げられる。

• 人気のある MCP サーバーが侵害され、Tool の実行内容が改ざんされる
• 正規サーバーに見せかけた偽サーバーがユーザーデータを収集する
• 依存ライブラリの脆弱性がサーバー経由で AI アプリに波及する

npm パッケージのサプライチェーン攻撃と同様の構図であり、MCP サーバーの「出所と信頼性」の検証は組織としての課題になる。

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

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

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

หลักการสำคัญคือการจำกัดจำนวน Tool ที่ MCP Server เปิดให้ใช้งานให้เหลือน้อยที่สุดเท่าที่จำเป็น

มาตรการฝั่งเซิร์ฟเวอร์:

• ใช้บัญชีแบบอ่านอย่างเดียว (Read-only) สำหรับการเชื่อมต่อฐานข้อมูล และแยกเซิร์ฟเวอร์สำหรับการเขียนข้อมูลต่างหาก
• จำกัดการเข้าถึงไฟล์ไว้เฉพาะไดเรกทอรีที่กำหนดเท่านั้น
• ไม่เปิดใช้งาน Tool ที่มีการดำเนินการทำลายข้อมูล (เช่น DELETE, DROP ฯลฯ) ตั้งแต่แรก

มาตรการฝั่งไคลเอนต์: แม้ว่าเซิร์ฟเวอร์จะเปิดใช้งาน Tool จำนวนมาก แต่ฝั่งไคลเอนต์สามารถจำกัด Tool ที่จะนำมาใช้งานได้ ในบางการใช้งานจะมีพารามิเตอร์ที่ระบุชุดย่อยของ Tool ที่โมเดลสามารถเรียกใช้ได้ (เช่น allowed_tools ใน OpenAI Responses API) การ "กรองข้อมูลที่ฝั่งผู้ใช้งาน" เช่นนี้ เมื่อใช้ร่วมกับการควบคุมที่ฝั่งเซิร์ฟเวอร์ จะช่วยเพิ่มความปลอดภัยแบบหลายชั้น (Defense in depth)

ตามหลักการของข้อกำหนด MCP ได้ระบุไว้ว่า "Host จะต้องได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้ก่อนที่จะมีการเรียกใช้เครื่องมือ (Tool)" ในระดับการนำไปใช้งานจริง การแบ่งระดับขั้นตอนการอนุมัติตามผลกระทบของการดำเนินการถือเป็นแนวทางที่เหมาะสม

ในการนำไปใช้งานบางรูปแบบ จะมีกลไกที่ช่วยให้สามารถควบคุมความจำเป็นในการอนุมัติก่อนการรันเครื่องมือได้ (ตัวอย่างเช่น require_approval ใน OpenAI Responses API ที่สามารถกำหนดค่าเป็น "always" / "never" หรือระบุเป็นราย Tool ได้) สิ่งสำคัญคือการ "ตั้งค่าเริ่มต้นให้มีความปลอดภัยไว้ก่อน" โดยแนะนำให้กำหนดว่า Tool ใหม่ทุกตัวต้องได้รับการอนุมัติเป็นหลัก และค่อยๆ ผ่อนปรนระดับการควบคุมหลังจากผ่านการตรวจสอบแล้ว

หาก MCP サーバー จำเป็นต้องมีการตรวจสอบสิทธิ์ ให้ส่งข้อมูลรับรอง (Credentials) เช่น OAuth token จาก Client ไปยัง Server สิ่งสำคัญคือ ต้องหลีกเลี่ยงการจัดเก็บข้อมูลรับรองไว้อย่างถาวร ตัวอย่างเช่น ในการใช้งานของ OpenAI ได้ระบุไว้อย่างชัดเจนว่าจะไม่มีการบันทึกโทเค็นที่ส่งผ่านฟิลด์ authorization ไว้ที่ฝั่งเซิร์ฟเวอร์ และออกแบบมาให้ส่งใหม่ทุกครั้งที่มีการร้องขอ

ในมุมมองของ trust boundary (ขอบเขตความเชื่อถือ) ให้แยกส่วนประกอบต่างๆ ออกจากกันอย่างชัดเจน ดังนี้:

• ระหว่าง Host และ Client: จัดการการตรวจสอบสิทธิ์และการอนุญาต (Authentication/Authorization) ของผู้ใช้ที่จุดนี้
• ระหว่าง Client และ Server: การสื่อสารในระดับ MCP protocol จำเป็นต้องมีการยืนยันตัวตนของ Server
• ระหว่าง Server และระบบภายนอก: จำกัดขอบเขตอำนาจที่ Server มีให้ชัดเจน

โดยเฉพาะในสภาพแวดล้อมการใช้งานจริง (Production) ควรแยกแยะระดับความเชื่อถือตามแหล่งที่มาของ MCP サーバー ว่าเป็นแบบทางการ (Official), ชุมชนพัฒนา (Community-made) หรือพัฒนาขึ้นเองภายในองค์กร และใช้กระบวนการอนุมัติรวมถึงการตั้งค่าสิทธิ์ให้เหมาะสม

มาตรการเพิ่มเติมด้านการปฏิบัติงาน:

นอกเหนือจากการตรวจสอบสิทธิ์และการอนุญาตแล้ว ควรพิจารณามาตรการควบคุมเชิงปฏิบัติการดังต่อไปนี้:

• Audit log: บันทึกว่า Tool ใดถูกเรียกใช้งาน เมื่อใด และโดยการกระทำของใคร เพื่อเป็นพื้นฐานในการตรวจจับการเรียกใช้งานที่ผิดปกติหรือการรัน Tool ที่ไม่คาดคิด
• Rate limiting: กำหนดขีดจำกัดความถี่ในการเรียกใช้ Tool เพื่อจำกัดความเสียหายในกรณีที่เกิดการทำงานผิดพลาดหรือการใช้งานในทางที่ผิด
• Egress control (การจำกัดปลายทางของเครือข่าย): จำกัดขอบเขตที่ MCP サーバー สามารถสื่อสารออกไปยังภายนอกได้ในระดับเครือข่าย เพื่อป้องกันการส่งข้อมูลออกไปภายนอกโดยไม่ตั้งใจ
• Sandboxing: แยกสภาพแวดล้อมการทำงานของ Tool ออกมา เพื่อลดผลกระทบต่อระบบหลัก (Host system) ให้เหลือน้อยที่สุด

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

วิธีที่ง่ายที่สุดคือการเชื่อมต่อ MCP サーバー ที่เผยแพร่อยู่แล้วเข้ากับ IDE หรือเครื่องมือ Agent

ตัวอย่างการตั้งค่าใน VS Code:

สร้างไฟล์ .vscode/mcp.json ไว้ที่รูทของโปรเจกต์ แล้วระบุ URL ของ MCP サーバー

หลังจากตั้งค่าเสร็จสิ้น คุณจะสามารถใช้งาน Tool ที่ MCP サーバー เผยแพร่ออกมาได้ในโหมด Agent ของ VS Code

ตัวอย่างการตั้งค่าใน Claude Desktop:

เพิ่มเซิร์ฟเวอร์ลงในไฟล์ ~/Library/Application Support/Claude/claude_desktop_config.json

ไม่ว่าจะกรณีใด เพื่อความปลอดภัย ควรเริ่มต้นทดลองจากเซิร์ฟเวอร์ที่จัดทำโดยทางการ หรือเซิร์ฟเวอร์ที่มีแหล่งที่มาชัดเจนก่อน

การสร้างเซิร์ฟเวอร์ด้วยตนเองเป็นวิธีที่ช่วยให้เข้าใจสถาปัตยกรรมของ MCP ได้ลึกซึ้งที่สุด ในเอกสารอย่างเป็นทางการของ MCP มีบทช่วยสอนการสร้างเซิร์ฟเวอร์ข้อมูลสภาพอากาศ ซึ่งคุณสามารถสร้างเซิร์ฟเวอร์ที่เปิดใช้งาน Tool 2 รายการ ได้แก่ get_alerts และ get_forecast (MCP 公式, Build an MCP server)

ขั้นตอนโดยสังเขป:

1. พัฒนาเซิร์ฟเวอร์โดยใช้ MCP SDK (TypeScript / Python / Rust ฯลฯ)
2. ตรวจสอบคำสั่งสำหรับการ Build หรือการรันเซิร์ฟเวอร์
3. เพิ่มพาธ (Path) ของเซิร์ฟเวอร์ลงในไฟล์การตั้งค่าของ Claude Desktop
4. รีสตาร์ท Claude และตรวจสอบว่าระบบตรวจพบ Tool แล้วหรือไม่

จุดที่ควรตรวจสอบหากใช้งานไม่ได้:

• ข้อผิดพลาดทางไวยากรณ์ JSON ในไฟล์การตั้งค่า (เช่น การลืมใส่เครื่องหมายคอมมาที่ท้ายบรรทัด)
• พาธของเซิร์ฟเวอร์เป็น Absolute path หรือไม่
• ได้ปิดโปรแกรม Claude อย่างสมบูรณ์ก่อนรีสตาร์ทหรือไม่
• มีข้อความแสดงข้อผิดพลาดในไฟล์บันทึก (Log file) หรือไม่ (macOS: ~/Library/Logs/Claude/mcp*.log)

หากต้องการรวม MCP เข้ากับแอปพลิเคชัน AI ของบริษัท รูปแบบที่เหมาะสมคือการเชื่อมต่อกับเซิร์ฟเวอร์ MCP ระยะไกลผ่าน API

รูปแบบการใช้งานเชิงแนวคิด:

ข้อดีของวิธีนี้คือสามารถควบคุมขั้นตอนการอนุมัติ (require_approval) การจำกัดเครื่องมือที่ใช้งานได้ (allowed_tools) และการยืนยันตัวตนผ่าน OAuth ได้โดยตรงผ่านโปรแกรม

สิ่งที่ควรพิจารณาในการใช้งานจริง:

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

MCP はすべての AI プロジェクトに必要なわけではない。導入すべきかどうかは「AI が動的にツールを選択する必要があるか」が最大の判断基準になる。

MCP ไม่จำเป็นสำหรับทุกโปรเจกต์ AI เกณฑ์การตัดสินใจที่สำคัญที่สุดว่าควรนำมาใช้หรือไม่ คือ "AI จำเป็นต้องเลือกใช้เครื่องมือแบบไดนามิก (Dynamically) หรือไม่"

MCP มีประสิทธิภาพสูงในงานที่ AI ไม่สามารถทำได้สำเร็จด้วยความรู้จากการฝึกฝนโมเดลเพียงอย่างเดียว แต่ต้องพึ่งพาข้อมูลหรือการดำเนินการจากภายนอก

• ผู้ช่วยจัดการความรู้ภายในองค์กร (Internal Knowledge Assistant) — สร้างคำตอบโดยผสมผสานการค้นหาเอกสารและการอ้างอิงฐานข้อมูล
• ผู้ช่วยสนับสนุนลูกค้า (Customer Support Copilot) — สนับสนุนการตอบกลับโดยเชื่อมโยงระบบตั๋ว (Ticket System), FAQ และ CRM เข้าด้วยกัน
• ผู้ช่วยใน IDE (IDE Assistant) — ช่วยเหลืองานพัฒนาโดยการเข้าถึงฐานโค้ด (Codebase), เอกสาร และเครื่องมือ CI/CD
• ระบบอัตโนมัติของเวิร์กโฟลว์ (Workflow Automation) — AI เลือกใช้เครื่องมือการทำงานหลายอย่าง (เช่น Slack, GitHub, DB ฯลฯ) ตามสถานการณ์
• ระบบเอเจนต์ (Agent System) — ทำการย่อยงาน, เลือกเครื่องมือ และรวบรวมผลลัพธ์อย่างอิสระ

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

ในกรณีต่อไปนี้ มีความเป็นไปได้สูงว่าการใช้ API Integration ปกติหรือ Function Calling ก็เพียงพอแล้ว โดยไม่จำเป็นต้องนำ MCP มาใช้

• บริการภายนอกที่ AI ต้องเรียกใช้งานมีเพียง 1-2 รายการที่แน่นอน
• ไม่จำเป็นต้องให้โมเดลเป็นผู้เลือกเครื่องมือเอง แต่สามารถตัดสินใจได้ด้วยตรรกะ (Logic)
• การใช้งานหลักคือกระบวนการ Backend ที่ไม่ได้ใช้ AI (เช่น Cron Job)
• ข้อกำหนดด้านความปลอดภัยไม่อนุญาตให้มีการเรียกใช้เครื่องมือแบบไดนามิกโดย AI

จุดตรวจสอบสำหรับการตัดสินใจนำมาใช้งาน:

หากคำตอบคือ No ทั้งหมด คุณสามารถตอบโจทย์ความต้องการได้ด้วย REST API หรือ Function Calling การนำ MCP มาใช้ไม่ใช่เพราะ "มันสะดวก" แต่จะแสดงคุณค่าที่แท้จริงก็ต่อเมื่อความซับซ้อนในการเชื่อมต่อกลายเป็นคอขวดในการทำงานจริงเท่านั้น

MCP คือโปรโตคอลแบบเปิดที่สร้างมาตรฐานการเชื่อมต่อระหว่าง AI กับเครื่องมือและแหล่งข้อมูลภายนอก คุณค่าที่สำคัญที่สุดคือการลดความซ้ำซ้อนของการพัฒนาแบบเฉพาะจุด (Individual Implementation) และช่วยให้สามารถนำไปใช้ซ้ำในสภาพแวดล้อมที่หลากหลายได้ง่ายขึ้น เช่น IDE, Desktop AI และการเชื่อมต่อ API

ในทางกลับกัน การที่ MCP ขยายขอบเขตการเข้าถึงของ AI ก็มาพร้อมกับความเสี่ยงด้านความปลอดภัย เช่น Prompt Injection, ความเสี่ยงด้าน Supply Chain และการให้สิทธิ์เกินความจำเป็น (Over-privileged) ดังนั้น จึงจำเป็นต้องนำมาตรการเชิงปฏิบัติมาใช้ตั้งแต่ขั้นตอนการออกแบบ เช่น หลักการให้สิทธิ์ขั้นต่ำ (Principle of Least Privilege), ขั้นตอนการอนุมัติแบบเป็นลำดับขั้น, การกำหนด Trust Boundary ให้ชัดเจน รวมถึงการบันทึก Audit Log และการควบคุม Egress

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

เอกสารอ้างอิง

1. Model Context Protocol — ข้อมูลจำเพาะอย่างเป็นทางการ (2025-03-26) https://modelcontextprotocol.io/specification/2025-03-26
2. Anthropic — "Introducing the Model Context Protocol" (2024-11-25) https://www.anthropic.com/news/model-context-protocol
3. Anthropic — "Donating the Model Context Protocol" (2025-12-09) https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
4. OpenAI Developers — "MCP and Connectors" https://developers.openai.com/api/docs/guides/tools-connectors-mcp
5. MCP Official — "Build an MCP server" https://modelcontextprotocol.io/docs/develop/build-server