Danh tính tác nhân AI: quyền, phê duyệt công cụ và nhật ký kiểm toán

Vì sao tác nhân AI cần danh tính trước khi dùng công cụ

Hãy bắt đầu bằng một tác vụ rất cụ thể: người dùng nói với phone agent “soạn tin cho Minh rằng tôi sẽ đến muộn 15 phút”. Trước khi bất kỳ công cụ nào được gọi, hệ thống cần biết ai là người yêu cầu, phiên nào đang hoạt động, tác nhân nào đang lập kế hoạch, công cụ nào có thể được dùng và người nhận “Minh” là mục tiêu nào. Đó là phần thực dụng của danh tính tác nhân AI: không phải một nhãn đẹp trong nhật ký, mà là cách gắn hành động với chủ thể, phiên và phạm vi ủy quyền.

hướng dẫn của NVIDIA về quản trị autonomous agents trong AI factories nhấn mạnh các lớp như identity, signed policy, human review, centralized logs, revocation và continuous verification. Dịch sang điện thoại, danh tính cần giữ được qua thử lại và chuyển giao. Nếu agent mở nhầm app rồi thử lại, bản ghi vẫn phải cho thấy cùng một yêu cầu ban đầu, cùng phiên người dùng và công cụ nào đã được thử.

Đăng nhập không đủ để định nghĩa quyền được ủy quyền. Người dùng có thể đã mở khóa điện thoại, nhưng điều đó không nói agent được phép gửi tin, đọc thông báo, bật system control hoặc truy cập vị trí. Danh tính chỉ là điểm bắt đầu của chuỗi kiểm soát: biết ai đang hành động, thay mặt ai, trong phiên nào, rồi mới đánh giá tác vụ đó có nằm trong phạm vi được phép hay không.

Biến danh tính thành quyền có phạm vi và có thể thu hồi

Sau khi xác định danh tính, bước tiếp theo là biến nó thành quyền có phạm vi. Một phone agent không nên đi từ “người dùng đã đăng nhập” thẳng tới “agent được làm mọi việc”. Chuỗi an toàn hơn gồm nhiều lớp: chính sách người dùng hoặc tổ chức, công cụ được bật, quyền Android trong ngữ cảnh, kiểm tra mục tiêu hành động, phê duyệt theo rủi ro và điểm thu hồi sau đó.

bài viết của NVIDIA về bốn cách triển khai AI agents an toàn hơn nêu các lỗi lặp lại như kiểm soát truy cập yếu, thực thi mã tùy ý, kết nối ra ngoài không kiểm soát và bí mật lưu dạng văn bản thuần. Khuyến nghị quan trọng là đặt các lớp kiểm soát xác định bên ngoài model plane, dùng công cụ theo nguyên tắc quyền tối thiểu, xác thực nguồn gói và mặc định hạn chế kết nối ra ngoài. Với Android, nguyên tắc tương tự là: đừng để prompt tự biến thành hệ thống phân quyền.

Android permission chỉ là một lớp. Quyền truy cập vị trí cho app không tự cho phép agent chia sẻ vị trí với người khác. Quyền đọc một loại dữ liệu không tự cho phép gửi dữ liệu đó sang một dịch vụ. Một công cụ đã được bật cũng chưa chắc hành động cụ thể được phê duyệt, vì mục tiêu và nội dung vẫn có thể rủi ro. Nếu bạn muốn đi sâu vào khác biệt giữa môi trường thực thi và quyền điện thoại, bài Sandbox AI agent và quyền trên điện thoại: vì sao vẫn cần ranh giới giữ phần kiến trúc đó ở đúng phạm vi.

Quyền tốt có thời hạn, mục tiêu và đường thu hồi. Một quyền đọc trạng thái màn hình trong tác vụ hiện tại nên kết thúc khi tác vụ kết thúc. Một công cụ gửi tin có thể được bật theo chính sách, nhưng hành động gửi đến một người nhận cụ thể vẫn cần quyết định riêng khi nội dung có tác động thật.

Cần quyết định và ghi gì tại ranh giới gọi công cụ

Ranh giới quan trọng nhất của phone agent là lúc model đề xuất dùng công cụ. Trước điểm đó, ta có ngôn ngữ, suy luận và kế hoạch. Sau điểm đó, hệ thống có thể đọc màn hình, mở app, chuẩn bị tin nhắn, điều chỉnh thiết bị hoặc tạo tác động bên ngoài. Vì vậy, phê duyệt theo từng công cụ không nên chỉ là một nút bật tắt; nó cần một bản ghi quyết định đủ rõ.

Một bản ghi tối thiểu nên có: yêu cầu ban đầu, tác nhân hoặc phiên đang xử lý, công cụ được chọn, lý do chọn công cụ, dữ liệu đầu vào đã được chuẩn hóa, nhãn rủi ro, kết quả chính sách, quyền Android cần dùng, mục tiêu hành động, trạng thái phê duyệt, kết quả thực thi quan sát được và lỗi nếu có. Với tác vụ đọc rủi ro thấp, bản ghi có thể ngắn. Với tác vụ gửi tin, đổi cài đặt, chia sẻ vị trí hoặc chạm dữ liệu nhạy cảm, bản ghi cần rõ hơn.

Cách ghi này tách kế hoạch khỏi kết quả. Model có thể “dự định” gửi bản nháp cho Minh, nhưng kết quả thực tế có thể là đã mở app nhắn tin, đã chuẩn bị nội dung, đang chờ xác nhận, bị từ chối do thiếu quyền, hoặc thất bại vì có nhiều liên hệ tên Minh. Nhật ký kiểm toán tác nhân có giá trị khi nó ghi cả lần bị từ chối, lỗi một phần và kết quả quan sát được, không chỉ các lần thành công.

Phần kỹ năng cũng cần được đặt cùng ranh giới. Một skill mở app, một skill đọc trạng thái và một skill gửi nội dung có hồ sơ rủi ro khác nhau. Bài Bảo mật kỹ năng AI agent trên điện thoại đào sâu vào kiểm soát skill; ở đây, trọng tâm là mọi lời gọi công cụ đều phải có quyết định và bằng chứng đủ dùng.

Sandbox doanh nghiệp và quyền Android là hai lớp khác nhau

Những hướng dẫn doanh nghiệp về agent thường nói đến sandbox, managed execution, secret management, egress restriction, signed policy và centralized logs. Chúng rất hữu ích, nhưng không nên bê nguyên sang điện thoại như thể Android permission là cùng một thứ. Một máy ảo doanh nghiệp có thể giới hạn kết nối ra ngoài; một điện thoại Android lại có trạng thái app, màn hình, quyền runtime, tài khoản cá nhân và thao tác người dùng.

mô hình quản trị agent của NVIDIA tách presentation khỏi managed execution và yêu cầu logs, revocation, verification liên tục. Nguyên tắc đó hữu ích cho điện thoại, nhưng cách triển khai phải đi qua lớp Android. Với các tổ chức cần chính sách rộng hơn, bài Bảo mật AI agent cho doanh nghiệp trên điện thoại phù hợp hơn cho phần workspace, quản trị và triển khai nội bộ.

Điểm chung giữa hai thế giới là không để model tự giữ chìa khóa. Điểm khác nhau là nơi hành động xảy ra: trong doanh nghiệp là môi trường quản lý; trên Android là thiết bị cá nhân, app cụ thể và quyền theo ngữ cảnh.

FoneClaw áp dụng kiểm soát toàn cục và từng công cụ ra sao

Trong FoneClaw, chúng tôi đưa chuỗi danh tính, quyền, phê duyệt và nhật ký về đúng ranh giới lời gọi công cụ Android. FoneClaw là runtime phone agent Android: mô hình tương thích được cấu hình để hiểu và lập kế hoạch; FoneClaw gọi công cụ Android được hỗ trợ, áp dụng chính sách, hướng dẫn quyền khi tác vụ cần, hiển thị kết quả và xử lý lỗi theo trạng thái thực tế của thiết bị.

Nền hiện có của FoneClaw bổ sung quản lý từng công cụ, tùy chỉnh phê duyệt, phục hồi quyền và xử lý lỗi mạnh hơn. Điều đó giúp người dùng và đội ngũ vận hành không phải chỉ chọn “bật agent” hoặc “tắt agent”. Họ có thể tìm công cụ, bật hoặc tắt từng công cụ, điều chỉnh phê duyệt ở mức phù hợp và phục hồi khi quyền Android chưa sẵn sàng. Nếu bạn muốn dùng phiên bản hiện tại, hãy bắt đầu từ trang Tải FoneClaw cho Android.

Chế độ phê duyệt toàn cục có ba lựa chọn. Auto approve cho phép runtime tự động phê duyệt theo phạm vi người dùng đã chọn, phù hợp với tác vụ đã được hiểu rõ và rủi ro thấp. Follow tool policy để mỗi công cụ đi theo nhãn rủi ro và quy tắc phê duyệt trong catalog. Deny all chặn các lời gọi công cụ, hữu ích khi muốn quan sát, chẩn đoán hoặc dừng toàn bộ phần thực thi.

FoneClaw hỗ trợ hơn 100 công cụ tích hợp cho các thao tác Android được quản trị, kèm nhãn rủi ro và chính sách phê duyệt. Con số chỉ có ý nghĩa khi đi cùng nhãn rủi ro, trạng thái bật công cụ và chính sách phê duyệt. Bạn có thể xem cách chúng tôi trình bày các khả năng này trên trang tính năng FoneClaw.

Nếu bạn muốn thấy toàn bộ đường đi từ ý định đến thao tác Android, bài Điều khiển điện thoại bằng AI agent trên Android trình bày lớp thực thi đầy đủ hơn. Trong bài này, điều cần giữ là: mô hình lập kế hoạch, nhưng quyền hành động nằm ở runtime, công cụ, chính sách và người dùng.

Bảng phê duyệt thực tế cho các hành động phone agent

Không nên gán một mức rủi ro duy nhất cho cả danh mục công cụ. Một hành động “mở app” thường đơn giản hơn “gửi email”, nhưng mở đúng app ngân hàng trước mặt người khác vẫn có ngữ cảnh khác với mở ứng dụng thời tiết. Vì vậy, nhãn catalog là điểm bắt đầu, còn mục tiêu và nội dung quyết định mức phê duyệt cuối cùng.

Bảng này không phải luật cứng cho mọi người dùng. Nó là cách suy nghĩ theo hậu quả. Công cụ đã bật vẫn có thể cần phê duyệt nếu mục tiêu nhạy cảm. Một công cụ thường cần phê duyệt có thể chạy ít ma sát hơn khi chỉ tạo bản nháp chưa gửi. Trọng tâm của phê duyệt theo từng công cụ là đưa quyết định đến đúng thời điểm, nơi người dùng hiểu hành động sẽ tạo ra điều gì.

Kiểm toán, thu hồi và khôi phục khi hành động lỗi hoặc đổi phạm vi

Quản trị chỉ có giá trị khi nó hoạt động cả lúc sai. FoneClaw hiện cải thiện phục hồi quyền và xử lý lỗi để hướng người dùng đến bước xử lý phù hợp khi tác vụ thất bại vì thiếu quyền. Nếu tác vụ bị từ chối vì chính sách, bản ghi cần nói rõ chính sách nào chặn. Nếu người dùng đổi ý, hệ thống cần có đường dừng: Deny all, tắt công cụ, hủy tác vụ, thu hồi quyền Android hoặc kết thúc phiên.

Nhật ký kiểm toán cần ghi cả phần không xảy ra. “Tin nhắn đã bị hủy trước khi gửi” quan trọng không kém “tin nhắn đã gửi”. “Công cụ bị Deny all chặn” quan trọng không kém “công cụ chạy thành công”. “Mở sai app và dừng ở bước chọn mục tiêu” tốt hơn rất nhiều so với nhật ký mơ hồ “tác vụ thất bại”. Những chi tiết đó giúp người dùng sửa lỗi mà không phải đoán agent đã chạm tới đâu.

Thu hồi cũng không đồng nghĩa hoàn tác mọi hậu quả. Một tin đã gửi hoặc một dữ liệu đã chia sẻ có thể không hoàn tác hoàn toàn. Vì thế quản trị thực dụng ưu tiên kiểm soát trước khi hành động có tác động: kiểm tra mục tiêu, hiển thị nội dung, yêu cầu phê duyệt khi cần và ghi lại kết quả quan sát được. Với tài nguyên hoặc công cụ được khám phá từ bên ngoài, bài Agentic Resource Discovery: ai-catalog.json, xác minh và quyền cho phone agent giúp mở rộng cùng nguyên tắc sang catalog, registry và xác minh nguồn.

Một phone agent đáng tin không cần hứa làm mọi thứ. Nó cần biết mình đang hành động với danh tính nào, quyền nào, công cụ nào, mục tiêu nào, kết quả nào và điểm thu hồi nào. Khi chuỗi đó rõ, người dùng có thể cho agent làm nhiều việc hơn mà vẫn giữ được quyền quyết định trên điện thoại của mình.