Giới thiệu

Model Context Protocol, hay MCP, định nghĩa một phương thức có cấu trúc để ứng dụng AI kết nối với các capability và dữ liệu bên ngoài. Các thành phần cốt lõi gồm ứng dụng host, một MCP client và một hoặc nhiều MCP server. Host là sản phẩm mà người dùng tương tác, chẳng hạn như IDE hoặc ứng dụng trợ lý. Thông thường, host tạo một kết nối client riêng cho từng server để trạng thái giao thức, capability và lỗi luôn được gắn với đúng server tương ứng.

MCP server cung cấp các capability thông qua các operation của giao thức. Tool là những operation có thể thực thi để truy vấn một service, sửa đổi một record, gửi tin nhắn hoặc thực hiện một side effect khác. Resource đại diện cho dữ liệu mà client có thể truy xuất, còn prompt cung cấp các template prompt hoặc mẫu tương tác có thể tái sử dụng. Các nhóm này hữu ích về mặt kiến trúc, nhưng không nhóm nào nên được mặc định xem là đáng tin cậy chỉ vì nó được truyền qua MCP. Bảo mật trong môi trường production phụ thuộc vào việc ai sở hữu từng component, dữ liệu nào đi qua mỗi kết nối và một operation có thể thực thi quyền hạn đến đâu.

Luồng request và vai trò của các component

Một tương tác điển hình bắt đầu khi host thiết lập một session với MCP server thông qua một transport được hỗ trợ. Client và server khởi tạo session giao thức, sau đó trao đổi thông tin về các capability được hỗ trợ. Host có thể khám phá các tool, resource hoặc prompt hiện có, rồi quyết định cách hiển thị những capability đó trong trải nghiệm người dùng hoặc đưa chúng vào context của model. Transport cụ thể có thể khác nhau giữa các môi trường triển khai cục bộ và từ xa, nhưng các câu hỏi về trust vẫn không thay đổi.

Khi model đề xuất một tool call, host hoặc client chịu trách nhiệm áp dụng policy tương tác và phân quyền của sản phẩm trước khi chuyển tiếp request. Server xác thực request một lần nữa và thực hiện operation bằng credential riêng cùng các quyền runtime của nó. Kết quả đi ngược qua server và client đến host, nơi kết quả có thể được hiển thị cho người dùng hoặc bổ sung vào context của model. Việc xác thực lặp lại này là có chủ đích: policy ở phía client giúp giảm các request không an toàn, còn việc xác thực ở phía server bảo vệ server khi có client khác hoặc message không hợp lệ gửi đến.

Việc đọc một resource đi theo luồng tương tự nhưng có hồ sơ rủi ro khác. Server phân giải resource được yêu cầu rồi trả về content hoặc metadata. Chỉ đọc không có nghĩa là vô hại: resource có thể chứa thông tin mật, chỉ dẫn độc hại, dữ liệu cá nhân hoặc content đã lỗi thời. Host phải duy trì provenance và áp dụng các access control trước khi hiển thị hoặc sử dụng content đó.

Các ranh giới tin cậy trong môi trường phát triển

Ranh giới đầu tiên nằm giữa người dùng và ứng dụng máy chủ. Máy chủ tiếp nhận các yêu cầu bằng ngôn ngữ tự nhiên, kết quả công cụ, nội dung tài nguyên và có thể cả chỉ dẫn từ các hệ thống bên ngoài. Máy chủ trong môi trường production không nên mặc định rằng mọi chỉ dẫn bên trong nội dung được truy xuất đều thể hiện ý định của người dùng. Cần có các quy tắc xác nhận rõ ràng, đặc biệt khi một hành động thay đổi dữ liệu, liên hệ với bên thứ ba, tiêu tiền hoặc làm lộ thông tin bí mật.

Ranh giới thứ hai nằm giữa MCP client của máy chủ và server. Server có thể là một tiến trình cục bộ được cài đặt từ một package, một dịch vụ nội bộ được quản lý riêng hoặc một dịch vụ từ xa do một đội ngũ khác vận hành. Các lựa chọn triển khai này làm thay đổi mô hình xác thực, cô lập và cập nhật. Một tiến trình cục bộ vẫn có thể đọc tệp, kế thừa biến môi trường, truy cập các đích mạng hoặc thực thi các dependency dễ bị tấn công. Một server từ xa vẫn có thể nhận các tham số nhạy cảm và trả về nội dung ảnh hưởng đến model.

Ranh giới thứ ba nằm giữa MCP server và các hệ thống downstream của nó. Server có thể gọi cơ sở dữ liệu, cloud API, hệ thống tệp, hệ thống ticket hoặc lệnh shell. Việc xác thực MCP không tự động cấp quyền cho các hành động downstream đó. Server nên sử dụng các service identity có phạm vi hẹp, kiểm soát đích đến một cách rõ ràng, timeout, rate limit và cơ chế cấp quyền theo từng thao tác. Một server có thể gửi các yêu cầu quản trị không hạn chế là một thành phần có mức độ tác động cao, ngay cả khi giao diện MCP của nó chỉ cung cấp một vài tool.

Danh tính và cấp quyền trong môi trường production

Xác thực trả lời câu hỏi ai đang kết nối; cấp quyền trả lời câu hỏi danh tính đó được phép làm gì. Trong một deployment production, khi có thể, hãy xác định riêng ngữ cảnh của máy chủ hoặc người dùng và MCP server. Tránh sử dụng một credential dùng chung cho mọi client và server. Các danh tính riêng biệt giúp cải thiện khả năng thu hồi quyền, điều tra sự cố, rate limit và thực thi nguyên tắc đặc quyền tối thiểu. Các deployment từ xa cũng cần transport bảo mật và một phương thức được xác định rõ để xử lý credential; không nên đặt credential trong tham số tool hoặc trả về credential trong kết quả tool.

Thương lượng capability hữu ích cho khả năng tương thích, nhưng không phải là quyết định cấp quyền. Việc server thông báo rằng nó hỗ trợ tool không có nghĩa là một người dùng cụ thể được phép gọi mọi tool. Cấp quyền nên được đánh giá cho thao tác, đích đến, tenant và phân loại dữ liệu được yêu cầu. Ví dụ, người dùng có thể được phép đọc một resource của dự án nhưng không được phép xóa dự án, ngay cả khi cả hai capability đều được cùng một server cung cấp.

Schema của tool giúp giới hạn input, nhưng schema không phải là chính sách bảo mật hoàn chỉnh. Server nên xác thực kiểu dữ liệu, phạm vi, độ dài, định danh và mối quan hệ giữa các trường. Server nên từ chối các đích đến không mong đợi, đường dẫn tệp không an toàn, tham chiếu tenant không hợp lệ và các yêu cầu vượt quá phạm vi của bên gọi. Đối với các hành động có mức độ tác động cao, host có thể yêu cầu người dùng phê duyệt rõ ràng và hiển thị đích đến, tác động dự kiến cùng các tham số quan trọng trước khi thực thi. Việc phê duyệt nên được ràng buộc với hành động cụ thể thay vì được xem như quyền cho phép vĩnh viễn.

Kiểm soát vận hành và xử lý lỗi

Vận hành trong môi trường production đòi hỏi khả năng quan sát trên toàn bộ đường đi của yêu cầu. Hãy ghi lại danh tính nào đã khởi tạo yêu cầu, server nào đã xử lý, tool hoặc resource nào được chọn, kết quả cấp quyền và kết quả downstream. Loại bỏ hoặc che giấu secret cùng dữ liệu cá nhân không cần thiết. Liên kết log của client, server và downstream bằng một request identifier, đồng thời lưu ý rằng bản thân log cũng trở thành tài sản nhạy cảm cần được kiểm soát truy cập và áp dụng quy tắc lưu giữ.

Hãy thiết kế cho các lỗi từng phần. Server có thể không khả dụng, API downstream có thể timeout, response có thể vượt giới hạn kích thước hoặc tool có thể trả về lỗi sau khi đã tạo ra một side effect. Host nên truyền đạt rõ ràng trạng thái không chắc chắn và không được tự động retry các thao tác không idempotent nếu chưa có chính sách được xác định. Server nên sử dụng timeout có giới hạn, concurrency được kiểm soát, giới hạn kích thước response và cơ chế xử lý lỗi nhất quán. Circuit breaker hoặc rate limit có thể phù hợp với các dependency tốn kém hoặc dễ lỗi.

Hãy coi việc cập nhật và cấu hình là một phần của mô hình tin cậy. Pin hoặc rà soát phiên bản server, xác minh nguồn và tính toàn vẹn của các artifact triển khai, quản lý secret bên ngoài source code và giới hạn môi trường được các tiến trình cục bộ kế thừa. Kiểm thử hành vi của tool với input sai định dạng, đích đến không được cấp quyền, kết quả quá lớn, prompt injection trong resource và lỗi downstream. Rà soát bảo mật nên kiểm tra các quyền thực tế của runtime, không chỉ tên và mô tả được MCP server công khai.

Những lỗi thường gặp và cách rà soát thực tế

Một lỗi thường gặp là tin vào phần mô tả công cụ như thể đó là một hợp đồng bảo mật. Phần mô tả hữu ích cho việc khám phá, nhưng một server bị xâm phạm hoặc được bảo trì kém có thể mô tả một thao tác nguy hiểm bằng ngôn ngữ vô hại. Hãy rà soát phần triển khai, quyền của danh tính, các đích mạng, luồng dữ liệu và cơ chế phê duyệt. Cần thận trọng tương tự với các template prompt và metadata tài nguyên: chúng có thể định hình hành vi của model nhưng không thiết lập quyền hạn.

Một lỗi khác là xem cấu hình phát triển cục bộ như một mô hình tin cậy dành cho production. Nhà phát triển thường chạy server với quyền truy cập rộng vào hệ thống tệp, thông tin xác thực cá nhân, quyền truy cập mạng outbound không hạn chế và log chi tiết. Production nên thay thế các mặc định đó bằng một danh tính runtime chuyên dụng, thư mục làm việc bị giới hạn, tập biến môi trường được tối giản, các quy tắc egress rõ ràng và cơ chế xử lý dữ liệu có kiểm soát. Hãy kiểm thử việc triển khai bằng đúng các quyền mà production thực sự sẽ cấp.

Trong quá trình rà soát, hãy lần theo một thao tác đọc điển hình và một thao tác ghi điển hình, từ yêu cầu của người dùng đến tác động ở hệ thống downstream. Ở mỗi bước, hãy xác định danh tính, việc xác thực đầu vào, phân loại dữ liệu, yêu cầu phê duyệt, thời gian chờ, sự kiện audit và cách xử lý lỗi. Nếu không thể giải thích chính xác bất kỳ bước nào, ranh giới đó vẫn chưa được định nghĩa ở cấp độ vận hành. Phương pháp này tạo ra các công việc khắc phục cụ thể thay vì dựa vào một nhận định chung rằng MCP server là đáng tin cậy.

Tóm tắt

MCP phân tách trải nghiệm phía host khỏi các capability do server cung cấp, nhưng không xóa bỏ các ranh giới bảo mật giữa chúng. Host quản lý tương tác với người dùng và các session của client; server xác thực request và triển khai tool, resource cũng như prompt; các hệ thống downstream vẫn là những authority độc lập với quyền hạn và cơ chế xử lý lỗi riêng.

Trong production, hãy tập trung vào danh tính rõ ràng, nguyên tắc đặc quyền tối thiểu, việc xác thực ở phía server, yêu cầu người dùng phê duyệt các hành động có hậu quả, xử lý cẩn trọng nội dung được truy xuất, thực thi có giới hạn và audit trail hữu ích. Capability negotiation hỗ trợ khả năng tương tác, còn authorization quyết định điều gì thực sự được phép xảy ra. Mục tiêu thực tế không phải là tin tưởng hoặc không tin tưởng MCP như một khối thống nhất, mà là ghi lại mọi ranh giới và áp dụng các biện pháp kiểm soát phù hợp với dữ liệu và quyền hạn đi qua ranh giới đó.