OpenAI Secure MCP Tunnel: ให้ AI ใช้เครื่องมือส่วนตัว โดยไม่ต้องเปิดบ้านสู่ Internet

AI Agent ที่ใช้ได้จริงไม่ได้จบที่การตอบคำถามเก่งครับ

สุดท้ายมันต้องแตะเครื่องมือจริงบางอย่างได้ เช่น CRM, ticket, database, workflow, report, internal API หรือระบบหลังบ้านของบริษัท

แต่พอ AI ต้องแตะระบบหลังบ้าน คำถามใหญ่ก็ตามมาทันที:

เราต้องเปิดระบบภายในเป็น public endpoint เพื่อให้ AI เรียกใช้หรือเปล่า

OpenAI เพิ่งเขียนบทความเรื่อง Making private MCP servers reachable without making them public และเปิด Secure MCP Tunnel เพื่อแก้โจทย์นี้

ในความเห็นของผม นี่ไม่ใช่แค่ feature network เล็ก ๆ

นี่คือสัญญาณว่า AI Agent กำลังเข้าใกล้ระบบจริงของธุรกิจ และเราต้องเริ่มคิดเรื่อง private tool access อย่างเป็นระบบ

1) ปัญหาเดิม: private MCP server มีค่า แต่ไม่ควรถูกเปิดเป็น public

MCP หรือ Model Context Protocol ทำให้ AI เชื่อมกับ tool และ data ภายนอกได้ง่ายขึ้น

แต่เครื่องมือที่มีค่าที่สุดในธุรกิจมักไม่ใช่ของที่อยากเปิดให้ internet เห็น

เช่น:

• CRM หลังบ้าน
• database ภายใน
• workflow automation server
• internal API
• monitoring dashboard
• local dev server
• private service mesh
• MCP server ที่รันบน laptop หรือ VM ภายใน

ถ้าทีมอยากให้ ChatGPT, Codex หรือ AI Agent เรียกเครื่องมือเหล่านี้ วิธีง่ายที่สุดแบบผิด ๆ คือเปิด endpoint ออก internet

อีกทางคือใช้ tunnel provider ภายนอก

อีกทางคือทำ VPN หรือ peering ให้ OpenAI หรือ agent เข้า network ได้กว้างขึ้น

แต่ทั้งสามทางมีราคาของมัน

เปิด public endpoint ทำให้ boundary อ่อนลง

third-party tunnel เพิ่ม vendor อีกเจ้าหนึ่งเข้ามาใน trust path

VPN หรือ peering มักกว้างเกินไปสำหรับงานแคบ ๆ อย่างการให้ agent เรียก MCP tool ไม่กี่ตัว

Secure MCP Tunnel เลยเลือกแนวทางที่แคบกว่า:

ให้ฝั่ง private เป็นคนเปิดทางออกเอง

2) Secure MCP Tunnel ทำงานอย่างไรแบบง่าย ๆ

ภาพรวมคือมี 4 ชิ้นหลัก:

1. OpenAI product เช่น ChatGPT, Codex, Responses API หรือ AgentKit
2. OpenAI-hosted tunnel endpoint
3. tunnel-client ที่ลูกค้ารันใน environment ของตัวเอง
4. private MCP server ที่ยังอยู่หลัง boundary เดิม

flow คือ:

• OpenAI product ส่ง MCP request ไปยัง tunnel endpoint
• tunnel service queue งานไว้
• tunnel-client ที่รันอยู่ฝั่ง customer long-poll ผ่าน outbound HTTPS เพื่อรับงาน
• client forward JSON-RPC request ไปหา private MCP server แบบ local/internal
• MCP server ตอบกลับ
• client ส่ง response กลับผ่าน tunnel เดิม

จุดสำคัญคือ private MCP server ไม่ต้องรับ inbound public traffic

server ยังอยู่ข้างใน

คนที่ออกไปหา OpenAI คือ client ที่เรารันและควบคุมเอง

ผมชอบประโยคหนึ่งจาก architecture นี้มาก:

มันกลับด้าน reachability

ไม่ใช่ให้ OpenAI วิ่งเข้าบ้านเรา

แต่ให้เราวางเจ้าหน้าที่ตัวเล็ก ๆ ข้างในบ้าน แล้วเจ้าหน้าที่คนนั้นเป็นคนไปรับงานจาก OpenAI เอง

3) ทำไม outbound-only สำคัญกับธุรกิจ

สำหรับทีม security คำว่า “เปิด inbound port” ไม่ใช่เรื่องเล็กครับ

เพราะทันทีที่ service ภายในกลายเป็น public endpoint งานที่ตามมาคือ:

• DNS
• certificate
• auth
• WAF
• logging
• firewall rule
• incident response
• vendor/security review
• data access policy

บางครั้งงานเหล่านี้ใหญ่กว่าตัว MCP server เองด้วยซ้ำ

Secure MCP Tunnel เลือก outbound HTTPS เพราะมันเข้ากับโลก enterprise มากกว่า

firewall ส่วนใหญ่เข้าใจ outbound HTTPS อยู่แล้ว

proxy environment รองรับได้ง่ายกว่า

และ long-poll ทำให้ client คุม backpressure ได้ ไม่ใช่ปล่อยให้ฝั่ง tunnel buffer งานไม่จำกัด

พูดง่าย ๆ คือมันเลือกทางที่ “boring” ในทาง operation

ซึ่งสำหรับระบบ production คำว่า boring เป็นคำชมครับ

4) Open-source client สำคัญเพราะมันรันอยู่ใน boundary ของเรา

จุดที่ไม่ควรมองข้ามคือ tunnel-client เป็น customer-run และ open source

ทำไมสำคัญ?

เพราะมันคือ code ที่รันอยู่ข้างใน environment ของเรา

ถ้าเราเป็นทีม security เราต้องตอบได้ว่า:

• client เปิด outbound path ไปที่ไหน
• forward request ไปหา MCP server ไหนได้บ้าง
• config อนุญาตอะไร
• log มีอะไร
• health/readiness อยู่ตรงไหน
• ถ้า client พัง connector จะเห็นอย่างไร

OpenAI host tunnel service แต่ code ที่อยู่ในฝั่ง customer ต้อง inspect ได้

นี่คือ trust model ที่ถูกต้องกว่า “เชื่อ tunnel provider อีกเจ้าหนึ่งแล้วหวังว่าดี”

5) Tunnel ไม่ใช่ VPN และไม่ควรกลายเป็น VPN

ประเด็นนี้สำคัญมากครับ

Secure MCP Tunnel ไม่ได้มีไว้เพื่อให้ OpenAI เข้า network ของเราทั้งก้อน

มันมีไว้เพื่อเปิดทางแคบ ๆ ไปยัง target ที่ configure แล้ว

OpenAI blog บอกชัดว่า boundary ยังอยู่

ถ้า authorization server เป็น private ตัว component ที่ทำ OAuth flow ก็ยังต้อง reach authorization server ได้ตาม boundary เดิม

ถ้า MCP server ต้องใช้ custom CA, proxy, หรือ MCP-side mTLS ก็ configure ฝั่ง client ให้เหมาะกับ environment นั้น

นี่คือแนวคิดที่ผมคิดว่าธุรกิจควรยึดไว้:

AI ไม่ควรได้ network access แบบกว้าง

AI ควรได้ tool access แบบแคบและมีเหตุผล

6) Harpoon บอกว่าเรื่องนี้จะไม่หยุดที่ MCP

ท้ายบทความ OpenAI พูดถึง Harpoon ซึ่งขยายแนวคิดเดียวกันไปยัง approved REST targets

เหตุผลคือระบบหลังบ้านจำนวนมากยังไม่ได้ถูกห่อเป็น MCP server

บางบริษัทมี REST API ภายในอยู่แล้ว

ถ้า Secure MCP Tunnel แก้ได้เฉพาะ MCP ทีมก็ยังต้องหาทางเปิด REST API ภายในอีกทางหนึ่ง

Harpoon เลยใช้แนวคิด label target:

ฝั่ง customer register target ที่อนุมัติแล้ว

ฝั่ง OpenAI เรียก label นั้น

request จริงยัง originate จากฝั่ง customer environment

แต่ OpenAI ก็ย้ำข้อจำกัดไว้หลายอย่าง เช่น allowed methods, response-size limits, timeouts, redirect behavior และ tunnel access controls

ผมอ่านตรงนี้เป็นสัญญาณว่าอนาคตของ AI Agent จะมีชั้น private action broker มากขึ้น

ไม่ใช่ให้ agent เข้าไปเห็นทุก URL

แต่ให้ agent เรียก action ที่ถูก label, limit, log, และ review แล้ว

7) บทเรียนสำหรับธุรกิจไทย: อย่าเริ่มจากเปิดทุกอย่าง

ถ้าทีมคุณเริ่มทำ AI Agent ที่ต่อ MCP หรือ internal tools ผมแนะนำให้เริ่มจากคำถามนี้ก่อน:

เครื่องมือนี้ควรเป็น public service จริง ๆ หรือควรอยู่หลัง private boundary เดิม

ถ้าคำตอบคือควรอยู่ private ก็อย่ารีบเปิด public endpoint แค่เพราะ setup ง่าย

ให้คิดเป็นลำดับ:

1. AI ต้องใช้ tool นี้เพื่ออ่านหรือทำ action
2. ใครเป็นเจ้าของ tool
3. MCP server รันตรงไหน
4. tunnel-client รันตรงไหน
5. tunnel identity ผูกกับ workspace หรือ org ไหน
6. runtime key ใครสร้าง
7. tool allowlist มีอะไรบ้าง
8. action ไหนต้อง approval
9. log/proof เก็บตรงไหน
10. ถ้าผิดพลาด kill switch อยู่ที่ใคร

คำถามพวกนี้ฟังดูไม่หวือหวา

แต่ถ้าไม่ตอบก่อน production คุณจะได้ AI Agent ที่ดูเก่ง แต่ไม่มีใครรู้ว่ามันแตะอะไรไปบ้าง

8) ตัวอย่างที่เอาไปคิดต่อได้ทันที

ลองนึกภาพ CustomerOS หรือ AI Admin Room ของธุรกิจหนึ่ง

เจ้าของอยากให้ AI ช่วยตอบว่า lead ไหนควร follow-up วันนี้

ข้อมูลจริงอยู่ใน CRM ภายใน

ถ้าเปิด CRM database ออก internet เพื่อให้ AI ถามได้ นั่นเสี่ยงเกินไป

ทางที่ดีกว่าคือทำ MCP server ที่ expose เฉพาะ tool ที่ต้องใช้ เช่น:

• search_leads
• get_customer_history
• list_overdue_followups
• draft_followup_message

จากนั้นให้ tunnel client อยู่ใน environment ที่ reach CRM ได้

AI เรียกเฉพาะ tool ที่อนุมัติ

response กลับมาพร้อม proof เช่น customer ID, last interaction, reason, confidence, and suggested next action

ก่อนส่งข้อความจริงให้ลูกค้า ยังต้องมี human approval

นี่คือ AI coworker ที่เริ่มทำงานกับระบบจริง แต่ยังมีขอบเขต

ไม่ใช่ AI ที่ได้กุญแจทั้งบ้าน

Operator Kit: Private MCP Tunnel Readiness Checklist

ก่อนต่อ private MCP server ให้ ChatGPT, Codex, Responses API หรือ AI Agent ใด ๆ ลองใช้ checklist นี้ครับ

1) Boundary

• MCP server นี้ควร private หรือ public
• private address ยังอยู่ใน network เดิมหรือไม่
• ไม่มี inbound public listener ที่ไม่จำเป็น
• tunnel ไม่ถูกใช้เป็น VPN กว้าง ๆ

2) Client ownership

• tunnel-client รันบนเครื่องไหน
• ใครดูแล process, restart, update
• มี /healthz, /readyz, /metrics, /ui หรือ monitoring เทียบเท่าไหม
• log อ่านได้โดยทีมที่ต้อง support หรือไม่

3) Tool scope

• tool ไหน read-only
• tool ไหนมี action
• tool ไหนห้ามให้ agent เห็น
• tool description เขียนพอให้ AI เข้าใจว่าใช้เมื่อไรและห้ามใช้เมื่อไรหรือยัง

4) Auth and identity

• tunnel identity ผูกกับ OpenAI organization/workspace ไหน
• runtime key แยกจาก admin key หรือยัง
• ใครมี Tunnels Read, Use, Manage
• OAuth, custom CA, proxy, and mTLS ถูกออกแบบโดยใคร

5) Runtime safety

• มี timeout
• มี response-size limit
• มี method allowlist
• redirect behavior ถูกคุม
• ถ้า tool fail agent เห็น error ที่มีประโยชน์พอ ไม่ใช่แค่ generic failure

6) Human approval

• action ไหนต้องให้คน approve
• action ไหนเป็น draft only
• action ไหน agent ทำได้เอง
• ถ้า agent เรียกผิด มี kill switch ที่ชัดเจนไหม

7) Proof

• ทุกคำตอบสำคัญควรมี source หรือ evidence
• ทุก action ควรมี request ID หรือ execution ID
• ทุก production change ควร trace กลับได้ว่าใครสั่ง ใครอนุมัติ tool ไหนทำ และผลลัพธ์คืออะไร

สรุป

OpenAI Secure MCP Tunnel ไม่ได้ทำให้การต่อ AI กับระบบภายใน “ง่ายจนไม่ต้องคิด”

มันทำให้เรามีทางเลือกที่ดีกว่าการเปิด MCP server เป็น public endpoint

สำหรับผม บทเรียนใหญ่คือ:

AI Agent ในธุรกิจต้องมีประตูเล็ก ๆ ที่ตรวจได้ ไม่ใช่กุญแจทั้งบ้าน

ถ้าจะให้ AI ใช้เครื่องมือส่วนตัวของบริษัท เริ่มจาก narrow path ก่อน

ให้มันเห็นเท่าที่จำเป็น

ทำเท่าที่อนุมัติ

และจบทุกงานด้วย proof ที่คนตรวจได้ครับ