Danh tính, quyền và nhật ký kiểm toán tác nhân AI: ghi lại hành động thế nào?

Lập bản ghi để kiểm tra từng hành động

Danh tính, quyền và nhật ký kiểm toán tác nhân AI hữu ích khi người rà soát có thể nối yêu cầu ban đầu với hành động thực tế: ai yêu cầu, danh tính nào thực thi, được phép làm gì, ai duyệt và kết quả ở đâu. Đừng chỉ lưu câu trả lời “đã xong” của tác nhân; hãy giữ tham chiếu để kiểm tra tại hệ thống đích.

Bảng sau là mẫu ghi thủ công minh họa cho yêu cầu đọc một tài liệu công việc và đề xuất câu trả lời, chưa gửi đi. Các ví dụ và phép kiểm tra trong bài là hướng dẫn đề xuất, không phải kết quả thử nghiệm hay định dạng nhật ký xuất sẵn của FoneClaw.

Ví dụ, bạn tự đặt mã yêu cầu YC-01, rồi tách bước đọc thành HD-01 và bước đề xuất thành HD-02. Nếu đây là mã tự đặt, ghi rõ như vậy; không trình bày chúng như mã do dịch vụ cấp. Kết quả cần ghi là tài liệu nào đã được đọc và bản đề xuất nào đã xuất hiện, không phải “thư đã gửi”.

Tên tác nhân trong hội thoại chỉ là nhãn. Thông tin xác thực cho phép một kết nối xác thực; phạm vi quyền giới hạn thao tác. Người yêu cầu, danh tính thực thi và người phê duyệt có thể khác nhau. Giữ tham chiếu đủ để đối chiếu, tránh sao chép toàn bộ tài liệu vào bản ghi.

Chọn danh tính và phạm vi quyền trong doanh nghiệp

Hướng dẫn ủy quyền danh tính tác nhân của Microsoft Entra phân biệt quyền được ủy quyền và quyền ứng dụng. Quyền được ủy quyền cho phép hành động thay mặt người dùng trong phạm vi cho phép. Quyền ứng dụng được quản trị viên cấp và không cần gắn với một người dùng đang thao tác. Đây là cơ chế của Entra, không phải đặc tính mặc định của mọi tác nhân AI.

Bắt đầu từ tài nguyên đích và thao tác cần làm. Tác vụ đọc một tài liệu không mặc nhiên cần quyền ghi cả kho hoặc vai trò quản trị. Vai trò tài nguyên Azure, vai trò thư mục và quyền Microsoft Graph kiểm soát những loại tài nguyên khác nhau; một loại quyền không thay thế cho tất cả loại còn lại.

• Xác định tài nguyên: tài liệu, hộp thư, thư mục hay tài nguyên Azure nào thực sự cần truy cập?
• Chọn thao tác: chỉ đọc, tạo mới, sửa hoặc xóa? Tách quyền đọc khỏi quyền có thể thay đổi dữ liệu.
• Chọn danh tính: hành động thay mặt người dùng hay bằng danh tính ứng dụng?
• Xác định người chịu trách nhiệm: ai sở hữu kết nối, rà soát quyền và xử lý khi tác nhân ngừng dùng?

Entra có giới hạn với vai trò và quyền API đặc quyền cao; không coi danh tính tác nhân là lý do cấp quyền quản trị rộng. Một lần đồng ý cấp quyền OAuth cũng không có nghĩa mọi lần gửi, sửa hoặc xóa sau đó đã được con người duyệt.

Ghi thời hạn hoặc lịch rà soát khi chính sách tổ chức yêu cầu, thay vì tự đặt một quy tắc lưu giữ chung. Với triển khai rộng hơn, bài Bảo mật AI agent cho doanh nghiệp trên điện thoại giúp xem xét phân quyền và vận hành nội bộ.

Ghép bằng chứng danh tính với kết quả hành động

Tài liệu nhật ký danh tính tác nhân của Microsoft Entra mô tả thuộc tính agentType và blueprintId để liên hệ chủ thể, đối tượng và bản thiết kế. Hoạt động bản thiết kế xuất hiện dưới dạng sự kiện ứng dụng; danh tính tác nhân dưới dạng sự kiện service principal; tài khoản người dùng của tác nhân dưới dạng sự kiện người dùng.

Người có ít nhất vai trò Reports Reader có thể vào Microsoft Entra ID, mục Giám sát và tình trạng, mở nhật ký đăng nhập rồi dùng bộ lọc tác nhân. Những truy vấn nhật ký tác nhân qua Microsoft Graph được tài liệu nêu sử dụng đường /beta; kiểm tra điều kiện của API trước khi đưa vào quy trình vận hành.

Nhật ký đăng nhập cho biết một danh tính đã thử truy cập khi nào và kết quả xác thực ra sao. Nó không tự chứng minh thư đã gửi đúng người, tài liệu đã sửa hay sự kiện lịch đã tồn tại. Cần ghép thêm bằng chứng ở ứng dụng thực hiện hành động.

1. Đối chiếu danh tính thực thi và tài nguyên đích.
2. Dùng mã yêu cầu hoặc mã tương quan nếu hệ thống cung cấp; bổ sung mốc thời gian và múi giờ.
3. Tìm thao tác nghiệp vụ tương ứng: đọc, tạo, sửa hoặc gửi.
4. Kiểm tra kết quả hoặc đối tượng thực tế tại đích.

Hai sự kiện gần nhau về thời gian chưa chắc thuộc cùng yêu cầu. Nếu thiếu mã tương quan, ghi mức độ chưa chắc chắn thay vì nối chúng như bằng chứng chắc chắn. Với ví dụ tài liệu, đăng nhập thành công nhưng chưa tìm thấy bản đề xuất phải được ghi là “chưa xác nhận kết quả”.

Nếu kỹ năng hoặc phần mở rộng tham gia luồng, cần biết nguồn và quyền của thành phần đó. Bài Bảo mật kỹ năng AI agent trên điện thoại hỗ trợ kiểm tra phần này riêng.

Ghi rõ thành công, từ chối, chờ duyệt và kết quả chưa rõ

Đừng dùng một trạng thái “xong” cho cả cấp quyền, phê duyệt và thực thi. Bốn bản ghi đề xuất dưới đây tách phạm vi được phép, lần thử và quan sát thực tế. Các mã minh họa do người rà soát đặt để theo dõi, không phải trường nhật ký bắt buộc của sản phẩm.

Trong trường hợp cuối, lỗi phản hồi không chứng minh thao tác ghi thất bại hoàn toàn. Sự kiện có thể đã được tạo trước khi phản hồi bị mất. Tìm theo tiêu đề, thời gian, lịch đích và mã đối tượng nếu có; ghi “đã tìm thấy”, “chưa tìm thấy” hoặc “chưa kiểm tra được”.

Nếu tìm thấy một mục nhưng giờ sai, ghi kết quả đó như một sai lệch cụ thể, không tạo thêm mục mới để che lỗi. Việc sửa hoặc xóa cần được xử lý như hành động riêng. Nếu chưa kiểm tra được đích, giữ trạng thái chưa rõ và không tự động lặp thao tác ghi.

Tương tự, một thao tác bị từ chối sau khi bước đọc đã hoàn tất vẫn có thể để lại kết quả đọc. Ghi từng bước đã xảy ra; “không có thay đổi mới” không đồng nghĩa “không có dữ liệu nào từng được truy cập”.

Áp dụng các câu hỏi ấy trên điện thoại

Trong FoneClaw, chúng tôi hỗ trợ device_battery_status để đọc mức pin và trạng thái tiết kiệm pin mà không đổi cài đặt. Với yêu cầu “cho tôi biết mức pin hiện tại”, ghi người yêu cầu, công cụ đang bật, chính sách áp dụng và giá trị thực tế trả về cùng thời điểm. Không cần thêm quyền ghi cho tác vụ chỉ đọc.

Với calendar_create_event, yêu cầu tạo lịch có tác động bên ngoài. Ví dụ đề xuất: “Tạo cuộc hẹn Trao đổi kế hoạch ngày 12/10/2026, từ 09:00 đến 09:30, nhắc trước 10 phút, theo múi giờ điện thoại”. Nếu ngày, giờ kết thúc hoặc lời nhắc còn thiếu, cần hỏi lại trước khi gọi công cụ; lịch cụ thể chỉ được chọn khi người dùng đã chỉ định.

Luồng công cụ sử dụng thời gian địa phương và múi giờ thiết bị. Sau khi tạo, dùng actualStart và actualEnd trả về để ghi thời gian thực tế, rồi mở ứng dụng Lịch kiểm tra tiêu đề, ngày giờ, lời nhắc và lịch đích. Yêu cầu ban đầu không thay thế bằng chứng mục đã được tạo đúng.

Quyền Android, công cụ FoneClaw được bật và thông tin xác thực nhà cung cấp mô hình là ba kiểm soát riêng. Nhãn rủi ro và phê duyệt mặc định của công cụ giúp định hướng; chế độ phê duyệt chung cùng tùy chỉnh từng công cụ quyết định hành vi thực tế. Không mặc định mọi bước đều có cùng hộp thoại xác nhận.

Mô hình được chọn diễn giải yêu cầu, còn công cụ hỗ trợ thao tác điện thoại. Mô hình trực tuyến có thể nhận ngữ cảnh tác vụ; bản ghi hành động cục bộ không mô tả đầy đủ việc xử lý dữ liệu của nhà cung cấp. Xem Trang tính năng FoneClaw để chọn phạm vi hỗ trợ. Mẫu tự kiểm tra này không phải tích hợp Entra hay bản xuất kiểm toán bất biến.

Thu hồi quyền và kiểm tra trạng thái còn lại

Để kiểm tra chặn công cụ với ít rủi ro, có thể chọn thao tác đọc pin. Ghi cấu hình ban đầu, tắt công cụ đọc pin rồi yêu cầu đọc lại trạng thái. Quan sát mong đợi là thao tác công cụ bị chặn; một giá trị cũ trong hội thoại không chứng minh đã có lần đọc mới.

Ghi chính xác phản hồi, công cụ bị tắt và việc có hay không có kết quả mới. Vì phép kiểm tra chỉ đọc, cài đặt pin không nên bị thay đổi. Nếu không xác định được công cụ có chạy hay không, ghi “chưa xác nhận”, không kết luận cơ chế chặn đã hoạt động. Sau đó chỉ bật lại nếu còn cần tác vụ.

Thu hồi quyền ngăn truy cập tiếp theo theo cơ chế của hệ thống, không tự xóa dữ liệu đã đọc hoặc hoàn tác thay đổi đã hoàn thành. Một sự kiện lịch đã tạo vẫn cần kiểm tra tại ứng dụng Lịch; không coi việc tắt công cụ là đã xóa sự kiện.

• Rà soát danh tính, kết nối và thông tin xác thực không còn dùng.
• Thu hồi quyền vượt nhu cầu, xem lại chủ sở hữu và các tùy chỉnh phê duyệt.
• Với thao tác ghi chưa rõ kết quả, kiểm tra đích trước khi cho phép thử lại.
• Giới hạn người đọc bản ghi và thời gian lưu theo chính sách tổ chức; tránh lưu bí mật hoặc nội dung thừa.

Nếu thông tin xác thực đã lộ, xử lý tại dịch vụ cấp thông tin đó; chỉ sửa ghi chú không vô hiệu hóa kết nối. Nếu bộ nhớ tác nhân chứa chỉ dẫn cũ có thể ảnh hưởng mục tiêu hoặc quyết định quyền, bài Đầu độc bộ nhớ tác nhân AI trên điện thoại giúp kiểm tra rủi ro này riêng. Hoàn tất rà soát khi biết quyền nào còn hiệu lực và trạng thái nào còn tồn tại ở đích.