MCP đã công bố đặc tả “Enterprise-Managed Authorization” (Ủy quyền do Doanh nghiệp Quản lý) ổn định; các bản thảo danh tính máy-với-máy khác—bao gồm một bản thảo OAuth client-credentials và hai đề xuất mở—vẫn chưa hoàn thiện. Đối với bất kỳ ai đang cố gắng vận hành các tác nhân tự trị (autonomous agents) với Model Context Protocol, điều đó có nghĩa là giao thức hiện tại có thể xác minh người dùng là con người nhưng chưa cung cấp cách thức sẵn có để chứng minh một tiến trình không cần giám sát (unattended process) đúng là thực thể mà nó tuyên bố.
Tại sao lộ trình (roadmap) lại quan trọng
Lộ trình của Model Context Protocol (MCP) liệt kê danh tính và bảo mật tác nhân là một trong những ưu tiên hàng đầu. Bốn hạng mục đã được lên kế hoạch phát hành: luồng trình duyệt tập trung vào con người (human-centric browser flow), luồng OAuth client-credentials cho các dịch vụ, liên kết token dựa trên DPoP, và cơ chế liên kết danh tính khối lượng công việc (workload-identity federation). Chỉ có hạng mục đầu tiên—Enterprise-Managed Authorization—là đã đạt đến trạng thái ổn định.
Đặc tả ổn định thực sự làm được gì
Enterprise-Managed Authorization cho phép quản trị viên IT cấp quyền truy cập máy chủ từ một bảng điều khiển duy nhất thay vì để mỗi nhân viên phải phê duyệt mọi kết nối. Luồng này sử dụng chuyển hướng trình duyệt và đăng nhập người dùng, vì vậy một người ngồi trước máy tính xách tay có thể xác thực và sau đó máy chủ sẽ tin tưởng phiên làm việc của người dùng đó.
Hạn chế là rất rõ ràng: quy trình này cần một con người ngồi trước bàn phím. Một tác nhân chạy qua đêm, xử lý dữ liệu hoặc phản hồi các cảnh báo sẽ không có ai để nhấn nút đăng nhập. Do đó, bất kỳ triển khai nào phụ thuộc vào các tác nhân không cần giám sát đều không thể sử dụng đặc tả duy nhất mà MCP hiện đang đảm bảo.
Các tùy chọn bản thảo và nhược điểm của chúng
Hai phần mở rộng bản thảo nhằm mục đích cung cấp danh tính riêng cho các tác nhân:
- SEP-1932 (DPoP) – liên kết các token với một cặp khóa công khai-riêng tư (public-private key pair), khiến các token bị đánh cắp trở nên vô dụng.
- SEP-1933 (Workload Identity Federation) – cho phép các tác nhân thừa hưởng danh tính đã được cấp phát sẵn trong các nền tảng đám mây.
Cả hai đều đang ở dạng pull request mở; chưa có cái nào được hợp nhất vào đặc tả chính thức. Trong thời gian chờ đợi, tùy chọn duy nhất khác được tài liệu hóa là luồng OAuth client-credentials yêu cầu các bí mật (secrets) đã được đăng ký trước. Việc lưu trữ các bí mật đó ở nơi mà tác nhân có thể đọc được sẽ tạo ra một bề mặt tấn công (attack surface) điển hình: nếu bí mật bị rò rỉ, bất kỳ kẻ tấn công nào cũng có thể mạo danh tác nhân.
Các bước thực tế cho môi trường production hiện nay
Vì giao thức vẫn chưa cung cấp danh tính tác nhân gốc (native agent identity), các đội ngũ vẫn có thể bảo mật các tác nhân bằng cách đưa việc quản lý danh tính ra ngoài MCP:
- Cấp phát danh tính có thể xác minh tại lớp workload. Các hệ thống như SPIRE tạo ra các chứng chỉ có thời hạn ngắn gắn liền với gốc tin cậy (trust root) của máy chủ, loại bỏ các bí mật tĩnh (static secrets).
- Kết thúc thông tin xác thực tại một gateway. Một dịch vụ front-end giữ API key hoặc token và chuyển tiếp các yêu cầu thay mặt cho tác nhân, giữ cho bí mật không nằm trong môi trường thực thi (runtime environment).
- Ủy quyền dựa trên danh tính đã được xác minh, không phải nội dung token. Tách biệt việc xác thực (ai đang gọi) khỏi việc ủy quyền (họ có thể làm gì) để chính sách có thể được thực thi ngay cả khi phương thức xác thực thay đổi.
Những gì cần theo dõi tiếp theo
Hai pull request đang mở – liên kết DPoP và liên kết danh tính khối lượng công việc (workload-identity federation) – là những con đường duy nhất dẫn đến một tiêu chuẩn danh tính máy-với-máy thực sự trong MCP. Nếu cộng đồng hợp nhất chúng, các tác nhân sẽ có thể chứng minh quyền sở hữu một khóa riêng tư hoặc thừa hưởng các danh tính do đám mây cấp mà không làm lộ các bí mật. Cho đến lúc đó, bất kỳ triển khai production nào cũng phải dựa vào các khung danh tính (identity frameworks) bên ngoài hoặc chấp nhận rủi ro từ các thông tin xác thực tĩnh.
Bài học rút ra rất rõ ràng: MCP hiện tại có thể xác thực người đứng sau một yêu cầu, nhưng nó vẫn chưa xác thực phần mềm đang thực hiện yêu cầu đó. Các đội ngũ cần các tác nhân tự trị bảo mật không nên chờ đợi đặc tả được hoàn thiện; họ phải xây dựng danh tính tại lớp workload ngay hôm nay và theo dõi các đề xuất DPoP và liên kết (federation) đang chờ xử lý.