AI agent an toàn: thiết kế quyền hạn để giảm blast radius
Prompt filter là lớp hỗ trợ, không phải ranh giới tin cậy. Bài viết này đi từ mô hình quyền, broker hành động đến diễn tập rollback để AI agent không trở thành điểm yếu production.
Ngày đăng:
Một AI agent thường bắt đầu rất vô hại: đọc tài liệu, trả lời câu hỏi nội bộ hoặc tóm tắt ticket. Sau vài tuần, người dùng muốn nó tra cứu CRM, tạo yêu cầu, cập nhật bảng tính hoặc gọi API vận hành. Lúc này, rủi ro không còn nằm ở một câu trả lời sai. Rủi ro nằm ở việc một hệ thống xác suất có thể tác động lên dữ liệu và dịch vụ thật với tốc độ nhanh hơn khả năng nhận ra của con người.
Đây là lý do không nên đặt kỳ vọng sai vào prompt filter. Filter, classifier và guardrail có thể chặn nhiều mẫu tấn công hoặc câu lệnh không phù hợp. Chúng rất đáng có. Nhưng chúng không tạo ra một trust boundary cứng giống như quyền truy cập database hay network policy. Dữ liệu không tin cậy vẫn có thể xuất hiện trong email, file, web page hoặc kết quả tìm kiếm; mô hình có thể hiểu sai bối cảnh; còn mẫu tấn công có thể thay đổi nhanh hơn rule.
Đặt câu hỏi đúng: agent có thể làm gì khi bị dẫn sai?
Thay vì cố chứng minh agent sẽ không bao giờ bị đánh lừa, hãy giả định nó có thể bị dẫn tới một hành động không mong muốn. Khi đó, hãy vẽ bản đồ bốn phần cho từng agent: dữ liệu được đọc, nguồn dữ liệu không tin cậy, công cụ có thể gọi và đích mà dữ liệu hoặc hành động có thể đi tới. Một agent cùng lúc có quyền đọc dữ liệu nhạy cảm, đọc email từ bên ngoài và gửi nội dung tới một dịch vụ ngoài tổ chức cần được xem là rủi ro cao ngay cả khi prompt hiện tại trông rất an toàn.
Bản đồ này nên có owner nghiệp vụ và owner kỹ thuật. Owner nghiệp vụ trả lời agent tạo ra giá trị gì và hành động nào có thể chấp nhận. Owner kỹ thuật trả lời danh tính nào được dùng, tool nào tồn tại, log lưu ở đâu và cách dừng agent khi có sự cố. Nếu không rõ hai owner này, agent chưa sẵn sàng vào production.
Danh tính và quyền hạn: nền móng trước mọi guardrail
Agent không nên thừa hưởng raw token dài hạn của người dùng, càng không nên chạy bằng tài khoản quản trị dùng chung. Cách làm an toàn hơn là cấp workload identity riêng, token ngắn hạn và scope đủ nhỏ cho một tác vụ. Khi agent hành động thay người dùng, quyền hiệu lực nên là giao của quyền người dùng, capability của agent và policy của tài nguyên. Điều này ngăn một agent được dùng bởi người có quyền thấp lại vô tình có quyền của một service account quá rộng.
Secret cũng cần được giữ ngoài model context. Mô hình có thể tạo ý định gọi công cụ, nhưng broker hoặc tool runner mới lấy credential từ vault tại thời điểm thực thi. Credential không nên xuất hiện trong prompt, log ứng dụng, response hay transcript để debug. Đây là một nguyên tắc đơn giản nhưng rất dễ bị phá vỡ khi team cố làm demo nhanh.
Để mô hình đề xuất, để broker thực thi
Một kiến trúc tốt tách agent khỏi quyền gọi API trực tiếp. Agent trả về một intent có cấu trúc, chẳng hạn “mở ticket với mức độ P2” hoặc “truy vấn trạng thái đơn hàng X”. Broker độc lập kiểm tra schema, user context, policy, allowlist endpoint, quota và tham số trước khi chạy. Với thao tác có ảnh hưởng lớn, broker chuyển yêu cầu sang hàng đợi phê duyệt thay vì tự gọi tool.
Sự tách này có hai lợi ích. Thứ nhất, policy có thể được kiểm tra bằng code xác định, không phụ thuộc vào model có “ngoan” hay không. Thứ hai, log dễ đọc hơn: ta biết agent đề xuất gì, broker từ chối hay chấp nhận vì rule nào, và tool thực sự đã làm gì. Đó là dữ liệu cần có khi khách hàng, auditor hoặc đội điều tra hỏi vì sao một hành động xảy ra.
Phê duyệt con người không cần trở thành nút thắt
Không cần bắt con người duyệt mọi thao tác. Điều đó chỉ tạo approval fatigue và sau cùng mọi người bấm đồng ý theo phản xạ. Hãy phân tầng theo mức tác động. Agent có thể tự động làm các thao tác chỉ đọc hoặc thay đổi nhỏ, có thể đảo ngược, trong phạm vi đã được kiểm soát. Các hành động xóa, thay đổi production, gửi dữ liệu ra bên ngoài, thay đổi firewall, phát sinh chi phí hoặc tạo nghĩa vụ với khách hàng phải có approval rõ ràng.
Approval tốt cần cho người duyệt đủ ngữ cảnh: agent định làm gì, dữ liệu nào bị dùng, tài nguyên nào bị tác động, policy nào cho phép và rollback là gì. Một nút “Approve” không có ngữ cảnh không phải kiểm soát; nó chỉ chuyển rủi ro sang một con người.
Quan sát, kill switch và diễn tập thực tế
Mỗi lần tool được gọi nên tạo audit trail gồm input đã được che dữ liệu nhạy cảm, danh tính, quyền hiệu lực, quyết định policy, kết quả và correlation ID. Hệ thống nên có giới hạn tốc độ, quota theo agent, cảnh báo hành vi bất thường và kill switch hoạt động độc lập với model. Kill switch cần được thử: ai có quyền dùng, mất bao lâu và những hàng đợi đang chạy được xử lý thế nào?
Trước release, hãy chạy các test tình huống: file chứa chỉ dẫn độc hại, API trả response bất ngờ, token hết hạn giữa phiên, tool timeout, người duyệt từ chối và rollback sau một thay đổi giả lập. Các test này không chứng minh agent hoàn hảo; chúng chứng minh hậu quả được khoanh vùng và đội ngũ biết cách vận hành khi điều xấu xảy ra.
Mở rộng theo nấc trưởng thành
Giai đoạn một, chỉ cho agent đọc và tóm tắt dữ liệu đã được chọn lọc. Giai đoạn hai, cho phép agent tạo đề xuất để con người phê duyệt. Giai đoạn ba, tự động hóa một số hành động low-risk có quota, allowlist và rollback. Chỉ khi telemetry, incident process và owner đã trưởng thành mới nên cân nhắc hành động có tác động lớn hơn. Đi chậm ở đây không làm mất lợi ích của AI; nó giúp lợi ích đó không bị trả giá bằng một sự cố mà tổ chức không giải thích được.