JSON schema không phải là tầng quản trị AI

Ngày 28/10/2026 Lược đồ JSON (JSON schema) không phải là một tầng quản trị AI Cuộc tranh luận về quản trị AI hiện đang diễn ra ở cấp độ cao hơn một bậc so với đoạn mã thực sự có chức năng ngăn chặn tác tử (agent) hoạt động. Chỉ trong vòng hai tuần của tháng 9 vừa qua, cuộc tranh luận về chủ thể quản trị AI đã đưa ra bốn phương án khác nhau, tất cả đều đến từ những người trực tiếp phát triển các hệ thống này. Ông Demis Hassabis đề xuất thành lập một cơ quan giám sát do ngành công nghiệp tài trợ, phỏng theo mô hình Cơ quan Quản lý Ngành Tài chính (FINRA), nhằm thử nghiệm các mô hình AI tiên phong trước khi triển khai. Ông Dario Amodei kêu gọi các phòng nghiên cứu làm chậm tốc độ phát triển mô hình tiên phong và cung cấp quyền tiếp cận thực chất cho các bên đánh giá độc lập; chỉ vài ngày sau, Anthropic và Accenture đã cam kết đầu tư ít nhất 2 tỷ USD trong 5 năm cho hoạt động đánh giá tích hợp. OpenAI bắt đầu công bố các báo cáo về hành vi bất thường của mô hình. Trong khi đó, theo tờ Wall Street Journal, các ông Mark Zuckerberg, Elon Musk và Jensen Huang đều đã có cuộc trao đổi với Tổng thống Trump và thuyết phục ông bãi bỏ đề xuất về cơ quan giám sát, với lập luận rằng một cơ quan điều hành chung sẽ chỉ bảo vệ vị thế dẫn đầu của các phòng nghiên cứu lớn nhất, đồng thời khẳng định các doanh nghiệp hoàn toàn có thể tự bảo đảm an toàn cho hệ thống của mình. Dù đồng thuận với bất kỳ lập điểm nào nêu trên, không có ý kiến nào đề cập trực tiếp đến đoạn mã quyết định liệu tác tử trong ứng dụng có được phép gửi thư điện tử, đảo khóa bảo mật (rotate key), sáp nhập nhánh mã nguồn (merge branch) hay chuyển tiền hay không. Quyết định này không do các phòng nghiên cứu đưa ra, cũng không được quy định trong các chính sách; quyết định đó được thực hiện bởi một hàm trong chính mã nguồn của hệ thống, và hàm đó trả về kết quả đúng (true) hoặc sai (false). Dưới đây là một lỗi thực tế trong hàm kiểm tra nói trên, hoàn toàn không phải một thử nghiệm trên lý thuyết: một đợt kiểm thử áp lực độc lập đã phát hiện lỗi này trong PIC - một giao thức mở chuyên kiểm tra các hành động của tác tử trước khi thực thi. Lược đồ này chấp nhận mã băm SHA-256 viết hoa, môi trường thực thi tham chiếu (reference runtime) đã tự động chuẩn hóa chuỗi ký tự mà không đưa ra cảnh báo rồi tiếp tục xử lý, trong khi tài liệu đặc tả kỹ thuật chưa từng nêu rõ định dạng này có hợp lệ hay không. Không có lỗi mã hóa nào xảy ra. Vấn đề chỉ đơn giản là giao thức tồn tại nhiều hơn một cách diễn giải hợp lý - điều này khó phát hiện hơn nhiều so với việc hệ thống mã hóa bị phá vỡ; và nhiều hệ thống tác tử đang vận hành hiện nay có thể cũng đang gặp phải tình trạng tương tự. Quản trị rốt cuộc quy về một giá trị boolean (đúng/sai) Khảo sát nhanh vào tháng 4/2026 của Stack Overflow đối với 1.100 nhà phát triển và chuyên gia công nghệ cho thấy 60% trong số họ ngăn chặn tác tử thực hiện các thay đổi hệ thống chưa được phê duyệt. Đây là bước đi hợp lý, song vẫn bỏ ngỏ một vấn đề nan giải: tiêu chí nào xác định một hành động đã được phê duyệt, và liệu mọi thành phần trong quy trình xử lý có cùng đưa ra một câu trả lời thống nhất hay không? Dưới đây là trường hợp một tác tử đề xuất giao dịch thanh toán. Tác tử cung cấp công cụ muốn gọi, các dữ liệu đầu vào định hình quyết định và bằng chứng củng cố cho khẳng định rằng khoản thanh toán đã được cấp phép. { "action": {"tool": "payments.transfer", "args": {"amount": 500}}, "impact": "money", "provenance": [ {"id": "invoice", "trust": "trusted"}, {"id": "invoice", "trust": "untrusted"} ], "claims": [ {"text": "The invoice was approved", "evidence": ["invoice"]} ] } Một lược đồ JSON Schema sẽ xác nhận rằng trường nguồn gốc dữ liệu (provenance) là một mảng, mỗi mục đều mang một mã định danh cùng giá trị độ tin cậy được phép, và các trường bắt buộc đều hiện diện đầy đủ. Trừ khi giao thức bổ sung thêm quy tắc riêng, gói dữ liệu này được coi là hợp lệ. Các mã định danh không có tính duy nhất, và tham chiếu bằng chứng lúc này trỏ đến hai mục hoàn toàn khác nhau. Giả sử chính sách được đặt ra rất đơn giản: khoản thanh toán chỉ được phép thực hiện nếu bằng chứng chứng minh xuất phát từ một nguồn đáng tin cậy. (Tạm thời chấp nhận các nhãn độ tin cậy trong gói dữ liệu theo giá trị bề mặt; thẩm quyền thiết lập các nhãn này sẽ được đề cập sau). Để áp dụng chính sách đó, bộ phận xác minh phải xác định xem nhãn "invoice" đang tham chiếu đến mục nào, và hai kỹ sư cùng có chuyên môn hoàn toàn có thể đưa ra hai cách giải quyết khác nhau. # Cách triển khai A, ngôn ngữ Python: dừng lại ở kết quả trùng khớp đầu tiên def resolve(pro venance, evidence_id): for entry in provenance: if entry["id"] == evidence_id: return entry return None // Phương án triển khai B, TypeScript: lập chỉ mục theo id, ghi đè lần cuối (last write wins) const index = Object.fromEntries(provenance.map(e => [e.id, e])); const resolve = (id) => index[id]; Cả hai cách tra cứu nêu trên tự thân đều không phải là lỗi; cả hai đều là mã lệnh thông thường, đúng chuẩn, và tài liệu đặc tả kỹ thuật chưa từng quy định mục nào sẽ được ưu tiên áp dụng. Với gói dữ liệu (payload) nói trên, phương án A phân giải bằng chứng về mục đáng tin cậy và giao dịch thanh toán được thực thi, trong khi phương án B lại phân giải về mục không đáng tin cậy và giao dịch bị ngăn chặn. Cả hai trình xác minh đều vận hành trên cùng một phiên bản giao thức, cùng chính sách và cùng các khóa tin cậy; điểm khác biệt duy nhất là cách thức mỗi bên tra cứu mã định danh (id). Như vậy, cùng một chuỗi byte dữ liệu, khi kiểm tra đối chiếu với cùng một lược đồ (schema), lại cho ra hai kết quả trái ngược, và đối tượng tấn công chỉ cần nắm được dịch vụ nào đang tiếp nhận ở đầu bên kia của lệnh gọi. Lược đồ (schema) đã thực hiện đúng chức năng, song chức năng đó có giới hạn. Lược đồ kiểm tra cấu trúc của gói dữ liệu: bảo đảm các trường dữ liệu hiện diện đầy đủ, đúng định dạng và chứa các giá trị hợp lệ. Lược đồ thậm chí có thể thiết lập một số quy tắc liên kết giữa các trường, chẳng hạn như “nếu trường này xuất hiện thì trường kia là bắt buộc”. Tuy nhiên, lược đồ không thể biểu đạt quy tắc mà gói dữ liệu này đòi hỏi: mục “hóa đơn” (invoice) được dẫn chiếu làm bằng chứng trong phần xác nhận (claims) phải trỏ chính xác tới duy nhất một mục trong phần thông tin nguồn gốc (provenance). Chuẩn JSON Schema thông thường không có cơ chế quy định một giá trị ở vị trí này phải trùng khớp tuyệt đối với duy nhất một giá trị ở vị trí khác trong tài liệu; và thuộc tính uniqueItems cũng không thể giải quyết vấn đề, do hai mục có giá trị tin cậy khác nhau nên lược đồ vẫn nhận diện đó là hai mục riêng biệt. Việc thanh toán có được thông qua hay không phụ thuộc hoàn toàn vào mối liên kết này, và lược đồ lại phó mặc việc xử lý cho từng trình xác minh. Đây là hiện tượng sai lệch phân tích cú pháp (parser differential), vốn đã xuất hiện từ rất lâu trước khi có các tác tử thông minh (agents) Giới chuyên môn về an toàn thông tin đã ghi nhận hiện tượng này nhiều lần: hai thành phần đọc cùng một dữ liệu đầu vào theo hai cách thức khác nhau, và lỗ hổng bảo mật phát sinh chính từ sự sai lệch đó. Ô nhiễm tham số HTTP (HTTP parameter pollution) là một ví dụ điển hình, khi máy chủ ủy nhiệm (proxy) đọc tham số id đầu tiên còn ứng dụng lại đọc tham số cuối cùng. Tấn công bao bọc chữ ký XML (XML signature wrapping) là một trường hợp khác: trình xác minh kiểm tra chữ ký trên một phần tử, trong khi bộ phân tích cú pháp lại đọc một phần tử khác. Ngoài ra còn có lỗi nhầm lẫn thuật toán JWT (JWT alg confusion), khi chính mã chứng thực (token) tự chỉ định thuật toán kiểm tra tính hợp lệ của nó. Tương tự, với kỹ thuật buôn lậu yêu cầu HTTP (HTTP request smuggling), máy chủ proxy và máy chủ phía sau không đạt được sự thống nhất về điểm kết thúc của một yêu cầu và điểm bắt đầu của yêu cầu kế tiếp. Dạng lỗi này đã tồn tại trong khoảng 20 năm qua. Bài học rút ra tương đối rõ ràng: khi hai phương án triển khai cần phải thống nhất