Đặc quyền tối thiểu là lưới an toàn cho tác tử AI

Đặc quyền tối thiểu cho tác tử AI giới hạn thiệt hại bằng cách chỉ cấp những quyền cần cho từng lần chạy. The New Stack đã công bố một thử nghiệm gồm 160 lần chạy. Phân quyền theo tác vụ hoàn thành 20/20 tác vụ với cả Claude Haiku 4.5 và Claude Sonnet 5. Cấu hình này chỉ kích hoạt 2 trong tổng số 30 phạm vi quyền.

Một tác tử hỗ trợ khách hàng đọc hồ sơ hóa đơn và xác nhận giao dịch đã thất bại. Không có tiền rời khỏi tài khoản, nhưng tác tử vẫn hoàn tiền. Nó lặp lại sai lầm đó thêm năm lần. Theo bài thử của The New Stack, Claude Haiku 4.5 thực hiện sai cả 6 trong 6 tình huống. Bài thử về đặc quyền tối thiểu cho tác tử AI được thiết kế để phát hiện chính lỗi suy luận đó.

Claude Sonnet 5 tự nhận ra cả 6 trường hợp ngoại lệ. Một dòng bổ sung yêu cầu Haiku kiểm tra trạng thái giao dịch trước khi thực hiện thao tác tài chính. Dòng chỉ dẫn hệ thống này cũng ngăn được toàn bộ lỗi. Tuy nhiên, cả hai biện pháp có thể biến mất khi doanh nghiệp đổi sang mô hình rẻ hơn. Việc chỉnh sửa chỉ dẫn để giảm chi phí vận hành cũng có thể loại bỏ chúng.

Biện pháp duy nhất hoạt động trong mọi lần thử là không cấp quyền hoàn tiền cho tác tử. Khi vai trò không có quyền billing:refund, lớp phân quyền chặn yêu cầu bất kể mô hình phía sau suy luận ra sao.

Kiểm soát an toàn tồn tại sau cả những đợt cắt giảm chi phí là quyền chưa từng được cấp.

Đặc quyền tối thiểu cần là nền móng của kiến trúc tác tử AI. Mục tiêu không chỉ là ngăn kẻ tấn công hoặc hạn chế hậu quả của thông tin xác thực bị lộ. Hệ thống còn phải ngăn một tác tử làm đúng chỉ dẫn sai, với tốc độ máy và không có người giám sát. Vấn đề này cũng xuất hiện trong những cuộc thảo luận rộng hơn về việc AI nên được trao bao nhiêu quyền trong trung tâm vận hành an ninh.

Nội dung: vai trò được định trước, công việc của tác tử thì không

Vai trò cố định không phù hợp với tác tử thay đổi công việc qua từng lần chạy. Một tác tử có thể cần nhiều quyền trong cả tuần nhưng chỉ cần một tập quyền nhỏ cho từng tác vụ, vì vậy rủi ro nên được đo theo chênh lệch giữa quyền tích lũy và quyền thực sự dùng trong mỗi lần chạy.

Vì sao vai trò cố định không phù hợp

Tài khoản dịch vụ thông thường nhận một vai trò cố định vì mỗi dịch vụ nhỏ thường làm một công việc có thể dự đoán. Dịch vụ thanh toán xử lý thanh toán, nên doanh nghiệp có thể giới hạn quyền một lần rồi rà soát định kỳ.

Theo The New Stack, cùng một tác tử hỗ trợ có thể đọc yêu cầu lúc 09:00, hoàn tiền lúc 09:04 và sửa số lượng chỗ ngồi lúc 09:11. Tập hợp mọi quyền nó có thể dùng trong cả tuần khác xa số quyền cần thiết cho một lần xử lý cụ thể.

Đo tỷ lệ quyền đã dùng trên tổng quyền được cấp không phản ánh đúng rủi ro. Nếu cấp 400 phạm vi quyền, mức sử dụng trông rất thấp. Nếu chỉ cấp 4, con số lại có vẻ hiệu quả. Chỉ số đó chủ yếu phản ánh quyết định cấu hình, không cho biết tác tử có thể gây thiệt hại đến đâu khi một lần chạy bị lỗi.

Đo hệ số vượt phạm vi

Cách tính có ý nghĩa hơn là lấy số lượng phạm vi quyền hợp nhất từng được sử dụng trong tất cả tác vụ. Sau đó, chia số này cho trung vị số phạm vi quyền được dùng trong mỗi tác vụ:

Hệ số vượt phạm vi = Số quyền hợp nhất của mọi tác vụ / Trung vị số quyền trong mỗi tác vụ

Theo thử nghiệm của The New Stack, hệ số này đạt 11,0. Trong 20 tác vụ, tập hợp chung có 22 phạm vi quyền, còn một tác vụ trung vị chỉ cần 2. Nếu một lần chạy bị xâm phạm, tác tử có thể tiếp cận tập quyền chung thay vì chỉ hai quyền thực sự cần cho công việc đó.

Thử nghiệm được thiết kế như thế nào

The New Stack đánh giá bốn mô hình phân quyền trong một môi trường có 30 phạm vi quyền và 20 tác vụ có thể kiểm tra tự động. Hai mô hình ngôn ngữ chạy với từng cấu hình, tạo thành 160 lần chạy. Kết quả được xác minh từ trạng thái hệ thống và nhật ký thực thi thay vì dựa vào câu trả lời do mô hình viết.

Môi trường và bộ tác vụ

Môi trường giả lập gồm 30 phạm vi quyền thuộc 9 nhóm. Các nhóm gồm yêu cầu hỗ trợ, người dùng, thanh toán, thuê bao, tệp, tin nhắn, kiểm toán, quản trị và tìm kiếm. Trong số đó, 13 quyền có thể thay đổi trạng thái hoặc đưa dữ liệu ra ngoài. Mỗi lệnh tương ứng đúng một phạm vi quyền. Hệ thống ghi lại cả lần gọi được chấp nhận lẫn lần bị từ chối.

Bộ thử nghiệm có 20 tác vụ. Mỗi tác vụ kết thúc bằng một thay đổi có thể kiểm tra tự động, chẳng hạn đóng yêu cầu hỗ trợ, hoàn tiền hóa đơn hoặc tính số chỗ ngồi vượt mức rồi đăng kết quả.

Trước khi chạy tác tử, nhóm thử nghiệm viết lời giải tham chiếu cho từng tác vụ. Lời giải xác nhận tác vụ có thể hoàn thành bằng giao diện dòng lệnh và xác định tập quyền tối thiểu từ những điểm cuối mà lời giải đúng thực sự sử dụng.

Bốn mô hình phân quyền

Bốn mô hình phân quyền được so sánh:

• Cấp rộng: một thông tin xác thực dài hạn chứa đủ 30 phạm vi quyền.
• Theo vai trò: vai trò hỗ trợ cố định có 17 phạm vi quyền, được xây dựng từ mô tả công việc thông thường.
• Theo tác vụ: quyền được cấp riêng cho từng lần chạy dựa trên kế hoạch đã khai báo và hết hạn khi lần chạy kết thúc.
• Cấp đúng lúc: bắt đầu với 0 quyền, sau đó yêu cầu từng quyền khi cần và phải nêu lý do.

Mỗi mô hình phân quyền được thử với Claude Haiku 4.5 và Claude Sonnet 5. Theo The New Stack, bộ thử nghiệm chỉ dùng thư viện chuẩn của Python, không cần thư viện ngoài hoặc khóa giao diện lập trình ứng dụng, nên các lần chạy tham chiếu và chỉ số có thể được tái tạo.

Phạm vi thiệt hại và khả năng hoàn thành

Theo số liệu từ The New Stack, phân quyền theo tác vụ đạt tỷ lệ hoàn thành 20/20 với cả hai mô hình. Cấu hình này chỉ kích hoạt 2/30 quyền, gồm 1 quyền có thể thay đổi trạng thái. Cấp rộng cũng hoàn thành 20/20 nhưng kích hoạt cả 30 quyền. Cấp đúng lúc giữ phạm vi thấp tương tự. Theo The New Stack, số lượt gọi tăng 79% với Haiku và 84% với Sonnet.

Các số liệu trong bảng lấy từ thử nghiệm 160 lần chạy do The New Stack công bố.

Hiệu quả của quyền theo tác vụ

Phân quyền theo tác vụ hoàn thành toàn bộ công việc trong khi chỉ giữ một phần mười lăm số quyền của phương án cấp rộng. Một số lần gọi bị từ chối rồi được thử lại không làm tổng lượng gọi giao diện lập trình ứng dụng tăng đáng kể. Trong thử nghiệm này, việc giảm phạm vi thiệt hại gần như không phát sinh chi phí vận hành.

Khoảng cách hoàn thành của mô hình theo vai trò không hoàn toàn bắt nguồn từ thiếu quyền. Cả hai mô hình ngôn ngữ đều dừng ở cùng 10 tác vụ. Chênh lệch một tác vụ xuất hiện vì dữ liệu có 3 yêu cầu đang mở với tiêu đề giống nhau. Sonnet không đoán yêu cầu nào cần đóng khi chạy với vai trò cố định, nhưng lại chọn yêu cầu có số nhỏ nhất trong ba cấu hình còn lại, dù vai trò đã có đủ quyền cho tác vụ đó.

Giới hạn của quyền theo vai trò

Xét cả phạm vi quyền và tỷ lệ hoàn thành, phân quyền theo vai trò cho kết quả kém nhất. Theo The New Stack, cấu hình này giữ số quyền nhiều gấp 8,5 lần mô hình theo tác vụ. Tuy vậy, nó chỉ hoàn thành khoảng một nửa số công việc. Vai trò còn cấp 4 quyền không tác vụ nào sử dụng và thiếu 9 quyền thiết yếu. Muốn mọi tác vụ đều chạy được, vai trò phải mở rộng lên 26 quyền. Trong khi đó, tác vụ trung vị chỉ cần 2 quyền.

Phân quyền theo vai trò vừa quá rộng vừa quá hẹp vì quyền được gắn với chức danh thay vì công việc thực tế.

Với phân quyền theo vai trò, mỗi mô hình gặp 10 lần từ chối quyền và thất bại ở mọi tác vụ bị chặn. Các lần từ chối chạm tới 8 trong 9 quyền còn thiếu. Hai quyền billing:refund và files:upload cùng chặn hai tác vụ. Quyền thứ chín, admin:update_settings, chưa bao giờ được gọi vì tác vụ đã thất bại trước đó tại admin:read_settings.

Trong cấu hình theo tác vụ, Haiku gặp một lần từ chối còn Sonnet gặp 6 lần trên tổng cộng 4 tác vụ, nhưng cả 4 tác vụ vẫn vượt qua bước xác minh. Các quyền bị từ chối chỉ thuộc những đường thăm dò tùy chọn, chẳng hạn thử điểm cuối tìm kiếm thay vì điểm cuối liệt kê. Quyền cốt lõi vẫn đủ để hoàn thành công việc.

Ba lớp phòng vệ cho tác tử AI

Ba lớp phòng vệ gồm năng lực suy luận của mô hình, chỉ dẫn hệ thống và chính sách phân quyền. Thử nghiệm cho thấy hai lớp đầu có thể ngăn lỗi nhưng phụ thuộc vào mô hình và câu chữ đang dùng. Lớp phân quyền chặn hành động gây hại ngay cả khi tác tử không tự phát hiện lỗi.

Các số liệu trong bảng do The New Stack ghi nhận trong bài thử ba lớp phòng vệ.

Vì sao mô hình và chỉ dẫn chưa đủ

Năng lực của mô hình không thể là lớp kiểm soát an ninh chính vì doanh nghiệp không sở hữu toàn bộ vòng đời mô hình. Khi bộ phận vận hành chuyển lưu lượng sang một mô hình rẻ hơn để giảm chi phí suy luận, bảo đảm an toàn có thể biến mất mà không tạo ra lỗi rõ ràng trong bộ kiểm thử.

Chỉ dẫn hệ thống cũng dễ thay đổi. Kỹ sư có thể rút gọn nội dung để tiết kiệm đơn vị xử lý hoặc viết lại cho một thử nghiệm, vô tình xóa hàng rào từng ngăn hành động tài chính sai. Những rủi ro tương tự khiến việc chia quyền giữa dữ liệu và mô hình AI trở thành một phần của thiết kế hệ thống, không chỉ là cấu hình phụ.

Quyền chưa từng được cấp vẫn bị chặn dù phía sau là mô hình nào, chỉ dẫn đã thay đổi ra sao hoặc đội vận hành còn nhớ lý do lập hàng rào hay không.

Rủi ro nằm ở quy mô quyền

Dữ liệu thử nghiệm không cho thấy tác tử vốn dĩ liều lĩnh. Trong các quy trình thông thường, theo The New Stack, tác tử chỉ gọi nhiều hơn mức tối thiểu tham chiếu từ 4% đến 5% số quyền. Rủi ro nằm ở quy mô. Một tác tử hoạt động có kỷ luật nhưng đang giữ 30 quyền vẫn có thể gây sai sót trên phạm vi 30 quyền khi gặp trường hợp ngoại lệ.

Mô hình danh tính dành riêng cho tác tử cần gì

Mô hình danh tính cho tác tử cần gắn quyền với từng lần thực thi, cho thông tin xác thực hết hạn cùng tác vụ và cung cấp đường nâng quyền có kiểm soát. Lần từ chối cũng phải giúp tác tử chuyển sang đường xử lý hợp lệ thay vì buộc hệ thống mở rộng một vai trò cố định.

Bốn yêu cầu thiết kế

1. Gắn thông tin xác thực với tác vụ thay vì tác nhân: trong thử nghiệm của The New Stack, quyền theo tác vụ giữ nguyên tỷ lệ hoàn thành và giảm phạm vi thiệt hại xuống một phần mười lăm. Cấu hình này không tạo chi phí đo được. Danh tính chính nên là lần thực thi cụ thể.
2. Cho quyền hết hạn cùng vòng đời lần chạy: thông tin xác thực theo tác vụ nhưng vẫn tồn tại sau khi tác vụ kết thúc sẽ dần trở thành một thông tin xác thực rộng. Tác vụ trung vị trong bộ thử nghiệm chỉ cần quyền cho một thao tác.
3. Dùng đường nâng quyền thay cho trần quyền cố định: theo The New Stack, cấp đúng lúc làm số lượt gọi tăng khoảng 80%. Con số này phản ánh chi phí của việc khám phá quyền trong khi chạy. Có thể khai báo trước khi bộ lập kế hoạch dự đoán được nhu cầu. Trường hợp chưa biết trước nên dùng cấp đúng lúc và ghi nhận từng lần nâng quyền.
4. Thiết kế lần từ chối để chuyển hướng tác tử: với quyền theo tác vụ, những lần bị từ chối không làm tác vụ thất bại vì tác tử vẫn có quyền cốt lõi. Nếu lần từ chối thường xuyên phá vỡ quy trình, cần sửa cách xác định quyền thay vì mở rộng vai trò cố định.

Áp dụng trong hạ tầng nhiều dịch vụ

Nguyên tắc này đặc biệt quan trọng khi tác tử AI trở thành một lớp hạ tầng mới trên Kubernetes. Trong môi trường đó, quyền truy cập có thể trải qua nhiều dịch vụ và tài nguyên trong cùng một lần chạy.

Nhật ký kiểm toán là bằng chứng an ninh chính

Nhật ký kiểm toán phải ghi cả lần gọi được chấp nhận, lần gọi bị từ chối và mỗi lần nâng quyền. Dữ liệu này cho biết quyền có khớp với quy trình hay không, hỗ trợ điều tra hành động ngoài luồng và cho phép xác minh kết quả từ thay đổi thực tế trong hệ thống.

Mọi thử nghiệm của The New Stack đều dùng nhật ký chỉ được phép ghi nối tiếp. Đây là dữ liệu trực tiếp để điều tra sự cố vận hành.

Giá trị của các lần gọi bị từ chối

Một lần gọi bị từ chối quan trọng không kém lần gọi thành công. Nó cho thấy quyền đang hoạt động không khớp với quy trình. Nguyên nhân có thể là xác định phạm vi sai hoặc chỉ dẫn độc hại. Với cấp đúng lúc, mỗi lần mở rộng đặc quyền đều có thời điểm và lý do cụ thể. Nhờ đó, quá trình điều tra dựa trên hồ sơ thay vì phỏng đoán.

Xác minh kết quả từ nhật ký

Nhật ký còn xác nhận tác tử không bỏ qua giao diện lập trình ứng dụng để sửa trực tiếp dữ liệu thử. Nếu tác tử báo hoàn thành nhưng nhật ký không có lệnh thay đổi tương ứng, hệ thống có cơ sở nhận diện can thiệp ngoài luồng. Theo The New Stack, cả 160 lần chạy đều nhất quán. Kết quả này được xác minh trực tiếp từ nhật ký thực thi.

Cách đánh giá quyền trong hệ thống đang vận hành

Để đánh giá quyền của tác tử đang vận hành, hãy so sánh hai giá trị. Giá trị thứ nhất là tổng số phạm vi quyền hợp nhất trong một tuần. Giá trị thứ hai là trung vị số quyền dùng trong mỗi lần chạy. Hệ số cao cho thấy bề mặt quyền lớn hơn nhu cầu của từng tác vụ. Khi đó, tác tử là ứng viên phù hợp cho phân quyền theo lần thực thi.

Tính hệ số quyền từ dữ liệu vận hành

Hãy lấy dữ liệu của một tuần và tính hai giá trị: tổng số phạm vi quyền hợp nhất đã được dùng trong mọi lần chạy, cùng trung vị số quyền được dùng trong từng lần chạy. Chia giá trị thứ nhất cho giá trị thứ hai.

Theo cách diễn giải của The New Stack, tỷ lệ gần 1,0 cho thấy tác tử thực hiện một công việc cố định. Trong trường hợp đó, thông tin xác thực cố định có thể phù hợp. Nếu tỷ lệ tiến gần 11,0 như trong bộ thử nghiệm, bề mặt quyền của mỗi lần chạy lớn hơn khoảng một bậc so với nhu cầu thực tế.

Sau đó, hãy xem lại hành động có tính phá hủy gần nhất mà tác tử thực hiện sai và xác định lớp nào lẽ ra phải ngăn nó. Nếu hệ thống chỉ dựa vào năng lực mô hình hoặc câu chữ trong chỉ dẫn, biện pháp bảo vệ có thể biến mất trong lần tối ưu chi phí tiếp theo. Trong thử nghiệm được công bố, mô hình rẻ hơn thực hiện sai cả 6 hành động tài chính dù dữ liệu mâu thuẫn đã hiển thị trực tiếp. Cấu hình duy nhất chặn được cả 6 lần là cấu hình không có quyền thực hiện hành động đó.

Nếu đang vận hành tác tử AI, hãy bắt đầu bằng việc rà soát một tuần nhật ký và thu hẹp quyền của từng lần chạy trước khi mở rộng thêm quyền cố định.