Your Insecure MCP Server Won't Survive Production — Tun Shwe, Lenses

• Thiết kế kém là nguyên nhân chính dẫn đến các máy chủ MCP không an toàn trong môi trường sản xuất; các máy chủ được thiết kế kém sẽ khuếch đại các lỗ hổng bảo mật đặc trưng của tác nhân AI thay vì chỉ thiếu xác thực.
• Tác nhân AI tương tác khác với con người, tạo ra các "bóng bảo mật" riêng như khả năng "đầu độc công cụ" thông qua mô tả công cụ, rò rỉ dữ liệu qua lịch sử hội thoại dài, và "tiêm ngữ cảnh" từ việc chia sẻ dữ liệu quá mức.
• Chuyển từ môi trường phát triển cục bộ sang sản xuất đòi hỏi vượt qua một "vách đá bảo mật" đáng kể, yêu cầu các giải pháp xác thực và ủy quyền phức tạp như OAuth 2.1 với Đăng ký máy khách động (DCR) và Mã xác minh khóa trao đổi (PCC) thay vì các khóa API đơn giản.

• Thu nhỏ bề mặt tấn công: Hợp nhất các hoạt động hạt mịn thành các lệnh gọi công cụ hạt thô duy nhất để giảm số lượng công cụ và cửa ngõ tiếp xúc, từ đó giảm thiểu các vectơ tấn công.
• Hạn chế đầu vào ở cấp độ lược đồ: Sử dụng các kiểu dữ liệu nguyên thủy (enum), từ điển không lồng nhau và thư viện kiểu (ví dụ: Pydantic) để từ chối các payload lồng nhau dạng tự do, ngăn chặn lỗ hổng command injection.
• Coi tài liệu là lớp phòng thủ: Viết tài liệu công cụ rõ ràng, đầy đủ và không mơ hồ để lấp đầy khoảng trống mà kẻ tấn công có thể lợi dụng cho việc "đầu độc công cụ."
• Chỉ trả về những gì tác nhân cần: Loại bỏ payload phản hồi đến mức tối thiểu, không bao gồm PII, định danh nội bộ hoặc thông tin xác thực không cần thiết cho nhiệm vụ trước mắt của tác nhân để tránh "chia sẻ dữ liệu quá mức."
• Giảm thiểu phạm vi ảnh hưởng: Giới hạn quyền ở cấp độ công cụ và tài nguyên, sử dụng chú thích chỉ đọc cho các công cụ không phá hủy và loại bỏ các công cụ không cần thiết để giảm thiểu các vectơ tấn công tiềm năng.
• Tránh I/O tiêu chuẩn trong sản xuất: Các máy chủ MCP cục bộ với I/O tiêu chuẩn không an toàn và không thể mở rộng quy mô cho môi trường sản xuất; luôn sử dụng giao thức truyền tải HTTP có khả năng truyền phát để triển khai từ xa và hỗ trợ nhiều máy khách.
• Triển khai OAuth 2.1 với DCR và PCC: Để xác thực cấp doanh nghiệp, áp dụng luồng OAuth 2.1 với Đăng ký máy khách động (DCR) cho việc đăng ký máy khách tại thời gian chạy và giao thức Proof Key for Code Exchange (PCC) để quản lý mã thông báo ngắn hạn, có phạm vi.

• MCP server — máy chủ MCP
• AI agent — tác nhân AI
• data operating fabric — nền tảng vận hành dữ liệu
• tool poisoning — đầu độc công cụ
• context injection — tiêm ngữ cảnh
• oversharing data — chia sẻ dữ liệu quá mức
• attack surface — bề mặt tấn công
• Proof Key for Code Exchange (PCC) — giao thức Proof Key for Code Exchange
• Dynamic Client Registration (DCR) — Đăng ký máy khách động
• authorization server — máy chủ ủy quyền

Giới thiệu

Xin chào mọi người, cảm ơn đã tham gia buổi chia sẻ về lý do tại sao MCP server không an toàn của bạn sẽ không thể tồn tại trong môi trường sản xuất. Tôi là Tune Shui, phụ trách AI tại Lenses. Hàng ngày, tôi là một kỹ sư AI, và bạn có thể kết nối với tôi trên LinkedIn. Và tôi là Jeremy Fene, tôi làm kỹ thuật AI tại Lenses.

Đầu tiên, một lưu ý nhanh về nơi chúng tôi làm việc. Lenses là một data operating fabric nằm giữa các tác nhân của bạn và bất kỳ sự kết hợp nào của Apache Kafka. Lenses là lớp dữ liệu truyền phát de facto cung cấp ngữ cảnh thời gian thực đáng tin cậy cho AI tác nhân. Các công ty làm việc với chúng tôi vì chúng tôi đặt quản trị, bảo mật và khả năng mở rộng lớn lên hàng đầu. Đây là một số khách hàng của chúng tôi, điều này giúp chúng tôi tiếp cận nhiều trường hợp sử dụng trong các ngành công nghiệp khác nhau ở quy mô lớn. Và tất nhiên, hôm nay chúng tôi ở đây vì chúng tôi có một MCP server mã nguồn mở mà chúng tôi đang áp dụng những bài học kinh nghiệm từ thực tế. Vì vậy, hãy ủng hộ dự án bằng cách gắn sao cho chúng tôi.

Đây là những gì chúng tôi sẽ trình bày trong phiên này. Những điểm chính chúng tôi muốn bạn nắm được là cách tư duy về việc thiết kế các MCP server, và trên thực tế, bất kỳ giao diện nào, để làm cho chúng mạnh mẽ cho các hệ thống AI đa tác nhân. Và vì đây là một buổi nói chuyện về MCP, chúng tôi sẽ đảm bảo bạn có các mẹo về cách tiếp cận để bảo mật MCP server của mình cho môi trường sản xuất. Tôi sẽ trình bày vài phần đầu, và trong các phần của mình, Jeremy sẽ đi sâu vào các luồng OAuth.

Tại sao hầu hết các MCP server kém hiệu quả

Hãy đi thẳng vào lý do tại sao hầu hết các MCP server không tuyệt vời. Tôi thích cách Jeremy Lohan, người tạo ra Fast MCP, đã diễn đạt. Ông nói rằng các tác nhân xứng đáng có giao diện riêng được tối ưu hóa cho các trường hợp sử dụng của chúng, để tiếp cận việc thiết kế cho tác nhân thông qua góc nhìn kỹ thuật sản phẩm. Tôi muốn đưa cách tiếp cận đó tiến thêm một bước nữa. Một MCP server được thiết kế kém cũng là một server được bảo mật kém; thiết kế yếu kém và bảo mật kém sẽ cộng hưởng lẫn nhau.

Jeremy đã đưa ra ba khía cạnh về sự khác biệt giữa con người và tác nhân, và để xem xét ba khía cạnh này khi bạn thiết kế cho MCP hoặc bất kỳ giao diện tác nhân nào. Lớp bổ sung mà tôi muốn nhấn mạnh là bảo mật: rằng mỗi khía cạnh đều tạo ra một "bóng bảo mật" (security shadow).

Khám phá (Discovery)

Khi bạn sử dụng một Giao diện lập trình ứng dụng mới, bạn mở tài liệu, bạn quét qua chúng một lần, bạn tìm thấy ba điểm cuối (endpoint) bạn cần và bạn không bao giờ nhìn vào tài liệu đó nữa. Một tác nhân không thể làm điều đó. Mỗi khi nó kết nối với một MCP server, nó liệt kê mọi công cụ và đọc mọi mô tả, và điều đó tốn kém về mã thông báo.

Nhưng đây là bóng bảo mật: mỗi mô tả công cụ đó là một bề mặt tấn công cho việc đầu độc công cụ (tool poisoning). Kẻ tấn công có thể nhúng các hướng dẫn ẩn bên trong các mô tả mà không hiển thị trên giao diện người dùng, nhưng mô hình sẽ làm theo chúng mà không nghi ngờ. Càng nhiều công cụ nghĩa là càng nhiều bề mặt tấn công để tiêm lệnh.

Lặp lại (Iteration)

Nếu tập lệnh của bạn thất bại, bạn chạy lại; chỉ mất một giây. Khi một tác nhân thử lại, nó gửi toàn bộ lịch sử cuộc trò chuyện qua mạng.

Và đây là bóng bảo mật của nó: một tác nhân lặp đi lặp lại trên một MCP server có phạm vi kém đang phát tán dữ liệu của bạn với mỗi lần thử lại. Toàn bộ lịch sử cuộc trò chuyện được gửi qua mạng, bao gồm bất kỳ dữ liệu nhạy cảm nào được trả về bởi các lệnh gọi công cụ trước đó. Mỗi chu trình khứ hồi (round trip) là một cơ hội cho rò rỉ dữ liệu.

Ngữ cảnh (Context)

Bạn và tôi có hàng thập kỷ ký ức, kinh nghiệm và trực giác. Một tác nhân có khoảng 200.000 mã thông báo, và chỉ có vậy thôi. Bóng bảo mật được trình bày chi tiết trong danh sách OWASP MCP Top 10, mà tôi khuyên tất cả các bạn nên đọc, và ở đó nó được liệt kê là số 10: tiêm ngữ cảnh (context injection) và chia sẻ quá mức (oversharing).

Nếu server của bạn đẩy dữ liệu chưa lọc vào cửa sổ ngữ cảnh hạn chế đó, bạn đang giao PII, thông tin xác thực, chi tiết hệ thống nội bộ cho một mô hình có thể bị lừa để rút trích dữ liệu chúng. Một tác nhân phải tải tất cả ngữ cảnh vào trước khi nó có thể đưa ra quyết định. Điều này làm cho nó phù hợp để tìm những thứ cụ thể, nhưng phải trả giá bằng độ trễ và phình to ngữ cảnh (context bloat). Vì vậy, bạn hãy nghĩ về nó như việc tìm kim trong đống rơm. Nếu một phần rơm đó bị nhiễm độc, tác nhân sẽ không nhận ra. Vì vậy, bạn nên nghĩ về việc tuyển chọn (curation): tuyển chọn các công cụ MCP có sẵn cho tác nhân, và đặt mục tiêu chỉ tiết lộ lượng thông tin nhỏ nhất. Bạn càng tiết lộ ít, càng ít bị tấn công, và ở đây, ít là nhiều.

Năm quy tắc chính để thiết kế tác nhân an toàn

Tiếp theo, tôi sẽ trình bày năm quy tắc chính mà tôi coi là quan trọng cho thiết kế tác nhân an toàn, để bạn tư duy với tư duy kỹ thuật sản phẩm và áp dụng nó vào các dịch vụ MCP. Điều tôi muốn bạn rút ra từ phần này là thiết kế MCP tốt và bảo mật MCP tốt là cùng một nguyên tắc. Nếu bạn thiết kế sai, không có bao nhiêu OAuth cũng không thể cứu bạn. Tôi có năm nguyên tắc ở đây, và tất cả đều mang lại cho bạn sự bảo vệ chống lại OWASP MCP Top 10 trước khi bạn viết dù chỉ một dòng mã xác thực.

1. Thu nhỏ bề mặt tấn công theo thiết kế

Về kết quả, ý tưởng ở đây là ép tất cả các hoạt động hạt mịn (fine-grain operations) hoặc các lệnh gọi API cơ bản thành một hoạt động hạt thô (coarse-grain operation) duy nhất tạo ra một kết quả mong muốn. Mỗi công cụ bạn tiết lộ là một cánh cửa. Đừng cấp cho tác nhân quyền xóa người dùng khi tất cả những gì nó cần là kiểm tra một đơn hàng. Hợp nhất các hoạt động liên quan đằng sau một lệnh gọi công cụ duy nhất với một kết quả được xác định rõ ràng. Vì vậy, bạn có một lần kiểm tra quyền, một mục nhật ký kiểm toán, một nơi để thực thi ủy quyền. Hãy nghĩ đến việc ít cửa hơn với ít khóa cần quản lý hơn.

2. Hạn chế đầu vào ở cấp độ lược đồ

Bạn phải chấp nhận các kiểu dữ liệu nguyên thủy cấp cao nhất như kiểu liệt kê, đó sẽ là cách tiếp cận tốt nhất. Từ điển cũng ổn, miễn là chúng không lồng nhau. Và để giới thiệu sự nghiêm ngặt hơn, bạn có thể sử dụng một thư viện kiểu (typing library) như Pydantic. Mục tiêu là từ chối các payload lồng nhau dạng tự do (freeform nested payloads) để tránh các lỗ hổng command injection mà nguyên nhân gốc rễ hầu như luôn là các đối số chuỗi không giới hạn (unconstrained string arguments) được truyền và truyền trực tiếp (stream) đến một shell, một công cụ truy vấn hoặc một Giao diện lập trình ứng dụng. Đầu vào bị ràng buộc (constrained inputs) dễ xác thực hơn và khó khai thác hơn.

3. Coi tài liệu của bạn là lớp phòng thủ

Đầu độc công cụ là số ba trong hướng dẫn OWASP MCP, và nó hoạt động bằng cách nhúng các hướng dẫn độc hại vào các mô tả không hiển thị trên giao diện người dùng nhưng được mô hình thực thi. Nếu bạn không viết các hướng dẫn rõ ràng, đầy đủ, một mô tả công cụ bị kẻ tấn công kiểm soát trong một MCP server lân cận có thể đánh lừa (shadow) server của bạn. Nếu tài liệu của bạn đầy đủ và không mơ hồ cho mọi công cụ, nó sẽ lấp đầy không gian mà một server lân cận bị đầu độc sẽ cố gắng lấp.

4. Chỉ trả về những gì tác nhân cần

Chia sẻ dữ liệu quá mức (oversharing data) vào các phản hồi là số 10 trong hướng dẫn OWASP MCP, và nó biến cửa sổ ngữ cảnh của tác nhân thành một khoản nợ (liability). PII, định danh nội bộ, thông tin xác thực, chi tiết hệ thống đều nằm trong ngữ cảnh – tất cả chỉ cách một tiêm lời nhắc để rút trích dữ liệu. Vì vậy, hãy loại bỏ payload của bạn đến mức tối thiểu. Nếu tác nhân không cần một mảnh dữ liệu cho nhiệm vụ trước mắt của nó, thì đừng trả về.

5. Giảm thiểu phạm vi ảnh hưởng

Giới hạn quyền ở cấp độ công cụ và tài nguyên, không phải cấp độ phiên. Sử dụng chú thích chỉ đọc của MCP cho các công cụ không phá hủy (non-destructive tools) để các máy khách có thể thực thi ranh giới. Hoặc nếu một công cụ MCP được thiết kế để có quyền truy cập chỉ đọc, thì hãy xem xét biến nó thành một tài nguyên MCP. Cũng hãy nhớ rằng mỗi công cụ bạn loại bỏ là một véc-tơ tấn công mà bạn loại bỏ, và bạn đang xây dựng một giao diện, không phải một công cụ. Vì vậy, đây là tư duy để bắt đầu: một tác nhân sẽ sử dụng bất cứ thứ gì bạn cung cấp với sự tự tin, vì vậy bạn phải cung cấp điều đó cho chúng tôi.

Vượt qua "Vách đá bảo mật" (Security Cliff)

Vậy là bạn đã thiết kế server của mình tốt, bạn đã tuân thủ năm nguyên tắc; bây giờ bạn cần triển khai nó. Và đây là nơi hầu hết các nhóm gặp phải cái mà tôi gọi là vách đá bảo mật. Nếu bạn đang chạy MCP ở chế độ I/O tiêu chuẩn, cuộc sống khá thoải mái. Đó là một tiến trình cục bộ, một người dùng duy nhất, không phơi bày mạng, không cần xác thực. Máy chủ MCP của bạn giao tiếp trực tiếp với tiến trình server trên máy của bạn. Đó là một vườn có tường bao quanh (walled garden), và nó hoạt động tuyệt vời cho năng suất của nhà phát triển một người chơi.

Nhưng môi trường sản xuất đòi hỏi một cái gì đó hoàn toàn khác. Bạn cần giao thức truyền tải HTTP có khả năng truyền phát. Điều này cho phép triển khai từ xa, nhiều máy khách kết nối với cùng một server. Bạn có thể mở rộng theo chiều ngang và bạn có thể tập trung hóa quản trị của mình. Và đây thực sự là nơi MCP trở nên có giá trị thực sự đối với một tổ chức, nơi bạn đi từ một nhà phát triển trên một máy tính xách tay đến một khả năng dùng chung mà toàn bộ nhóm hoặc toàn bộ hạm đội tác nhân có thể sử dụng. MCP trở thành giao diện duy nhất mà tất cả các máy khách có thể sử dụng mà không phải lo lắng về việc liệu chúng có phải là phiên bản Giao diện lập trình ứng dụng mới nhất hay xem xét các tài nguyên cần thiết để mở rộng.

Vấn đề là không có đường dốc (on-ramp) dần dần. Bạn đi từ bề mặt bảo mật bằng không đến một danh sách khổng lồ các mối lo ngại cùng một lúc. Bạn đột nhiên cần rất nhiều quản lý mã thông báo, cấu hình hạt thô (coarse-grain configuration), TLS, giới hạn tốc độ, và nhiều hơn nữa, và bạn cần tất cả cùng một lúc. Vì vậy, không có giải pháp tạm thời vì bạn không thể làm một chút sản xuất. Bạn đang ở sau bức tường hoặc bạn đang đứng ngoài trời. Và bạn không thể chỉ ở lại cục bộ và hy vọng điều tốt nhất. Stack Lock đã chạy kiểm thử tải (load tests) trên giao thức truyền tải I/O tiêu chuẩn, và kết quả rất thảm khốc: 20 trong số 22 yêu cầu đã thất bại chỉ với 20 kết nối đồng thời. I/O tiêu chuẩn sụp đổ ngay khi bạn thêm đồng thời. Vì vậy, nếu bạn muốn mở rộng, bạn phải vượt qua vực sâu.

Và làm thế nào để bạn bắt đầu vượt qua vực sâu đó? Tôi sẽ giao lại cho Jeremy để tiếp tục.

Triển khai xác thực cho MCP Server

Vâng, việc triển khai tất cả cho server của tổ chức cho MCP không hề đơn giản. Hãy xem danh sách các RFC cần triển khai với luồng OAuth cốt lõi, khám phá máy khách (client discovery) và siêu dữ liệu, và quản lý vòng đời mã thông báo. Chúng ta đã có hơn 10 đặc tả để triển khai. Bây giờ, giả sử chúng ta đã đọc tất cả các RFC này và tôi đã sẵn sàng triển khai một máy chủ ủy quyền (authorization server) cho MCP. Ủy quyền cấp doanh nghiệp trông như thế nào?

Vì vậy, hãy bắt đầu bằng cách xem xét các thiết lập MCP server cục bộ và từ xa và các luồng OAuth tương ứng của chúng. Tune đã nói về vườn có tường bao quanh, MCP server cục bộ chạy trên I/O tiêu chuẩn với một Khóa API. Hãy xem sơ đồ luồng.

Thiết lập MCP Server cục bộ

MCP server chạy trên máy của tôi. Máy khách kết nối qua I/O tiêu chuẩn. Người dùng phải đặt khóa làm tham số trong cấu hình máy khách MCP. Và tham số sẽ được lưu trữ dưới dạng Biến môi trường, được MCP server truyền đi cùng với yêu cầu của nó đến dịch vụ bên ngoài. Điều đó có thể tốt cho các thiết lập cục bộ, nhưng tôi cần cấp phát, lưu trữ và duy trì khóa. Khóa này tồn tại lâu dài, hiếm khi được xoay vòng (rotated), và không được giới hạn phạm vi (scoped) cho các hành động cụ thể mà máy khách của tôi thực hiện. Tệ hơn nữa, những khóa này thường được chia sẻ giữa các hệ thống. Vì vậy, khóa được lưu trữ trong một tệp cấu hình, một Biến môi trường và không được MCP server xác minh.

Thiết lập MCP Server từ xa

Bây giờ, hãy xem xét một MCP server từ xa. Trong trường hợp này, MCP server chạy trên server từ xa. Máy khách kết nối qua HTTP. Người dùng phải đặt khóa trong tiêu đề ủy quyền HTTP. Một lần nữa, chúng ta có thể thấy cấu hình máy khách MCP ở đây trên màn hình.

Vì vậy, giai đoạn một là tạo mã thông báo (generation of the token) và cấu hình máy khách. Ở bước hai, thời gian chạy, chúng ta có thể thấy máy khách thực hiện một yêu cầu, đính kèm Khóa API này trong tiêu đề ủy quyền. Khóa API này được MCP server xác thực hoặc không và sẽ được chuyển đến API thượng nguồn nơi nó sẽ được xác minh. Dù Khóa API có được xác thực hay không, chúng ta nhận được phản hồi 200 hoặc phản hồi 401, trong trường hợp đó người dùng sẽ cần xoay vòng mã thông báo theo cách thủ công. Đó là cách phần lớn các MCP server từ xa được cấu hình hiện nay.

Khóa này tồn tại lâu dài, nó cũng không được giới hạn phạm vi cho hành động cụ thể của các tác nhân của tôi. Khóa được lưu trữ trong một tệp cấu hình, và không phải lúc nào cũng được MCP server xác minh. Hoặc khóa đơn giản được chuyển qua API, tạo ra một lỗ hổng confused deputy (confused deputy vulnerability) nơi các máy khách độc hại giành được ủy quyền mà không có sự đồng ý hợp lệ của người dùng. Đôi khi khóa có thể được ánh xạ tới một khóa và mã thông báo khác để truy cập API chính nó. Bây giờ chúng ta có một thông tin xác thực dùng chung duy nhất phục vụ nhiều người dùng, nhưng thông tin xác thực này thậm chí còn mạnh hơn, khó bị người dùng thu hồi hơn, và nếu bị rò rỉ, nó sẽ làm lộ thông tin của tất cả mọi người. Cách tiếp cận này hoạt động cho các thiết lập thông tin xác thực tồn tại lâu dài và có phạm vi. Nó vẫn chiếm hơn 50% các MCP server hiện có.

Điều chúng tôi thấy hệ sinh thái đang hướng tới là các mã thông báo tồn tại ngắn hạn, có phạm vi thông qua OAuth 2.1.

Trao đổi mã thông báo và OAuth truyền thống

Chúng ta thậm chí còn thấy việc trao đổi mã thông báo để có quyền truy cập đặc quyền này. OAuth truyền thống giả định bạn biết các máy khách của mình từ trước. Bạn đăng ký chúng trong một cổng thông tin nhà phát triển, nhận ID máy khách và tiếp tục. Điều này hoạt động khi bạn có 5 đến 10 ứng dụng kết nối với dịch vụ của mình. Nhưng với MCP, luồng này hoàn toàn bị phá vỡ.

Hãy nghĩ về kiến trúc của MCP thực sự trông như thế nào. Bất kỳ máy khách nào – Clodestop, Cursor, VS Code, một công cụ CI, một tác nhân ngẫu nhiên – đều có thể phát hiện và kết nối với bất kỳ máy chủ MCP nào tại thời gian chạy. Đăng ký trước đòi hỏi quá nhiều nỗ lực trong một môi trường có khả năng thay đổi cao. Đó là một số lượng máy khách không giới hạn kết nối với một số lượng máy chủ không giới hạn. Bạn không thể yêu cầu mọi nhà phát triển tự đăng ký ứng dụng của họ với mọi máy chủ MCP mà họ có thể muốn giao tiếp.

Đăng ký máy khách động (DCR)

Đó là lúc Đăng ký máy khách động (DCR) ra đời. Trong trường hợp này, chúng ta vẫn có một máy chủ MCP chạy trên một máy chủ từ xa, nhưng giờ đây nó được bảo vệ bởi một máy chủ ủy quyền OAuth. Máy khách có thể tự đăng ký với máy chủ ủy quyền và chúng ta nhận được một ID máy khách mới trên mỗi lần đăng ký.

Trong giai đoạn một, khám phá, hoặc máy khách MCP (ví dụ: Cursor) sẽ thực hiện một yêu cầu trên /MCP đối với máy chủ MCP. Chúng ta có thể thấy máy chủ MCP trả về phản hồi 401 vì chúng ta chưa có mã thông báo để chuyển. Nhưng nó cũng chuyển qua tiêu đề On-TK rất yếu, chứa siêu dữ liệu tài nguyên có thể được máy khách của bạn sử dụng để khám phá máy chủ MCP và siêu dữ liệu của nó. Tài liệu đó trông hơi giống thế này. Nó mô tả tài nguyên thể hiện sự thành công và máy chủ ủy quyền bảo vệ nó. Điều này cho phép máy khách của chúng ta trỏ đến chính máy chủ ủy quyền và khám phá lần này siêu dữ liệu do chính máy chủ ủy quyền cung cấp.

Giờ đây, máy khách biết cách tự ủy quyền để truy cập máy chủ MCP. Nó cần tự đăng ký với máy chủ ủy quyền. Việc đó được thực hiện thông qua một yêu cầu POST trên /register. Như chúng tôi đã đề cập trước đó, máy chủ ủy quyền sẽ tạo và duy trì một ID máy khách mới và trả về cho máy khách. Giờ đây, chúng ta biết mình đang nói chuyện với ai.

Tiếp theo, đã đến lúc ủy quyền cho máy khách của chúng ta với máy chủ ủy quyền. Và để làm điều đó, đặc tả MCP yêu cầu sử dụng PCC – giao thức Proof Key for Code Exchange. Vì vậy, máy khách MCP của chúng ta trước tiên sẽ tạo một code verifier và một code challenge. Nhưng nó sẽ chuyển một yêu cầu đến /authorize để lấy một mã ủy quyền. Máy chủ ủy quyền sẽ xác thực yêu cầu này và code challenge. Và vì chúng ta chưa có phiên đang chạy cho người dùng này, nó sẽ chuyển hướng người dùng đến nhà cung cấp danh tính của họ. Đó là biểu mẫu đăng nhập một lần để người dùng đăng nhập. Sau khi đăng nhập thành công, người dùng sẽ được chuyển hướng đến một trang đồng ý, nơi họ có thể cấp các phạm vi khác nhau cho máy khách của mình.

Bây giờ chúng ta đã cấp một mã ủy quyền hợp lệ cho máy khách, đã đến lúc sử dụng nó để lấy một mã thông báo – một mã thông báo truy cập. Việc đó được thực hiện bằng cách gửi một yêu cầu đến /token và chuyển mã ủy quyền cùng với code verifier mà chúng ta đã tạo cho giao thức PCC trước đó. Máy chủ ủy quyền sẽ xác thực thử thách PCC và mã ủy quyền. Và sau đó, nó sẽ tạo ra một mã thông báo hoàn toàn mới. Trong trường hợp này, chúng ta đang sử dụng Jason Web tokens để trả về một mã thông báo truy cập cho máy khách để bây giờ sử dụng máy chủ MCP.

Bước cuối cùng thực sự là sử dụng máy chủ MCP. Đây là lúc máy khách MCP của bạn sẽ thực hiện một gọi công cụ, ví dụ. Chúng ta có thể thấy nó sẽ chuyển mã thông báo truy cập vừa được cấp làm giá trị bearer trong phần Authorization. Máy chủ MCP của chúng ta sẽ xác thực mã thông báo này, kiểm tra các phạm vi hợp lệ, và sau đó nó sẽ thực hiện luồng trao đổi mã thông báo để đổi mã thông báo ủy quyền này lấy mã thông báo phiên. Điều này có nghĩa là máy chủ MCP của chúng ta bây giờ thực sự là một máy khách OAuth cho một máy chủ tài nguyên hoặc API mới. Nhưng nó đang sử dụng cùng một máy chủ ủy quyền để lấy một mã thông báo. Vậy đó là luồng trao đổi mã thông báo được định nghĩa trong RFC 8693. Và khi chúng ta hoàn thành luồng, máy chủ MCP của chúng ta có thể sử dụng mã thông báo phiên mới này để thực hiện một gọi API bằng cách chuyển mã thông báo trong tiêu đề Authorization.

Nhược điểm của Đăng ký máy khách động (DCR)

Vậy DCR phục vụ việc tự đăng ký, đăng ký động của máy khách, để tất cả người dùng không phải đi và đăng ký trước, tạo trước các thông tin xác thực tĩnh và đặt nó trên máy khách đó. Nhưng nó cũng có những vấn đề riêng.

Thứ nhất, mỗi khi người dùng kết nối một máy khách với một máy chủ MCP, một đăng ký mới được tạo. Các đăng ký không di động được, vì vậy việc sử dụng Claude trên Windows và sau đó trên macOS tạo ra hai đăng ký máy khách riêng biệt. DCR dễ bị tổn thương trước tấn công lừa đảo vì nó không cung cấp một cách đáng tin cậy để xác minh danh tính máy khách. Bất kỳ ai cũng có thể POST đến endpoint đó, endpoint /register, bao gồm cả những kẻ tấn công. Cuối cùng, máy chủ chỉ tin tưởng bất kỳ siêu dữ liệu nào mà máy khách tự cung cấp. Điều đó có nghĩa là một máy khách độc hại có thể tự nhận là Claude và máy chủ không có cách nào khác để biết.

Tài liệu siêu dữ liệu ID máy khách (CIMD)

Vì vậy, cộng đồng MCP phải đưa ra một cách tốt hơn để cho phép máy khách tự đăng ký. Và đó là CIMD – Tài liệu siêu dữ liệu ID máy khách.

Trong trường hợp này, chúng ta vẫn không có máy chủ ủy quyền ở phía trước máy chủ MCP của chúng ta, nhưng chủ sở hữu máy khách cung cấp ID máy khách trên URL công khai. Điều này sẽ cho phép máy chủ MCP của chúng ta lấy ID máy khách trong quá trình ủy quyền.

Hãy xem sơ đồ. Giai đoạn một vẫn là khám phá, hoặc máy khách truy cập máy chủ MCP mà không có mã thông báo, nhận phản hồi 401 và URL siêu dữ liệu tài nguyên. Nó có thể theo URL này, khám phá máy chủ MCP và nó sẽ khám phá máy chủ ủy quyền. Nhưng lần này, máy chủ ủy quyền không đề cập rằng nó cần một yêu cầu /register. Điều đó có nghĩa là máy khách, máy khách MCP, có thể trực tiếp đến giai đoạn ủy quyền. Chúng ta lại tạo code verifier PCC và thực hiện yêu cầu /authorize.

Nhưng lần này, máy khách của chúng ta chuyển ID duy nhất của nó và chúng ta có thể thấy nó ở đây. Nó thực sự là một URL hợp lệ nơi siêu dữ liệu cho máy khách được cung cấp. Đây là cách máy chủ ủy quyền của chúng ta tìm nạp siêu dữ liệu này và đăng ký một máy khách mới với một ID duy nhất. Đó là URL được cung cấp bởi chủ sở hữu máy khách và chúng ta có thể chuyển sang giai đoạn xác thực.

Một lần nữa, máy chủ ủy quyền sẽ chuyển hướng đến nhà cung cấp danh tính, đợi đăng nhập hợp lệ từ phía người dùng, trình bày màn hình đồng ý để người dùng cấp một số phạm vi. Và chúng ta đã sẵn sàng cấp mã thông báo ủy quyền và mã thông báo phiên, hoặc mã thông báo được sử dụng bởi máy chủ MCP.

Vậy, CIMD không có cơ sở dữ liệu đăng ký máy khách đang phát triển để duy trì. Việc chứng minh rằng bạn kiểm soát HTTPS, claude.ai có ý nghĩa, không giống như việc chứng minh rằng bạn có thể POST trên endpoint đăng ký. Chúng chuyển hướng URL được liên kết rõ ràng với máy khách trong tài liệu siêu dữ liệu của nó, hoặc khiến những kẻ tấn công khó lén lút đưa vào các callback độc hại hơn. Và máy chủ ủy quyền có thể cho phép hoặc từ chối máy khách một cách có chọn lọc.

Bảo mật cấp độ doanh nghiệp cho AI Agent

Tóm lại, DCR là một khởi đầu tốt, nhưng nó tạo ra vấn đề. CIMD là một bước tiến nhảy vọt và là cách tiếp cận được ưa thích kể từ tháng 11 năm 2025. Nhưng để đạt được cấp độ doanh nghiệp đòi hỏi phải thêm các lớp bảo mật và độ tin cậy khác.

Đối với quyền hạn, tất cả các phạm vi đều giúp bạn đạt được một phần mục tiêu, nhưng nó được giới hạn trong phiên làm việc. Kiểm soát truy cập dựa trên vai trò cấp độ doanh nghiệp thực sự có nghĩa là giới hạn quyền hạn ở cấp độ công cụ và tài nguyên riêng lẻ, không chỉ là phiên làm việc.

Che giấu dữ liệu là cách bạn xử lý các trường thông tin nhận dạng cá nhân (PII) như email, số điện thoại và số bảo hiểm quốc gia. Chúng có thể cần được che giấu trước khi tác nhân nhìn thấy chúng vì các tác nhân không bao giờ nên tiếp xúc với dữ liệu mà họ không có quyền xử lý.

Bạn sẽ cần ghi nhật ký những gì đang xảy ra trong mỗi tương tác, tác nhân nào đã gọi công cụ nào với tham số nào và dữ liệu nào đã được trả về. Để tuân thủ các quy định như EU AI Act, các cơ quan quản lý sẽ mong đợi mức độ minh bạch và chi tiết này đối với các hệ thống AI tự hành.

Cuối cùng, bạn sẽ cần có khả năng quan sát toàn bộ yêu cầu. Điều này có nghĩa là xác thực yêu cầu của máy khách, thực thi công cụ, truy xuất dữ liệu và phản hồi được tạo ra. Nếu bạn không thể truy vết những gì một tác nhân đã làm từ đầu đến cuối, bạn không thể quản lý nó. Truy vết cho tác nhân AI tuân theo các nguyên tắc tương tự như khả năng quan sát của hệ thống phân tán, nhưng được áp dụng cho việc ra quyết định tự chủ.

Cảm ơn rất nhiều, Jeremy, và cảm ơn tất cả các bạn đã theo dõi buổi hội thảo này. Chúng tôi rất muốn biết hành trình của các bạn với việc đưa các dịch vụ MCP vào sản xuất đang diễn ra như thế nào. Vì vậy, vui lòng để lại bình luận hoặc gửi tin nhắn cho chúng tôi biết nơi để tìm chúng tôi, và hãy kiểm tra máy chủ MCP của chúng tôi và tặng chúng tôi một star. Hy vọng chúng tôi sẽ gặp lại các bạn sớm. Cảm ơn và tạm biệt. Cảm ơn.