Tác nhân AI nên có bao nhiêu quyền? Đề bài mới doanh nghiệp không muốn đối mặt nhất nhưng không né được

Một kỹ sư ở một công ty phần mềm, để trợ lý AI nội bộ tra được trạng thái đơn hàng, tiện tay cấp cho nó quyền chỉ đọc cơ sở dữ liệu. Rất hợp lý.

Hai tháng sau, quản lý sản phẩm muốn trợ lý cũng giúp cập nhật ghi chú đơn hàng. Kỹ sư nghĩ một lát, thêm quyền ghi. Cũng khá hợp lý.

Thêm một tháng nữa, có người hỏi liệu có thể để nó xử lý hoàn tiền trực tiếp không. Lúc này mới có người sực nhớ hỏi: vậy tài khoản của trợ lý này giờ rốt cuộc làm được những gì?

Không ai trả lời được.

Bối cảnh sự kiện

Lộ trình đưa AI vào mấy năm nay gần như đều giống nhau: trước làm chat hỏi đáp (chỉ đọc), rồi làm tạo nội dung (không đụng hệ thống), rồi bắt đầu nối công cụ (tra được), cuối cùng bắt đầu thực thi hành động (sửa được).

Ba giai đoạn đầu, vấn đề quyền không rõ. Đến giai đoạn thứ tư thì tính chất hoàn toàn đổi — tác nhân AI thành một "chủ thể hành động" biết thao tác hệ thống công ty, mà nó vừa không phải nhân viên, vừa không phải tài khoản dịch vụ truyền thống.

Tài khoản dịch vụ (service account) truyền thống có mẫu hành vi rõ, cố định: mỗi ngày ba giờ sáng chạy một lần theo lô, làm gì viết cứng trong chương trình. Tác nhân AI thì không. Nó dựa vào đầu vào để quyết định gọi công cụ nào, sửa dữ liệu nào, không gian hành vi lớn đến mức không liệt kê hết được.

Đó chính là vấn đề. Khung quản trị truy cập sẵn có được thiết kế cho "chương trình có hành vi dự đoán được" và "con người có cái giá tâm lý". Tác nhân không phải cả hai.

Trọng điểm

Quản trị truy cập thời đại tác nhân, tôi cho rằng có bốn vấn đề thiết kế bắt buộc phải xử lý:

• Danh tính độc lập: tác nhân phải có tài khoản và chứng chỉ riêng, không được mượn danh tính nhân viên. Đây là tiền đề của mọi kiểm soát sau đó.
• Quyền tối thiểu và có thời hạn: chỉ cấp quyền cần cho tác vụ, và cố gắng cấp chứng chỉ tạm có thời hạn, không phải khóa có hiệu lực lâu dài.
• Áp phân tách nhiệm vụ cho tài khoản phi con người: một tác nhân không nên đồng thời có quyền "tạo" và "phê duyệt" cùng một việc. Quy tắc này với tác nhân nên nghiêm hơn với người.
• Vết kiểm toán đầy đủ: ai kích hoạt, dựa vào gì, sửa gì, có người phê duyệt không. Mục thứ tư hay bị bỏ sót nhất.

Công cụ xử lý quyền ERP và phân tách nhiệm vụ trên thị trường (ví dụ Pathlock) vốn thiết kế cho người, nay đang đối mặt cùng vấn đề: kho quy tắc SoD của chúng phải phủ chủ thể phi con người ra sao. Đây là giai đoạn cả ngành vẫn đang mò mẫm.

Phân tích tác động thị trường

Với người dùng: Nhân viên thường sẽ cảm nhận thay đổi là "tác nhân thường nói nó không làm được". Nghe như thiếu chức năng, nhưng nhiều khi là thiết kế cố ý.

Tôi thấy công ty cần nói rõ lý do việc này cho nhân viên. Nếu không ai giải thích, phản ứng của nhân viên sẽ là đi vòng — tự viết một script, tự kéo một bản dữ liệu ra làm. Đó mới là rủi ro an ninh thật sự. Thiết kế quyền nếu làm cho công việc chính đáng trở nên quá đau, người ta chắc chắn sẽ tìm đường lách.

Với ứng dụng doanh nghiệp: Doanh nghiệp có hai điểm yếu mang tính cấu trúc sẽ bị phóng đại ở đề bài này.

Thứ nhất là quyền nhiều năm chỉ thêm không giảm. Quản lý quyền của đa số công ty là "có nhu cầu thì thêm, nghỉ việc mới xóa", tích lũy mười mấy năm, riêng việc làm rõ hiện trạng đã là công trình lớn. Trên nền đó thêm tác nhân, chẳng khác nào xây nhà trên móng mục.

Thứ hai là quyền hạn giữa IT và bộ phận nghiệp vụ mơ hồ. "Tác nhân này nên có quyền gì" rốt cuộc ai quyết? IT nghĩ là việc của bộ phận nghiệp vụ, bộ phận nghiệp vụ nghĩ là chuyên môn của IT. Kết quả là không ai quyết, cứ cấp lớn trước đã.

Cách thực tế là lập một "sổ đăng ký tác nhân": mỗi tác nhân AI lên phải đăng ký công dụng, quyền sở hữu, cấp quản lý bộ phận phụ trách, và chu kỳ rà soát. Việc này không cần mua hệ thống, một bảng tính là bắt đầu được, nhưng nó buộc ra câu hỏi then chốt nhất — mỗi tác nhân đều phải có một người chịu trách nhiệm.

Với lập trình viên: Ba nguyên tắc thiết kế tôi cho là nên coi là quy tắc cứng.

Một, quyền ghi mặc định tắt. Tác nhân lên chỉ cấp đọc, chức năng ghi phải xin riêng, đánh giá riêng. Điều này ngược với thói quen phát triển thông thường (cấp toàn quyền cho dễ thử, sau thu lại), nhưng môi trường thử của tác nhân với môi trường chính thức thường dùng chung dữ liệu, "sau thu lại" thường không xảy ra.

Hai, hành động phá hủy nhất loạt phải người phê duyệt. Xóa, hoàn tiền, gửi thư cho khách ngoài, sửa số tiền — mấy loại này nên thiết kế thành "tác nhân chuẩn bị, người bấm xác nhận". Đây không phải không tin AI, mà vì cái giá sai của mấy việc này bất đối xứng: chi phí bấm xác nhận thêm một lần rất thấp, chi phí gửi sai một thư cho khách rất cao.

Ba, ghi lại cả "từ chối". Đa số hệ thống chỉ ghi thao tác thành công. Nhưng việc tác nhân định làm gì đó nhưng bị quyền chặn lại là tín hiệu cực có giá trị — nó có thể đại diện cho tấn công tiêm câu lệnh, cũng có thể đại diện cho việc thiết kế quyền của bạn không hợp nhu cầu thực. Cả hai đều cần người xem.

Xu hướng phát triển tương lai

Tôi cho rằng ba việc sẽ xảy ra.

Thứ nhất, "danh tính tác nhân" sẽ thành một loại danh tính độc lập. Hệ thống quản lý danh tính hiện chia "người" và "tài khoản dịch vụ" hai loại, tác nhân không hoàn toàn thuộc loại nào. Sản phẩm IAM tương lai sẽ xuất hiện loại danh tính tác nhân chuyên biệt, kèm khai báo công dụng, ranh giới hành vi và thời hạn hiệu lực.

Thứ hai, công cụ quản trị truy cập sẽ bắt đầu đưa tác nhân vào phân tích SoD. Đây là khoảng trống sản phẩm rõ với các hãng hiện có, cũng là cơ hội cho startup.

Thứ ba, quản lý sẽ theo kịp, nhưng bắt đầu từ tài chính và y tế. Hai ngành này yêu cầu nghiêm nhất về "quyết định do ai làm", sẽ là nhóm đầu bị yêu cầu giải thích thiết kế quyền của tác nhân.

Tôi phải bổ sung một quan sát khá dè dặt: các thảo luận về quản trị tác nhân hiện nay nặng mùi kỹ thuật — nói OAuth scope, nói sandbox, nói policy engine. Nhưng thứ thật sự làm doanh nghiệp kẹt thường là vấn đề ở phía trước hơn: không ai biết trong công ty rốt cuộc đang chạy mấy tác nhân. Đây cùng loại vấn đề với shadow IT mười năm trước, giải pháp cũng giống, làm kiểm kê trước.

Học viện TheAI tổng kết và nhận định

Quay lại ví dụ ở đầu. Cuối cùng việc họ làm rất đơn giản: đổi tài khoản trợ lý từ tài khoản dịch vụ dùng chung sang tài khoản riêng, đổi chức năng hoàn tiền thành "trợ lý chuẩn bị, chăm sóc khách hàng xác nhận", và đăng ký mọi tác nhân vào một biểu mẫu dùng chung.

Mất hai tuần, không mua công cụ nào.

Nhận định: việc quyền của tác nhân, thời điểm tốt nhất là trước khi nó lên, thời điểm tốt thứ hai là ngay bây giờ. Đợi có sự cố rồi mới thiết kế thì thứ bạn phải xử lý không chỉ là vấn đề kỹ thuật nữa.

Gợi ý cụ thể cho bạn đọc, ba việc tuần tới làm được:

Một, làm một lần kiểm kê tác nhân. Trong công ty hiện có mấy tác nhân AI đang chạy? Mỗi cái dùng tài khoản gì? Ai phụ trách? Chỉ cần liệt kê bảng này ra, đa số công ty sẽ phát hiện một hai thứ không ai nhớ vẫn đang chạy.

Hai, thu quyền ghi lại, xin lại. Việc này sẽ bị than phiền, nhưng đáng. Thu lại xong bạn sẽ phát hiện có tác nhân quyền ghi thực ra chưa từng được dùng — đó là rủi ro thuần túy, không có giá trị tương ứng.

Ba, chỉ định người chịu trách nhiệm cho mỗi tác nhân. Không phải IT, mà là cấp quản lý bộ phận thực tế dùng tác nhân đó. Người này phải trả lời được "tác nhân này vì sao cần quyền này". Không trả lời được thì đó là quyền nên thu.

Đọc thêm: Trước khi đưa tác nhân AI vào hãy hỏi dữ liệu có mấy phiên bản bàn chuẩn bị mặt dữ liệu, AI vào phòng kiểm toán bàn ranh giới tự động hóa kiểm soát nội bộ, Khả năng quan sát và quản trị tác nhân AI bàn giám sát sau khi lên.

Nguồn tham khảo

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• Thuyết minh sản phẩm chính thức Pathlock

Tổng hợp theo thông tin công khai, căn cứ theo bên chính thức; bài viết là gợi ý mang tính chung, thiết kế kiểm soát của từng môi trường xin làm theo đánh giá rủi ro của mình.