Phân quyền tác tử AI: tài khoản, phạm vi và thu hồi giữa phiên

Đăng ngày 27/10/2026

Cấp quyền cho một công việc, không cho một lời hứa

Phân quyền tác tử AI cần bắt đầu từ công việc được giao: hệ thống đại diện ai, được thấy dữ liệu nào, làm hành động gì và trong bao lâu. Trợ lý đặt lịch tài nguyên nội bộ có thể cần xem khoảng trống và tạo một lượt đặt cho người yêu cầu. Nó không vì vậy cần đọc mọi nội dung cuộc họp, sửa lịch người khác hoặc quản trị toàn bộ tài nguyên. Quyền phải được hệ thống thực thi, không chỉ nằm trong lời nhắc cho mô hình.

NIST SP 800-207 mô tả việc truy cập tài nguyên với quyền tối thiểu cần cho tác vụ, đánh giá theo chính sách và không tự chuyển quyền từ tài nguyên này sang tài nguyên khác [1]. Đây là hướng dẫn kiến trúc, không phải chứng nhận một tác tử đã an toàn. Áp dụng vào thiết kế, mỗi thao tác cần nối được với danh tính đáng tin, phạm vi công việc và một quyết định cho phép có thể kiểm lại.

Bài viết đề xuất hai công cụ: phiếu ủy quyền sáu chiều để xác định quyền cần cấp, và bảng kiểm thu hồi ở bốn điểm của đường chạy. Ca đặt lịch tại Việt Nam là giả định, không mô tả hệ thống đang được triển khai. Trọng tâm là thử quyền thay đổi giữa phiên: tác tử đã đọc lịch nhưng chưa tạo lượt đặt thì bị thu hồi quyền; ứng dụng phải xử lý ra sao để không tiếp tục bằng một quyết định đã cũ.

Phân biệt người giao việc và hệ thống đang hành động

RFC 8693 phân biệt ngữ nghĩa đại diện có giữ danh tính bên hành động với ngữ nghĩa hoạt động trong một phạm vi như chính chủ thể được đại diện; chi tiết phụ thuộc chính sách và triển khai [2]. Bài này không yêu cầu mọi doanh nghiệp triển khai trao đổi token theo RFC ấy. Điểm cần giữ là biết ai yêu cầu, ứng dụng nào thực hiện và quyền nào cho phép ứng dụng hành động thay người đó trong công việc cụ thể.

Một tài khoản dịch vụ dùng cho mọi yêu cầu nhưng không ghi được người giao việc sẽ làm khó việc điều tra. Ngược lại, chỉ ghi tên người dùng do mô hình tự điền cũng chưa xác minh được danh tính. Hệ thống cần lấy danh tính từ đường xác thực đáng tin và nối với mã công việc. Trong nhật ký phù hợp, giữ được quan hệ giữa người giao, tiến trình thực hiện và đối tượng bị tác động, không nhất thiết giữ toàn bộ nội dung hội thoại.

Nên tách danh tính của tác tử khỏi vai quản trị viên cá nhân. Ứng dụng có người sở hữu, mục đích và chu kỳ rà soát quyền riêng; khi người phụ trách đổi vị trí, ứng dụng không nên tiếp tục dựa vào quyền cá nhân bỏ quên. Không giao mật khẩu của một nhân viên cho mô hình để nó dùng như chính người ấy. Cách tích hợp cụ thể cần được đội quản trị danh tính chọn và kiểm với dịch vụ đang sử dụng.

Công cụ một: phiếu ủy quyền sáu chiều

OWASP Authorization Cheat Sheet khuyến nghị quyền tối thiểu, mặc định từ chối và kiểm quyền trên mọi yêu cầu, cùng việc thử các quyền đã ánh xạ [3]. Từ đó, phiếu được đề xuất gồm chủ thể, người được đại diện, tài nguyên, hành động, thời hạn và ngân sách hoặc điều kiện chấp thuận. Đây là khung thiết kế biên tập. Phiếu không tự cấp quyền: các trường phải được chuyển thành kiểm soát thực thi phù hợp và được người có trách nhiệm duyệt.

Với đặt lịch, tài nguyên có thể là một nhóm phòng cho phép, hành động là xem khoảng trống và tạo lượt đặt trong phạm vi người yêu cầu. Thời hạn là cửa sổ thực hiện công việc, không phải thời lượng cuộc họp; hai thứ cần phân biệt. Điều kiện có thể yêu cầu chuyển người duyệt khi vượt hạn mức đặt đã xác định. Không điền điều kiện bằng con số tùy tiện; chủ tài nguyên phải quyết định theo cách vận hành của đơn vị trước khi thử.

Phiếu cũng ghi phần không được làm và người tiếp nhận khi thiếu quyền. Nếu chỉ được tạo lượt đặt của mình, hủy lượt đặt người khác phải bị chặn dù họ có cùng phòng ban. Nếu không được xem tiêu đề cuộc họp, kết quả lịch trống không được kèm những chi tiết ấy chỉ vì API dưới trả sẵn. Khi thiết kế chưa hỗ trợ một giới hạn cần thiết, giảm phạm vi tác vụ hoặc giữ bước ấy cho người thực hiện thay vì tuyên bố đã phân quyền đủ.

Không dùng khóa quản trị chung để tránh thiết kế quyền

RFC 9700, hướng dẫn thực hành an ninh OAuth 2.0 công bố tháng 1/2025, khuyến nghị giới hạn quyền của access token theo ứng dụng hoặc ca sử dụng, tài nguyên và hành động cần thiết [4]. Nguyên tắc ấy giúp giảm hậu quả nếu chứng thư truy cập bị lộ, nhưng không có nghĩa mọi token tự mang đủ ràng buộc nghiệp vụ. Máy chủ tài nguyên vẫn cần kiểm nội dung và phạm vi của yêu cầu theo chính sách được triển khai.

Một khóa quản trị dùng chung có thể làm bản trình diễn chạy nhanh vì bỏ qua nhiều chỗ thiếu tích hợp, nhưng cũng khiến mọi lỗi chọn công cụ mang quyền lớn. Khi các tác tử hoặc nhiều loại công việc dùng chung khóa, khó thu hồi một nhánh mà không ảnh hưởng nhánh khác. Nên phân tách chứng thư theo ứng dụng và phạm vi hợp lý, giữ bí mật ngoài ngữ cảnh mô hình và kiểm được nơi chúng được sử dụng.

Không đưa khóa, mật khẩu hoặc toàn bộ token vào câu lệnh, báo cáo hay nhật ký thông thường. Tác tử nên gọi một công cụ có lớp kiểm quyền, còn chứng thư cần thiết được thành phần được phép quản lý. Nếu công cụ không thể xác minh chủ thể hoặc chỉ hoạt động với quyền quản trị rộng, đó là điều kiện cần giải quyết trước khi mở tác vụ ghi. Việc mô hình được dặn chỉ đặt lịch không làm khóa quản trị bớt quyền.

Quyền đọc dữ liệu khác với quyền thay đổi tài nguyên

RFC 8707 mô tả cách chỉ định tài nguyên đích khi yêu cầu quyền OAuth và phân biệt việc xin loại quyền với nơi quyền ấy sẽ được dùng [5]. Trong ứng dụng, quyền đọc lịch và quyền tạo lượt đặt phải được ánh xạ tới đúng dịch vụ cùng đối tượng. Một tên phạm vi nghe phù hợp chưa bảo đảm token chỉ dùng được ở nơi mong muốn; bên nhận phải kiểm nó có được phát hành cho mình và cho hành động đang xử lý hay không.

Đặc tả ủy quyền MCP phiên bản 2025-11-25 áp dụng cho luồng truyền qua HTTP, có yêu cầu kiểm đúng nơi nhận token và không chuyển nguyên token nhận từ phía gọi sang dịch vụ dưới như một đường tắt [6]. Đừng suy rằng mọi kết nối MCP, kể cả dạng chạy cục bộ, có cùng luồng ủy quyền. Giao thức cung cấp cơ chế kết nối; quyền đặt lịch, xem nội dung hoặc hủy vẫn cần chính sách của ứng dụng và dịch vụ tài nguyên.

Với lịch phòng, dữ liệu cần thiết có thể chỉ là khoảng bận, sức chứa và điều kiện sử dụng. Quyền hành động lại có thể chỉ cho tạo lịch ở một nhóm tài nguyên hoặc sửa lượt đặt do chính công việc ấy tạo. Nếu công cụ trả cả danh sách người dự, mô tả và liên kết tài liệu cuộc họp, phải xem phần nào thật sự cần trước khi đưa cho mô hình. Có quyền đọc không đồng nghĩa nên chuyển mọi dữ liệu được đọc vào mọi bước xử lý.

Giới hạn thời gian và tài nguyên cần thực thi ở nhiều tầng

Thời hạn của chứng thư, thời gian được phép thực hiện công việc và tuổi của dữ liệu vừa đọc là ba đồng hồ khác nhau. Token còn hiệu lực không có nghĩa yêu cầu đặt phòng từ hôm trước vẫn được phép thực hiện hôm nay. Dữ liệu trống đã đọc cũng có thể hết đúng trước lúc ghi vì người khác vừa đặt. Ứng dụng cần kiểm thời hạn công việc và trạng thái tài nguyên tại thời điểm hành động, không chỉ xem hạn token.

Ngân sách có thể gồm số lượt đặt đang giữ, số lời gọi và chi phí dịch vụ nếu có. Giới hạn trên chỉ dẫn cho mô hình giúp định hướng, còn giới hạn thực thi cần nằm ở thành phần đủ quyền kiểm soát thao tác. Khi chạm giới hạn, kết quả nên nói rõ chưa đặt và điều kiện cần giải quyết. Không tự chuyển sang tài khoản khác hoặc một công cụ rộng quyền hơn để hoàn thành bằng mọi cách.

Với công việc chạy dài, giữ phần tiến triển không kèm quyền mặc định tiếp tục. Trạng thái đã lưu có thể chứa đối tượng và dự định cũ; khi khôi phục, phải kiểm quyền hiện hành và căn cứ thời gian trước thao tác tiếp. Không gọi việc tiếp tục từ điểm lưu là giữ nguyên sự cho phép. Nếu không xác minh được trạng thái quyền, dừng hành động cần quyền đó và bàn giao thông tin cần thiết cho người có trách nhiệm.

Công cụ hai: thử thu hồi ở bốn điểm

RFC 7009 định nghĩa cơ chế thu hồi token, đồng thời lưu ý thực tế có thể có độ trễ lan truyền việc vô hiệu hóa và chính sách ảnh hưởng token liên quan có thể khác nhau [7]. Vì vậy, nút thu hồi cần được kiểm tới nơi tài nguyên chấp nhận hay từ chối thao tác. Phản hồi của điểm thu hồi là một phần bằng chứng; nó không tự chứng minh mọi tiến trình đang chạy, hàng đợi và bản lưu đệm đã ngừng dùng quyền cũ.

RFC 7662 cho phép dịch vụ tài nguyên hỏi trạng thái token và bàn rõ đánh đổi khi lưu đệm câu trả lời: dữ liệu quyền cũ có thể tạo cửa sổ trong đó token đã thu hồi vẫn được dùng [8]. Không có một thời gian lưu đệm chung phù hợp mọi tài nguyên. Đội vận hành cần xác định mức trễ chấp nhận, kiểm cách hệ thống thực tế xử lý và báo giới hạn ấy thay vì hứa thu hồi tức thời ở mọi tầng.

Bảng kiểm được đề xuất đặt bốn điểm cạnh nhau: chứng thư truy cập; phiên và trạng thái công việc; hàng đợi cùng bản lưu đệm; nơi ghi thay đổi vào tài nguyên. Ở mỗi điểm, ghi cách chặn quyền cũ, bằng chứng cần thấy và người chịu trách nhiệm. Sau thu hồi, thử một yêu cầu mới, một bước đã chuẩn bị nhưng chưa chạy và một công việc được khôi phục. Các đường này có thể dùng trạng thái khác nhau nên không được thay thế nhau bằng một phép thử duy nhất.

Thu hồi không hoàn tác hành động đã hoàn thành. Nếu lịch đã tạo trước khi quyền bị thu hồi, nó có thể vẫn tồn tại hợp lệ hoặc cần người có quyền xem xét hủy theo quy trình. Tác tử không nên dùng lại chứng thư đã thu hồi để sửa hậu quả. Tách quyết định chặn việc tương lai khỏi quyết định xử lý thay đổi quá khứ giúp đội vận hành biết cần kiểm lịch nào và tránh tạo thêm thao tác ngoài quyền trong lúc xử lý sự cố.

Tình huống giả định: đặt phòng và thiết bị nội bộ

Giả sử một công ty tư vấn tại Việt Nam muốn trợ lý tìm phòng phù hợp và đặt một máy chiếu cho buổi họp nội bộ. Người yêu cầu đã đăng nhập; ứng dụng chỉ được xem khoảng trống của nhóm phòng được phép và tạo lượt đặt cho người ấy trong hạn mức đã duyệt. Nội dung cuộc họp riêng của người khác và quyền quản trị tài nguyên đều ngoài phạm vi. Đây là thiết kế giả định, không phải thông tin về hệ thống của một công ty cụ thể.

Sau khi đọc lịch, tác tử đề xuất một lựa chọn nhưng chưa ghi. Đúng lúc đó, người quản trị thu hồi quyền tạo lượt đặt của ứng dụng để bảo trì. Bước ghi tiếp theo phải được kiểm theo trạng thái quyền hiện hành và bị chặn nếu không còn được phép. Trợ lý có thể báo đã tìm được phương án nhưng chưa đặt, nếu phần thông tin ấy vẫn được phép sử dụng. Nó không được đổi sang một lịch chung có quyền rộng hơn chỉ để vượt chặn.

Một nhánh khác là quyền vẫn đủ nhưng phòng đã bị người khác đặt giữa bước đọc và ghi. Đây là xung đột tài nguyên, không nhất thiết là lỗi quyền. Hệ thống cần trả đủ thông tin để tác tử tìm phương án khác trong phạm vi hoặc hỏi lại nếu không còn lựa chọn phù hợp. Phân biệt hai loại từ chối giúp tránh đề nghị cấp thêm quyền khi vấn đề thật sự là lịch đã thay đổi, đồng thời giúp người vận hành hiểu đúng nguyên nhân chưa hoàn thành.

Nếu lượt đặt đã thành công nhưng thông báo trả về bị mất, tác tử cần kiểm trạng thái theo quyền còn hiệu lực trước khi thử lại. Nếu quyền đã bị thu hồi, bàn giao phần chưa rõ và mã công việc cho người vận hành có quyền kiểm. Không báo chắc chưa đặt chỉ vì không nhận được biên nhận. Không báo chắc đã hủy khi mới thu hồi token. Cả hai kết luận đều cần bằng chứng tại hệ thống giữ trạng thái tài nguyên.

Tổ chức theo quy mô và khả năng trực vận hành

Đội nhỏ có thể bắt đầu với quyền xem khoảng trống và gợi ý lựa chọn, giữ việc đặt cho người dùng thực hiện. Khi muốn mở quyền ghi, cần có chủ tài nguyên, người giữ tích hợp và cách xử lý lịch tạo nhầm. Nếu chưa có người tiếp nhận sự cố, không nên cấp quyền rộng chỉ vì việc đặt phòng có vẻ đơn giản. Phạm vi nhỏ giúp kiểm được quyền thực sự cần và nhận ra dữ liệu nào đang được trả thừa.

Ở đơn vị nhiều nhóm, cần ánh xạ quan hệ người dùng với tài nguyên và phân biệt quản trị cục bộ với quản trị toàn hệ thống. Quyền được cấp cho một chi nhánh không tự có hiệu lực ở mọi chi nhánh khác. Người nghỉ việc, chuyển nhóm hoặc đổi nhiệm vụ là các tình huống cần được đưa vào chu kỳ rà soát. Tên vai thuận tiện cho quản lý, nhưng điều kiện thực thi còn có thể phụ thuộc tài nguyên, thời điểm và quan hệ cụ thể.

Báo cáo vận hành nên nêu phần yêu cầu hoàn thành trong phạm vi, phần từ chối đúng và những trường hợp vượt quyền đã lọt qua. Đo thời gian từ lệnh thu hồi tới khi các đường thử ngừng chấp nhận quyền cũ, có nêu cấu hình và giới hạn đo. Giữ riêng thời gian người vận hành kiểm thay đổi đã xảy ra. Nếu chưa thử một nhánh khôi phục hoặc hàng đợi, ghi chưa thử, không đưa nó vào lời khẳng định hệ thống thu hồi toàn diện.

Phép thử trước khi cấp quyền ghi rộng hơn

Bộ thử cần bắt đầu từ bảng quyền đã duyệt: người dùng nào, tài nguyên nào, hành động nào và điều kiện thời gian nào. Trong môi trường thử tách biệt, tạo các ca cùng hành động nhưng khác chủ lượt đặt, nhóm phòng hoặc trạng thái ủy quyền. Kỳ vọng gồm cho phép đúng và từ chối đúng. Không dùng việc một người quản trị thử thành công làm bằng chứng rằng một tác tử quyền hẹp sẽ bị chặn đúng trong mọi trường hợp khác.

Chạy phép thu hồi giữa bước đọc và bước ghi, khi công việc đang chờ trong hàng đợi, rồi khi khôi phục từ trạng thái đã lưu. Nếu kiến trúc có lưu đệm quyền, thử trong và sau cửa sổ hiệu lực được cấu hình để xem hành vi khớp thiết kế không. Ghi thời điểm ở các điểm kiểm đáng tin; không chỉ dựa vào câu tác tử báo đã dừng. Đây là đề xuất phép thử, chưa có số đo thực tế nào được bài viết khẳng định.

Thử cả trường hợp chỉ thu hồi một loại quyền. Chẳng hạn, quyền tạo lượt đặt bị rút nhưng quyền đọc khoảng trống vẫn còn theo chính sách giả định. Ứng dụng cần biết phần việc nào vẫn được phép và không biến lỗi ghi thành yêu cầu dùng tài khoản quản trị. Nếu không kiểm được việc phân tách ấy, có thể chọn dừng toàn bộ công việc và bàn giao theo thiết kế đã thống nhất, nhưng phải nói rõ phạm vi dừng thay vì báo mơ hồ là không truy cập được.

Dừng mở rộng khi chứng thư dành cho dịch vụ khác vẫn được chấp nhận, quyền cũ tiếp tục ghi ngoài giới hạn đã chốt hoặc nhật ký không xác định được ai đại diện ai. Khắc phục ở lớp danh tính, chính sách hoặc thực thi tương ứng rồi kiểm lại các đường bị ảnh hưởng. Kế hoạch xử lý cần bao gồm thay đổi đã xảy ra trước khi bị chặn. Thu hồi là một khả năng vận hành phải chứng minh, không phải một tùy chọn được bật rồi coi như đã đủ.

Hỏi đáp về phân quyền tác tử AI

Có thể dùng tài khoản của một nhân viên cho tiện không? Cần chọn cơ chế tích hợp có thể xác định ứng dụng đang làm thay ai và giữ phạm vi phù hợp. Không giao mật khẩu cá nhân cho mô hình hoặc dùng quyền quản trị chung để thay việc thiết kế. Cách đại diện cụ thể phụ thuộc hệ thống danh tính và dịch vụ đang dùng; đội quản trị cần kiểm khả năng phân biệt, thu hồi và ghi dấu vết trước khi mở tác vụ.

Token ngắn hạn có làm hết nhu cầu thu hồi không? Không. Cửa sổ còn hiệu lực vẫn có thể dài hơn mức chấp nhận của công việc, và tác vụ đã xếp hàng có thể chạy sau thời điểm không còn được phép. Cần kiểm cả thời hạn công việc, quyền hiện hành và cách xử lý token liên quan. Token ngắn hạn là một phần thiết kế, không thay toàn bộ đường chặn và thử thu hồi theo bối cảnh.

Không cấp quyền xem nội dung cuộc họp thì có đặt phòng được không? Có thể, nếu dịch vụ hỗ trợ thông tin khoảng trống và các thuộc tính tài nguyên đủ để lựa chọn. Phải xác minh với giao diện và cấu hình cụ thể, không mặc định công cụ nào cũng tách được dữ liệu ấy. Nếu không tách được, cần điều chỉnh cách tích hợp hoặc phạm vi công việc trước khi đưa nhiều nội dung lịch vào ngữ cảnh mô hình.

Thu hồi rồi có phải mọi lịch tác tử tạo đều bị hủy không? Không. Thu hồi chặn việc dùng quyền trong tương lai theo cơ chế triển khai; lịch đã tạo là trạng thái nghiệp vụ cần được xem xét riêng. Người có quyền phải xác định thay đổi nào hợp lệ, thay đổi nào cần sửa và cách thông báo. Không dùng lại chứng thư đã thu hồi để tự hủy, và không báo hoàn tác thành công nếu chưa kiểm trạng thái tài nguyên.

Nguồn, phương pháp và giới hạn suy luận

Bài có hỗ trợ AI từ tám nguồn gốc đã đọc ngày 27/10/2026, gồm NIST, các RFC và tài liệu chính thức OWASP, MCP. Phiên bản, phần đọc và giới hạn được ghi trong hồ sơ nguồn; cơ chế OAuth hoặc MCP không được coi là bảo chứng toàn ứng dụng. Phiếu sáu chiều, bảng thu hồi và ca đặt lịch là tổng hợp biên tập giả định, chưa thử thực địa hay thẩm định chuyên gia. Đây không phải kết luận pháp lý hoặc cấu hình cấp quyền cho một dịch vụ cụ thể.