Khi AI Agent trở nên tự chủ hơn (agentic autonomy), chúng ta đối mặt với một vấn đề bảo mật sống còn: Ai đang gọi MCP Server?
Trong quá khứ, các công cụ tự động hóa thường dùng chung một “Service Account” với quyền hạn cực rộng. Nhưng nếu một Agent (được cấp quyền đọc/ghi toàn bộ hệ thống) bị đánh lừa bởi một Prompt Injection, nó có thể gây ra thảm họa.
Năm 2026, ngành công nghiệp đã thống nhất: AI Agent phải được đối xử như một Non-Human Identity (NHI) hạng nhất. Bài viết này sẽ đi qua 3 cấp độ định danh cho Agent khi giao tiếp qua MCP.
1. Cấp Độ Cơ Bản: OAuth 2.1 + PKCE
Nếu bạn đang sử dụng Streamable HTTP transport cho MCP (như đã phân tích ở Phần 1), việc dùng chung API Key tĩnh (static secrets) là một “anti-pattern” nghiêm trọng.
Tiêu chuẩn bắt buộc hiện nay là OAuth 2.1.
- Không còn Implicit Flow: Mọi kết nối đều phải dùng Authorization Code.
- Bắt buộc PKCE (Proof Key for Code Exchange): Ngay cả với non-public clients, PKCE ngăn chặn việc kẻ gian đánh cắp authorization code trên đường truyền.
- Short-lived, task-scoped tokens: Thay vì cấp một token sống 30 ngày, token cho Agent chỉ nên sống vài phút và gắn chặt với “nhiệm vụ” hiện tại. Nhờ đó, nếu token bị lộ (compromised), “blast radius” (phạm vi ảnh hưởng) là vô cùng nhỏ.
2. Cấp Độ Mở Rộng: Chuẩn CIMD Mới Của MCP
Trong hệ sinh thái MCP, các AI Client thường xuyên phải kết nối với những MCP Server mới mà chúng chưa từng biết đến. Nếu dùng luồng OAuth truyền thống, Client phải đăng ký trước (pre-register) với Authorization Server để lấy client_id và client_secret. Việc này tạo ra một nút thắt cổ chai khổng lồ.
Giải pháp Dynamic Client Registration (DCR - RFC 7591) từng được dùng, nhưng làm phình to database của máy chủ auth.
Vì vậy, từ bản cập nhật tháng 11/2025 (SEP-991), MCP đã chính thức chọn CIMD (Client ID Metadata Documents) làm chuẩn mặc định:
CIMD Hoạt Động Ra Sao?
Thay vì dùng một chuỗi ngẫu nhiên làm client_id, Client sẽ dùng một HTTPS URL.
Tại URL này (ví dụ: https://my-agent.example.com/.well-known/mcp-client), Client host một JSON document chứa metadata của nó:
{
"client_name": "Finance Review Agent",
"redirect_uris": ["https://my-agent.example.com/callback"],
"scope": "read write"
}
Khi Agent gửi request OAuth:
- Nó gửi URL trên làm
client_id. - Authorization Server (của MCP) sẽ fetch (tải) URL đó on-demand.
- Niềm tin được neo vào quyền sở hữu domain thay vì database nội bộ.
Cảnh Báo: SSRF Vulnerability
Vì Server của bạn phải tải một URL do bên ngoài cung cấp, bạn phải thiết lập cơ chế chống Server-Side Request Forgery (SSRF): Block dải mạng internal/loopback, enforce timeout, và giới hạn payload ở mức 5KB.
3. Cấp Độ Zero Trust: Workload Identity (SPIFFE/SPIRE)
Với các tổ chức có yêu cầu compliance cao (Tài chính, Y tế), OAuth là chưa đủ. Bạn cần chứng minh bằng mật mã (cryptographically) rằng “Tiến trình (process) đang gọi MCP Server đích thực là Agent X đang chạy trên Node Y”.
Đây là lúc SPIFFE (Secure Production Identity Framework for Everyone) và SPIRE tỏa sáng.
SPIFFE cấp cho mỗi workload một định danh duy nhất (SVID), thường là X.509 certificate hoặc JWT. Định danh này có dạng:
spiffe://example.com/agent/finance-bot/uuid-abc123
Tích hợp SPIFFE vào MCP (3 Patterns)
sequenceDiagram
participant A as AI Agent
participant S as SPIRE Agent
participant IdP as Identity Provider
participant MCP as MCP Server
A->>S: 1. Fetch SVID (Workload Identity)
S-->>A: 2. Cấp phát SVID (X.509/JWT)
A->>IdP: 3. Trình SVID để đổi OAuth Token
IdP-->>A: 4. Cấp Short-lived Access Token
A->>MCP: 5. Gọi Tool + kèm Access Token
MCP->>IdP: 6. Xác thực Token (Introspection)
MCP-->>A: 7. Trả kết quả (Nếu hợp lệ)
- SPIFFE-Backed OAuth/OIDC (Phổ biến nhất): Agent gọi SPIRE Agent cục bộ để lấy SVID. Đem SVID này đổi lấy OAuth Token (JWT) từ Identity Provider, rồi dùng token đó gọi MCP Server.
- Service Mesh Sidecar: Đẩy việc định danh xuống network layer. Agent và MCP Server chạy chung với Istio/Envoy sidecar. Envoy tự động lấy SVID và thiết lập mTLS. Code của bạn hoàn toàn không cần biết về Auth.
- Instance-Level Identity (Advanced): Đừng cấp chung một SPIFFE ID cho mọi “Finance Agent”. Hãy cấp SPIFFE ID riêng cho từng instance của Agent (dùng pod UID). Điều này đảm bảo tính Auditability (truy vết) cực cao khi một Agent đưa ra quyết định sai lầm.
Lời Kết
Việc xác định được AI Agent là ai mới chỉ là một nửa bài toán. Nửa còn lại là: Làm sao quản lý việc 100 Agent giao tiếp với 50 MCP Server khác nhau trong công ty? Đây chính là lúc chúng ta cần một MCP Gateway - Control Plane thực sự của kiến trúc Agentic.
Next up: Phần 4: MCP Gateway Architecture