Phần 4: MCP Gateway Architecture

Trong giai đoạn PoC, kiến trúc MCP thường rất đơn giản: Một Agent kết nối 1-1 với một MCP Server. Tuy nhiên, khi tổ chức của bạn mở rộng hệ sinh thái Agentic, bức tranh sẽ lập tức hỗn loạn.

Hãy tưởng tượng bạn có 20 AI Agents khác nhau (Code Review, DevOps, Customer Support…) và 50 MCP Servers (Jira, GitHub, Internal Database, Cloud Provisioning…). Nếu sử dụng kết nối trực tiếp, bạn sẽ có 1000 đường kết nối (N×M connectivity problem).

Làm sao bạn có thể:

Thu hồi quyền của một Agent khi nó bị lỗi?
Áp dụng Rate Limiting để Agent không gọi sập database backend?
Ghi log (Audit) toàn bộ hành vi của hệ thống ra SIEM tập trung?

Đây là lý do MCP Gateway ra đời và trở thành thành phần kiến trúc bắt buộc trong năm 2026.

graph LR
    subgraph Truoc_Khi_Co_Gateway[N×M Connectivity - Hỗn Loạn]
        A1[Agent 1] --> S1(Server A)
        A1 --> S2(Server B)
        A2[Agent 2] --> S1
        A2 --> S2
    end

    subgraph Enterprise_Scale[MCP Gateway - Quản Trị Tập Trung]
        A3[Agent 1] --> G{MCP Gateway}
        A4[Agent 2] --> G
        G -->|Policy / AuthZ| S3(Server A)
        G -->|Rate Limit| S4(Server B)
        G -.->|Audit Logs| SIEM[(Hệ thống SIEM)]
    end

1. Vai Trò Của MCP Gateway

MCP Gateway đóng vai trò như một Reverse Proxy đặc thù cho AI. Nó đứng giữa toàn bộ lưu lượng giao tiếp từ Agent đến các MCP Servers, trở thành một Control Plane (Mặt phẳng điều khiển) duy nhất.

Sức mạnh của Gateway nằm ở 4 chức năng cốt lõi:

Centralized Authentication & Routing: Mọi Agent chỉ cần kết nối đến Gateway. Gateway sẽ xác thực (dùng OAuth 2.1/SPIFFE như đã bàn ở Phần 3) và định tuyến (route) request đến đúng MCP Server.
Policy Enforcement (OPA): Gateway tích hợp với Open Policy Agent (OPA) để áp dụng RBAC/ABAC. Ví dụ: “DevOps Agent chỉ được gọi provision_server trong khoảng từ 8h-18h, và không được cấp quá 5 server/ngày”.
Semantic Validation & Rate Limiting: Chặn đứng các hành vi spam API (do Agent bị vòng lặp vô tận) ngay tại cửa ngõ.
Audit Logging: Trích xuất toàn bộ luồng giao tiếp JSON-RPC thành các logs có cấu trúc để đẩy vào SIEM (Datadog, Splunk).

2. Hai Mô Hình Triển Khai (Deployment Patterns)

Tùy vào quy mô, bạn có thể chọn một trong hai kiến trúc:

Hub-and-Spoke (Phổ biến nhất)

Phù hợp cho các doanh nghiệp tầm trung (Mid-scale). Tất cả Agents và Servers đều nằm trong cùng một mạng và giao tiếp qua một cụm Gateway trung tâm duy nhất.

Ưu điểm: Dễ vận hành, một điểm cấu hình duy nhất.
Nhược điểm: Gateway có thể trở thành Single Point of Failure (SPOF) hoặc gây nghẽn cổ chai mạng (network bottleneck).

Federated Mesh (Enterprise Scale)

Phù hợp cho các tập đoàn lớn có nhiều chi nhánh, multi-cloud, hoặc các team độc lập. Thay vì một Gateway khổng lồ, mỗi team/vùng (region) sở hữu một Gateway cục bộ để xử lý traffic local. Tất cả các Gateway này được quản lý chung bởi một Central Control Plane.

Ưu điểm: Độ trễ thấp (latency), tính cô lập (isolation) cao.
Nhược điểm: Phức tạp trong vận hành, yêu cầu hạ tầng Service Mesh (như Istio) mạnh mẽ.

3. Ngăn Chặn Shadow MCP Servers (OWASP MCP09)

Một khái niệm bảo mật cực kỳ quan trọng được nhắc đến trong bản dự thảo OWASP MCP Top 10 (Beta) là mã lỗi MCP09: Shadow MCP Servers.

Tương tự như “Shadow IT”, Shadow MCP Servers là các máy chủ MCP do các team tự ý deploy mà không thông qua quy trình bảo mật của công ty. Vì MCP quá dễ viết (như ta đã thấy ở Phần 2), một developer có thể vô tình expose toàn bộ production database cho các Agent thông qua một MCP Server tự tạo.

Giải pháp của MCP Gateway: Hệ thống Gateway phải được thiết kế để chỉ định tuyến đến các MCP Server đã được đăng ký trong một Governed Internal Registry (Sổ đăng ký nội bộ có kiểm soát). Bất kỳ Server nào không nằm trong danh sách này sẽ bị Gateway từ chối phục vụ (Drop connections).

Hơn nữa, Gateway phải chặn đứng mọi giao tiếp trực tiếp (direct access) từ Agent đến Server ở tầng Network (bằng Network Policies trong Kubernetes), buộc 100% traffic phải đi qua nó.

Lời Kết

Với MCP Gateway, bạn đã giải quyết được bài toán scale và governance (quản trị). Tuy nhiên, Gateway chỉ là cơ sở hạ tầng. Bản thân nội dung (payload) truyền qua Gateway vẫn có thể chứa mã độc.

Làm thế nào một kẻ tấn công có thể “hạ độc” một công cụ (Tool Poisoning), hay khiến Agent thực thi các lệnh phá hoại (Prompt Injection)? Chào mừng bạn đến với Phần 5: Production Security & OWASP MCP Top 10.

Next up: Phần 5: Production Security & OWASP MCP Top 10 (Beta)

1. Vai Trò Của MCP Gateway#

2. Hai Mô Hình Triển Khai (Deployment Patterns)#

Hub-and-Spoke (Phổ biến nhất)#

Federated Mesh (Enterprise Scale)#

3. Ngăn Chặn Shadow MCP Servers (OWASP MCP09)#

Lời Kết#