MCP bỏ session: bản spec 28/07/2026 biến agent nội bộ thành thứ nhân bản được — và danh sách phải sửa trước khi nâng

Ngày 28/07/2026, Model Context Protocol — lớp giao thức mà gần như mọi trợ lý AI doanh nghiệp hiện nay dùng để gọi ra công cụ và dữ liệu bên ngoài — phát hành bản spec mới, đặt tên theo đúng ngày phát hành: 2026-07-28. Điểm chính không phải một tính năng cộng thêm, mà là một thứ bị lấy đi: giao thức bỏ hẳn phiên làm việc. Không còn bắt tay initialize, không còn header Mcp-Session-Id. Với người vận hành một hệ AI nội bộ, thay đổi này giải quyết đúng nút thắt khiến MCP server trước đây rất khó nhân bản trên nhiều máy; đổi lại, đây là bản gãy tương thích, và những thứ bị gỡ thì gỡ thật. Bài này đọc thẳng ba tài liệu gốc của dự án, trích nguyên văn phần quan trọng, rồi quy về câu hỏi thực tế: nếu doanh nghiệp bạn đang chạy một MCP server sau tường lửa, bạn phải rà lại những gì. Số liệu tra cứu ngày 03/08/2026.

MCP vừa đổi cái gì?

MCP bỏ khái niệm phiên làm việc ở tầng giao thức: thay vì mở một kết nối, bắt tay để thống nhất phiên bản và năng lực, rồi giữ kết nối đó cho mọi lệnh sau, giờ mỗi yêu cầu tự mang đủ thông tin về mình và đứng độc lập.

Trong bài công bố ngày 28/07/2026, hai maintainer chính của dự án là David Soria Parra và Den Delimarsky viết thẳng ngay đoạn mở: "The highlight of this release is a stateless protocol core - MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol." Tạm dịch: điểm nhấn của bản này là một lõi giao thức phi trạng thái — MCP đang chuyển từ giao thức hai chiều có trạng thái thành giao thức request/response phi trạng thái. Họ cũng nói rõ đây là thứ được yêu cầu nhiều nhất từ phía lập trình viên, những người muốn MCP server của mình chạy ổn định và mở rộng được.

Về mặt cơ học, hai thứ bị rút đi. Thứ nhất là cặp lệnh bắt tay: "we've officially retired the initialize/initialized exchange along with the Mcp-Session-Id header". Thứ hai là chỗ chứa trạng thái đi kèm nó. Thay vào đó, mỗi yêu cầu tự khai phiên bản giao thức và năng lực của client trong trường _meta; server nào muốn cho client biết trước mình hỗ trợ những gì thì cung cấp một lệnh mới tên server/discover. Điểm đáng chú ý là lệnh này bắt buộc với server nhưng không bắt buộc với client — bản ghi thay đổi viết: "servers MUST implement this RPC to advertise their supported protocol versions, capabilities, and identity. Clients MAY call it before any other request."

Mức độ nghiêm túc của bản phát hành thể hiện ở chỗ nó được đánh dấu ổn định chứ không phải bản xem trước. Trang release trên GitHub ghi đúng một câu: "This release marks the stable release of the 2026-07-28 revision of the Model Context Protocol", với dấu thời gian 28/07/2026 lúc 16:47 UTC. Quy mô hệ sinh thái phía sau con số này cũng không nhỏ: theo bài công bố, "Across our Tier 1 SDKs, we're seeing close to half-a-billion downloads a month, with both TypeScript and Python SDKs crossing the 1 billion total downloads threshold."

Vì sao bỏ session lại là chuyện lớn với hệ AI nội bộ

Vì phiên làm việc ở tầng giao thức chính là thứ trói một client vào đúng một tiến trình server, và khi đã bị trói như vậy thì mọi cách nhân bản để chịu tải hay để không chết khi một máy hỏng đều trở nên đắt đỏ.

Hãy hình dung một trợ lý nội bộ đang chạy trong doanh nghiệp: nó nối tới một MCP server để tra cứu tài liệu, một MCP server khác để truy vấn hệ thống bán hàng. Với mô hình có phiên, muốn chạy hai bản sao của cùng một MCP server cho an toàn, đội vận hành phải làm một trong hai việc: cấu hình bộ cân bằng tải "dính" để mọi yêu cầu của một client luôn về đúng máy cũ, hoặc dựng một kho lưu trạng thái dùng chung ở giữa. Cả hai đều thêm thành phần, thêm chỗ hỏng, thêm việc phải giám sát. Bản spec mới xóa yêu cầu đó bằng một câu: "Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage."

Điều dễ hiểu lầm ở đây, và tài liệu chủ động đính chính, là "phi trạng thái" không có nghĩa ứng dụng của bạn không được nhớ gì. Nhóm maintainer viết: "Dropping the protocol-level session doesn't force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument." Nghĩa là trạng thái vẫn tồn tại, chỉ chuyển từ chỗ ẩn trong tầng vận chuyển ra chỗ hiện: server phát ra một mã tham chiếu, mô hình cầm mã đó truyền qua lại giữa các lệnh. Lý do họ đưa ra rất thực dụng — cách này chạy tốt hơn vì bản thân mô hình nhìn thấy được cái mã đó.

Đi kèm là một thay đổi nhỏ nhưng có sức nặng với đội hạ tầng: tên phương thức và tên công cụ được đẩy lên header HTTP. Bài công bố viết: "Streamable HTTP requests now must include Mcp-Method and Mcp-Name (SEP-2243). Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies." Với một tổ chức đã có sẵn cổng API và tường lửa ứng dụng, điều này có nghĩa: từ nay có thể đặt quy tắc chặn hoặc giới hạn tần suất cho từng công cụ MCP cụ thể ngay tại lớp mạng, mà không phải mở gói tin JSON ra đọc. Đó là loại kiểm soát mà đội an ninh thông tin thường đòi hỏi trước khi cho một trợ lý AI đụng vào hệ thống nội bộ — chúng tôi đã mô tả kiến trúc lớp bảo vệ này trong bài hệ thống bảo mật cho AI nội bộ.

Bản này gãy tương thích, và gãy theo cách đoán trước được

Một client viết theo bản mới nói chuyện với một server còn ở bản cũ sẽ hỏng, và ngược lại cũng hỏng — spec không giấu điều đó mà công bố sẵn bảng liệt kê đủ năm tổ hợp cùng kết quả của từng tổ hợp.

Đây là chi tiết đáng khen về mặt kỹ thuật viết chuẩn: thay vì để mỗi đội tự đoán, trang quy tắc phiên bản và tương thích đưa ra một ma trận nêu rõ hành vi mong đợi của mọi cặp client–server. Spec gọi bên viết theo lối cũ là "legacy", bên viết theo lối mới là "modern", và bên hỗ trợ cả hai là "dual-era". Đoạn cốt lõi: "A server that wishes to support both legacy clients (which expect an initialize handshake) and modern clients (which use per-request metadata) MAY implement both behaviors."

Ô đáng lo nhất là ô thứ hai. Khi một client mới gọi vào một server cũ, spec thừa nhận server có thể "stay silent, or even process an era-ambiguous method under legacy semantics" — im lặng, hoặc tệ hơn, vẫn xử lý một phương thức mơ hồ theo ngữ nghĩa cũ. Trong một hệ thống nội bộ nơi MCP server có quyền chạm vào dữ liệu thật, một lệnh được xử lý theo ngữ nghĩa sai mà không báo lỗi là kiểu sự cố khó truy nhất. Vì vậy trình tự nâng cấp an toàn là nâng server trước, hoặc để server chạy chế độ hỗ trợ cả hai, chứ không nâng client trước.

Bản này cũng gỡ vài thứ mà nhiều đội đang dùng mà không để ý: ping, logging/setLevel và notifications/roots/list_changed đều bị xóa khỏi giao thức. Mức nhật ký giờ đặt theo từng yêu cầu qua trường io.modelcontextprotocol/logLevel trong _meta, và bản ghi thay đổi nói rõ: "servers MUST NOT emit notifications/message for requests that did not include this field". Một chi tiết nhỏ nữa dễ làm hỏng phần xử lý lỗi viết tay: mã lỗi khi không tìm thấy tài nguyên đổi từ -32002 sang -32602 cho khớp chuẩn JSON-RPC.

Phần siết bảo mật: một lỗ hổng OAuth kinh điển được bịt

Bản này bắt máy chủ ủy quyền trả về định danh của chính nó trong phản hồi, và bắt client kiểm định danh đó trước khi đổi mã lấy token — đúng biện pháp mà IETF đã chuẩn hóa từ 2022 để chặn một họ tấn công có tên riêng.

Nhóm maintainer thừa nhận đây là chỗ tốn thời gian nhất của người triển khai. Thay đổi cụ thể: "Authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code (SEP-2468). This closes an authorization-server mix-up hole." Đọc RFC 9207 của IETF, ban hành tháng 3/2022, sẽ thấy vì sao đây không phải chi tiết vặt: tài liệu định nghĩa tham số iss để "explicitly include the issuer identifier of the authorization server in the authorization response", và kết luận thẳng rằng "The iss parameter serves as an effective countermeasure to 'mix-up attacks'". Tấn công dạng này lợi dụng việc client không phân biệt được mã ủy quyền vừa nhận là do máy chủ nào cấp — trong môi trường doanh nghiệp có nhiều nhà cung cấp danh tính cùng lúc, đó là kịch bản có thật.

Hai siết chặt còn lại đi cùng hướng. Một là ràng buộc thông tin đăng nhập vào đúng nơi cấp: "Client credentials are bound to the issuer that minted them. No reuse across authorization servers (SEP-2352)." Hai là khai tử dần cơ chế đăng ký client động: "Dynamic Client Registration itself is now formally deprecated in favor of CIMD. DCR continues to work for backward compatibility, but will be removed in a future version of the MCP spec." Với một tổ chức đã dựng phân quyền theo phòng ban quanh trợ lý nội bộ — mô hình chúng tôi mô tả trong bài phân quyền AI theo phòng ban — thì đây là tin tốt: giao thức đang đi từ chỗ "ai đăng ký cũng được" sang chỗ "danh tính phải khai báo trước và kiểm chứng được".

Thay đổi mà đội vận hành sẽ cảm ơn nhất lại nằm ở phần quản trị dự án chứ không phải phần kỹ thuật. Bản ghi thay đổi ghi: "Adopt a specification feature lifecycle and deprecation policy defining the Active, Deprecated, and Removed feature states, a minimum twelve-month deprecation window, and a registry of deprecated features (SEP-2596)." Trước đây, một tính năng có thể biến mất giữa hai bản mà không ai kịp chuẩn bị. Từ nay, mọi thứ vào trạng thái Deprecated đều có tối thiểu một năm để chuyển đổi, và có một sổ đăng ký để tra. Bài công bố diễn đạt gọn hơn: "so you can plan upgrades instead of reacting to them" — để bạn lên kế hoạch nâng cấp thay vì phản ứng với nó.

Cùng tuần đó: 22 lỗ hổng liên quan MCP được công bố

Trong đúng mười ngày quanh mốc phát hành, cơ sở dữ liệu lỗ hổng quốc gia của Hoa Kỳ công bố 22 lỗ hổng có liên quan tới MCP — và mẫu lỗi lặp lại nhiều nhất chính là thứ mà bản spec mới vừa xóa khỏi giao thức: định danh phiên không được ràng buộc vào chủ phiên.

Con số này tra được trực tiếp chứ không phải ước lượng. Truy vấn công khai trên API của National Vulnerability Database với từ khóa MCP, giới hạn ngày công bố từ 25/07/2026 đến 03/08/2026, trả về totalResults: 22 tại thời điểm tra ngày 03/08/2026. Cần nói ngay cho sòng phẳng: đây là lỗ hổng trong các sản phẩm triển khai MCP, không phải lỗ hổng của bản đặc tả. Và cũng vì vậy, việc spec bỏ phiên ở tầng giao thức không tự động vá cái nào trong số 22 lỗ hổng đó — sản phẩm vẫn phải tự sửa.

Điều đáng đọc là mẫu lỗi. Ba trong số đó mô tả gần như cùng một sai lầm ở ba dự án khác nhau. Bản ghi NVD của CVE-2026-67431, lỗi trong SDK Ruby chính thức của MCP, viết: transport streamable HTTP "does not bind a session ID to a session owner, allowing an attacker with a stolen session ID to send tools/call requests that execute in the victim's session" — không ràng định danh phiên vào chủ phiên, nên kẻ trộm được định danh phiên có thể gọi công cụ chạy trong phiên của nạn nhân. Với terraform-mcp-server của HashiCorp, hệ quả cụ thể hơn: người lấy được định danh phiên của người khác có thể khiến lệnh của mình "executed using that user's Terraform credentials" — chạy bằng chính thông tin đăng nhập hạ tầng của nạn nhân. Và ArcadeDB, công bố ngày 02/08, "fail to bind the authenticated principal in the MCP HTTP transport, causing all engine permission checks to silently pass as no-ops" — mọi lớp kiểm quyền của engine âm thầm trở thành vô hiệu.

Nhóm lỗi thứ hai thì cơ bản hơn nữa: endpoint MCP mở ra mà không kiểm quyền. Nặng nhất trong cả nhóm là CVE-2026-66012 với điểm CVSS tuyệt đối 10,0, trong phần mềm ghi chú SiYuan: endpoint POST /mcp chỉ qua một lớp kiểm xác thực chung, không phân biệt vai trò quản trị hay chỉ-đọc, và theo mô tả của NVD nó "exposes 31 MCP tools, including a file tool with list/read/write/delete/rename/copy actions across the entire workspace" — phơi ra 31 công cụ, trong đó có công cụ tệp với đủ quyền liệt kê, đọc, ghi, xóa, đổi tên, sao chép trên toàn bộ không gian làm việc. Cùng nhóm này còn có một lỗi khiến MCP server chính thức của GitHub sập chỉ bằng một yêu cầu thiếu trường, mà theo NVD, "the crash occurs before any authentication or token validation" — sập trước cả khâu xác thực.

Đọc bảng này cạnh bản spec mới sẽ thấy một trùng khớp không ngẫu nhiên: khi phiên làm việc là thứ do từng dự án tự cài đặt, thì từng dự án lại tự mắc cùng một lỗi. Bỏ phiên khỏi giao thức không xóa được lỗi đã có, nhưng xóa được một hạng mục mà mọi người triển khai về sau đều phải tự nghĩ ra cách làm đúng. Bài học rút ra được ngay cả trước khi nâng cấp: bất kỳ MCP server nào trong tổ chức cũng nên bị đối xử như một endpoint HTTP có đặc quyền — đặt sau xác thực, không nghe trên mọi giao diện mạng, và có nhật ký ghi lại ai gọi công cụ nào.

Doanh nghiệp Việt đang chạy MCP server nội bộ nên làm gì

Việc cần làm không phải nâng cấp ngay trong tuần, mà là lập danh mục: liệt kê những MCP server đang chạy trong tổ chức, xác định mỗi cái do ai viết và bản nào, rồi mới quyết định thứ tự nâng — server trước, client sau.

Lý do của thứ tự đó nằm ở Bảng 2: tổ hợp gãy im lặng là client mới gặp server cũ, còn tổ hợp client cũ gặp server mới thì hỏng rõ ràng bằng lỗi 400 Bad Request. Giữa hai kiểu hỏng, kiểu hỏng ồn ào luôn dễ xử lý hơn. Với các MCP server do bên thứ ba cung cấp, câu hỏi phải đặt ra với nhà cung cấp rất cụ thể: có hỗ trợ 2026-07-28 chưa, có chạy chế độ dual-era không, và lộ trình gỡ HTTP+SSE cũ là bao giờ.

Mặt lợi thì rõ và đáng để lên lịch. Một MCP server phi trạng thái chạy được nhiều bản sao sau một bộ cân bằng tải thông thường nghĩa là hệ trợ lý nội bộ không còn điểm chết đơn lẻ, và có thể mở rộng bằng cách thêm máy thay vì thay máy to hơn. Đây là mảnh ghép còn thiếu trong bài toán chúng tôi mô tả ở sơ đồ hệ thống AI nội bộ và ở phần vận hành mô hình trong bài tự xây AI nội bộ: serving. Còn việc nối MCP vào các hệ thống sẵn có của doanh nghiệp thì chúng tôi đã bóc trong bài tự xây AI nội bộ: tích hợp.

Còn một lý do nữa để rà, và lý do này thuộc về pháp lý chứ không thuộc về kỹ thuật. MCP server là chỗ trợ lý AI chạm vào dữ liệu thật của tổ chức, thường bao gồm dữ liệu cá nhân của nhân viên và khách hàng. Theo Cổng thông tin Bộ Công an: "Ngày 01/01/2026, Luật Bảo vệ dữ liệu cá nhân (Luật số 91/2025/QH15) chính thức có hiệu lực thi hành. Trong đó, đã xác lập rõ các quyền dữ liệu cơ bản của công dân, bao gồm quyền được biết, quyền đồng ý, quyền truy cập, chỉnh sửa và yêu cầu xóa dữ liệu." Cùng trang cũng nêu chế tài: "Mức phạt tiền tối đa trong xử phạt vi phạm hành chính đối với hành vi mua, bán dữ liệu cá nhân là 10 lần khoản thu có được từ hành vi vi phạm." Muốn đáp ứng những quyền đó, tổ chức phải trả lời được ai đã truy cập dữ liệu gì, lúc nào, qua công cụ nào. Việc tên công cụ nay nằm ở header và có thể ghi nhận ngay tại cổng API khiến câu trả lời đó dễ dựng hơn hẳn so với việc đi bóc gói tin JSON trong nhật ký. Khung pháp lý cho phần AI thì chúng tôi đã phân tích riêng trong bài Nghị định 142/2026 về AI.

Cũng nên giữ đúng liều: đây là bản spec của một giao thức, không phải bản vá khẩn cấp, và chính sách 12 tháng tồn tại đúng để cho các tổ chức thời gian. Nhưng có một việc nên làm ngay và gần như không tốn gì: mở danh mục MCP server nội bộ ra, xem có cái nào còn chạy tầng vận chuyển HTTP+SSE cũ — thứ đã bị coi là lỗi thời từ tháng 3/2025 và nay chính thức bước vào đồng hồ đếm ngược một năm.

Bản spec MCP ngày 28/07/2026 lấy đi phiên làm việc ở tầng giao thức, và chính việc lấy đi đó mới là thứ cho phép một MCP server nội bộ chạy nhiều bản sao sau một bộ cân bằng tải thông thường — đổi lại, mọi hệ thống đang dựa vào phiên phải được rà lại trước khi nâng.

Câu hỏi thường gặp

Lưu ý: Bài viết tổng hợp từ nguồn công khai, tra cứu ngày 03/08/2026. Các đoạn trong ngoặc kép là trích nguyên văn tiếng Anh từ tài liệu chính thức của dự án Model Context Protocol, từ RFC 9207 của IETF và từ Cổng thông tin Bộ Công an; phần dịch là của Namtech. Số liệu lỗ hổng lấy từ National Vulnerability Database (NIST), tra ngày 03/08/2026. Bảng 5 là khuyến nghị của Namtech, không phải nội dung trong tài liệu MCP. Ảnh minh họa lấy từ Pexels theo Pexels License — ảnh đầu bài và ảnh chia sẻ: panumas nikhomkhai. Thông tin tham khảo, không phải tư vấn pháp lý.