Cấp quyền cho AI agent: xem, sửa và gửi là những việc khác nhau

“Xem giúp mình lịch chiều mai” không có nghĩa “tự đổi cuộc hẹn sang chiều mai”. Khi AI được nối với công cụ, sự khác nhau này cần nằm trong quyền của hệ thống. Một câu trả lời hiểu sai có thể sửa được; một thông báo gửi nhầm đã tới người khác thì không thể coi như chưa xảy ra.

Agent là ứng dụng dùng AI để chọn bước tiếp theo và gọi công cụ. Để dùng nó vào công việc hằng ngày, hãy tách rõ quyền đọc, chuẩn bị và thực hiện. Mỗi quyền nên gắn với nhiệm vụ cụ thể, có giới hạn và cách kiểm kết quả.

Agent có thể đọc, chuẩn bị và hành động

Lấy ví dụ giả định về trợ lý hỗ trợ đổi lịch giao hàng. Nó có thể tìm đơn, xem khung giờ, đề xuất lựa chọn rồi lưu thay đổi. Bốn bước liên quan nhau nhưng không nên được coi là một quyền chung muốn làm gì cũng được.

Nhóm viết rõ đầu vào và kết quả của từng bước. Tìm đơn cần mã hoặc thông tin đủ để xác định đúng đơn. Đề xuất giờ cần lịch còn chỗ. Lưu thay đổi cần kiểm trạng thái và quyền của người yêu cầu.

Nếu bản thử chỉ cần đưa ra phương án, chưa cần cấp quyền sửa đơn. Agent vẫn hỗ trợ được công việc bằng cách tìm và chuẩn bị thông tin. Phần mềm phải giới hạn quyền thật, không chỉ nhắc trong prompt rằng “đừng tự sửa”.

OWASP mô tả rủi ro cấp quá nhiều khả năng cho ứng dụng AI và khuyến nghị giới hạn chức năng, quyền cùng mức tự chủ. Với hành động có tác động lớn, tổ chức này đề xuất có bước con người phê duyệt trước khi thực hiện.

Tránh dùng tài khoản chung đọc được mọi hồ sơ chỉ vì dễ kết nối. Người dùng đang có quyền tới đâu cần được kiểm ở hệ thống. Bot không nên trở thành đường vòng để xem dữ liệu mà tài khoản ấy vốn không được phép truy cập.

Thêm quyền từng bước và biết khi nào dừng

Bản đầu có thể chỉ tìm đơn và trình bày thông tin có nguồn. Nhóm đối chiếu bằng các trường hợp đã biết kết quả. Nếu còn chọn nhầm đơn, chưa nên mở quyền cập nhật chỉ vì giao diện trao đổi đã khá trôi chảy.

Bước kế tiếp là chuẩn bị thay đổi ở trạng thái nháp. Người dùng thấy giờ hiện tại, giờ đề xuất và phần còn thiếu. Nháp chưa được lưu thành lịch thật. Sự phân biệt này nên rõ trong cả dữ liệu lẫn cách hiển thị.

Khi cho phép thực hiện, giới hạn loại trường được sửa. Quyền đổi giờ giao không đồng nghĩa được đổi giá, địa chỉ hoặc người nhận. Một quyền hẹp dễ kiểm bằng tình huống cụ thể hơn tên gọi rộng như “quản lý đơn”.

Giới hạn cả phạm vi mỗi lượt. Yêu cầu về một đơn không nên biến thành cập nhật cả danh sách cùng khách. Nếu người dùng muốn thao tác nhiều đơn, hệ thống cần thể hiện rõ danh sách và điều kiện được phép áp dụng.

Có cách dừng dễ tìm cho người vận hành. Khi phát hiện lỗi, họ cần biết tắt bước nào, kiểm các thao tác đang chờ ở đâu và ai hỗ trợ. Đừng đợi sự cố rồi mới tìm người giữ quyền quản trị.

Yêu cầu xác nhận phải có thông tin

Một nút “Đồng ý” không giúp kiểm nếu người dùng không biết đang đồng ý điều gì. Với đổi lịch, cần hiện mã đơn, giờ cũ, giờ mới và điều kiện liên quan. Người dùng phải xem được đúng thay đổi sắp lưu.

Nếu có phí hoặc giới hạn kèm theo, đưa vào trước khi xác nhận. Không giấu chúng trong thông báo sau cùng. Việc duyệt chỉ có ý nghĩa khi người nhận đã thấy thông tin cần để chọn.

Cho phép sửa hoặc hủy ở bước đó. Yêu cầu còn thiếu thông tin thì hỏi đúng phần thiếu. Có hai đơn cùng tên khách là tình huống bình thường, không phải lý do để agent chọn đại đơn đầu tiên rồi sửa sau.

Nếu nội dung thay đổi sau khi được duyệt, không dùng lần đồng ý cũ cho một hành động khác. Chẳng hạn khách chọn chiều thứ Năm, hệ thống lại đổi sang thứ Sáu vì hết chỗ thì cần xác nhận lựa chọn mới.

Người dùng rời màn hình hoặc không trả lời cần được giữ ở trạng thái phù hợp. Im lặng không tự trở thành đồng ý. Khi quay lại, họ phải biết yêu cầu đang chờ, đã hủy hay đã được thực hiện.

Thử trước khi cho agent chạm dữ liệu thật

Dùng hồ sơ mẫu có tên gần giống, đơn đã khóa và các mức quyền khác nhau. Đừng chỉ thử một đơn hoàn hảo với câu lệnh đầy đủ. Những trường hợp thiếu hoặc mâu thuẫn mới cho thấy hệ thống có hỏi lại đúng lúc không.

Thử câu “đổi lịch cho Minh”. Kết quả cần phụ thuộc dữ liệu và quyền: nếu chưa xác định đủ, phải hỏi thêm. Không coi việc tự chọn được một hồ sơ là thành công khi chưa có căn cứ đó là hồ sơ người dùng muốn.

Thử nội dung bên ngoài có câu đòi gửi dữ liệu hoặc bỏ qua quy tắc. Tài liệu agent đọc không tự cấp quyền cho hành động mới. Có thể tham khảo thêm cách giảm rủi ro từ chỉ dẫn nằm trong dữ liệu khi thiết kế tình huống thử.

Kiểm trường hợp cập nhật xong nhưng phản hồi chậm. Nếu người dùng bấm lại, hệ thống có tạo thao tác trùng không? Nhóm kỹ thuật cần kiểm cách nhận biết yêu cầu đã thực hiện và đối chiếu trạng thái trước khi chạy lại.

Nhật ký nên đủ để biết ai yêu cầu, công cụ nào được gọi, bản ghi nào đổi và kết quả. Chỉ giữ thông tin cần thiết. Sao chép cả hồ sơ riêng vào log cho tiện kiểm lỗi có thể tạo thêm nơi phải quản lý dữ liệu.

Thống nhất cách xử lý khi kết quả chưa chắc. Agent không nên báo thành công chỉ vì đã gửi lệnh. Nếu công cụ chưa xác nhận, trạng thái cần nói đang kiểm hoặc chưa hoàn tất. Người dùng dựa vào thông báo ấy để quyết định bước tiếp theo.

Ví dụ: xử lý yêu cầu đổi lịch

Khách nhắn muốn nhận hàng vào chiều tuần sau. Agent tìm được hai đơn đang mở, nên hỏi khách chọn mã nào. Sau khi xác định, nó kiểm các khung giờ được phép đổi và đưa lựa chọn, không tự chọn thay khách.

Khách chọn chiều thứ Năm. Màn hình xác nhận cho thấy đơn cụ thể, lịch cũ và lịch mới. Trước khi lưu, hệ thống kiểm lại chỗ trống và trạng thái đơn vì chúng có thể vừa thay đổi trong lúc khách đang cân nhắc.

Nếu đơn đã chuyển sang bước không cho sửa, dừng và chuyển người phụ trách theo quy trình. Không thử công cụ khác để vượt qua giới hạn đó. Cách trả lời khách rõ bước tiếp theo giúp họ biết cần chờ hay liên hệ ai.

Lưu thành công thì báo lại giờ mới và mã đơn. Nếu chưa rõ kết quả, kiểm trạng thái trước khi thử lại. Cả luồng cần giữ một nguyên tắc: agent làm đúng phần được giao, còn người dùng nhìn được điều sắp xảy ra và kết quả thực tế sau đó.