Uỷ nhiệm có thể kiểm chứng cho tác nhân: từ định danh kỹ thuật đến thẩm quyền được uỷ quyền

Cách đọc bản tóm lược này

Ba loại nhận định được tách bạch, và mỗi đoạn đều mang một nhãn:

• Nêu trong các bản thảo điều mà các bản thảo Internet quy định hoặc nêu, được diễn đạt sát nghĩa, kèm các trích dẫn ngắn;
• Phân tích của Viện cách Viện đọc những gì các bản thảo giải quyết và những gì còn để ngỏ;
• Câu hỏi giáo dục — ARENOMICS Institute các câu hỏi và quan điểm mà Viện đang phát triển để giảng dạy Mandate Engineering.

Bản tóm lược này tiếp nối mục 3 trong phân tích The 10,000-Agent Problem của Viện (12 tháng 10 năm 2026), vốn nhận thấy công việc tiêu chuẩn hoá về định danh tác nhân đang hội tụ trong khi công việc về uỷ nhiệm thì chưa. Tình trạng của các tài liệu được kiểm tra trên IETF Datatracker ngày 26 tháng 10 năm 2026.

A. Hai bản thảo, hai câu hỏi khác nhau

Tình trạng tài liệu theo IETF Datatracker, ngày 26 tháng 10 năm 2026

Nêu trong các bản thảo AIMS mở đầu: “Tài liệu này đề xuất các thực hành tốt nhất cho việc xác thực và cấp phép trong tương tác của tác nhân AI.” Bản thảo về uỷ nhiệm chỉ ra một khoảng trống hẹp hơn: “Điều chưa được định nghĩa là bằng chứng rằng bên ở gốc của một uỷ nhiệm có quyền trao uỷ nhiệm đó.”

Phân tích của Viện Hai tài liệu trả lời những câu hỏi khác nhau. AIMS mô tả cách một tác nhân chứng minh nó là ai và được cấp quyền truy cập trong hạ tầng định danh hiện nay; bản thảo về uỷ nhiệm hỏi làm thế nào một bên xa lạ ở tổ chức khác có thể kiểm tra rằng tác nhân đã được trao quyền mà nó tuyên bố, bởi một người có quyền trao. Chính bản thảo về uỷ nhiệm mô tả quan hệ của nó với AIMS là bổ sung cho nhau. Không tài liệu nào là tiêu chuẩn, và bản thảo về uỷ nhiệm là một trong mười tám bản thảo cá nhân mà Datatracker hiện liệt kê là liên quan đến WIMSE, nhiều bản trong đó bàn về chuỗi uỷ quyền và bằng chứng cấp phép.

B. Định danh tác nhân và xác thực workload

Nêu trong các bản thảo AIMS coi tác nhân là workload (khối lượng công việc chạy trên hệ thống). “Một tác nhân tham gia khung này PHẢI được gán đúng một định danh WIMSE, định danh này CÓ THỂ là một SPIFFE ID”; thông tin xác thực của tác nhân nên có thời hạn ngắn và phải ghi rõ thời điểm hết hạn, và tác nhân xác thực bằng mutual TLS, WIMSE Workload Proof Token hoặc HTTP Message Signatures. “Khoá API tĩnh là một phản mẫu đối với định danh tác nhân.” Bản thân mô hình ngôn ngữ “KHÔNG ĐƯỢC có quyền truy cập vào thông tin xác thực của tác nhân”.

Nêu trong các bản thảo Bản thảo về uỷ nhiệm nêu định danh như vậy chứng minh điều gì: một Workload Identity Token do bên vận hành cấp khẳng định một định danh phiên bản gắn với một khoá, và không nói gì về mô hình, cấu hình hay hành vi của nó.

Phân tích của Viện Định danh trả lời hai câu hỏi: đây là workload nào đang chạy, và nó có chứng minh được không? Nó không cho biết ai đã cho phép workload đó hành động, thay cho ai, hay trong những giới hạn nào. Các bản thảo phù hợp với bức tranh trong phân tích về 10.000 tác nhân: định danh là tầng mà công việc tiêu chuẩn hoá đang hội tụ.

C. Cấp phép và thẩm quyền của tổ chức

Nêu trong các bản thảo Về cấp phép, AIMS dựa vào OAuth 2.0 làm khung uỷ quyền. Trong một access token, tác nhân xuất hiện như client và người dùng hoặc hệ thống mà nó hành động thay cho xuất hiện như chủ thể. Người dùng uỷ quyền qua luồng authorisation code; tác nhân hành động nhân danh chính mình dùng client credentials hoặc một JWT grant. Token có thể được đổi lấy transaction token ngắn hạn gắn với một giao dịch, và việc chuyển tiếp token của tác nhân cho các dịch vụ phía sau bị coi là phản mẫu. Bản thân transaction token, chuỗi định danh và JWT grant dựa trên khẳng định định danh được định nghĩa trong những bản thảo Internet vẫn đang soạn thảo. Khi một người phải xác nhận một hành động, tác nhân “KHÔNG ĐƯỢC coi việc xác nhận trên giao diện cục bộ là đủ để cấp phép”.

Phân tích của Viện Một OAuth grant ghi nhận rằng một người dùng hoặc hệ thống đã đồng ý cho một client truy cập trong những phạm vi nhất định. Nó không ghi nhận người đó có quyền, trong nội bộ tổ chức của mình, để trao quyền lực ấy hay không — chẳng hạn nhân viên đã kết nối tác nhân ngân quỹ với tài khoản ngân hàng của công ty có thẩm quyền ràng buộc công ty vào các khoản thanh toán hay không. Cấp phép kỹ thuật và thẩm quyền của tổ chức là hai quan hệ khác nhau: cái thứ nhất có thể hoàn hảo trong khi cái thứ hai không tồn tại.

D. Uỷ nhiệm, khẳng định thẩm quyền và kiểm chứng

Nêu trong các bản thảo Bản thảo về uỷ nhiệm tách bạch những vai trò thường bị gộp làm một: bên uỷ nhiệm (principal), nhân danh người đó tác nhân hành động; người trao uỷ nhiệm (delegator), người trao uỷ nhiệm gốc — chính bên uỷ nhiệm hoặc người được phép hành động thay; nguồn xác nhận thẩm quyền (authority source), khẳng định rằng người trao uỷ nhiệm có thẩm quyền đó; bên phát hành uỷ nhiệm, ký uỷ nhiệm theo chỉ thị của người trao uỷ nhiệm; phiên bản tác nhân; và bên dựa vào ở miền kia. Các ví dụ của bản thảo là tác nhân ngân quỹ của một công ty khởi tạo khoản thanh toán tại ngân hàng của công ty, và tác nhân của một công ty môi giới gửi chỉ thị tới một tổ chức lưu ký.

Nêu trong các bản thảo Sau đó bản thảo giữ hai tuyên bố có chữ ký tách biệt. Mandate Assertion (khẳng định uỷ nhiệm) nói rằng một uỷ nhiệm đã được trao; Authority Assertion (khẳng định thẩm quyền), do một nguồn xác nhận thẩm quyền như sổ đăng ký người đại diện theo pháp luật phát hành, nói rằng người trao uỷ nhiệm có quyền trao nó. Bản thảo nêu rằng “riêng một Mandate Assertion không bao giờ xác lập thẩm quyền của người trao uỷ nhiệm.” Bản thảo không quy định nguồn xác nhận thẩm quyền nào được chấp nhận; với Liên minh châu Âu, bản thảo lưu ý rằng các khẳng định có thể được rút ra từ chứng thực điện tử về thuộc tính theo Quy định (EU) 2024/1183.

Nêu trong các bản thảo Việc kiểm chứng gồm mười ba bước theo thứ tự, từ cấu trúc chuỗi, chữ ký, thời gian và tình trạng thu hồi đến thẩm quyền của người trao uỷ nhiệm, ràng buộc khoá, đối tượng nhận và sự khớp giữa hành động được yêu cầu với uỷ nhiệm. Bên kiểm chứng thực hiện mọi bước có thể và ghi lại mọi lỗi thay vì dừng ở lỗi đầu tiên, và “Hai bên kiểm chứng tuân thủ, với đầu vào giống hệt nhau, PHẢI cho ra kết quả kiểm chứng giống hệt nhau.” Kết quả là hợp lệ, không hợp lệ hoặc — khi chỉ riêng tình trạng thu hồi không lấy được — chưa xác định.

Phân tích của Viện Đề xuất này đi thẳng vào câu hỏi mà Mandate Engineering bắt đầu: không chỉ tác nhân được làm gì, mà người nói điều đó có tư cách để nói hay không. Đóng góp của bản thảo là làm cho câu hỏi thứ hai có thể được kiểm tra bởi một bên không tin tưởng tổ chức thứ nhất. Sự phụ thuộc của nó cũng rõ ràng như vậy: phép kiểm tra chỉ tốt bằng nguồn xác nhận thẩm quyền và khung tin cậy quyết định nguồn nào được tính, và bản thảo cố ý không định nghĩa cả hai.

E. Chuỗi uỷ quyền và thu hẹp quyền

Nêu trong các bản thảo Trong bản thảo về uỷ nhiệm, một tác nhân chỉ được uỷ quyền tiếp khi độ sâu tối đa còn cho phép. Mỗi uỷ nhiệm con phải hết hạn không muộn hơn uỷ nhiệm cha và phải được thu hẹp (attenuation): mọi yêu cầu khớp với uỷ nhiệm con cũng phải khớp với uỷ nhiệm cha. Ngân sách tích luỹ đi cùng chuỗi, nên các hành động của tác nhân con được tính vào cùng một giới hạn. Bản thảo cũng nêu giới hạn của riêng việc thu hẹp: “Một chuỗi chỉ thu hẹp thì chứng minh rằng không bước nào vượt quá bước cha của nó” — chứ không chứng minh rằng uỷ nhiệm gốc nằm trong thẩm quyền của chính người trao uỷ nhiệm.

Nêu trong các bản thảo AIMS không định nghĩa một mô hình chung cho chuỗi uỷ quyền nhiều tác nhân. Nó bao quát việc truy cập xuyên miền tin cậy thông qua trao đổi token và chuỗi định danh, yêu cầu tác nhân chỉ xin những phạm vi tối thiểu cần thiết, và thu hẹp quyền truy cập bằng transaction token gắn với một giao dịch duy nhất.

Phân tích của Viện Thu hẹp quyền là điều kiện cần cho một chuỗi chính đáng nhưng chưa đủ. Một chuỗi có thể thu hẹp đúng ở mọi bước từ một gốc vốn không có thẩm quyền để khởi đầu nó. Bản thảo cung cấp từ vựng kỹ thuật chính xác cho một điểm mà chương trình Foundation nêu bằng ngôn ngữ tổ chức: uỷ quyền có thể chuyển giao ít thẩm quyền hơn người uỷ quyền đang có, không bao giờ nhiều hơn, và mắt xích đầu tiên tự nó phải được chứng minh là chính đáng.

F. Thu hồi, hết hạn, giới hạn thực thi và bằng chứng kiểm toán

Nêu trong các bản thảo Bản thảo về uỷ nhiệm biểu đạt giới hạn bằng các vị từ có thể kiểm tra bằng máy — bằng, thuộc tập hợp, tối đa, tối thiểu và khung thời gian — cùng hai vị từ có trạng thái: ngân sách tích luỹ theo chu kỳ trượt và yêu cầu đồng ký khi vượt một ngưỡng. Số tiền được ghi dưới dạng chuỗi thập phân: “KHÔNG ĐƯỢC dùng số JSON cho số tiền.” Mỗi token chỉ cho phép thực thi hành động một lần; thời hạn của nó bị giới hạn bởi thời điểm hết hạn sớm nhất trong chuỗi; tình trạng thu hồi được kiểm tra khi kiểm chứng và một lần nữa khi cấp phép. Về độ trễ, bản thảo nêu rằng việc thu hồi sau khi phát hành “có hiệu lực muộn nhất là khi token hết hạn”. Bên dựa vào nên lưu giữ kết quả kiểm chứng, quyết định và xác nhận thực thi, và hồ sơ lưu cho tranh chấp có thể cần còn kiểm chứng được trong nhiều năm.

Nêu trong các bản thảo AIMS yêu cầu nhật ký kiểm toán bền vững về các quyết định cấp phép và biện pháp khắc phục, ghi lại, cùng những thông tin khác, định danh tác nhân, chủ thể được uỷ quyền, tài nguyên, hành động và quyết định: “Bản ghi kiểm toán PHẢI cho phép phát hiện sửa đổi và được lưu giữ theo chính sách an ninh của hệ thống triển khai.” Tín hiệu thu hồi và rủi ro có thể được phân phối qua Shared Signals Framework, và bên nhận “PHẢI bảo đảm rằng quyền đã bị thu hồi hoặc hạ cấp được thực thi không chậm trễ quá mức.”

Phân tích của Viện Cả hai bản thảo đều cung cấp nguyên liệu cho một dấu vết bằng chứng. Không bản nào quyết định ai rà soát dấu vết đó hay điều gì được coi là tuân thủ: AIMS coi tiêu chí tuân thủ là riêng của từng hệ thống triển khai, còn bản thảo về uỷ nhiệm để việc lưu giữ, trách nhiệm pháp lý và giải quyết tranh chấp cho các khung tin cậy. Một ngân sách tích luỹ dùng chung cho nhiều bên dựa vào được chính bản thảo liệt kê là vấn đề còn mở, nên một giới hạn trông như toàn cục trên thực tế có thể chỉ được từng bên dựa vào thực thi riêng rẽ.

G. Tầng còn bỏ ngỏ: từ ý định của tổ chức đến quyền có thể thực thi

Nêu trong các bản thảo AIMS lưu ý rằng tác nhân thường nhận nhiệm vụ của mình bằng ngôn ngữ tự nhiên và rằng “Việc chuyển một nhiệm vụ thành các yêu cầu cấp phép được kỳ vọng diễn ra như một bước lập kế hoạch trước khi tác nhân yêu cầu cấp phép.” AIMS đặt chính quy trình chuyển đổi ấy ra ngoài phạm vi, cũng như mô hình chính sách và định dạng của nó.

Nêu trong các bản thảo Bản thảo về uỷ nhiệm không “định nghĩa một khung tin cậy, các mức bảo đảm, hay hiệu lực pháp lý của một uỷ nhiệm”, cũng không định nghĩa cách người trao uỷ nhiệm được trình bày hay đồng ý với một uỷ nhiệm, hay suy luận và đầu ra của tác nhân có đúng không. “Định dạng có thể biểu đạt uỷ nhiệm hẹp nhưng không thể buộc bên phát hành viết ra chúng.” Và về thao túng: “Một uỷ nhiệm hợp lệ cho thấy một hành động nằm trong thẩm quyền được uỷ quyền, chứ không cho thấy tác nhân đã không bị thao túng để yêu cầu hành động đó.”

Phân tích của Viện Các bản thảo làm cho kết quả của việc chuyển đổi có thể kiểm chứng; chúng không thực hiện cũng không kiểm tra chính việc chuyển đổi. Một uỷ nhiệm như “thanh toán cho các nhà cung cấp đã được duyệt trong phạm vi ngân sách hằng tháng” có phản ánh đúng ý của hội đồng quản trị hay không, các giới hạn có đúng không, và ai chịu trách nhiệm khi một uỷ nhiệm hợp lệ dẫn đến một hành động gây hại vẫn là những câu hỏi của tổ chức và pháp luật. Đây là tầng mà phân tích về 10.000 tác nhân gọi là chưa được xử lý. Sau các bản thảo này nó vẫn chưa được xử lý, nhưng nay có một ranh giới kỹ thuật sắc nét hơn ở một phía.

H. Các bản thảo giải quyết được gì cho Mandate Engineering — và để ngỏ điều gì

Phân tích của Viện Điểm mạnh: bản thảo về uỷ nhiệm tách việc trao uỷ nhiệm khỏi thẩm quyền đứng sau nó, định nghĩa phép kiểm chứng tất định, làm cho mọi token chỉ dùng một lần và đối xử trung thực với nguy cơ thao túng. AIMS xây dựng một nền tảng định danh và truy cập nhất quán từ các tiêu chuẩn đã công bố và từ những bản thảo khác mà bản thân chúng vẫn đang được soạn thảo. Giới hạn: bản thảo về uỷ nhiệm là bản thảo cá nhân của một tác giả, chưa được chấp nhận, chưa có báo cáo triển khai hay vector kiểm thử đã công bố; nó trùng lặp với các bản thảo cá nhân khác về chuỗi uỷ quyền và tự nói rằng định dạng chuỗi của nó có thể được thay thế; cả hai bản thảo đều có thể thay đổi đáng kể.

Câu hỏi giáo dục — ARENOMICS Institute Viện đọc các tài liệu này như bằng chứng cho thấy câu hỏi về uỷ nhiệm đã đi vào thảo luận tiêu chuẩn kỹ thuật, chứ không phải như các tiêu chuẩn để giảng dạy. Trong chương trình Foundation, chúng có thể được dùng làm ví dụ minh hoạ cho cách một uỷ nhiệm có giới hạn, có thể thu hồi được biểu đạt và kiểm tra. Chương trình không yêu cầu học viên sử dụng chúng, và đặc tả chương trình không thay đổi.

Các câu hỏi nghiên cứu mở

1. Ai nên được chấp nhận là nguồn xác nhận thẩm quyền cho các sự uỷ quyền của một tổ chức, và chính việc chấp nhận ấy được quản trị ra sao?
2. Làm thế nào để chứng minh rằng một uỷ nhiệm được viết dưới dạng giới hạn có thể kiểm tra bằng máy khớp với ý định của tổ chức mà nó nhằm biểu đạt?
3. Giới hạn và việc thu hồi nên vận hành thế nào khi nhiều bên dựa vào cùng lúc căn cứ vào một uỷ nhiệm?

Nguồn

1. C. Hulea (Braincap SRL), Verifiable Mandates for Agents Acting Across Administrative Domains, draft-hulea-wimse-agent-mandate-00, bản thảo Internet cá nhân, 24 tháng 10 năm 2026, hết hạn 27 tháng 4 năm 2027. Datatracker · toàn văn.
2. P. Kasselman, J.-F. Lombardo, Y. Rosomakho, B. Campbell, N. Steele và A. Parecki, AI Identity Management System, draft-ietf-wimse-aims-00, bản thảo Internet của nhóm công tác WIMSE, 15 tháng 9 năm 2026, hết hạn 19 tháng 3 năm 2027. datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00.
3. IETF, nhóm công tác Workload Identity in Multi System Environments (WIMSE), trang tài liệu, truy cập ngày 26 tháng 10 năm 2026. datatracker.ietf.org/group/wimse/documents.
4. ARENOMICS Institute, The 10,000-Agent Problem: Who Has the Authority to Let Machines Act?, v0.1, 12 tháng 10 năm 2026.

Kiểm chứng: tiêu đề, tác giả, ngày tháng, tình trạng và mọi trích dẫn đã được đối chiếu với các tài liệu và Datatracker ngày 26 tháng 10 năm 2026; các trích dẫn được dịch từ nguyên bản tiếng Anh. Bản thảo Internet thay đổi thường xuyên; hãy kiểm tra phiên bản hiện hành trên Datatracker trước khi dựa vào bất kỳ chi tiết nào.