Cấp cho tác tử AI đúng bộ quyền nhỏ nhất đủ để nó làm xong việc, không hơn. Thực tế là: tài khoản riêng cho tác tử thay vì dùng tài khoản của mình, chỉ cho đọc ở mọi chỗ có thể, chỉ mở đúng thư mục hay hộp thư cần thiết thay vì mở hết, đặt hạn mức chi tiêu và gửi đi, bắt duyệt với hành động không đảo ngược được, và có sẵn cách thu hồi quyền trong vài phút đã thử trước. Nguyên tắc này gọi là quyền tối thiểu (least privilege), đã bảo vệ hệ thống máy tính hàng chục năm, và càng quan trọng hơn khi người dùng là một phần mềm có thể bị rối hoặc bị lừa.
Cám dỗ thì dễ hiểu. Nối tác tử vào email và ổ dữ liệu chính chỉ bằng một cú bấm là xong, còn cấp quyền hẹp thì tốn công. Nhưng tác tử cầm toàn quyền của mình thì làm được mọi thứ mình làm được, kể cả những lỗi mình không bao giờ mắc. Bỏ vài giờ sắp xếp từ đầu rẻ hơn rất nhiều so với dọn hậu quả một email gửi nhầm cho cả danh sách khách hay một thư mục chung bị xoá.
Vì sao cấp quyền cho tác tử quan trọng hơn cho người?
Khi một người có quyền vào hệ thống, vài thứ tự nhiên giới hạn thiệt hại họ có thể gây ra: họ mệt, họ thấy lạ thì khựng lại, họ ngần ngừ trước khi xoá thư mục tên “Hợp đồng 2025”. Tác tử không có cái phanh nào như vậy. Nó làm hàng trăm thao tác trong vài phút và sẽ làm theo những chỉ dẫn mà người thường thấy kỳ quặc.
Tác tử còn có thể bị dắt mũi. Nó đọc email, trang web, tài liệu trong lúc làm việc, và trong đó có thể có những đoạn chữ cố tình cài vào để ra lệnh mới cho nó. Tác tử được phép làm càng nhiều, kẻ tấn công càng được lợi nếu lái được nó.
Sai sót cũng nhân lên theo kiểu khác. Một nhân viên hiểu nhầm việc thường chỉ làm sai một hai món trước khi có người phát hiện. Tác tử hiểu nhầm thì áp đúng lỗi đó lên mọi món trong cả lô. Quyền hẹp biến một thảm hoạ tiềm tàng thành một phiền toái khoanh vùng được.
Cuối cùng, quyền hạn là thứ giúp lần ra hành động của tác tử. Nó làm việc dưới tài khoản riêng thì mọi thay đổi đều mang tên nó trong nhật ký hệ thống. Nó dùng tài khoản của mình thì việc nó làm và việc mình làm trộn vào nhau, điều tra sự cố thành đoán mò.
Nguyên tắc thực tế khi cấp quyền
Tạo tài khoản riêng cho tác tử. Dùng một tài khoản người dùng hay tài khoản dịch vụ riêng, đặt tên rõ ràng, không dùng tài khoản cá nhân của mình. Như vậy việc nó làm hiện rõ và tắt đi cũng dễ.
Bắt đầu bằng quyền chỉ đọc. Nhiều việc hữu ích như tóm tắt, so sánh, theo dõi chỉ cần đọc. Quyền ghi để sau, và chỉ mở ở đúng chỗ cần.
Khoanh phạm vi cụ thể. Cấp một nhãn thư, một thư mục, một dự án, chứ không phải cả ổ dữ liệu hay mọi hộp thư.
Ưu tiên nháp thay vì gửi. Để tác tử tạo bản nháp, đề xuất thay đổi hay đơn hàng chờ, rồi người duyệt.
Đặt hạn mức cứng. Giới hạn số email mỗi ngày, giá trị mỗi lần mua, và tổng chi cho các dịch vụ trả phí mà tác tử được gọi.
Đừng đưa mật khẩu gốc. Dùng cách kết nối phần mềm hỗ trợ, như cấp quyền ứng dụng có giới hạn và thu hồi được. Tuyệt đối không dán mật khẩu quản trị vào chỉ dẫn cho tác tử.
Bảo vệ tài khoản mà tác tử dùng. Bật xác thực hai lớp cho người chủ quản và cất thông tin đăng nhập của tài khoản tác tử trong trình quản lý mật khẩu.
Tách môi trường thử và thật. Cho tác tử chạy trên bản sao dữ liệu hoặc môi trường thử trước khi nối vào hệ thống đang chạy.
Rà quyền định kỳ. Vài tháng một lần xem mỗi tác tử đang vào được những đâu, bỏ những gì không còn cần.
Các mức quyền và khi nào dùng
Chỉ nâng một mức khi việc thật sự cần và đã có hồ sơ cho thấy tác tử chạy ổn định.
| Mức | Tác tử làm được gì | Hợp với |
|---|---|---|
| Chỉ đọc | Xem tệp, email, hồ sơ; làm bản tóm tắt, báo cáo | Tìm hiểu, theo dõi, trích dữ liệu, thử nghiệm đầu tiên |
| Tạo bản nháp | Viết bản nháp hay đề xuất mới, người phải duyệt | Trả lời khách, văn bản, bài đăng, đề xuất mua hàng |
| Ghi trong hạn mức | Tạo hoặc cập nhật hồ sơ, gửi số tin nhắn có giới hạn | Cập nhật thường lệ sau nhiều tuần nháp ổn định |
| Hành động có duyệt | Làm việc nhạy cảm chỉ sau khi người xác nhận từng lần | Đặt hàng, hẹn giờ gửi, sửa trang công khai |
| Toàn quyền | Làm mọi thứ tài khoản đó làm được | Hiếm khi chính đáng; tránh với dữ liệu doanh nghiệp |
Thu hồi quyền thật nhanh thế nào?
Tập làm trước khi cần, đừng đợi tới lúc có sự cố.
- Biết rõ mọi kết nối nằm ở đâu. Giữ một danh sách đơn giản: tên tác tử, nối vào đâu, dùng tài khoản nào, ai cài đặt.
- Tìm trang “ứng dụng đã kết nối” của từng dịch vụ. Email, ổ đám mây và nhiều phần mềm quản lý có trang liệt kê ứng dụng được cấp quyền. Lưu sẵn đường dẫn.
- Vô hiệu tài khoản hoặc mã truy cập của tác tử. Tắt tài khoản riêng của nó là dừng mọi thứ trong một lần, đó là lý do tài khoản riêng quan trọng.
- Đổi các khoá bí mật dùng chung. Khoá hay mật khẩu từng để chỗ tác tử đọc được thì thay mới.
- Xem nhật ký để biết chuyện gì đã xảy ra. Rà các hành động gần đây dưới tài khoản tác tử để biết cần hoàn tác gì.
- Ghi lại bài học. Sửa cách cài đặt để chuyện cũ không lặp lại.
Ví dụ cụ thể: tác tử đọc hoá đơn nhà cung cấp
Một cửa hàng bán sỉ ở Cần Thơ muốn có tác tử đọc hoá đơn nhà cung cấp gửi qua email rồi nhập tổng tiền, ngày, tên nhà cung cấp vào bảng tính. Cài nhanh thì nối tác tử vào hộp thư của chủ cửa hàng và cả ổ dữ liệu công ty. Cài cẩn thận thì tốn thêm một buổi chiều.
Bước một, nhờ nhà cung cấp gửi hoá đơn về một địa chỉ riêng, hoặc đặt luật lọc thư dồn chúng vào một nhãn. Tác tử chỉ được đọc đúng nhãn đó. Bước hai, tác tử được sửa đúng một bảng tính, không phải cả ổ, và không xoá được dòng nào. Bước ba, hoá đơn nào đọc không rõ thì liệt kê ra cho người kiểm, không đoán. Tác tử hoàn toàn không gửi được email.
Lỡ có chuyện, chẳng hạn một “hoá đơn” giả chứa chỉ dẫn kỳ quặc, thì tệ nhất tác tử cũng chỉ thêm một dòng sai vào một bảng, và đợt kiểm hằng tuần sẽ bắt được. So với tác tử cầm nguyên hộp thư của chủ: cùng email giả đó có thể khiến nó chuyển tiếp thư riêng hay trả lời khách. Một buổi chiều bỏ thêm đổi lấy một kịch bản xấu nhất khác hẳn.
Câu hỏi thường gặp
Nối tác tử AI vào email chính có an toàn không?
Rủi ro nếu tác tử được toàn quyền đọc và gửi. Nên dùng hộp thư hoặc nhãn riêng, chỉ cho đọc, và để nó tạo nháp thay vì gửi thẳng, nhất là lúc đầu.
Tài khoản dịch vụ là gì?
Đó là tài khoản tạo cho phần mềm chứ không cho người, có bộ quyền giới hạn riêng. Dùng nó cho tác tử giúp tách việc nó làm khỏi việc của mình và tắt được nó mà không ảnh hưởng tới nhân viên.
Đưa mật khẩu cho tác tử dùng một lần có được không?
Nên tránh. Mật khẩu dán vào chỉ dẫn có thể bị lưu trong nhật ký hay bộ nhớ và bị dùng lại về sau. Hãy dùng kết nối được cấp quyền, có giới hạn và thu hồi được.
Bao lâu nên rà quyền của tác tử một lần?
Ít nhất vài tháng một lần, và mỗi khi việc thay đổi, người cài đặt nghỉ việc, hoặc tác tử cư xử bất thường.
Quyền tối thiểu có làm tác tử chậm lại không?
Đôi khi nó thêm một bước duyệt, tốn chút thời gian. Cái giá đó nhỏ so với thời gian khắc phục một lần gửi email hàng loạt sai hay tệp bị xoá.
Trong công ty nhỏ ai nên giữ quyền quản lý tác tử?
Một người cụ thể, thường là người lo IT hoặc chủ doanh nghiệp, duyệt kết nối mới và giữ danh sách mỗi tác tử vào được đâu. Ai cũng quản thường là không ai quản.
