Tiêu chuẩn MCP 2026-07-28: Lõi phi trạng thái, thắt chặt phân quyền và cơ chế ủy quyền quản trị doanh nghiệp

Tiêu chuẩn MCP 2026-07-28 đánh dấu một bước chuyển dịch kiến trúc quan trọng: phần lõi chuyển từ cơ chế bắt tay chào và duy trì phiên làm việc sang mô hình yêu cầu phản hồi phi trạng thái (stateless). Các thông điệp khởi tạo initialize và notifications/initialized bị loại bỏ hoàn toàn trong phiên bản giao thức hiện đại; mỗi yêu cầu đều tự mang thông tin phiên bản và năng lực máy khách trong trường _meta, trong khi thông tin clientInfo chỉ phục vụ hiển thị nhận diện hoặc gỡ lỗi, và kết quả từ máy chủ sẽ trả về serverInfo. Mỗi yêu cầu có thể gửi tới bất kỳ phiên bản máy chủ nào phía sau bộ cân bằng tải thông thường. Tuy nhiên, việc phi trạng thái ở tầng giao thức không đồng nghĩa với việc doanh nghiệp không cần lưu trạng thái: các tác vụ kéo dài, yêu cầu phê duyệt hoặc quy trình nghiệp vụ nhiều vòng tương tác sẽ sử dụng một định danh trạng thái tường minh do máy chủ phát hành, đi kèm đầy đủ phạm vi phân quyền, thời hạn hết hiệu lực và nhật ký kiểm tra chi tiết.

Giao thức truyền dẫn Streamable HTTP sử dụng phương thức POST cho từng thông điệp cùng định dạng dữ liệu JSON hoặc luồng sự kiện máy chủ (SSE) gắn theo từng yêu cầu. Các tiêu đề Mcp-Method và Mcp-Name (khi phù hợp) giúp cổng trung gian nhận biết phương thức và thực thể để phân luồng định tuyến, giới hạn tốc độ gọi và áp dụng chính sách mà không cần bóc tách toàn bộ phần thân yêu cầu. Hệ thống triển khai bắt buộc phải đối soát xem tiêu đề có khớp với nội dung JSON-RPC hay không, tuyệt đối không tin cậy riêng phần tiêu đề. Các phản hồi liệt kê danh mục và đọc dữ liệu có thêm thời gian sống ttlMs và phạm vi lưu trữ cacheScope; thứ tự sắp xếp công cụ có tính tất định giúp tối ưu bộ nhớ đệm câu lệnh của máy khách. Bộ nhớ đệm phải luôn tạo khóa theo phiên bản, quyền xác thực, năng lực và ngữ cảnh, đồng thời không bao giờ kéo dài quyền hạn đã hết hạn. Những thay đổi này giúp nâng cao đáng kể năng lực mở rộng quy mô, nhưng đòi hỏi sự chuyển dịch từ việc dựa dẫm vào phiên kết nối cố định sang kỷ luật kiểm soát hợp đồng giao tiếp, chống xử lý trùng (idempotency) và quản lý trạng thái phân tán.

Sự tương tác giữa máy chủ và máy khách được thiết kế lại hoàn toàn xoay quanh mô hình yêu cầu nhiều vòng trao đổi (Multi Round-Trip Requests - MRTR). Công cụ có thể phản hồi trạng thái cần thêm dữ liệu đầu vào; máy khách sẽ thu thập thông tin người dùng bổ sung, yêu cầu phê duyệt hoặc lấy mẫu dữ liệu rồi tiếp tục gửi yêu cầu mới lên máy chủ. Không còn cần duy trì luồng truyền dữ liệu hai chiều mở liên tục, nhưng định danh trạng thái lúc này trở thành một đối tượng bảo mật trọng yếu: phải mã hóa không thể đoán, gắn chặt với chủ thể, không gian riêng của khách hàng (tenant), công cụ tương ứng, có thời hạn hiệu lực và được kiểm soát thứ tự nhằm chống xử lý trùng lặp. Máy khách phải hiển thị rõ ràng nguồn gốc và hậu quả hành động cho người dùng; biểu mẫu nhập liệu tuyệt đối không được yêu cầu nhập khóa bí mật. Các tình huống hủy lệnh, bỏ dở giữa chừng và dọn dẹp tài nguyên phải được kiểm thử kỹ lưỡng. Cơ chế MRTR chỉ là một khuôn mẫu giao tiếp kỹ thuật, tuyệt đối không trao quyền tự quyết không giới hạn cho tác nhân AI.

Cơ chế phân quyền vẫn dựa trên nền tảng OAuth 2.1 cho giao thức HTTP nhưng được thắt chặt bảo mật rõ rệt hơn. Việc công bố siêu dữ liệu tài nguyên được bảo vệ (Protected Resource Metadata) là yêu cầu bắt buộc để máy khách tìm ra đúng máy chủ cấp quyền; máy khách cần hỗ trợ siêu dữ liệu máy chủ cấp quyền và cơ chế khám phá OIDC. Định danh máy khách qua siêu dữ liệu (CIMD) được ưu tiên hàng đầu, cơ chế đăng ký trước được coi là hợp lệ, trong khi đăng ký máy khách động (DCR) đã bị xem là lỗi thời dù vẫn giữ tương thích ngược. Kiểm tra máy chủ phát hành theo tiêu chuẩn RFC 9207 giúp ngăn ngừa rủi ro trộn lẫn mã cấp quyền; cơ chế chỉ định tài nguyên và gắn kết đối tượng thụ hưởng đảm bảo mã token chỉ có hiệu lực với đúng tài nguyên MCP được chỉ định, nghiêm cấm việc chuyển tiếp mã token tùy tiện. Phạm vi quyền truy cập luôn bắt đầu ở mức tối thiểu và chỉ nâng cấp từng bước khi có yêu cầu thử thách xác thực. Kho lưu trữ thông tin xác thực phải phân tách độc lập theo tổ hợp máy chủ phát hành, máy khách, tài nguyên, chủ thể và phạm vi quyền hạn.

Cơ chế ủy quyền doanh nghiệp (Enterprise Managed Authorization - EMA) là phần mở rộng định danh `io.modelcontextprotocol/enterprise-managed-authorization`, tích hợp hệ thống định danh IdP và chính sách doanh nghiệp vào luồng hoạt động nhằm tập trung hóa việc quản lý truy cập, tự động hóa quy trình tiếp nhận hoặc chấm dứt quyền nhân sự và giảm thiểu các yêu cầu xin đồng ý lặp đi lặp lại. Cơ chế này chỉ hoạt động khi toàn bộ ngăn xếp công nghệ hỗ trợ và đàm phán thành công phần mở rộng, đồng thời mối quan hệ tin cậy đã được cấu hình chặt chẽ. Cơ chế EMA không biến hệ thống đăng nhập một lần SSO thành giải pháp phân quyền toàn diện, không thay thế việc kiểm tra đối tượng thụ hưởng, phạm vi quyền, chính sách riêng cho từng công cụ, sự phê duyệt của con người hay nhật ký kiểm tra. Tình trạng hỗ trợ thực tế trên từng bộ SDK và máy khách cụ thể phải được kiểm tra cẩn thận; việc bản đặc tả phần mở rộng đã ổn định không đồng nghĩa mọi bản triển khai bên ngoài đều đã đạt chuẩn tuân thủ.

Quá trình chuyển đổi hệ thống không nên tiến hành ồ ạt cùng một lúc. Doanh nghiệp cần lập danh mục kiểm kê toàn bộ máy khách, máy chủ, bộ SDK, phương thức truyền dẫn, cơ chế xác thực và các phần mở rộng; xây dựng ma trận phân loại rõ ràng giữa các thành phần hiện đại, kế thừa hệ thống cũ và hệ thống kép hỗ trợ cả hai; cố định phiên bản chặt chẽ; bổ sung kiểm thử tại cổng trung gian, cấu trúc dữ liệu và tiêu đề yêu cầu; vận hành các điểm cuối kép hoặc tách riêng điểm cuối đi kèm chính sách bảo mật; điều hướng lưu lượng thử nghiệm diện hẹp (canary); đo lường tỷ lệ sai lệch, hạ cấp giao thức, lỗi phân quyền, bộ nhớ đệm và các vòng trao đổi MRTR; luôn duy trì phương án khôi phục bản cũ. Khi gặp phiên bản không được hỗ trợ, hệ thống phải trả về mã lỗi kèm danh sách các phiên bản hỗ trợ thay vì tự ý phán đoán. Khoảng thời gian thông báo ngừng hỗ trợ giúp doanh nghiệp lập kế hoạch chủ động, song các sự cố an ninh và thời hạn hỗ trợ từ nhà cung cấp mới là yếu tố quyết định mốc thời gian thực tế. Cần lưu ý rằng ngày 28/07/2026 là mốc phát hành tiêu chuẩn kỹ thuật, chứ không phải thời điểm tắt bỏ toàn bộ hệ sinh thái cũ ngay lập tức.

Cổng kiểm soát bằng chứng bao gồm: bảng đối chiếu cấu trúc dữ liệu chính thức và nhật ký thay đổi, tệp khóa phiên bản và danh mục thành phần phần mềm (SBOM), cấu hình triển khai, kết quả kiểm thử hợp đồng giao tiếp và tuân thủ chuẩn, kiểm thử phủ định về phân quyền, dấu vết thực thi đã được lọc bỏ dữ liệu nhạy cảm, kiểm thử tải và khả năng chịu lỗi, chỉ số đo lường từ đợt triển khai diện hẹp, diễn tập ứng phó sự cố cùng quy trình quay về bản cũ, và biên bản phê duyệt nghiệm thu chính thức. Việc đạt chuẩn tuân thủ giao thức lõi không thể thay thế việc phân quyền ở tầng ứng dụng, mức độ an toàn của công cụ, bảo vệ quyền riêng tư hay tính chính xác về mặt nghiệp vụ. Một công cụ dù truyền nhận đúng định dạng trên đường truyền vẫn có thể vượt quá quyền hạn cho phép hoặc gây ra tác dụng phụ trùng lặp. Mô hình quản trị cần tách bạch rõ ràng giữa ba khía cạnh: tuân thủ giao thức kỹ thuật, kiểm soát an ninh bảo mật và nghiệm thu theo từng tình huống sử dụng thực tế.

Bài viết này phân định rạch ròi giữa các yêu cầu quy chuẩn bắt buộc trong tài liệu tiêu chuẩn với những kiến trúc khuyến nghị thực tế từ ATECH. Các thuật ngữ quy chuẩn như BẮT BUỘC (MUST) hoặc NÊN (SHOULD) được áp dụng đúng ngữ cảnh văn bản gốc; trong khi các mô hình cổng trung gian, lộ trình triển khai, khả năng quan sát hệ thống và nhịp độ vận hành là các đề xuất thực tiễn cần được tùy chỉnh theo từng doanh nghiệp. Chúng tôi không truyền thông mô hình phi trạng thái như một giải pháp bảo mật tuyệt đối không tin cậy (Zero Trust), không coi cơ chế EMA là đã hoàn thành toàn bộ công tác quản trị, và không xem việc tuân thủ MCP như một chứng nhận sản phẩm thương mại.

Đội ngũ kỹ thuật thường dễ hiểu lầm khái niệm phi trạng thái thành việc xóa bỏ mọi trạng thái trong hệ thống. Hệ quả là họ nhồi nhét toàn bộ thông tin tác vụ, phê duyệt và ngữ cảnh vào phần thân gói tin hoặc chuỗi truy vấn, làm rò rỉ dữ liệu nhạy cảm và gia tăng nguy cơ bị tấn công phát lại; hoặc ngược lại, họ âm thầm lưu bộ nhớ ẩn riêng trên từng phiên bản máy chủ, khiến cơ chế cân bằng tải luân phiên (round-robin) phát sinh lỗi chập chờn ngẫu nhiên. Doanh nghiệp cần phân định rạch ròi ba cấp độ: trạng thái giao thức, trạng thái ứng dụng và trạng thái hệ thống bên ngoài. Chỉ những trạng thái ứng dụng thật sự cần thiết mới được cấp định danh tường minh và lưu trữ trong kho dữ liệu có quyền sở hữu, cơ chế xác thực và vòng đời rõ ràng.

Phiên bản của bộ công cụ SDK và phiên bản giao thức đường truyền thường bị đánh đồng với nhau. Việc nâng cấp gói phần mềm có thể thay đổi giao diện lập trình nhưng chưa chắc đã kích hoạt giao thức mới, hoặc máy chủ đã hỗ trợ cả hai thời kỳ nhưng máy khách vẫn chỉ gửi gói tin theo chuẩn cũ. Nếu bảng điều khiển chỉ ghi nhận phiên bản SDK 2.x chung chung, đội ngũ quản trị sẽ không thể biết yêu cầu nào đang chạy theo phiên bản giao thức nào. Danh mục kiểm kê và dấu vết kiểm tra bắt buộc phải ghi rõ gói phần mềm, phiên bản giao thức cấu hình hoặc đã đàm phán, cùng điểm cuối tiếp nhận. Việc kiểm thử tính tương thích phải được thực hiện theo từng cặp máy khách và máy chủ cụ thể, chứ không thể suy đoán đơn thuần từ tên phiên bản.

Nếu cổng trung gian chỉ tin vào tiêu đề Mcp-Name để cấp phép gọi công cụ nhưng hệ thống máy chủ phía sau lại thực thi một lệnh khác nằm trong phần thân yêu cầu, lỗ hổng vượt quyền trái phép sẽ xuất hiện. Các máy chủ ủy nhiệm trung gian có thể loại bỏ, nhân bản hoặc chuẩn hóa tiêu đề theo những cách khác nhau. Động cơ thực thi chính sách bắt buộc phải đối soát tính nhất quán giữa tiêu đề và phần thân ngay tại ranh giới tin cậy, lập tức từ chối mọi yêu cầu có sự sai lệch, ký số và chuyển tiếp ngữ cảnh một cách an toàn, đồng thời triển khai phòng thủ chiều sâu tại máy chủ xử lý. Tuyệt đối không sử dụng ký tự đại diện mơ hồ cho tên công cụ. Kiểm thử phủ định đối với hành vi chèn ép tiêu đề trái phép là một cổng kiểm soát bắt buộc trước khi phát hành.

Việc lưu danh mục công cụ riêng tư vào tầng bộ nhớ đệm dùng chung rất dễ làm rò rỉ công cụ và dữ liệu giữa các khách hàng; thiết lập thời gian tồn tại (TTL) quá dài sẽ khiến các công cụ đã bị thu hồi quyền vẫn tiếp tục hiển thị; thứ tự sắp xếp công cụ thiếu tính tất định còn làm hỏng bộ nhớ đệm câu lệnh của AI. Phạm vi lưu đệm (CacheScope), quy tắc tạo khóa và cơ chế vô hiệu hóa bộ nhớ đệm bắt buộc phải được thiết kế chuẩn xác. Quyền truy cập phải luôn được kiểm tra tại thời điểm gọi lệnh thực tế. Danh mục phản hồi tuyệt đối không được chứa những công cụ mà người dùng không có quyền biết. Phía máy khách cần xử lý dữ liệu đệm cũ bằng cơ chế phòng vệ an toàn và chủ động làm mới, không bao giờ được mặc định rằng dữ liệu còn trong bộ nhớ đệm nghĩa là vẫn có quyền thực thi.

Trường thông tin clientInfo gửi kèm mỗi yêu cầu rất dễ bị lạm dụng làm định danh bảo mật, dù tài liệu tiêu chuẩn đã nêu rõ đây chỉ là dữ liệu do máy khách tự khai báo. Kẻ tấn công có thể giả mạo tên hoặc phiên bản máy khách để nhận thêm quyền hạn tính năng hoặc vượt qua danh sách cho phép. Định danh bảo mật thực sự bắt buộc phải bắt nguồn từ mã token đã qua xác thực, chứng chỉ mTLS hoặc định danh tải công việc đi kèm chính sách phân quyền nghiêm ngặt. Trường clientInfo chỉ đóng vai trò gợi ý phục vụ khả năng quan sát hệ thống hoặc gợi ý tính tương thích; mọi thay đổi hành vi xử lý theo từng máy khách đều đòi hỏi siêu dữ liệu có chữ ký số, mối quan hệ tin cậy xác lập trước hoặc cấu hình tường minh trên máy chủ.

Cơ chế nạp định danh máy khách qua siêu dữ liệu (CIMD) mở ra bề mặt tấn công giả mạo yêu cầu từ phía máy chủ (SSRF) và rủi ro chuỗi cung ứng. Định danh máy khách dưới dạng đường dẫn URL có thể bị trỏ về các dịch vụ siêu dữ liệu nội bộ, bị chuyển hướng độc hại hoặc trỏ tới tài liệu đã bị chiếm đoạt quyền kiểm soát. Máy chủ cấp quyền bắt buộc phải giới hạn nghiêm ngặt giao thức HTTPS, tên miền đáng tin cậy, kiểm tra phân giải tên miền DNS, địa chỉ IP, chặn chuyển hướng, giới hạn kích thước và nội dung tài liệu, quy định cơ chế lưu đệm và xác thực lại, cùng quyền sở hữu tài liệu. Mọi thay đổi trong tài liệu định danh phải qua quy trình rà soát chặt chẽ. Cơ chế đăng ký trước là lựa chọn phù hợp nhất cho môi trường áp dụng danh sách cho phép nghiêm ngặt; tuyệt đối không mở tính năng đăng ký máy khách động công khai một cách tùy tiện chỉ nhằm mục đích tương thích.

Việc kiểm tra máy chủ phát hành và tài nguyên mục tiêu thường bị nới lỏng khi quá trình chuyển đổi hệ thống gặp lỗi: ví dụ như chấp nhận mọi máy chủ phát hành trên cùng máy chủ lưu trữ hoặc bỏ qua kiểm tra đối tượng thụ hưởng. Đây chính là các biện pháp kiểm soát then chốt nhằm chống lại tấn công trộn lẫn mã và chuyển tiếp mã token trái phép. Trong giai đoạn chuyển đổi, việc hỗ trợ máy chủ phát hành phải có bảng ánh xạ tường minh, thiết lập lòng tin kép có giới hạn thời gian, yêu cầu xác thực lại và giám sát liên tục. Mã token dành cho các giao diện lập trình nội bộ phía sau tuyệt đối không được chuyển tiếp tùy tiện qua giao thức MCP; việc trao đổi mã token hoặc sử dụng thông tin xác thực dịch vụ phải nhắm đúng đối tượng thụ hưởng. Hệ thống cần phân định rõ ràng giữa lỗi chưa xác thực 401 với lỗi từ chối do thiếu phạm vi quyền 403.

Cơ chế nâng cấp phạm vi quyền từng bước có thể dẫn đến tình trạng mệt mỏi vì phải liên tục phê duyệt đồng ý hoặc rủi ro phình rộng quyền hạn. Công cụ liên tục đưa ra thử thách cấp quyền do cấu trúc phân loại quyền kém khoa học; máy khách tự động gom góp các phạm vi quyền rồi giữ chúng trong thời gian dài. Quyền hạn cần được cấp chính xác theo từng mục đích và thao tác cụ thể, phần quyền chênh lệch phát sinh phải được hiển thị rõ ràng, giới hạn số lần thử lại và phải tôn trọng quyết định từ chối của người dùng. Việc làm mới mã token không được phép mở rộng thêm phạm vi quyền. Doanh nghiệp cần ban hành quy định về giới hạn quyền tối đa cho mỗi phiên làm việc, quy trình phê duyệt nghiêm ngặt đối với các quyền hạn có rủi ro cao, và theo dõi số liệu đối soát giữa quyền đã cấp với quyền thực tế được sử dụng.

Cơ chế ủy quyền doanh nghiệp EMA rất dễ bị tiếp thị sai lệch như một giải pháp chỉ cần bật đăng nhập một lần SSO là bảo mật hoàn tất. Hệ thống định danh tập trung chỉ giải quyết được một phần của bài toán tin cậy; máy chủ tài nguyên vẫn bắt buộc phải tự kiểm tra đối tượng thụ hưởng, phạm vi quyền, chủ thể yêu cầu, chính sách riêng của từng công cụ và không gian riêng của từng khách hàng; các thao tác có độ rủi ro cao vẫn cần con người phê duyệt. Sự cố gián đoạn tầng chính sách, sai sót cấu hình hoặc tài khoản quản trị bị xâm nhập sẽ tạo ra phạm vi ảnh hưởng vô cùng lớn. Các yêu cầu về tính sẵn sàng cao, quy trình phê duyệt thay đổi, phân tách nhiệm vụ, quy trình khẩn cấp và nhật ký kiểm tra là bắt buộc. Ngoài ra, mức độ hỗ trợ thực tế trên ma trận các bộ SDK hiện vẫn chưa thực sự đồng đều.

Mô hình yêu cầu nhiều vòng trao đổi MRTR rất dễ gây ra các tác dụng phụ trùng lặp nếu yêu cầu được thử lại sau khi hết thời gian chờ và chuỗi định danh trạng thái không có cơ chế chống xử lý trùng. Khi đó, một quyết định phê duyệt có thể bị sử dụng lại hai lần hoặc thông tin nhập liệu bị gắn sai cho người dùng khác. Kho lưu trữ bắt buộc phải liên kết chặt chẽ định danh trạng thái, vòng trao đổi dự kiến, bản băm tóm tắt thao tác, chủ thể yêu cầu và thời hạn hết hiệu lực; áp dụng cơ chế giao dịch hoặc so sánh và ghi dữ liệu an toàn; đồng thời lưu đệm kết quả cuối cùng. Giao diện máy khách phải hiển thị trạng thái đang xử lý hoặc đã hoàn tất, tuyệt đối không tự ý gửi lại các yêu cầu không có tính chống trùng một cách mù quáng.

Giai đoạn duy trì song song hai thời kỳ có thể kéo dài vô tận nếu doanh nghiệp không đặt ra tiêu chí kết thúc rõ ràng. Luồng xử lý cũ ít được kiểm thử sẽ nhanh chóng trở thành lỗ hổng bảo mật tiềm ẩn trong bóng tối, trong khi các tính năng hiện đại bị kìm hãm không thể triển khai. Kế hoạch chuyển đổi hệ thống bắt buộc phải có người phụ trách, lộ trình điều tiết lưu lượng, danh sách máy khách cụ thể, hạn mức lỗi cho phép, thời điểm đóng băng thay đổi, thông báo ngừng hỗ trợ chính thức, quy trình xử lý ngoại lệ bảo mật và bài kiểm thử loại bỏ hoàn toàn hệ thống cũ. Các máy khách chưa xác định danh tính cần được đưa vào diện theo dõi chứ không thể duy trì cơ chế cũ mãi mãi. Bản lưu trữ phục vụ quay về bản trước phải được phân biệt rõ ràng với một phương án dự phòng vĩnh viễn.

Việc vượt qua bài kiểm thử tuân thủ chuẩn rất dễ tạo ra sự tự tin ảo. Kết quả này chỉ xác nhận hệ thống xử lý đúng các kịch bản tầng giao thức, chứ hoàn toàn không kiểm tra xem công cụ có bị lỗi chèn mã độc vào cơ sở dữ liệu hay không, quy trình phê duyệt có chuẩn xác không, dữ liệu có được phép truy cập không hay kết quả nghiệp vụ có chính xác không. Cổng kiểm soát phát hành cần bổ sung mô hình hóa mối đe dọa, kiểm thử tầng ứng dụng, diễn tập tấn công thử nghiệm, bảo vệ quyền riêng tư, kiểm thử tải và khả năng chịu lỗi, cùng nghiệm thu người dùng thực tế. Các lỗi dự kiến chấp nhận tạm thời phải có đánh giá rủi ro và thời hạn hết hiệu lực cụ thể. Đợt thử nghiệm diện hẹp trên môi trường vận hành chính thức cần kiểm tra trực tiếp trên các cổng tiếp nhận, hệ thống định danh IdP và tầng bộ nhớ đệm thực tế.

Bốn ngộ nhận nguy hiểm

• ⦿Mô hình phi trạng thái không đồng nghĩa với việc tầng ứng dụng không cần quản lý trạng thái.
• ⦿Thông tin clientInfo chỉ mang tính tự khai báo, tuyệt đối không phải là định danh bảo mật.
• ⦿Cơ chế EMA không thay thế việc phân quyền riêng cho từng công cụ và quy trình con người phê duyệt.
• ⦿Vượt qua kiểm thử tuân thủ giao thức không chứng minh công cụ đã an toàn hay chính xác về nghiệp vụ.

1. Lập danh mục phát hành bắt đầu từ việc đối soát cấu trúc dữ liệu chính thức và nhật ký thay đổi của hệ thống, chứ không thể chỉ dựa vào các bản trình bày trên giấy tờ. Đội ngũ kỹ thuật cần ghi nhận chi tiết các phiên bản giao thức đang vận hành, tên gói thư viện SDK và số hiệu phiên bản, phương thức truyền tải, từng cặp máy khách và máy chủ kết nối, chế độ xác thực phân quyền, các phần mở rộng, hệ thống cổng trung gian, sơ đồ triển khai hạ tầng và người phụ trách nghiệp vụ tương ứng. Tiêu chuẩn 2026-07-28 là một bản cập nhật giao thức phá vỡ tính tương thích ngược, song ngày phát hành chính thức không tự động khai tử các hệ thống cũ. Mọi điểm tích hợp cần được phân loại rõ ràng thành ba nhóm: hiện đại, kế thừa hệ thống cũ hoặc giải pháp kép hỗ trợ cả hai thời kỳ; ma trận tương thích phải nêu rõ bên nào gửi yêu cầu cho bên nào, phiên bản gói tin trên đường truyền và phương án dự phòng khi có sự cố. Doanh nghiệp cần cố định chính xác các gói phụ thuộc trong môi trường kiểm thử; tuyệt đối không đánh đồng ghi chú phát hành của thư viện phần mềm với tài liệu tiêu chuẩn quy chuẩn. Việc một máy chủ nâng cấp thư viện nhưng chưa kích hoạt phiên bản giao thức đường truyền mới thì chưa thể coi là đã chuyển đổi thành công. Bằng chứng kiểm soát bắt buộc bao gồm tệp khóa phiên bản và danh mục thành phần phần mềm (SBOM), tệp cấu hình, siêu dữ liệu đã lọc bỏ thông tin nhạy cảm, kết quả kiểm thử tuân thủ và bộ tệp tin sẵn sàng phục vụ việc quay về bản trước.

2. Lõi phi trạng thái loại bỏ hoàn toàn bước bắt tay khởi tạo và các thông điệp thông báo khởi tạo, đồng thời xóa bỏ việc duy trì phiên làm việc ở tầng giao thức. Mỗi yêu cầu độc lập gửi đi đều phải mang trường định danh phiên bản io.modelcontextprotocol/protocolVersion cùng thông tin năng lực của máy khách nằm trong đối tượng _meta; thông tin nhận diện máy khách clientInfo được khuyến nghị đưa vào để ghi nhật ký và phục vụ gỡ lỗi, song đây chỉ là dữ liệu tự khai báo nên tuyệt đối không được dùng làm định danh bảo mật. Máy chủ sẽ phản hồi thông tin máy chủ serverInfo trong phần siêu dữ liệu kết quả theo đúng quy chuẩn. Phía máy chủ không được tự suy đoán năng lực của máy khách từ các yêu cầu trước đó. Sự thay đổi này cho phép từng yêu cầu có thể gửi độc lập tới bất kỳ phiên bản máy chủ nào phía sau bộ cân bằng tải, nhưng ở tầng ứng dụng, doanh nghiệp vẫn có thể cần lưu giữ trạng thái nghiệp vụ thông qua một định danh tường minh. Tuyệt đối không chuyển phiên làm việc cũ vào cookie hay bộ nhớ ẩn trên máy chủ rồi ngộ nhận rằng hệ thống đã đạt chuẩn phi trạng thái. Định danh trạng thái phải có phạm vi áp dụng, liên kết xác thực, thời hạn hiệu lực, người sở hữu và quy trình dọn dẹp tài nguyên; phần thân gói tin không được chứa các khóa bí mật hay dữ liệu định danh cá nhân dư thừa. Cơ chế gửi lại yêu cầu đòi hỏi tính chống xử lý trùng lặp theo từng thao tác, chứ không được dựa dẫm vào cơ chế gán phiên kết nối cố định.

3. Xử lý phiên bản là một hợp đồng giao tiếp độc lập trên từng yêu cầu. Phía máy khách gửi phiên bản giao thức bên trong trường _meta và tiêu đề HTTP phù hợp với phương thức truyền dẫn; nếu máy chủ không hỗ trợ, hệ thống bắt buộc phải trả về mã lỗi UnsupportedProtocolVersionError kèm danh sách các phiên bản được hỗ trợ để hai bên cùng đàm phán phiên bản chung hoặc báo lỗi dừng lại. Máy chủ tuyệt đối không được âm thầm tự diễn giải gói tin theo phiên bản gần giống nhất, bởi vì cấu trúc dữ liệu và ngữ nghĩa xử lý có thể hoàn toàn khác nhau. Điểm cuối tiếp nhận của hệ thống kép cần thực hiện phân luồng giao thức trước khi bước vào khâu xác thực tính hợp lệ; nhật ký hệ thống phải ghi rõ phiên bản được yêu cầu và phiên bản thực tế được chấp nhận. Các bài kiểm thử phủ định cần sử dụng phiên bản không xác định, sai định dạng hoặc cố tình để trống. Việc hạ cấp phiên bản chỉ được phép diễn ra theo đúng quy định và danh sách cho phép, tránh nguy cơ bị kẻ tấn công ép hạ cấp xuống phiên bản giao thức yếu hơn để trục lợi. Chính sách ngừng hỗ trợ với lộ trình tối thiểu mười hai tháng giúp doanh nghiệp chủ động lập kế hoạch, song không thể thay thế cho việc kiểm kê danh mục, năng lực hỗ trợ của bộ SDK và quy trình ứng phó an ninh mạng. Các bản vá lỗ hổng bảo mật khẩn cấp có thể sẽ phải triển khai sớm hơn nhiều so với vòng đời phát hành thông thường.

4. Việc đính kèm năng lực theo từng yêu cầu giúp thông điệp có khả năng tự mô tả đầy đủ, nhưng đồng thời gia tăng trách nhiệm kiểm tra tính hợp lệ trên hệ thống. Máy khách chỉ được phép công bố những năng lực mà nó thực sự hỗ trợ cho yêu cầu cụ thể đó; máy chủ chỉ được kích hoạt các tính năng đã được công bố và phải trả về lỗi có cấu trúc chuẩn khi phát hiện sự không tương thích. Năng lực kỹ thuật không đồng nghĩa với quyền hạn: quy trình phân quyền vẫn bắt buộc phải kiểm tra chủ thể, đối tượng thụ hưởng, phạm vi quyền và chính sách bảo mật tương ứng. Cổng trung gian tuyệt đối không được lưu đệm năng lực theo thông tin clientInfo hoặc địa chỉ IP. Các bài kiểm thử cần cố tình thay đổi năng lực giữa hai yêu cầu liên tiếp để phát hiện lỗi rò rỉ trạng thái giữa các phiên. Các phần mở rộng phải được khai báo tường minh trong phần năng lực và đòi hỏi sự chấp thuận rõ ràng từ cả hai phía; phần mở rộng không xác định phải bị bỏ qua hoặc xử lý theo đúng quy định của tài liệu tiêu chuẩn, chứ không được tự kích hoạt dựa trên tên gọi gần giống. Hệ thống quan sát ghi nhận các mã định danh phần mở rộng đã được đàm phán thành công, nhưng nghiêm cấm ghi lại các tham số nhạy cảm vào nhật ký.

5. Điểm cuối server/discover chỉ là một tiện ích khám phá tùy chọn, hoàn toàn không nhằm mục đích khôi phục lại cơ chế bắt tay chào hay phiên kết nối cố định. Máy khách có thể chủ động truy vấn năng lực và siêu dữ liệu trước để tối ưu hóa trải nghiệm giao diện người dùng, nhưng mỗi yêu cầu gửi đi sau đó vẫn bắt buộc phải tự mang theo toàn bộ ngữ cảnh cần thiết. Kết quả khám phá được lưu vào bộ nhớ đệm dựa trên ngữ nghĩa, độ tươi mới của dữ liệu và ngữ cảnh xác thực tương ứng; tuyệt đối không dùng bộ nhớ đệm công khai cho các danh mục công cụ riêng tư. Khi máy chủ có sự thay đổi về năng lực, hệ thống phải cập nhật phiên bản và vô hiệu hóa bộ nhớ đệm ngay lập tức. Máy khách phải có khả năng xử lý các yêu cầu trực tiếp ngay cả khi dữ liệu khám phá bị cũ hoặc khi điểm cuối khám phá không được gọi tới. Quy trình kiểm tra sức khỏe hệ thống không bao giờ được gọi thử các công cụ có tính chất nguy hiểm. Cổng trung gian cần phân luồng luồng khám phá này với hạn ngạch gọi riêng biệt; thông điệp phản hồi tuyệt đối không được để lộ cấu trúc liên kết mạng nội bộ, các công cụ quản trị cấp cao hay dữ liệu của khách hàng khác. Các bài kiểm thử hợp đồng giao tiếp cần so sánh đối chiếu giữa tài liệu cấu trúc khám phá với hành vi vận hành thực tế của hệ thống.

6. Cơ chế truyền dẫn Streamable HTTP thế hệ mới tiếp nhận từng thông điệp thông qua phương thức POST gửi tới điểm cuối; phản hồi trả về dưới dạng dữ liệu JSON hoặc luồng sự kiện máy chủ (SSE) gắn theo từng yêu cầu riêng biệt. Hệ thống không duy trì luồng truyền dữ liệu hai chiều mở liên tục vô thời hạn chỉ để máy chủ gửi câu hỏi ngược lại cho máy khách. Bộ cân bằng tải có thể phân phối yêu cầu theo cơ chế luân phiên linh hoạt vì phiên làm việc tầng giao thức đã biến mất, song các yếu tố xác thực, giới hạn tần suất gọi, chính sách theo từng khách hàng riêng và định danh trạng thái ứng dụng vẫn phải được đảm bảo tính nhất quán trên toàn bộ các phiên bản máy chủ. Trạng thái chia sẻ phải được lưu trữ trong cơ sở dữ liệu hoặc bộ nhớ đệm tường minh, chứ không được giữ trong bộ nhớ riêng của từng máy chủ. Các thông số thời gian chờ, bộ đệm của máy chủ ủy nhiệm, vòng đời luồng SSE, cơ chế thử lại và quy trình hủy yêu cầu phải được kiểm thử kỹ lưỡng trên cổng tiếp nhận thực tế. Phương thức truyền qua luồng nhập xuất chuẩn (stdio) vẫn là phương thức mặc định cho các tiến trình con do máy khách trực tiếp khởi chạy; song các giả định về mạng xác thực và môi trường phục vụ đa khách hàng của hai mô hình này là hoàn toàn khác nhau. Dù ngữ nghĩa giao thức là đồng nhất, các biện pháp kiểm soát tầng truyền dẫn không thể tự động sao chép nguyên xi từ mô hình này sang mô hình kia.

7. Các tiêu đề Mcp-Method và Mcp-Name giúp cổng trung gian có thể định tuyến, phân quyền, kiểm soát hạn ngạch và quan sát hệ thống mà không cần bóc tách toàn bộ phần thân yêu cầu; tuy nhiên cổng trung gian không bao giờ được tin tưởng tiêu đề một cách độc lập. Cả máy chủ và cổng trung gian đều bắt buộc phải đối soát xem tiêu đề có khớp chính xác với phương thức JSON-RPC và tên thực thể được gọi trong phần thân hay không, lập tức từ chối các yêu cầu có sự sai lệch, bị lặp tiêu đề hoặc sai định dạng, chuẩn hóa dữ liệu theo đúng quy chuẩn và ngăn chặn tấn công lách tiêu đề gói tin (header smuggling). Chính sách bảo mật phải áp dụng cơ chế so khớp chính xác theo tên gọi chuẩn tắc, tuyệt đối không sử dụng tiền tố mơ hồ. Việc để lộ tên các công cụ nhạy cảm trong nhật ký hệ thống cần được phân loại và quản lý chặt chẽ; các tham số dữ liệu không được phép đưa vào tiêu đề trừ khi tuân thủ cấu trúc x-mcp-header đã được phê duyệt. Mạng phân phối nội dung (CDN), tường lửa ứng dụng web và máy chủ ủy nhiệm phải giữ nguyên vẹn các tiêu đề bắt buộc và không bao giờ được lưu đệm sai các yêu cầu POST. Bộ kiểm thử tuân thủ bao gồm các tình huống kiểm tra tên công cụ không khớp, thiếu tiêu đề bắt buộc, độ dài và ký tự Unicode đặc biệt, hành vi truyền qua từng chặng mạng và nguy cơ tấn công phát lại.

8. Thứ tự danh sách có tính tất định cùng các thông số thời gian sống ttlMs và phạm vi lưu trữ cacheScope trong đối tượng CacheableResult phục vụ cho việc lưu đệm danh mục công cụ và duy trì sự ổn định của bộ nhớ đệm câu lệnh prompt. Máy chủ cần thiết lập quy tắc sắp xếp ổn định và không để cơ sở dữ liệu trả về thứ tự ngẫu nhiên. Thời gian sống (TTL) chỉ là một gợi ý về độ tươi mới của dữ liệu, hoàn toàn không phải lời đảm bảo rằng quyền truy cập vẫn còn hiệu lực; máy khách bắt buộc phải xác thực lại khi mã token, định danh khách hàng, chính sách hoặc ngữ cảnh có sự thay đổi. Các giá trị phạm vi bộ nhớ đệm công khai (public) hoặc riêng tư (private) phải được tôn trọng xuyên suốt qua các máy chủ trung gian; danh mục công cụ gắn theo từng người dùng hoặc khách hàng riêng luôn phải đặt ở chế độ riêng tư. Khóa bộ nhớ đệm bao gồm máy chủ, phiên bản giao thức, ngữ cảnh xác thực, năng lực công bố, phần mở rộng, phiên bản và các tiêu đề liên quan. Việc thu hồi quyền hoặc vô hiệu hóa công cụ phải đi kèm chiến lược xóa bộ nhớ đệm chủ động hoặc cơ chế thông báo ngoài băng; thiết lập TTL dài không bao giờ được phép kéo dài thời gian sống của các quyền hạn đã bị hủy. Phía máy khách cần xử lý tốt các tình huống dữ liệu cũ, không tìm thấy trong bộ nhớ đệm và sự thay đổi cấu trúc dữ liệu. Bộ nhớ đệm giúp giảm tải việc gửi yêu cầu thăm dò liên tục, nhưng tuyệt đối không thể thay thế việc kiểm tra quyền truy cập từ nguồn tin cậy duy nhất tại thời điểm thực thi lệnh.

9. Mô hình yêu cầu nhiều vòng trao đổi (MRTR) thay thế các tương tác kéo dài do máy chủ khởi xướng bằng một chuỗi các cặp yêu cầu và phản hồi độc lập, sử dụng định danh trạng thái và kết quả thông báo yêu cầu thêm dữ liệu đầu vào. Công cụ có thể yêu cầu cung cấp thêm thông tin, lấy mẫu dữ liệu hoặc bổ sung ngữ cảnh giữa chừng; máy khách sẽ thu thập dữ liệu đầu vào hoặc ý kiến phê duyệt của người dùng rồi tiếp tục gửi yêu cầu tiếp nối theo đúng giao thức. Định danh trạng thái do máy chủ trực tiếp phát hành, được mã hóa che giấu cấu trúc bên trong, có phạm vi giới hạn, gắn chặt với đối tượng thụ hưởng, có thời hạn hiệu lực và được kiểm soát theo chuỗi thứ tự hoặc chỉ dùng một lần khi phù hợp. Tuyệt đối không nhúng toàn bộ lịch sử cuộc trò chuyện hay các khóa bí mật vào bên trong định danh này. Máy chủ kiểm tra lại chủ thể yêu cầu, khách hàng riêng, công cụ và phiên bản giao thức trong mỗi vòng trao đổi; quyền hạn truy cập hoàn toàn có thể thay đổi giữa các vòng. Cơ chế chống xử lý trùng lặp giúp ngăn chặn việc phát sinh tác dụng phụ hai lần khi máy khách gửi lại yêu cầu. Các tình huống hết thời gian chờ, hủy bỏ hoặc từ bỏ giữa chừng phải có quy trình dọn dẹp tài nguyên và ghi nhật ký kiểm tra đầy đủ. Giao diện người dùng cần nêu rõ thao tác đang chờ đợi điều gì, ai là người yêu cầu và hậu quả thực thi là gì; biểu mẫu nhập liệu tuyệt đối không bao giờ được hỏi mật khẩu hoặc khóa bảo mật API. Cơ chế MRTR chỉ là giải pháp trao đổi thông tin kỹ thuật, chứ không phải giấy phép cho tác nhân AI tự ý chạy vòng lặp vô tận.

10. Các định danh trạng thái tường minh đại diện cho trạng thái của tầng ứng dụng, chứ hoàn toàn không phải là phiên làm việc của tầng giao thức. Chẳng hạn, một tác vụ xuất dữ liệu kéo dài, quy trình phê duyệt hay thao tác phân trang nhiều trang sẽ được cấp một mã tác vụ riêng biệt; kho lưu trữ sẽ duy trì thông tin người phụ trách, khách hàng riêng, thời điểm tạo và hết hiệu lực, trạng thái xử lý, hành động dự kiến tiếp theo cùng nhật ký kiểm tra bất biến. Quy trình phân quyền bắt buộc phải kiểm tra trong mỗi lần truy cập, tuyệt đối không coi việc chỉ nắm giữ định danh trong tay là đủ điều kiện để truy cập vào các tác vụ nhạy cảm. Hệ số ngẫu nhiên cao, tính không thể dự đoán, giới hạn tần suất gọi và cơ chế thu hồi là những yêu cầu an ninh tối cần thiết; các đường dẫn URL và nhật ký hệ thống không được để lộ định danh này. Các tác vụ định kỳ dọn dẹp tài nguyên và thời hạn lưu giữ dữ liệu phải được đo lường cụ thể. Kế hoạch khôi phục sau sự cố phải bảo toàn hoặc vô hiệu hóa các định danh có thông báo rõ ràng cho người dùng. Hợp đồng giao diện lập trình cần tuyên bố rõ ràng tính chống trùng lặp, khả năng tiếp tục xử lý hoặc hủy bỏ. Nếu trạng thái chỉ cần tồn tại trong một lần gọi đơn lẻ thì tuyệt đối không tạo định danh lưu trữ. Kế hoạch chuyển đổi hệ thống cần ánh xạ từng trường dữ liệu trong phiên làm việc cũ sang siêu dữ liệu của yêu cầu mới, chuyển sang trạng thái bền vững tường minh hoặc loại bỏ hoàn toàn; tuyệt đối không sao chép nguyên trạng khối dữ liệu nhị phân cũ sang hệ thống mới.

11. Cơ chế khám phá phân quyền sử dụng siêu dữ liệu tài nguyên được bảo vệ (Protected Resource Metadata) cùng siêu dữ liệu máy chủ cấp quyền hoặc cơ chế khám phá OIDC theo đúng các yêu cầu quy chuẩn. Tài nguyên MCP công bố các máy chủ cấp quyền tương ứng; máy khách hỗ trợ các tuyến đường khám phá, xác thực nghiêm ngặt giao thức bảo mật HTTPS, máy chủ phát hành và tính hợp lệ của siêu dữ liệu, đồng thời không bao giờ tự động chuyển hướng theo các liên kết lạ. Khi có nhiều máy chủ cấp quyền, hệ thống cần thiết lập chính sách lựa chọn rõ ràng; bộ nhớ đệm siêu dữ liệu có thời gian sống TTL và được tạo khóa chính xác theo từng máy chủ phát hành. Cần triển khai các biện pháp phòng vệ chống tấn công yêu cầu từ phía máy chủ (SSRF), danh sách cho phép, kiểm soát phân giải DNS và lọc địa chỉ IP khi nạp siêu dữ liệu và tài liệu máy khách. Thông báo phản hồi lỗi trong tiêu đề WWW-Authenticate cần hướng dẫn máy khách tìm tới đúng siêu dữ liệu tài nguyên và phạm vi quyền, nhưng không được để lộ các chính sách bảo mật nội bộ dư thừa. Bộ kiểm thử bao gồm các kịch bản không khớp máy chủ phát hành, chuyển hướng độc hại, khóa xác thực hết hạn, thiếu phương thức thử thách mã bảo mật, tuyến đường thay thế và siêu dữ liệu riêng cho từng khách hàng. Tính sẵn sàng của quy trình khám phá phải có cơ chế chịu lỗi và phương án dự phòng đã được phê duyệt, tuyệt đối không gán cứng các điểm cuối bí mật vào mã nguồn.

12. Việc sử dụng tài liệu siêu dữ liệu định danh máy khách (CIMD) được ưu tiên hơn so với đăng ký máy khách động (DCR); trong khi cơ chế đăng ký trước thủ công vẫn luôn là một lựa chọn an toàn. Định danh máy khách sẽ trỏ trực tiếp tới một tài liệu siêu dữ liệu chứa danh sách các đường dẫn chuyển hướng hợp lệ, tên máy khách và các thuộc tính xác thực theo dự thảo quy chuẩn áp dụng. Máy chủ cấp quyền sẽ tải về và kiểm tra tính hợp lệ của tài liệu, áp dụng chính sách tin cậy theo tên miền, đồng thời lưu đệm và xác thực lại một cách an toàn. Nơi lưu trữ tài liệu lúc này trở thành một mắt xích bảo mật trọng yếu: đòi hỏi mã hóa TLS, chứng minh quyền sở hữu, kiểm soát thay đổi nghiêm ngặt, lịch sử sửa đổi bất biến và quy trình ứng phó sự cố sẵn sàng. Tuyệt đối không chấp nhận các đường dẫn URL tùy ý trỏ vào mạng nội bộ. Cơ chế đăng ký máy khách động DCR đã bị coi là lỗi thời dù vẫn giữ tương thích ngược; doanh nghiệp cần áp dụng danh sách cho phép, giới hạn tần suất đăng ký, quy trình phê duyệt và lộ trình khai tử rõ ràng. Loại hình ứng dụng application_type cùng các quy tắc chuyển hướng phải khớp chính xác với bản chất của máy khách. Cơ chế đăng ký phải được ghi nhận chi tiết cho từng điểm tích hợp; các phương án dự phòng tuyệt đối không được âm thầm làm suy yếu các biện pháp kiểm soát an ninh.

13. Việc xác thực máy chủ phát hành theo tiêu chuẩn RFC 9207 là biện pháp cốt lõi để chống lại tấn công trộn lẫn mã cấp quyền. Phản hồi cấp quyền chứa trường thông tin iss bắt buộc phải được so khớp chính xác với máy chủ phát hành dự kiến đã được khám phá hoặc lựa chọn trước đó; định danh máy chủ phát hành trong siêu dữ liệu phải tuân thủ đúng quy tắc chuẩn tắc và kho lưu trữ thông tin xác thực phải tạo khóa theo từng máy chủ phát hành cụ thể. Phía máy khách tuyệt đối không được sử dụng mã token hoặc mã ủy quyền từ một máy chủ phát hành khác chỉ vì điểm cuối dịch vụ trông có vẻ tương tự nhau. Bộ kiểm thử bao gồm các tình huống thiếu trường phát hành, xuất hiện máy chủ không mong muốn, sai định danh, sai lệch chuẩn hóa, máy chủ đa khách hàng, chuyển hướng độc hại và đầu độc bộ nhớ đệm. Nhật ký hệ thống chỉ ghi nhận định danh máy chủ phát hành đã được lọc bỏ thông tin nhạy cảm kèm mã đối soát liên kết, nghiêm cấm ghi lại mã token hoặc mã ủy quyền. Quá trình chuyển đổi thông tin xác thực không được gộp chung đơn thuần theo tên máy chủ lưu trữ. Khi máy chủ xác thực thay đổi định danh phát hành, doanh nghiệp cần tiến hành kế hoạch chuyển đổi bài bản với cơ chế tin cậy song song có thời hạn cụ thể, yêu cầu người dùng xác thực lại và chuẩn bị sẵn phương án quay về bản cũ; tuyệt đối không thêm ký tự đại diện để khắc phục lỗi tạm thời trên môi trường vận hành chính thức.

14. Cơ chế chỉ định tài nguyên và gắn kết đối tượng thụ hưởng token là giải pháp ngăn chặn tình trạng chuyển tiếp mã token trái phép và lỗ hổng người ủy nhiệm bị nhầm lẫn (confused deputy). Máy khách gửi đường dẫn chuẩn tắc của máy chủ MCP trong yêu cầu cấp quyền và yêu cầu nhận token; máy chủ tài nguyên chỉ chấp nhận các mã token được phát hành riêng cho chính nó, đồng thời kiểm tra tính hợp lệ của đối tượng thụ hưởng, chữ ký số, máy chủ phát hành, thời hạn hiệu lực và phạm vi quyền hạn, tuyệt đối không chuyển tiếp mã token đó lên các dịch vụ thượng nguồn. Các giao diện lập trình hạ nguồn phía sau phải sử dụng cơ chế trao đổi mã token, đại diện ủy quyền hoặc thông tin xác thực dịch vụ chuyên dụng theo đúng thiết kế kiến trúc; mã token của người dùng không bao giờ được sử dụng như một mã mang quyền chung chung vô điều kiện. Định dạng đường dẫn chuẩn tắc, dấu gạch chéo cuối dòng, tên máy chủ và đường dẫn thư mục cần được chuẩn hóa thống nhất. Các bài kiểm thử phủ định cần sử dụng mã token phát hành đúng nguồn nhưng sai tài nguyên mục tiêu, mã token cấp cho giao diện lập trình khác, token đã hết hạn hoặc chưa đến thời điểm hiệu lực, và các lỗi về thuật toán hay khóa ký. Cổng trung gian và máy chủ phải đồng nhất toàn diện quy trình kiểm tra; việc lưu đệm kết quả phân quyền tuyệt đối không được vượt quá thời gian sống của token hoặc chính sách thu hồi quyền.

15. Tối thiểu hóa phạm vi quyền bắt đầu từ các chỉ dẫn phạm vi trong tiêu đề WWW-Authenticate và danh sách các phạm vi được hỗ trợ ở mức tối thiểu. Máy khách chỉ yêu cầu phạm vi quyền thực sự cần thiết cho mục đích hiện tại; nếu thao tác tiếp theo đòi hỏi thêm quyền, máy chủ sẽ trả về mã lỗi 403 đi kèm thông báo quyền chưa đủ hoặc yêu cầu thử thách để nâng cấp quyền từng bước. Việc tích lũy quyền hạn được phép duy trì các quyền cần thiết theo đúng đặc tả và chính sách an ninh, nhưng nghiêm cấm việc xin toàn bộ mọi quyền ngay từ đầu. Chính sách bảo mật ở cấp độ công cụ sẽ kết hợp các tiêu đề Mcp-Method và Mcp-Name cùng các tuyên bố định danh và ngữ cảnh yêu cầu, nhưng vẫn luôn phải đối soát với phần thân nội dung. Tên phạm vi quyền cần được đặt cụ thể theo hành động và tài nguyên, tránh đặt chung chung như quyền quản trị hay quyền ghi. Giao diện người dùng cần hiển thị rõ ràng phần quyền chênh lệch cần cấp thêm, lý do yêu cầu, thời hạn hiệu lực và hậu quả thực thi; người dùng hoặc chính sách doanh nghiệp có toàn quyền từ chối. Việc làm mới mã token không được phép tự động mở rộng thêm phạm vi quyền. Bộ kiểm thử bao gồm giới hạn số lần thử lại, vòng lặp thử thách vô tận, cấp quyền một phần, vai trò người dùng bị thu hồi và các yêu cầu nâng cấp quyền đồng thời. Nguyên tắc quyền tối thiểu được đo lường cụ thể thông qua tỷ lệ giữa quyền đã cấp so với quyền thực tế được sử dụng và số lượng các phạm vi quyền bị bỏ quên không dùng tới.

16. Việc ràng buộc thông tin xác thực với máy chủ cấp quyền đòi hỏi phải phân tách độc lập các kho lưu trữ mã token theo từng máy chủ phát hành, máy khách, tài nguyên, chủ thể người dùng, khách hàng riêng và tập hợp phạm vi quyền hạn. Tuyệt đối không được tùy tiện lấy mã làm mới token ra dùng chỉ vì chúng cùng trỏ tới một điểm cuối MCP. Cần áp dụng mã hóa dữ liệu khi lưu trữ, tận dụng kho khóa của hệ điều hành hoặc hệ thống quản lý khóa bí mật chuyên dụng, kiểm soát quyền truy cập, định kỳ luân chuyển khóa, sẵn sàng quy trình thu hồi và lọc bỏ dữ liệu nhạy cảm trong nhật ký. Ứng dụng máy khách công khai bắt buộc phải sử dụng cơ chế bảo mật PKCE và các biện pháp bảo vệ liên kết chuyển hướng; thông tin xác thực của máy khách bảo mật tuyệt đối không được đặt ở phía giao diện người dùng. Xử lý đồng thời khi làm mới token cần có cơ chế khóa và phát hiện tấn công phát lại; khi gặp lỗi invalid_grant, hệ thống phải yêu cầu người dùng xác thực lại chứ không được tự ý dùng thử một mã token khác. Quyền truy cập ngoại tuyến chỉ được yêu cầu khi thực sự được hỗ trợ, có nhu cầu chính đáng và được chính sách doanh nghiệp phê chuẩn. Khi người dùng đăng xuất hoặc chấm dứt hợp đồng lao động, toàn bộ thông tin xác thực phải được thu hồi và xóa sạch. Việc sao lưu và chuyển đổi kho thông tin xác thực phải được giới hạn trong phạm vi nhỏ nhất. Cẩm nang ứng phó sự cố phải giúp xác định nhanh chóng các mã token, máy khách và tài nguyên bị ảnh hưởng cùng bằng chứng cụ thể, nghiêm cấm việc trích xuất hàng loạt các khóa bí mật ra ngoài.

17. Cơ chế ủy quyền doanh nghiệp (Enterprise Managed Authorization - EMA) là một phần mở rộng tùy chọn mang định danh io.modelcontextprotocol/enterprise-managed-authorization, chứ không phải là sự đảm bảo bắt buộc của tầng giao thức lõi hay từ đồng nghĩa với hệ thống đăng nhập một lần SSO. Phần mở rộng này tích hợp hệ thống định danh IdP và các chính sách quản trị của doanh nghiệp vào quy trình phân quyền, giúp bộ phận công nghệ thông tin kiểm soát quyền truy cập một cách nhất quán, tự động hóa việc tiếp nhận hoặc thu hồi quyền của nhân viên và giảm thiểu phiền toái khi từng người dùng phải liên tục bấm nút đồng ý cấp quyền. Toàn bộ ngăn xếp công nghệ gồm máy khách, máy chủ và hệ thống xác thực phải hỗ trợ và đàm phán thành công phần mở rộng này; đồng thời tổ chức cần cấu hình mối quan hệ tin cậy giữa hệ thống định danh doanh nghiệp và các máy chủ cấp quyền tài nguyên. Cơ chế EMA tuyệt đối không xóa bỏ việc kiểm tra đối tượng thụ hưởng tài nguyên, nguyên tắc quyền tối thiểu, chính sách riêng cho từng công cụ, ngữ cảnh người dùng, nhật ký kiểm tra hay quy trình phê duyệt thủ công. Mặt phẳng chính sách trung tâm lúc này trở thành một thành phần phụ thuộc tối quan trọng, đòi hỏi tính sẵn sàng cao, quy trình khẩn cấp dự phòng, rà soát thay đổi nghiêm ngặt và phân tách nhiệm vụ rõ ràng. Định danh nhân sự lao động phải được phân biệt rạch ròi với định danh dịch vụ và định danh tải công việc. Doanh nghiệp cần đánh giá kỹ lưỡng việc triển khai thực tế trên từng bộ SDK và máy khách cùng mức độ tuân thủ chuẩn; việc bản đặc tả của phần mở rộng đã ổn định hoàn toàn không đồng nghĩa với việc mọi bộ SDK bên ngoài đều đã được triển khai trọn vẹn.

18. Khung làm việc phần mở rộng thiết lập cơ chế không gian tên và đàm phán năng lực, song không thể mặc định coi mọi phần mở rộng là an toàn. Doanh nghiệp cần lập danh mục kiểm kê chi tiết mã định danh phần mở rộng, phiên bản, nhà cung cấp, loại dữ liệu và hành động được phép, vòng đời vận hành, đánh giá an ninh, tính tương thích và phương án dự phòng khi phát sinh sự cố. Các phần mở rộng không xác định hoặc không được hỗ trợ tuyệt đối không được âm thầm giả lập hoạt động. Các bài kiểm thử khả năng tương tác của giao thức lõi phải chạy độc lập mà không cần phần mở rộng; các bài kiểm thử phần mở rộng cần được tiến hành riêng biệt và việc thất bại ở phần mở rộng tùy chọn không được phép làm gián đoạn hoạt động của lõi hệ thống. Các phần mở rộng như Tác vụ (Tasks), Ứng dụng (Apps), Kỹ năng (Skills) hay EMA đều sở hữu các mô hình mối đe dọa hoàn toàn khác nhau. Chính sách tại cổng trung gian cần thiết lập danh sách cho phép các mã định danh và giới hạn kích thước siêu dữ liệu; phần mở rộng của nhà cung cấp bên thứ ba bắt buộc phải sử dụng không gian tên dạng tên miền ngược và tuyệt đối không được mạo danh không gian tên dành riêng của tiêu chuẩn MCP. Việc nâng cấp phần mở rộng có thể diễn ra độc lập nhưng phải có ma trận phụ thuộc rõ ràng. Kế hoạch ngừng hỗ trợ hoặc rút lui cần có giải pháp xuất dữ liệu trạng thái đầy đủ. Khi truyền thông ra bên ngoài, doanh nghiệp cần nêu rõ phần mở rộng được hỗ trợ trên dòng máy khách, máy chủ và phiên bản cụ thể nào, chứ không được tuyên bố chung chung rằng MCP hỗ trợ tính năng đó.

19. Ngữ cảnh OpenTelemetry có thể được truyền tải thông qua trường _meta với các quy chuẩn traceparent, tracestate và baggage, tuy nhiên các tiêu đề truy vết này luôn phải được coi là dữ liệu đầu vào không đáng tin cậy. Hệ thống cần kiểm tra tính hợp lệ của định dạng, chủ động khởi tạo một dấu vết mới khi dữ liệu sai định dạng theo đúng chính sách, nghiêm cấm việc đưa dữ liệu định danh cá nhân, mã token, quyết định phân quyền hoặc dữ liệu vượt quá kích thước vào trường hành lý dữ liệu (baggage). Ranh giới tin cậy sẽ quyết định việc giữ lại hay loại bỏ thông tin truy vết; các đối tượng gọi bên ngoài không được phép ép buộc tỷ lệ lấy mẫu hoặc thay đổi không gian riêng của khách hàng. Các thuộc tính của đoạn truy vết (span) bao gồm phiên bản giao thức, phương thức, tên hoặc bản băm chính sách, phiên bản máy chủ, kết quả hoặc mã lỗi, độ trễ, trạng thái bộ nhớ đệm, kết quả phân quyền và định danh trạng thái, nhưng bắt buộc phải lọc bỏ các tham số và kết quả dữ liệu nhạy cảm. Mã tương quan cần kết nối liền mạch từ cổng trung gian, máy chủ xử lý, các hệ thống hạ nguồn cho tới nhật ký kiểm tra. Cơ chế lấy mẫu cần ưu tiên lưu giữ toàn bộ các sự kiện an ninh và sự cố lỗi, áp dụng kỹ thuật lấy mẫu ở đuôi khi cần thiết; thời hạn lưu giữ và quyền truy cập nhật ký phải tuân thủ đúng phân loại dữ liệu. Dấu vết hệ thống không thể thay thế cho nhật ký kiểm tra nghiệp vụ chính thức và không thể coi là bằng chứng xác thực rằng tác dụng phụ đã được cam kết ghi nhận vào cơ sở dữ liệu.

20. Bộ kiểm thử tuân thủ chuẩn dùng để xác minh hành vi gói tin trên đường truyền, nhưng không thể thay thế cho chất lượng và độ an toàn tổng thể của sản phẩm. Ma trận kiểm thử bao gồm máy khách và máy chủ của lõi giao thức, cơ chế phân quyền, phương thức truyền dẫn và các phần mở rộng theo từng phiên bản cụ thể. Kiểm thử hợp đồng giao tiếp đánh giá cấu trúc dữ liệu, tiêu đề, phiên bản, năng lực, bộ nhớ đệm và các vòng trao đổi MRTR; kiểm thử phủ định về phân quyền kiểm tra máy chủ phát hành, tài nguyên, phạm vi quyền, cơ chế đăng ký và mã token; kiểm thử tính tương tác với các phiên bản bộ công cụ SDK cấp 1 (Tier 1); kiểm thử tải và khả năng chịu lỗi đối với cơ chế cân bằng tải phi trạng thái, gửi lại yêu cầu, máy chủ ủy nhiệm và sự cố gián đoạn dịch vụ phụ thuộc; kiểm thử an ninh đối với tấn công SSRF, chèn ép tiêu đề trái phép và rò rỉ mã token; kiểm thử ứng dụng đối với việc phân quyền công cụ, tính chống xử lý trùng và quy trình phê duyệt. Kết quả kiểm thử phải lưu lại thông tin môi trường chạy và phiên bản, mã băm cam kết mã nguồn, tệp cấu hình, môi trường triển khai, tệp kết quả thô kèm mã kiểm tra tính toàn vẹn và danh sách các trường hợp ngoại lệ. Lỗi dự kiến chấp nhận tạm thời chỉ được phê duyệt khi có người chịu trách nhiệm, thời hạn hết hiệu lực và đánh giá rủi ro rõ ràng; tuyệt đối không được sửa đổi trạng thái kiểm thử để vượt qua bài kiểm tra một cách đối phó. Giai đoạn triển khai thử nghiệm diện hẹp trên môi trường vận hành chính thức cần bổ sung thêm cổng tiếp nhận thực tế, hệ thống định danh IdP và công cụ quan sát hoàn chỉnh.

21. Đường ống xử lý siêu dữ liệu yêu cầu cần ưu tiên kiểm tra tính hợp lệ theo cấu trúc dữ liệu trước khi chuyển tiếp gói tin tới bộ xử lý nghiệp vụ. Cổng trung gian hoặc máy chủ kiểm tra phiên bản JSON-RPC, tính duy nhất của mã định danh yêu cầu, phương thức gọi, cấu trúc tham số và các khóa dành riêng trong đối tượng _meta; đảm bảo sự hiện diện đầy đủ của phiên bản giao thức protocolVersion và năng lực capabilities theo đúng tiêu chuẩn hiện đại; siêu dữ liệu không xác định phải được giữ lại hoặc bỏ qua theo đúng quy tắc, tuyệt đối không được chuyển đổi tự động vào các cấu hình đặc quyền. Cần thiết lập giới hạn kích thước, độ sâu lồng ghép và độ dài mảng dữ liệu để ngăn chặn nguy cơ cạn kiệt tài nguyên hệ thống. Các khóa tùy chỉnh bắt buộc phải dùng định dạng tên miền ngược để tránh xung đột với không gian tên dành riêng. Toàn bộ siêu dữ liệu do bên gọi gửi lên đều bị coi là không đáng tin cậy: các thông tin như dấu vết truy vết, ngôn ngữ địa phương, clientInfo hay các gợi ý phần mở rộng tuyệt đối không được phép quyết định định danh khách hàng hay vai trò người dùng. Hành vi của bộ phân tích cú pháp phải hoàn toàn đồng nhất trên mọi phiên bản máy chủ; cần chạy kiểm thử dữ liệu ngẫu nhiên (fuzz test) đối với giá trị rỗng, khóa trùng lặp, ký tự Unicode, dải số và định dạng nội dung. Khi phát sinh lỗi xác thực, hệ thống phải trả về mã lỗi rõ ràng và tuyệt đối không phản hồi ngược lại toàn bộ gói tin nhạy cảm. Hệ thống đo lường từ xa ghi nhận lý do từ chối yêu cầu, nhưng phải kiểm soát chặt chẽ số lượng biến thể và loại bỏ hoàn toàn dữ liệu định danh cá nhân.

22. Chuẩn JSON Schema 2020-12 là phương ngữ mặc định khi trường $schema bị bỏ trống; hệ thống triển khai bắt buộc phải hỗ trợ tối thiểu các phương ngữ được nêu trong tài liệu tiêu chuẩn và ghi rõ tài liệu hướng dẫn nếu hỗ trợ thêm phương ngữ khác. Cấu trúc dữ liệu đầu vào, đầu ra của công cụ và tài nguyên cần được biên dịch và lưu vào bộ nhớ đệm an toàn, giới hạn độ sâu đệ quy và tham chiếu, đồng thời không bao giờ tự ý phân giải tham chiếu bên ngoài làm thay đổi ngữ nghĩa xử lý. Cả bên cung cấp lẫn bên sử dụng dữ liệu cần kiểm thử kỹ các trường bắt buộc, các thuộc tính bổ sung, cấu trúc kết hợp, định dạng dữ liệu và giá trị mặc định; giá trị mặc định tuyệt đối không được lạm dụng để âm thầm thực thi các hành động mang tính đặc quyền. Cấu trúc dữ liệu chỉ đóng vai trò kiểm tra tính hợp lệ của hợp đồng giao tiếp, chứ không phải là bộ lọc làm sạch dữ liệu hay công cụ phân quyền. Phiên bản của công cụ và cấu trúc dữ liệu phải gắn liền với tên gọi cùng chính sách tương thích; bất kỳ thay đổi nào phá vỡ tính tương thích đều đòi hỏi tạo ra công cụ hoặc phiên bản mới, hoặc phải triển khai theo lộ trình đàm phán trước. Phía máy khách khi kết xuất biểu mẫu không được tin tưởng mù quáng vào phần mô tả hay định dạng văn bản markdown. Việc kiểm thử tuân thủ chuẩn đòi hỏi phải bảo toàn trọn vẹn cấu trúc dữ liệu trong toàn bộ quy trình gửi nhận hai chiều, chứ không chỉ đơn thuần là chấp nhận một tập con hữu hạn.

23. Quản trị danh mục công cụ áp dụng thứ tự sắp xếp có tính tất định, song ý nghĩa nghiệp vụ tuyệt đối không được phụ thuộc vào vị trí hiển thị của công cụ. Thứ tự ổn định được xác lập dựa trên khóa chuẩn tắc và phiên bản; phần mô tả và cấu trúc dữ liệu cần có mã băm nội dung để đối soát toàn vẹn. Danh mục phải được xây dựng từ kho kiểm kê đã qua bộ lọc chính sách phân quyền từ trước, chứ không bao giờ lọc quyền sau khi dữ liệu đã đưa vào bộ nhớ đệm dùng chung. Thông tin người phụ trách công cụ, phân loại dữ liệu và hành động, tác dụng phụ và tính chống xử lý trùng, các phạm vi quyền bắt buộc, quy trình phê duyệt, hạn mức tần suất gọi, vòng đời vận hành và siêu dữ liệu hỗ trợ đều phải được lưu trữ trong sổ đăng ký nội bộ, ngay cả khi cấu trúc truyền nhận trên đường truyền chỉ gửi đi phần thông tin tối thiểu. Mọi thao tác thêm mới, sửa đổi hoặc xóa bỏ công cụ đều phải trải qua quy trình rà soát, kiểm thử hợp đồng giao tiếp, an ninh bảo mật, kiểm thử hồi quy và vô hiệu hóa bộ nhớ đệm ngay lập tức. Các công cụ ngừng hỗ trợ phải có lộ trình khai tử và người phụ trách theo dõi mức độ sử dụng; các tên định danh thay thế (alias) không được duy trì vô hạn. Hệ thống cần phát hiện sự sai lệch danh mục giữa các phiên bản máy chủ, khu vực hạ tầng và không gian riêng của từng khách hàng. Việc tối ưu hóa bộ nhớ đệm câu lệnh prompt tuyệt đối không được giữ lại mô tả hoặc quyền hạn cũ sau khi công cụ đã bị vô hiệu hóa khẩn cấp; công tắc ngắt khẩn cấp trên tuyến thực thi lệnh luôn được ưu tiên cao hơn dữ liệu trong bộ nhớ đệm.

24. Các tài nguyên dữ liệu và mẫu câu lệnh prompt cũng đòi hỏi cơ chế phân quyền độc lập. Thao tác liệt kê hoặc đọc tài nguyên có thể làm rò rỉ tên gọi, đường dẫn định danh URI, siêu dữ liệu hoặc nội dung nhạy cảm; trong khi các mẫu câu lệnh prompt có thể vô tình chứa chính sách nội bộ, cấu trúc khóa bí mật hoặc mã độc chèn lệnh. Bộ lọc danh mục cần căn cứ chính xác theo chủ thể yêu cầu, khách hàng riêng và mục đích sử dụng; thao tác đọc dữ liệu bắt buộc phải kiểm tra quyền truy cập ở cấp độ từng đối tượng và chính sách an ninh hiện hành. Chuẩn hóa đường dẫn URI giúp ngăn chặn tấn công duyệt thư mục trái phép và tấn công SSRF; việc tải dữ liệu từ các hệ thống hạ nguồn cần áp dụng danh sách cho phép, giới hạn dung lượng, định dạng và thời gian chờ, kết hợp quét nội dung phù hợp. Phạm vi bộ nhớ đệm phải đặt ở chế độ riêng tư (private) đối với mọi dữ liệu cá nhân hóa hoặc dữ liệu riêng của khách hàng; thời gian sống TTL không được vượt quá chu kỳ thay đổi hoặc yêu cầu thu hồi quyền. Các tham số truyền vào mẫu câu lệnh prompt cần được kiểm tra tính hợp lệ theo cấu trúc dữ liệu; câu lệnh sau khi kết xuất hoàn chỉnh tuyệt đối không được tự động coi là các chỉ dẫn đáng tin cậy. Nhật ký kiểm tra cần ghi nhận nguồn gốc, phiên bản và các quyết định xử lý ở hạ nguồn. Các quy định về truy xuất nguồn gốc dữ liệu, thời hạn lưu giữ và sự đồng ý của chủ thể dữ liệu vẫn bắt buộc phải áp dụng đầy đủ, dù giao thức MCP chỉ đóng vai trò là tầng truyền dẫn trung gian.

25. An ninh trong khâu yêu cầu người dùng cung cấp thêm thông tin (elicitation) được phân tách thành chế độ biểu mẫu và chế độ đường dẫn liên kết URL. Ở chế độ biểu mẫu, hệ thống tuyệt đối không bao giờ được yêu cầu người dùng nhập mật khẩu, khóa bảo mật API hay bất kỳ bí mật an ninh nào; cả máy khách lẫn máy chủ phải kiểm tra tính hợp lệ của cấu trúc dữ liệu và tối thiểu hóa việc thu thập dữ liệu cá nhân. Ở chế độ liên kết URL, giao diện phải hiển thị nổi bật tên miền gốc, cảnh báo về tên miền giả mạo punycode hoặc các đường dẫn đáng ngờ, và chỉ cho phép người dùng nhấp vào trường liên kết chính thức; đồng thời áp dụng cơ chế đối soát liên kết chuyển hướng và phản hồi, thời hạn hết hiệu lực cùng các biện pháp bảo vệ chống tấn công làm giả yêu cầu từ trình duyệt (CSRF). Máy chủ không bao giờ được tin vào lời tự khai báo danh tính của người dùng; định danh bắt buộc phải đến từ quy trình phân quyền đã được xác minh. Nội dung văn bản yêu cầu có thể chứa bẫy lừa đảo trực tuyến hoặc mã độc chèn câu lệnh prompt; giao diện người dùng cần phân định rõ nguồn gốc máy chủ yêu cầu, loại dữ liệu đang đòi hỏi, hậu quả của hành động và nút hủy bỏ thao tác. Phản hồi của người dùng phải được gắn chặt với mã thao tác, định danh trạng thái và chủ thể, có cơ chế chống tấn công phát lại và lưu giữ đúng mục đích cam kết. Tính dễ tiếp cận và quy trình phê duyệt minh bạch không ép buộc là yếu tố then chốt; hành vi từ chối của người dùng tuyệt đối không được kích hoạt phương án dự phòng để lách qua rào cản kiểm soát.

26. Quá trình lấy mẫu dữ liệu hoặc các vòng tương tác có sự trợ giúp của mô hình AI trong cơ chế MRTR bắt buộc phải thiết lập ranh giới bảo vệ dữ liệu riêng biệt. Yêu cầu từ máy chủ tuyệt đối không được tự ý gửi ngữ cảnh dữ liệu của doanh nghiệp tới các mô hình AI hoặc nhà cung cấp nằm ngoài chính sách an ninh của máy khách. Máy khách cần hiển thị rõ ràng và áp dụng danh sách mô hình AI được phép sử dụng, mức độ phân loại dữ liệu, thời hạn lưu giữ, tính sẵn sàng của công cụ và sự phê duyệt của con người. Mọi câu lệnh prompt, tài nguyên dữ liệu và kết quả đầu ra của công cụ đều phải bị coi là dữ liệu không đáng tin cậy; kết quả lấy mẫu từ mô hình AI không bao giờ được coi là sự thật tuyệt đối hay quyết định phân quyền chính thức. Cần thiết lập hạn ngạch số lượng token, chi phí và thời gian chờ để ngăn chặn vòng lặp suy luận vô tận. Dấu vết truy vết liên kết các vòng trao đổi nhưng bắt buộc phải lọc bỏ nội dung nhạy cảm; bộ câu hỏi đánh giá an toàn kiểm tra nguy cơ trích xuất dữ liệu trái phép, xung đột chỉ dẫn và các hành vi gây hại. Nếu máy khách không hỗ trợ năng lực này, máy chủ phải xử lý bằng phương án dự phòng an toàn hoặc trả về lỗi có cấu trúc, tuyệt đối không tự ý phỏng đoán. Cơ chế EMA và định danh nhân viên không tự động cấp quyền truy cập tài nguyên cho các nhà cung cấp mô hình AI bên ngoài. Hợp đồng pháp lý và danh mục kiểm kê quyền riêng tư phải bao quát toàn diện các tuyến truyền dữ liệu tới nhà cung cấp mô hình.

27. Thao tác hủy lệnh và thông báo tiến độ xử lý bắt buộc phải mang ngữ nghĩa nghiệp vụ rõ ràng. Yêu cầu hủy lệnh sẽ dừng việc tính toán với nỗ lực tối đa, song những tác dụng phụ đã được cam kết ghi nhận vào hệ thống thì có thể không thể hoàn tác; thông báo kết quả và nhật ký kiểm tra phải nêu rõ trạng thái thực tế. Các tác vụ kéo dài cần sử dụng trạng thái tường minh và quy trình đền bù nghiệp vụ thay vì giả định rằng hệ thống có tính nguyên tử tuyệt đối. Thông báo tiến độ xử lý là tính năng tùy chọn theo từng yêu cầu và năng lực của máy khách, phải được giới hạn tần suất gửi và không được để lộ thông tin nhạy cảm. Khi máy khách kết nối lại, hệ thống không được tự suy đoán rằng tác vụ đã biến mất, mà phải chủ động truy vấn theo định danh trạng thái. Tình trạng tranh chấp giữa hành động hủy lệnh và hoàn tất tác vụ phải được kiểm thử nghiêm ngặt theo cơ chế giao dịch. Thời gian chờ tại máy chủ ủy nhiệm trung gian hoàn toàn khác biệt với thời gian chờ ở tầng ứng dụng; chính sách gửi lại yêu cầu phải nhận thức rõ tính chống xử lý trùng lặp. Người dùng cần được nhìn thấy rõ ràng các trạng thái: đang chờ xử lý, đã cam kết hoàn tất, đang đền bù khắc phục hoặc chưa xác định, chứ không chỉ nhìn thấy biểu tượng xoay vòng chờ đợi vô nghĩa. Cẩm nang ứng phó sự cố phải có quy trình đối soát dữ liệu với các hệ thống bên ngoài. Cam kết chất lượng dịch vụ (SLO) cần tách bạch rõ giữa thời gian tiếp nhận yêu cầu, thời gian xử lý tính toán và thời gian hoàn tất nghiệp vụ trọn vẹn. Quy trình dọn dẹp tài nguyên tuyệt đối không được xóa bỏ các hồ sơ chính thức đang trong thời hạn lưu giữ bắt buộc.

28. Hệ thống phân loại mã lỗi khoa học giúp máy khách không gửi lại yêu cầu một cách mù quáng và sai lầm. Cần phân loại rạch ròi các nhóm lỗi: lỗi phân tích cú pháp hoặc yêu cầu không hợp lệ, phiên bản giao thức hoặc năng lực không được hỗ trợ, lỗi xác thực 401, lỗi phân quyền hoặc thiếu phạm vi quyền 403, lỗi không tìm thấy tài nguyên an toàn theo chính sách, lỗi xung đột hoặc vi phạm tính chống trùng lặp, lỗi vượt giới hạn tần suất gọi, lỗi dịch vụ phụ thuộc không sẵn sàng, lỗi hết thời gian chờ và lỗi nội bộ hệ thống. Thông điệp lỗi phản hồi tuyệt đối không được để lộ dấu vết ngăn xếp kỹ thuật, mã token hay chi tiết chính sách bảo mật; chỉ cần cung cấp mã đối soát tương quan là đủ để phục vụ công tác hỗ trợ. Cờ báo hiệu yêu cầu có thể gửi lại cùng thuật toán giãn cách thời gian phải dựa trên ngữ nghĩa đã được ghi chép trong tài liệu, tuyệt đối không tự động gửi lại mọi lỗi máy chủ đầu 5xx hoặc các công cụ có tác dụng phụ. Mã lỗi UnsupportedProtocolVersion đặc biệt sẽ dẫn hướng tới quy trình đàm phán phiên bản chung đi kèm chính sách hạ cấp an toàn. Các thử thách nâng cấp quyền cần giới hạn số lần lặp để tránh vòng lặp bất tận. Các chỉ số đo lường lỗi cần thống kê theo phương thức, công cụ, phiên bản giao thức, lớp lỗi và các chiều an toàn theo từng khách hàng. Quy trình ánh xạ lỗi qua cổng trung gian không được biến mã lỗi 403 thành lỗi máy chủ 500. Các bài kiểm thử hỗn loạn (chaos test) giúp xác minh hành vi ứng xử của máy khách, khả năng điều tiết áp lực ngược của hàng đợi và đảm bảo không gây ra cơn bão yêu cầu làm tê liệt hệ thống.

29. Cơ chế giới hạn tần suất gọi và hạn ngạch tài nguyên cần được thiết lập ở nhiều tầng nấc: lọc theo địa chỉ IP chỉ là giải pháp sơ đẳng chống lạm dụng thô thiển; việc kiểm soát chi tiết theo chủ thể yêu cầu, khách hàng riêng, máy khách, tài nguyên, phương thức, công cụ và trọng số chi phí mới phản ánh đúng sự công bằng trong sử dụng tài nguyên. Tiêu đề Mcp-Name hỗ trợ thực thi chính sách nhưng tính nhất quán với phần thân yêu cầu luôn phải được ưu tiên đối soát trước. Các thao tác đọc và liệt kê danh mục có chi phí thấp phải được phân loại khác biệt so với các thao tác xuất dữ liệu, ghi dữ liệu hoặc lấy mẫu mô hình AI; toàn bộ các vòng trao đổi trong cơ chế MRTR phải được tính chung vào ngân sách của cùng một thao tác nghiệp vụ. Khi vượt hạn mức, hệ thống trả về chỉ dẫn kèm tiêu đề thời gian chờ thử lại phù hợp, tuyệt đối không làm lộ thông tin hạn ngạch của khách hàng khác. Hợp đồng thương mại hay hạn ngạch cam kết của doanh nghiệp không bao giờ được phép ghi đè lên các giới hạn an toàn kỹ thuật cốt lõi. Bộ đếm phân tán cần đảm bảo tính nhất quán vừa đủ và có chế độ xử lý lỗi linh hoạt theo mức độ rủi ro; sự cố gián đoạn tại cổng trung gian không bao giờ được phép tự động mở quyền truy cập không giới hạn. Cần thiết lập rào chắn ngân sách chi phí cho mô hình AI và công cụ, kiểm soát tải đồng thời, áp lực ngược và tuổi thọ của hàng đợi. Mọi ngoại lệ miễn trừ đều phải có giới hạn thời gian, được phê duyệt chính thức và ghi nhật ký kiểm tra đầy đủ. Các bài kiểm thử tải cần mô phỏng lưu lượng đột biến, máy khách phản hồi chậm trên luồng SSE, cơn bão gửi lại yêu cầu và hiện tượng láng giềng gây ồn ào chiếm dụng tài nguyên.

30. Sự cô lập giữa các khách hàng (tenant) tuyệt đối không được suy đoán đơn thuần từ điểm cuối dịch vụ hay siêu dữ liệu do máy khách tự gửi lên. Mã token đã qua xác thực và chính sách doanh nghiệp là cơ sở duy nhất xác lập không gian riêng của khách hàng; máy chủ và cổng trung gian lan truyền ngữ cảnh đã được ký số và kiểm soát chặt chẽ, tuyệt đối không chấp nhận mã định danh khách hàng tùy ý truyền vào từ tham số của công cụ nếu có sự sai lệch. Dữ liệu, bộ nhớ đệm, định danh trạng thái, dấu vết truy vết, nhật ký kiểm tra, khóa bảo mật và hạn ngạch tài nguyên đều phải được phân vùng độc lập; các câu truy vấn cơ sở dữ liệu phải có bộ lọc ở cấp độ từng đối tượng và được kiểm thử kỹ lưỡng để ngăn chặn rò rỉ chéo giữa các khách hàng. Việc dùng chung phiên bản máy chủ trong cụm phi trạng thái không đồng nghĩa với việc chia sẻ trạng thái rộng rãi giữa các khách hàng. Quy trình ánh xạ nhóm trong cơ chế EMA cần có nguồn gốc, phiên bản và chính sách mặc định từ chối; quy trình điều chuyển nhân sự hoặc thôi việc phải lập tức đồng bộ và thu hồi quyền hạn. Các trường hợp nhân viên hỗ trợ mạo danh người dùng hoặc kích hoạt quy trình khẩn cấp đều phải có sự phê duyệt chính thức, giới hạn thời gian, hiển thị biểu ngữ thông báo rõ ràng và ghi nhật ký kiểm tra. Việc sao lưu, xuất và khôi phục dữ liệu bắt buộc phải giữ nghiêm ngặt ranh giới giữa các khách hàng. Cần chạy kiểm thử ngẫu nhiên đối với các chuỗi định danh và quy tắc chuẩn hóa. Diễn tập kiểm thử xâm nhập để phát hiện các lỗ hổng phân quyền cấp đối tượng bị phá vỡ (BOLA/IDOR), thiếu sót khóa trong bộ nhớ đệm và hành vi tráo đổi định danh trạng thái giữa các khách hàng.

31. Các biện pháp kiểm soát công cụ có rủi ro cao phải được thiết lập bao bọc xung quanh tầng giao thức. Sổ đăng ký công cụ phân loại rõ ràng từng hành động: đọc dữ liệu, ghi dữ liệu, xóa dữ liệu, giao dịch tài chính, liên lạc với hệ thống bên ngoài hoặc thao tác đặc quyền quản trị; đi kèm các phạm vi quyền bắt buộc, quy trình phê duyệt, hạn mức giao dịch, môi trường áp dụng và danh mục tài nguyên được phép truy cập. Giai đoạn lập kế hoạch và xem trước kết quả phải tách bạch hoàn toàn với giai đoạn thực thi lệnh; bản tóm tắt thao tác phải hiển thị rõ mục tiêu tác động và những nội dung sẽ thay đổi; quyết định phê duyệt phải gắn kết chặt chẽ với bản băm thao tác, chủ thể yêu cầu, có thời hạn hiệu lực và chỉ được sử dụng đúng một lần. Máy chủ phải xác thực lại toàn bộ chính sách và trạng thái hệ thống ngay tại thời điểm thực thi; tác nhân AI hay máy khách tuyệt đối không được tự ý xác nhận thay cho người dùng. Cần áp dụng đầy đủ tính chống xử lý trùng, bước xác nhận lại, cơ chế đền bù nghiệp vụ và nhật ký kiểm tra bất biến. Môi trường hộp cát cách ly hoặc chế độ chạy thử nghiệm phải được áp dụng cho việc thực thi mã lệnh hoặc câu truy vấn cơ sở dữ liệu; kết hợp danh sách cho phép, giải pháp phòng chống thất thoát dữ liệu và kiểm tra tính hợp lệ của đầu ra. Cần trang bị công tắc ngắt khẩn cấp cho từng công cụ và từng khách hàng riêng biệt. Áp dụng nguyên tắc kiểm duyệt bốn mắt (cần hai người phê duyệt) cho các hành động đặc biệt nhạy cảm. Việc tuân thủ chuẩn giao thức MCP hoàn toàn không thể biến một công cụ dòng lệnh shell, công cụ truy vấn cơ sở dữ liệu hay công cụ quản trị thành một công cụ an toàn. Doanh nghiệp cần liên tục giám sát các hành vi sử dụng bất thường, tỷ lệ từ chối lệnh và chuẩn bị sẵn quy trình khôi phục sau sự cố.

32. Quản trị chuỗi cung ứng phần mềm bao quát toàn bộ các bộ SDK, công cụ sinh cấu trúc dữ liệu, các phần bổ trợ của cổng trung gian, mã nguồn máy chủ, các gói phần mở rộng, vùng chứa ứng dụng và toàn bộ các thư viện phụ thuộc. Doanh nghiệp cần cố định số hiệu phiên bản, duy trì danh mục thành phần phần mềm (SBOM), xác minh nguồn gốc và chữ ký số khi có sẵn, chỉ định người phụ trách theo dõi các cảnh báo lỗ hổng bảo mật, sẵn sàng quy trình biên dịch lại và quay về bản cũ, cùng việc rà soát giấy phép phần mềm. Cấp độ ưu tiên của thư viện hay việc lưu trữ trên kho lưu trữ chính thức không thể thay thế cho công tác thẩm định an ninh độc lập. Các kiểu dữ liệu do bộ SDK tự sinh có thể có hành vi sai lệch so với gói tin thực tế trên đường truyền; do đó cần thực hiện kiểm thử hợp đồng giao tiếp đối chiếu trực tiếp với tài liệu tiêu chuẩn. Các gói phần mở rộng tuyệt đối không được phép tự ý đăng ký thêm công cụ hay quyền hạn nằm ngoài danh mục kiểm kê chính thức. Các khóa bí mật dùng trong khâu đóng gói phần mềm phải được phân tách độc lập với môi trường vận hành thực tế, áp dụng nguyên tắc quyền tối thiểu trên đường ống tích hợp liên tục (CI), cùng quy trình nâng cấp sản phẩm đầu ra qua đợt thử nghiệm diện hẹp. Kịch bản một bản cập nhật bị kẻ tấn công xâm nhập cần được diễn tập ứng phó bài bản thông qua quy trình thu hồi quyền, quay về bản trước, luân chuyển khóa và mã token cùng thu thập bằng chứng đầy đủ. Mọi bản vá tùy chỉnh hoặc nhánh mã nguồn tự phát triển đều phải có người phụ trách, theo dõi các thay đổi từ nguồn gốc thượng nguồn và thiết lập thời hạn hết hạn cụ thể. Các gói phụ thuộc kế thừa đã hết vòng đời hỗ trợ là một rủi ro trọng yếu cần được quản lý chặt chẽ trong kế hoạch chuyển đổi hệ thống kép.

33. Sơ đồ triển khai cụm máy chủ phi trạng thái đòi hỏi phân tách rạch ròi giữa mặt phẳng điều khiển và mặt phẳng dữ liệu. Các phiên bản máy chủ là bất biến, đồng nhất về cấu hình, cấu trúc dữ liệu và gói chính sách, đồng thời có cơ chế kiểm tra trạng thái hoạt động và độ sẵn sàng; các thành phần dùng chung như cơ sở dữ liệu, bộ nhớ đệm, hàng đợi và bộ khóa bảo mật phải đảm bảo tính sẵn sàng cao và đủ năng lực xử lý. Bộ cân bằng tải tuyệt đối không sử dụng cơ chế gán phiên kết nối cố định; cần kiểm thử khả năng tiếp nhận yêu cầu bất kỳ trên một phiên bản máy chủ bất kỳ. Việc bố trí vùng địa lý, quy định lưu trữ dữ liệu nội địa, độ trễ mạng và quy trình chuyển đổi dự phòng khi có sự cố phải được rà soát kỹ lưỡng. Quy trình nâng cấp cuốn chiếu cần có chính sách cùng tồn tại phiên bản; phiên bản yêu cầu sẽ được định tuyến tới cụm máy chủ tương thích tương ứng nhưng nghiêm cấm việc hạ cấp phiên bản giao thức. Việc phát hành cấu hình phải có chữ ký số, quản lý phiên bản và triển khai thử nghiệm diện hẹp; kết hợp phát hiện sai lệch cấu hình. Quá trình giải phóng máy chủ cần xử lý trọn vẹn các luồng SSE và các vòng trao đổi MRTR đang thực thi dở dang; trạng thái tác vụ tường minh phải được lưu trữ độc lập bên ngoài tiến trình máy chủ. Tự động co giãn tài nguyên cần dựa trên số lượng kết nối đồng thời, độ trễ và chi phí chứ không chỉ dựa vào mức tải CPU. Cần tối ưu hóa các nhóm kết nối mạng và dung lượng lưu trữ. Kế hoạch khôi phục sau thảm họa phải xác minh lại các định danh trạng thái, nhật ký kiểm tra và tính chống trùng lặp sau khi hoàn tất khôi phục.

34. Mô hình hiệu năng không bao giờ được ngộ nhận rằng kiến trúc phi trạng thái sẽ mặc định luôn chạy nhanh hơn. Việc gửi kèm siêu dữ liệu trên từng yêu cầu, khám phá phân quyền, kiểm tra tính hợp lệ của mã token, đối soát chính sách và tình trạng bộ nhớ đệm nguội đều làm tăng chi phí tính toán phụ trội; bù lại việc loại bỏ phiên làm việc và kết nối cố định giúp cải thiện đáng kể khả năng cân bằng tải và tốc độ phục hồi hệ thống. Bài kiểm thử chuẩn hiệu năng cần bóc tách rạch ròi từng giai đoạn: từ máy khách tới cổng trung gian, xác thực và thực thi chính sách, máy chủ xử lý, các dịch vụ hạ nguồn, tuần tự hóa dữ liệu và truyền luồng SSE; đo lường các phân vị thời gian phản hồi P50, P95 và P99 theo từng phương thức, công cụ, dung lượng gói tin và mức độ đồng thời. Tỷ lệ trúng hoặc trượt bộ nhớ đệm và thời gian sắp xếp danh mục tất định phải được đo lường chính xác. Bộ nhớ đệm bộ khóa JWKS và siêu dữ liệu phải có thời gian sống TTL an toàn và quy trình tái xác thực phù hợp. Doanh nghiệp cần cân nhắc đánh đổi giữa việc tự kiểm tra mã token cục bộ với việc gọi tới điểm cuối kiểm tra từ xa. Kiểm thử tải cần mô phỏng lưu lượng tăng đột biến, triển khai đa vùng, danh mục và cấu trúc dữ liệu dung lượng lớn, các vòng trao đổi MRTR và tình huống các dịch vụ phụ thuộc bị suy giảm hiệu năng. Việc tối ưu hóa chỉ được tiến hành sau khi đã đo lường hồ sơ hiệu năng bài bản; tuyệt đối không cắt giảm việc kiểm tra đối tượng thụ hưởng, lược bỏ chính sách hay tắt nhật ký chỉ nhằm đạt được mục tiêu độ trễ. Năng lực xử lý và chi phí trên mỗi yêu cầu thành công cần được gắn chặt với ngân sách lỗi cho phép và cam kết chất lượng dịch vụ (SLO) của doanh nghiệp.

35. Tầng chuyển đổi giữa hai thời kỳ cần được thiết lập ranh giới vận hành rõ ràng. Tầng này có thể chuyển đổi bước khởi tạo và phiên kết nối cũ sang ngữ cảnh tương thích nội bộ và siêu dữ liệu trên từng yêu cầu hiện đại, song tuyệt đối không được tự ý tạo thêm năng lực giả định hay làm suy yếu cơ chế xác thực phân quyền. Luồng truyền dữ liệu từ máy chủ tới máy khách thế hệ cũ và cơ chế MRTR hiện đại tồn tại những khoảng cách ngữ nghĩa đáng kể; bất kỳ tính năng nào không được hỗ trợ đều phải báo lỗi công khai. Ngữ cảnh chuyển đổi chỉ có phạm vi giới hạn và có thời hạn hiệu lực cụ thể, tuyệt đối không được coi là định danh bảo mật chính thức. Các hành vi của tiêu đề hay bộ nhớ đệm không được phép giả lập cho hệ thống cũ nếu không thể bảo đảm chắc chắn. Ma trận tài liệu cần ghi rõ các điểm ánh xạ có nguy cơ suy hao thông tin, kèm bộ kiểm thử và hệ thống đo lường từ xa tương ứng. Tầng chuyển đổi bắt buộc phải có người phụ trách, vòng đời vá lỗi bảo mật, ngưỡng lưu lượng điều tiết và ngày khai tử dứt điểm; không bao giờ được để tầng này trở thành một nền tảng vận hành vĩnh viễn. Tài liệu hướng dẫn chuyển đổi cho máy khách cần cung cấp chính xác các số hiệu phiên bản và cấu hình mẫu. Việc cắt chuyển sang hệ thống mới cần tiến hành theo từng công cụ và từng khách hàng riêng, phương án dự phòng phải có giới hạn thời gian cụ thể. Quy trình điều tra sự cố cần phân định rạch ròi xem nguyên nhân bắt nguồn từ tầng chuyển đổi hay từ chính điểm cuối xử lý.

36. An ninh chống hạ cấp phiên bản đòi hỏi chính sách thực thi nghiêm ngặt hơn là cơ chế thử lại đơn thuần. Khi nhận được danh sách các phiên bản hỗ trợ, máy khách chỉ được phép lựa chọn các phiên bản mà tổ chức cho phép đi kèm định danh máy chủ và máy chủ phát hành chính xác; tuyệt đối không quay về phiên bản cũ chỉ vì kẻ tấn công cố tình chèn gói tin phản hồi giả mạo. Tính toàn vẹn của tầng truyền tải qua mã hóa TLS và tính xác thực của thông điệp lỗi phải được bảo đảm. Cần thiết lập phiên bản tối thiểu cho từng khách hàng, từng công cụ và mức độ rủi ro; các công cụ trọng yếu bắt buộc chỉ chạy trên phiên bản hiện đại. Mọi sự kiện hạ cấp phiên bản đều phải được ghi nhật ký, phát cảnh báo, thống kê chỉ số và hiển thị minh bạch cho người dùng lẫn quản trị viên. Khi bị mất mát năng lực bảo mật bắt buộc, hệ thống phải tự động khóa an toàn ngay lập tức. Những điểm khác biệt về xác thực của hệ thống cũ cần được đưa vào mô hình hóa mối đe dọa; các kho lưu trữ mã token và thông tin xác thực phải được phân tách độc lập. Máy chủ ủy nhiệm tuyệt đối không được tự ý ghi đè phiên bản được yêu cầu. Bộ kiểm thử cần bao quát các tình huống giả mạo danh sách hỗ trợ, hiện tượng dao động phiên bản, vòng lặp cạn kiệt tài nguyên và sự cố chuyển đổi dở dang trên một phần cụm máy chủ. Việc khôi phục khẩn cấp về bản cũ đòi hỏi phê duyệt chính thức và có thời hạn hết hạn rõ ràng. Sau thời điểm ngừng hỗ trợ, các yêu cầu theo chuẩn cũ phải bị từ chối dứt khoát kèm thông tin hướng dẫn chuyển đổi mà không để lộ cấu trúc nội bộ.

37. Quá trình chuyển đổi máy chủ cấp quyền phân quyền phải được chia thành từng giai đoạn có kiểm soát. Cần lập danh mục kiểm kê toàn diện các máy chủ phát hành, máy khách, đường dẫn chuyển hướng, tài nguyên, phạm vi quyền hạn, khóa ký, mã làm mới token, sự đồng ý, chính sách bảo mật và các dịch vụ phụ thuộc. Siêu dữ liệu và bộ khóa JWKS của máy chủ phát hành mới phải đạt trạng thái ổn định; máy khách chỉ thiết lập lòng tin với chính xác các máy chủ phát hành theo kế hoạch trong một khung thời gian giới hạn; thông tin xác thực luôn gắn chặt với từng máy chủ phát hành. Cần xác định rõ ràng tuyến đường yêu cầu người dùng xác thực lại hoặc cơ chế trao đổi mã token; tuyệt đối không sao chép mã làm mới token từ máy chủ phát hành này sang máy chủ phát hành khác. Máy chủ tài nguyên chỉ chấp nhận xác thực cả hai máy chủ phát hành khi đã được phê duyệt và phải xác định rõ ràng bảng ánh xạ riêng theo từng máy chủ phát hành. Triển khai thử nghiệm cho nhóm người dùng và máy khách nhỏ trước; theo dõi chặt chẽ các chỉ số đăng nhập, tỷ lệ lỗi, phạm vi quyền và tài nguyên; luôn sẵn sàng phương án quay về bản trước. Chỉ xóa bỏ máy chủ phát hành cũ, quan hệ tin cậy, bộ khóa, máy khách, mã token và bộ nhớ đệm sau khi đã thu thập đầy đủ bằng chứng và hết thời hạn lưu giữ bắt buộc. Quan hệ tin cậy với hệ thống định danh IdP trong cơ chế EMA cần được cập nhật theo quy trình riêng biệt. Kế hoạch truyền thông và hỗ trợ người dùng phải được chuẩn bị chu đáo. Quy trình giám sát sự cố cần đặc biệt chú ý tới rủi ro trộn lẫn mã hoặc xuất hiện máy chủ phát hành bất thường.

38. Vận hành khóa bảo mật và bộ khóa JWKS ảnh hưởng trực tiếp tới tính sẵn sàng và độ tin cậy của toàn hệ thống. Thuật toán mã hóa, mục đích sử dụng khóa và siêu dữ liệu của máy chủ phát hành bắt buộc phải nằm trong danh sách cho phép; việc luân chuyển khóa cần có khoảng thời gian gối đầu đủ dài để các mã token hợp lệ và dữ liệu trong bộ nhớ đệm kịp xử lý, nhưng không bao giờ kéo dài vô tận. Bộ nhớ đệm JWKS phải tuân thủ cơ chế làm mới an toàn và giới hạn số lần thử lại khi gặp mã định danh khóa lạ để ngăn chặn nguy cơ tắc nghẽn hàng loạt do cơn bão truy vấn. Khi phát hiện khóa bị xâm phạm, hệ thống phải kích hoạt quy trình thu hồi, rút ngắn thời hạn, xoay vòng khóa mới, vô hiệu hóa mã token liên quan và thu thập bằng chứng pháp y số. Khóa riêng tư bắt buộc phải lưu trong mô-đun bảo mật phần cứng (HSM) hoặc hệ thống quản lý khóa bí mật chuyên dụng, tuyệt đối không xuất hiện trong nhật ký ứng dụng hay ảnh vùng chứa; áp dụng phân tách quyền truy cập và kiểm tra nhật ký nghiêm ngặt. Đồng bộ hóa đồng hồ hệ thống và khoảng dung sai thời gian phải được kiểm soát chặt chẽ. Đảm bảo tính nhất quán giữa các khu vực hạ tầng đa vùng. Cần kiểm thử các tình huống bộ khóa JWKS bị cũ, xuất hiện mã khóa không xác định, khóa đã bị xóa, thuật toán sai, chứng chỉ sai định dạng, sự cố gián đoạn dịch vụ và quy trình khôi phục bản cũ. Cơ chế ký số tài liệu hoặc siêu dữ liệu của máy khách (nếu sử dụng) phải có người phụ trách rõ ràng. Lịch trình luân chuyển khóa phải liên kết đồng bộ giữa quy trình triển khai phần mềm, máy chủ xác thực và các máy chủ tài nguyên.

39. Quản trị quyền riêng tư và hồ sơ lưu trữ đòi hỏi phải vẽ lại sơ đồ toàn bộ các luồng dữ liệu qua giao thức MCP: từ siêu dữ liệu yêu cầu, mã token và các tuyên bố định danh, tham số và kết quả của công cụ, nội dung tài nguyên, câu lệnh prompt, thông tin thu thập người dùng, dấu vết truy vết, nhật ký kiểm tra, bộ nhớ đệm, định danh trạng thái cho tới các bản sao lưu và dữ liệu xuất hỗ trợ kỹ thuật. Mục đích sử dụng hợp pháp, nguyên tắc tối thiểu hóa, quyền truy cập, vị trí lưu trữ và đối tượng tiếp nhận, thời hạn lưu giữ và quy trình xóa bỏ dữ liệu, quyền của chủ thể dữ liệu cùng quy trình ứng phó sự cố bắt buộc phải được quy định rõ bởi người phụ trách dữ liệu và bộ phận pháp lý. Việc giao thức phi trạng thái không đồng nghĩa với việc không có dữ liệu nào được lưu giữ lại; trên thực tế các kho lưu trữ quan sát hệ thống và kho trạng thái thậm chí có thể lưu giữ nhiều dữ liệu hơn. Các tuyên bố trong mã token và tên công cụ hoàn toàn có thể chứa thông tin cá nhân hoặc dữ liệu mật của doanh nghiệp. Việc lọc bỏ dữ liệu nhạy cảm phải được thực hiện ngay tại nguồn phát sinh, chứ không chỉ che giấu ở bảng điều khiển hiển thị. Dữ liệu dùng trong môi trường kiểm thử và hỗ trợ kỹ thuật phải được kiểm soát nghiêm ngặt. Các tuyến truyền dữ liệu xuyên biên giới, chuyển tới nhà cung cấp dịch vụ hay nhà cung cấp mô hình AI phải được rà soát thẩm định kỹ lưỡng. Các hồ sơ nghiệp vụ chính thức bắt buộc phải được lưu giữ độc lập bên ngoài các tệp nhật ký tạm thời của giao thức với tính toàn vẹn cao nhất. Bài viết này không cấu thành ý kiến tư vấn pháp lý chính thức.

40. Đóng quy trình chuyển đổi và hoàn tất hồ sơ bằng chứng là bước cuối cùng khép lại dự án. Cần xác minh lưu lượng qua hệ thống cũ đã hoàn toàn về mức 0 trong khoảng thời gian thỏa thuận, toàn bộ các trường hợp ngoại lệ đã được xử lý xong, thông báo chính thức đã gửi tới các bên máy khách và thời hạn đưa ra quyết định quay về bản trước đã trôi qua an toàn; sau đó mới tiến hành vô hiệu hóa các điểm cuối và tính năng cũ, thu hồi thông tin xác thực, định danh máy khách và các mã token, xóa sạch các kho lưu phiên làm việc, bộ nhớ đệm và các bộ dịch chuyển đổi, đồng thời gỡ bỏ các quy tắc tường lửa, bản ghi DNS và bảng định tuyến cũ. Cần lưu trữ bảo toàn các sản phẩm đầu ra về nhật ký kiểm tra, quyết định phê duyệt và kết quả kiểm thử bắt buộc đi kèm quyền truy cập và thời hạn lưu giữ chuẩn mực; xóa bỏ an toàn các dữ liệu không cần thiết và lập biên bản bằng chứng đầy đủ. Cập nhật lại danh mục kiểm kê, danh mục thành phần phần mềm (SBOM), sơ đồ kiến trúc, tài liệu vận hành, kế hoạch khôi phục sau thảm họa, hệ thống giám sát và thông tin người phụ trách. Chạy quét toàn diện để phát hiện các lệnh gọi hệ thống cũ còn sót lại hoặc các cấu hình phiên làm việc cố định ẩn giấu. Báo cáo đánh giá sau triển khai cần so sánh các chỉ số về tính sẵn sàng, độ trễ, nỗ lực vận hành, sự cố an ninh và chi phí thực tế so với mốc đo ban đầu, tránh tuyên bố chủ quan rằng tài liệu tiêu chuẩn là nguyên nhân duy nhất tạo nên mọi chuyển biến tích cực. Sổ theo dõi tuyên bố kết quả và lịch rà soát định kỳ cần được cập nhật. Những bài học kinh nghiệm rút ra sẽ là đầu vào quý báu phục vụ cho các đợt chuyển đổi phần mở rộng và cập nhật phiên bản giao thức tiếp theo.

41. Trải nghiệm người dùng và việc định chuẩn mức độ tin cậy trên máy khách cần phản ánh trung thực trạng thái yêu cầu, phần mở rộng và cơ chế phân quyền mà không bắt người dùng cuối phải hiểu về các chi tiết giao thức phức tạp. Giao diện người dùng phải hiển thị rõ ràng máy chủ và tên miền đã được xác minh, công cụ và hành động sắp thực hiện, loại dữ liệu sẽ sử dụng, phạm vi quyền hiện có và quyền hạn cần nâng cấp thêm, các yêu cầu phê duyệt hoặc các vòng trao đổi MRTR đang chờ xử lý, thông báo lỗi hoặc không tương thích phiên bản cùng hướng dẫn cách hủy bỏ thao tác. Tuyệt đối không hiển thị thông tin clientInfo hay biểu tượng đồ họa như một chứng nhận an toàn chính thức. Các hành động có độ rủi ro cao bắt buộc phải có bước xem trước, bản tóm tắt nội dung và yêu cầu xác nhận tường minh; các tác vụ chạy nền cần có thông báo tiến độ và kết quả rõ ràng. Khi bị chính sách doanh nghiệp từ chối, hệ thống cần giải thích thỏa đáng để người dùng biết cách khắc phục nhưng không làm lộ các quy tắc an ninh nội bộ nhạy cảm. Cần đưa ra cảnh báo đối với các đường dẫn URL lừa đảo và máy chủ có tên miền mạo danh tương tự. Tính tiếp cận, khả năng bản địa hóa ngôn ngữ và luồng thao tác trên thiết bị di động cần được kiểm thử kỹ. Tình trạng mệt mỏi vì phải liên tục bấm nút đồng ý phải được đo lường cụ thể; việc thông báo liên tục xuất hiện là dấu hiệu cho thấy cấu trúc phạm vi quyền, chính sách hoặc quy trình nghiệp vụ cần được tái cấu trúc, chứ không phải cái cớ để tự động phê duyệt tùy tiện.

42. Trải nghiệm của nhà phát triển phải hướng tới việc biến con đường an toàn nhất thành con đường dễ triển khai nhất. Các lớp bao bọc thư viện SDK cần mặc định tự động gắn siêu dữ liệu hiện đại, đối soát tính nhất quán giữa tiêu đề bắt buộc với phần thân yêu cầu, quản lý thông tin xác thực gắn chặt với máy chủ phát hành và tài nguyên, lọc bỏ dữ liệu nhạy cảm trong nhật ký và cung cấp sẵn các cơ chế xử lý chống trùng lặp cùng định danh trạng thái. Các bộ khung mẫu dự án phải thiết lập sẵn phạm vi quyền tối thiểu, điểm kiểm tra sức khỏe và độ sẵn sàng, chính sách OpenTelemetry và các bài kiểm thử tiêu chuẩn; tuyệt đối không kèm theo ký tự đại diện hay mã token quyền quản trị. Môi trường phát triển cục bộ cần sử dụng máy chủ và máy chủ phát hành giả lập cùng bộ dữ liệu tổng hợp, nghiêm cấm sao chép các khóa bí mật của môi trường vận hành chính thức về máy cá nhân. Thông báo lỗi phải hướng dẫn nhà phát triển tới đúng phiên bản, năng lực và cấu hình phân quyền chuẩn xác. Các đoạn mã ví dụ cần cố định số hiệu phiên bản gói thư viện và có ngày rà soát định kỳ; các đoạn mã cũ không còn phù hợp phải được gỡ bỏ kịp thời. Công cụ kiểm tra tĩnh và đường ống tích hợp liên tục (CI) cần chủ động ngăn chặn việc truyền mã token qua chuỗi truy vấn, thiếu tài nguyên chỉ định, sử dụng clientInfo làm định danh xác thực, lưu đệm công khai các kết quả riêng tư và kích hoạt các phần mở rộng chưa qua phê duyệt. Các cơ chế thoát hiểm khẩn cấp phải được khai báo tường minh, ghi nhật ký kiểm tra và có giới hạn thời gian cụ thể.

43. Cẩm nang vận hành dành cho kỹ sư độ tin cậy hệ thống (SRE) cần được biên soạn theo triệu chứng sự cố thay vì chỉ liệt kê đơn thuần theo từng thành phần kỹ thuật. Khi xảy ra sai lệch phiên bản: xác định chính xác đối tượng gọi, cặp kết nối và chính sách liên quan, tuyệt đối không mở tính năng hạ cấp phiên bản trên diện rộng. Khi phát sinh lỗi xác thực 401: kiểm tra máy chủ phát hành, tài nguyên, mã token, khóa ký và độ lệch đồng hồ hệ thống; khi gặp lỗi phân quyền 403: rà soát phạm vi quyền hạn, chính sách bảo mật và chủ thể yêu cầu; khi phát hiện rò rỉ bộ nhớ đệm: lập tức vô hiệu hóa bộ nhớ đệm, cô lập không gian khách hàng bị ảnh hưởng, xoay vòng khóa hoặc thu hồi quyền khi cần thiết; khi định danh trạng thái bị tắc nghẽn: kiểm tra trạng thái lưu trữ, thời hạn thuê quyền và người phụ trách để khôi phục an toàn theo cơ chế chống trùng lặp; khi phát hiện vòng lặp MRTR vô tận: giới hạn số vòng trao đổi tối đa và hủy bỏ yêu cầu; khi tiêu đề và phần thân không khớp nhau: lập tức chặn ngay tại cổng tiếp nhận và điều tra máy khách cùng các máy chủ ủy nhiệm liên quan. Mỗi quy trình xử lý sự cố phải nêu rõ mức độ nghiêm trọng, yêu cầu thu thập bằng chứng, biện pháp khoanh vùng cô lập, quy trình quay về bản trước, đối soát dữ liệu, kế hoạch truyền thông và báo cáo tổng kết sau sự cố. Trang bị công tắc ngắt khẩn cấp cho từng công cụ, phần mở rộng và phiên bản giao thức. Nhân viên trực vận hành mặc định không được quyền xem trực tiếp gói tin nhạy cảm ở dạng thô. Các bài diễn tập định kỳ cần bao quát các tình huống gián đoạn hệ thống định danh IdP, sự cố bộ khóa JWKS, gián đoạn bộ nhớ đệm, tê liệt cơ sở dữ liệu, sự cố gián đoạn toàn bộ vùng hạ tầng và tình huống máy khách bị kẻ tấn công chiếm quyền điều khiển.

44. Cây chỉ số đo lường và cam kết chất lượng dịch vụ (SLO) cần kết nối chặt chẽ các chỉ số tầng giao thức với kết quả thực tế của người dùng. Các chỉ số về tính sẵn sàng, độ trễ và tỷ lệ lỗi phải được phân tích chi tiết theo tổ hợp phiên bản giao thức, phương thức và công cụ; theo dõi tỷ lệ yêu cầu không được hỗ trợ hoặc bị hạ cấp; sự sai lệch tiêu đề; tỷ lệ trúng, cũ hoặc vô hiệu hóa của bộ nhớ đệm; các thử thách trong khâu khám phá phân quyền, mã token, máy chủ phát hành, tài nguyên và phạm vi quyền; tuổi thọ của định danh trạng thái và số lượng định danh bị bỏ rơi; số vòng trao đổi và tỷ lệ hủy lệnh trong cơ chế MRTR; các tác dụng phụ bị trùng lặp; số lần bị chính sách từ chối; cùng sự sai lệch trong việc tuân thủ chuẩn. Chỉ số nghiệp vụ cốt lõi ở cấp cơ sở phải được tính dựa trên số lượng hành động an toàn thành công, chứ không phải dựa vào tổng số lượng yêu cầu kỹ thuật gửi đi. Các quy tắc loại trừ bảo trì của cam kết SLO cần được quản lý phiên bản nghiêm ngặt; thiết lập cảnh báo dựa trên tốc độ tiêu hao ngân sách lỗi và các sự kiện nghiêm trọng đơn lẻ. Hạn mức biến thể dữ liệu và kỹ thuật băm mã hóa giúp bảo vệ an toàn cho tên khách hàng và tên công cụ. Bảng điều khiển cần ghi rõ độ tươi mới của dữ liệu, nguồn gốc thông tin và định nghĩa chỉ số. Bất kỳ lỗ hổng nào trong việc thu thập dữ liệu đo lường từ xa đều phải bị xử lý như một sự cố an ninh đối với các tuyên bố chất lượng. Việc đối chiếu so sánh trước và sau khi chuyển đổi hệ thống cần kiểm soát chặt chẽ các biến động về lưu lượng mạng, cơ cấu người dùng và các dịch vụ phụ thuộc; tài liệu đặc tả phi trạng thái không thể tự nhận toàn bộ công trạng đối với việc nâng cao tính sẵn sàng của hệ thống.

45. Đánh giá chi phí và năng lực hạ tầng cần xem xét thấu đáo cả phần tiết kiệm được lẫn phần chi phí phát sinh phụ trội. Việc loại bỏ các phiên kết nối cố định có thể giúp giảm bớt độ phức tạp trong khâu vận hành và nâng cao hiệu suất sử dụng máy chủ; song việc đính kèm siêu dữ liệu trên từng yêu cầu, kiểm tra tính hợp lệ của phân quyền, thực thi chính sách, lưu vết truy vết và vận hành bộ nhớ đệm sẽ làm tăng thêm mức tiêu thụ CPU, băng thông mạng và dung lượng lưu trữ. Cơ chế MRTR giúp giảm tải việc duy trì các kết nối dài hạn nhưng lại làm tăng số lượng các vòng trao đổi gói tin gửi nhận; trong khi danh mục công cụ có tính tất định và bộ nhớ đệm hiệu quả sẽ giúp giảm đáng kể các yêu cầu thăm dò liên tục. Doanh nghiệp cần đo lường chính xác số lượng máy chủ, tải của bộ cân bằng tải, kho lưu trữ trạng thái, số lượt gọi tới dịch vụ xác thực, bộ nhớ đệm, lưu lượng mạng đầu ra, hạ tầng quan sát hệ thống cùng nỗ lực kỹ thuật trực vận hành tính trên mỗi hành động thành công. Việc so sánh chi phí phải được thực hiện trên cùng một tiêu chuẩn về cam kết SLO, chất lượng dịch vụ và mức độ an toàn an ninh. Cần tính toán kỹ hiện tượng khởi động nguội và công suất tối thiểu khi áp dụng kiến trúc không máy chủ hoặc cơ chế tự động co giãn. Việc tối ưu hóa chi phí tuyệt đối không được phép thực hiện bằng cách kéo dài thời hạn của mã token, bộ nhớ đệm hay quyền hạn, cũng như không được cắt giảm nhật ký kiểm tra. Người phụ trách tài chính và quản trị chi phí đám mây (FinOps) phải xác nhận tổng chi phí sở hữu (TCO); các lợi ích kinh tế chỉ được chính thức ghi nhận sau khi đã quan sát dữ liệu thực tế sau chuyển đổi, chứ không thể lấy các bài viết quảng bá phát hành làm mốc đo chuẩn hiệu quả đầu tư (ROI).

46. Nhịp độ quản trị định kỳ là chìa khóa bảo đảm tính tương thích lâu dài của hệ thống sau khi dự án chuyển đổi kết thúc. Hàng ngày, đội ngũ kỹ thuật theo dõi các sự kiện an ninh trọng yếu về phân quyền, tiêu đề, bộ nhớ đệm, tác dụng phụ và tính sẵn sàng của hệ thống; hàng tuần, rà soát tỷ lệ phân bổ các phiên bản giao thức, các trường hợp ngoại lệ duy trì hệ thống cũ, các định danh trạng thái bị bỏ rơi và các lỗi thất bại trong kiểm thử tuân thủ chuẩn; hàng tháng, đánh giá các bộ SDK, thư viện phụ thuộc, cảnh báo bảo mật, danh mục công cụ và phạm vi quyền hạn, các thay đổi chính sách, biến động chi phí và các sự cố phát sinh; hàng quý, kiểm tra toàn diện bộ khóa bảo mật, kế hoạch khôi phục sau thảm họa, quyền truy cập, cơ chế EMA, các phần mở rộng, lộ trình ngừng hỗ trợ và lợi ích kinh doanh thực tế. Hội đồng tư vấn thay đổi cần đánh giá mọi thay đổi trọng yếu liên quan tới gói tin đường truyền, cơ chế phân quyền hoặc phần mở rộng; các thay đổi khẩn cấp phải có buổi họp rút kinh nghiệm ngay sau đó. Các bên chịu trách nhiệm bao gồm đội ngũ nền tảng, quản lý định danh và an ninh (IAM/Security), người phụ trách công cụ và dữ liệu, kỹ sư SRE, bộ phận pháp chế và bảo vệ quyền riêng tư cùng đại diện rủi ro nghiệp vụ. Mọi quyết định và bằng chứng lưu trữ đều phải có thời hạn hiệu lực rõ ràng. Việc theo dõi các cập nhật của tài liệu tiêu chuẩn không được tự ý kích hoạt việc nâng cấp hệ thống. Bất kỳ tình huống sử dụng, công cụ hay máy chủ nào không còn mục đích kinh doanh chính đáng, thiếu sự hỗ trợ kỹ thuật hoặc không còn các biện pháp kiểm soát đầy đủ đều phải được chủ động cho ngừng hoạt động.

47. Ranh giới của bản triển khai tham chiếu mẫu cần được xác định rõ ràng để ngăn chặn thói quen sao chép mã nguồn thử nghiệm vào môi trường vận hành chính thức. Chẳng hạn, các công cụ kiểm tra (Inspector), máy chủ mẫu hay các bài hướng dẫn mẫu của bộ SDK chỉ nhằm mục đích chứng minh giao diện lập trình và luồng hoạt động cơ bản, chứ không mặc định đáp ứng các tiêu chuẩn khắt khe về kiến trúc đa khách hàng, tính sẵn sàng cao, quản lý khóa bảo mật, bảo vệ quyền riêng tư, giới hạn tần suất gọi, nhật ký kiểm tra, dịch vụ hỗ trợ hay tuân thủ pháp lý. Đội ngũ kỹ thuật cần lập bảng phân tích khoảng cách chi tiết giữa bản tham chiếu mẫu với các yêu cầu vận hành thực tế của doanh nghiệp; mỗi khoảng cách phải có người chịu trách nhiệm, biện pháp kiểm soát cụ thể, phương pháp kiểm thử và thời hạn hoàn thành rõ ràng. Các thông tin xác thực dùng thử nghiệm, cấu hình chia sẻ tài nguyên nguồn gốc chéo (CORS) quá dễ dãi, liên kết chuyển hướng về máy cục bộ localhost, nhật ký gỡ lỗi chi tiết, lưu trạng thái trong bộ nhớ tạm thời và các phạm vi quyền hạn quá rộng phải bị phát hiện và ngăn chặn tự động thông qua công cụ quét mã tích hợp liên tục và quét tệp cấu hình. Toàn bộ mã nguồn phải được mô hình hóa mối đe dọa, cố định các thư viện phụ thuộc và rà soát kỹ lưỡng như bất kỳ phần mềm thương mại nào khác. Khi mã nguồn ví dụ ở các kho lưu trữ thượng nguồn có sự thay đổi, tuyệt đối không tự động sáp nhập vào hệ thống nội bộ. Tài liệu nội bộ cần phân định rạch ròi giữa các yêu cầu quy chuẩn bắt buộc, các tiện ích hỗ trợ của bên thứ ba và các phần được tùy chỉnh riêng. Biên bản sẵn sàng vận hành chính thức chỉ được ký duyệt sau khi đã vượt qua các bài kiểm thử trên sơ đồ hạ tầng thực tế, hoàn tất diễn tập ứng phó sự cố và khôi phục hệ thống, cùng quy trình bàn giao trực ban đầy đủ; việc một đoạn mã mẫu chạy thành công hoàn toàn không phải là bằng chứng chứng minh hệ thống của doanh nghiệp đã an toàn. Mọi ngoại lệ trên môi trường vận hành chính thức bắt buộc phải có người chịu trách nhiệm rủi ro, ngày hết hạn cụ thể, biện pháp kiểm soát bù đắp và biên bản chứng nhận đóng lại sau khi đã khắc phục xong.