Chuyển đến nội dung chính
Quay lại danh sách bài viết

Gemini Enterprise ต่อ MCP ใน VPC ได้แล้ว: Agent Gateway เปิดทางไปเครื่องมือภายในแบบ GA

Google Cloud เปิด GA การเชื่อม custom MCP server ใน VPC ผ่าน Agent Gateway และ PSC รวมถึง static IP egress ผ่าน Cloud NAT พร้อมขอบเขต traffic ที่ต้องตรวจ

Gemini Enterprise ต่อ MCP ใน VPC ได้แล้ว: Agent Gateway เปิดทางไปเครื่องมือภายในแบบ GA

Gemini Enterprise ต่อ MCP ใน VPC ได้แล้ว: Agent Gateway เปิดทางไปเครื่องมือภายในแบบ GA

Google Cloud ประกาศใน release notes วันที่ 27 ตุลาคม 2026 ว่า Gemini Enterprise รองรับการเชื่อมต่อ VPC และการใช้ออกอินเทอร์เน็ตด้วย IP คงที่สำหรับ custom MCP server data store แบบ General Availability (GA) ผู้ดูแลสามารถให้การเรียกเครื่องมือจาก Gemini Enterprise ผ่าน Agent Gateway เข้าหา MCP server ที่อยู่ใน VPC โดยใช้ Private Service Connect (PSC) network attachment หรือส่งคำขอไปยัง MCP server สาธารณะผ่าน Cloud NAT เพื่อให้ปลายทางอนุญาต IP ต้นทางที่กำหนดไว้ได้

ฟีเจอร์นี้แก้โจทย์ทีมที่มีเครื่องมือภายใน เช่น ระบบ ticket, ฐานข้อมูลการปฏิบัติงาน หรือ API องค์กร ที่ไม่ต้องการเปิด endpoint ให้เข้าถึงจากอินเทอร์เน็ตทั่วไป ก่อนหน้านี้การเชื่อม custom MCP server ที่อยู่หลังเครือข่ายส่วนตัวต้องออกแบบการเข้าถึงเพิ่มเอง ขณะนี้มีแนวทางเครือข่ายที่ Google รองรับโดยตรง แต่ยังต้องตั้งค่า VPC, สิทธิ์, DNS และการตรวจสอบการเรียกใช้อย่างรอบคอบ

เส้นทางเครือข่ายทำงานอย่างไร

ตาม เอกสารการตั้งค่า VPC สำหรับ custom MCP server Gemini Enterprise ไม่เข้าถึงทรัพยากรใน private network ได้โดยค่าเริ่มต้น เมื่อเปิดเส้นทางนี้ ระบบส่ง traffic ของการเรียก tool ขาออกผ่าน Egress Agent Gateway ไปยัง VPC ที่องค์กรควบคุม องค์ประกอบหลักมีสามส่วน: PSC network attachment สำหรับสร้าง interface ใน VPC, agent connectivity template ที่กำหนด attachment การ resolve DNS และรูปแบบ egress, และ Agent Gateway ที่อ้าง template ดังกล่าว

หาก MCP server อยู่ใน VPC โดยไม่มี public IP ก็ให้ Gateway ไปยังปลายทางส่วนตัวผ่าน attachment และ private DNS ตามการตั้งค่า หาก MCP server อยู่ภายนอกแต่รับเฉพาะ IP ที่อนุญาต สามารถเลือกส่ง traffic ผ่าน VPC แล้วออกทาง Cloud NAT ที่ใช้ static external IPv4 address ได้ แนวทางหลังเหมาะกับบริการคู่ค้าที่มี allowlist แต่ไม่เท่ากับการทำให้เซิร์ฟเวอร์ปลายทางกลายเป็น private endpoint

ขอบเขตที่ Google ระบุสำคัญมาก: Agent Gateway ในรูปแบบนี้ดูแล outbound query-time tool execution ไปยัง custom MCP server, action connector และ agent เท่านั้น ไม่ได้เป็น proxy ให้คำขอ model inference, การดึงข้อมูล RAG, built-in assistant tools หรือ connector ingestion และไม่รองรับ traffic ขาเข้ามายัง Gemini Enterprise ดังนั้นทีมที่วางนโยบาย “ข้อมูลทั้งหมดต้องผ่าน VPC” ต้องแยกตรวจเส้นทางอื่นด้วย ไม่ควรเห็น Gateway ตัวเดียวแล้วสรุปว่าทุกการสื่อสารผ่านเครือข่ายนี้

สิ่งที่ต้องเตรียมก่อนเปิดใช้

เอกสารระบุภูมิภาคที่รองรับ Agent Gateway และ connectivity template สำหรับฟีเจอร์นี้คือ us-central1 และ europe-west1 ในเวลาประกาศ ควรตรวจตำแหน่งข้อมูล ข้อกำหนดองค์กร และความพร้อมของบริการในภูมิภาคก่อนออกแบบจริง สำหรับ private MCP server ต้องรองรับ transport แบบ StreamableHTTP และหากใช้ชื่อโดเมนภายในต้องกำหนด DNS peering พร้อมสิทธิ์ roles/dns.peer ให้ service agent ที่เกี่ยวข้อง

ถ้าใช้ TLS certificate จาก CA ภายในหรือ self-signed certificate ให้พิจารณา Certificate Manager TrustConfig เพื่อให้ Gateway ตรวจใบรับรองปลายทางได้ การเปิด route เครือข่ายอย่างเดียวไม่พอ หากการตรวจ TLS ล้มเหลวหรือทีมแก้ด้วยการปิดการตรวจใบรับรองก็จะลดความมั่นใจของช่องทางที่ตั้งใจให้ปลอดภัย ผู้ดูแลควรตรวจ IAM ของผู้สร้าง network attachment, template และ Gateway รวมถึงสิทธิ์บน MCP server ที่เรียกจริงแยกเป็นชั้น ๆ

ในกรณี public MCP server ที่ใช้ IP allowlist ให้สำรอง static IP และกำหนด Cloud NAT ให้ถูก subnet ทดสอบจากปลายทางว่าคำขอออกด้วย IP ที่คาด ไม่ใช่เพียงทดสอบว่าการเชื่อมต่อสำเร็จ ป้องกันการเผลอใช้เส้นทาง egress อื่นที่ไม่ได้บันทึกใน allowlist และอย่าลืมจัดการช่วงเวลาที่ NAT หรือกฎ firewall ถูกเปลี่ยนแปลง

ทดสอบกับเครื่องมือจริงอย่างไร

เริ่มจาก MCP server ที่มี action อ่านข้อมูลทดสอบเท่านั้น เชื่อมผ่าน Agent Gateway แล้วบันทึกผลของการเรียกทั้งฝั่ง Gateway, VPC flow และ application log ของ MCP server ตรวจ identity ของผู้เรียกและสิทธิ์ action ว่าตรงกับที่ตั้งใจ ลองปิดเส้นทาง DNS, ปิด endpoint และเปลี่ยน TLS certificate เพื่อดูว่า error ถูกแจ้งอย่างเข้าใจได้ ไม่ควรปล่อยให้ agent ตีความการเชื่อมต่อล้มเหลวเป็น “ไม่มีข้อมูล” แล้วสร้างคำตอบขึ้นเอง

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

การเปิด GA ทำให้การต่อ Gemini Enterprise กับเครื่องมือหลัง VPC มีรูปแบบที่ตรวจสอบและดูแลได้ชัดขึ้น ทีมที่กำลังสร้าง agent ในองค์กรควรเริ่มจากแผนผัง traffic และขอบเขตความรับผิดชอบของ Gateway แล้วจึงเลือกว่าจะใช้ private MCP หรือ static IP egress ตามตำแหน่งของปลายทางจริง

แหล่งต้นทาง: Google Cloud release notes วันที่ 27 ตุลาคม 2026, ข้อกำหนด VPC สำหรับ custom MCP server และ คู่มือตั้งค่า custom MCP server

Chia sẻ bài viết:
Xem thêm bài viết