← Chương trước: Phần 2: Build Production Server Bằng Go | Mục lục Series | Chương tiếp theo: Phần 4: MCP Gateway Architecture →
Answer-first: Quản lý danh tính trong Agentic AI yêu cầu áp dụng Non-Human Identity (NHI), Workload Identity Federation và OAuth 2.1 với Proof Key for Code Exchange (PKCE). Bài viết hướng dẫn thiết lập cơ chế ủy quyền đa tầng, phân quyền scoped-token và bảo vệ trust boundary khi agent gọi MCP tools.
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.
- Resource Indicators (RFC 8707) & Protected Resource Metadata (RFC 9728): Agent phải chỉ định rõ Resource Server đích để tránh token replay attacks và hỗ trợ xác định chính xác endpoint từ handshake ban đầu.
- 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 được ứng dụ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)
flowchart TD
A["AI Agent"] -->|"1. Fetch SVID (Workload Identity)"| S["SPIRE Agent"]
S -->|"2. Cấp phát SVID (X.509 / JWT)"| A
A -->|"3. Trình SVID đổi OAuth Token"| IdP["Identity Provider (IdP)"]
IdP -->|"4. Cấp Short-Lived Access Token"| A
A -->|"5. Gọi Tool + Kèm Access Token"| MCP["MCP Server"]
MCP -->|"6. Xác thực Token (Token Introspection)"| IdP
IdP -->|"Token Hợp Lệ"| MCP
MCP -->|"7. Trả kết quả thực thi Tool"| A
- 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.
← Chương trước: Phần 2: Build Production Server Bằng Go | Mục lục Series | Chương tiếp theo: Phần 4: MCP Gateway Architecture →
❓ Câu Hỏi Thường Gặp (FAQ)
Q1: Identity & AuthN Cho Agentic Workflows giải quyết vấn đề cốt lõi nào trong kiến trúc hệ thống?
Bảo vệ hệ thống trước sự tự chủ của AI Agent. Phân tích 3 cấp độ định danh (NHI), áp dụng Workload Identity và OAuth 2.1 với PKCE để bảo vệ MCP Server.
Q2: Những lưu ý quan trọng nhất khi triển khai thực tế là gì?
Cần chú trọng phân tầng ranh giới trách nhiệm (bounded context), thiết lập cơ chế fallback dự phòng, và giám sát chặt chẽ qua metrics OpenTelemetry để phát hiện sớm các điểm nghẽn.
Q3: Làm sao để kiểm thử và đánh giá hiệu quả sau khi áp dụng?
Áp dụng kiểm thử tải (load test), benchmark độ trễ P95/P99 trước và sau triển khai, kết hợp tracing phân tán để xác minh tính ổn định dưới tải cao.