AI agents have graduated from chat windows. They now book meetings, update customer records, query internal databases, a

AI agents đã vượt ra khỏi các cửa sổ chat. Giờ đây, chúng đặt lịch họp, cập nhật hồ sơ khách hàng, truy vấn cơ sở dữ liệu nội bộ và kích hoạt các giao dịch tài chính. Sự chuyển dịch từ vai trò cố vấn sang vai trò vận hành làm thay đổi mọi thứ về rủi ro. Khi phần mềm ngừng đưa ra gợi ý và bắt đầu thực hiện hành động, mọi API endpoint đều trở thành một cánh cửa tiềm năng. Các mô hình bảo mật truyền thống được xây dựng dựa trên hành vi có thể dự đoán của con người: một người đăng nhập, nhấp qua các lộ trình quen thuộc và đăng xuất. Các tác nhân tự trị không tuân theo những mô hình đó. Chúng lặp lại, thử lại và phân nhánh qua hàng trăm lượt gọi chỉ trong vài giây. Lớp API, vốn được thiết kế cho các yêu cầu do con người khởi xướng, giờ đây phải đối mặt với áp lực tự động hóa liên tục. Nếu các biện pháp phòng thủ của bạn vẫn dựa trên các quy tắc tĩnh được viết từ quý trước, bạn đang để ngỏ cửa cho việc rò rỉ dữ liệu và truy cập trái phép. Bạn cần một hệ thống phòng thủ thời gian thực để đánh giá mọi lượt gọi ngay khi chúng diễn ra.

Giới hạn đặc quyền của tác nhân

Lối tắt nguy hiểm nhất trong việc triển khai tác nhân là bàn giao một API key quyền năng duy nhất. Một mã khóa cấp quyền truy cập cho tất cả, trên mọi hệ thống. Nếu kẻ tấn công chiếm quyền kiểm soát tác nhân thông qua một prompt bị đầu độc hoặc một tích hợp bị chiếm đoạt, chúng sẽ thừa hưởng "chìa khóa vạn năng" của toàn bộ hệ thống. Việc khôi phục sẽ trở thành một cơn ác mộng vì phạm vi ảnh hưởng bao trùm mọi thứ, từ dịch vụ email đến cơ sở dữ liệu production của bạn.

Hãy chấm dứt thói quen đó ngay lập tức. Hãy bắt đầu với OAuth 2.0 để ủy quyền đại diện. Tác nhân không nên xác thực dưới tư cách là một superuser độc lập. Thay vào đó, nó nên mang một token đại diện cho cả tác nhân và người dùng cuối mà nó phục vụ. Khi phiên làm việc của con người kết thúc, quyền truy cập của tác nhân cũng phải chấm dứt theo.

Token Exchange giúp việc này trở nên khả thi. Hãy cấp các token có thời hạn ngắn, được giới hạn phạm vi (scoped) chính xác với những gì tác nhân cần ngay lúc này. Một tác nhân lập lịch có thể được cấp quyền đọc lịch và gửi lời mời, nhưng không được phép xóa hạ tầng lịch hoặc truy cập các API bảng lương. Nếu kẻ tấn công chặn được token, cửa sổ để lạm dụng sẽ rất hẹp.

Context-Bound Scopes (Phạm vi giới hạn theo ngữ cảnh) thêm một lớp bảo vệ nữa. Hãy mặc định mọi token ở chế độ chỉ đọc (read-only). Nếu tác nhân phải ghi dữ liệu, chẳng hạn như xử lý hoàn tiền hoặc cập nhật hợp đồng, hãy áp dụng một cổng phê duyệt của con người. Đừng bao giờ để mô hình tự mình quyết định khi nào tiền được chuyển, tài khoản thay đổi hoặc hồ sơ biến mất. Quyền hạn phải khớp với thời điểm thực hiện, chứ không phải là quyền hạn tối đa.

Ephemeral Windows (Cửa sổ tạm thời) đóng kín vòng lặp hoàn toàn. Hãy giữ thời gian sống của token tính bằng phút, không phải bằng ngày. Một token bị thu thập trong một đợt xâm nhập ngắn ngủi sẽ trở nên vô dụng vào thời điểm kẻ tấn công cố gắng phát lại (replay) nó. Hãy coi nó như một ổ khóa xoay vòng liên tục.

Hãy xem xét một tác nhân tự động hóa bán hàng có nhiệm vụ đọc dữ liệu khách hàng tiềm năng từ CRM và viết email theo dõi thông qua API email của bạn. Thay vì một admin key vĩnh viễn, tác nhân sẽ nhận được một token có thời hạn 15 phút từ nhà cung cấp danh tính của bạn. Token này cho phép đọc CRM và gửi email, nhưng chặn việc xóa liên hệ và truy cập thanh toán. Nếu tác nhân gặp một chỉ dẫn đáng ngờ yêu cầu xuất toàn bộ cơ sở dữ liệu, phạm vi quyền hạn sẽ đơn giản là ngăn chặn nỗ lực đó.

Ngăn chặn Prompt Injection gián tiếp

Prompt injection không còn là một trò diễn cho các chatbot nữa. Trong kỷ nguyên của các tác nhân (agentic era), nó hoạt động giống như việc thực thi mã từ xa (remote code execution) được gửi qua email.

Đây là một kịch bản cụ thể. Một tác nhân theo dõi hộp thư đến của người dùng để lên lịch họp. Nằm sâu bên trong một tin nhắn, có thể là trong văn bản ẩn hoặc siêu dữ liệu (metadata) trong một tệp đính kèm, là một câu lệnh như chuyển tiếp tất cả hóa đơn đến một địa chỉ bên ngoài và xóa các bản gốc. Tác nhân đọc email, nhầm lẫn văn bản bị đầu độc là một chỉ dẫn hệ thống hợp lệ và bắt đầu gọi các API. Vì bản thân tác nhân đã được ủy quyền, các yêu cầu độc hại sẽ trôi qua các kênh thông thường. Kết quả là việc trích xuất dữ liệu trái phép diễn ra mà trông giống như hành vi tiêu chuẩn.

Lớp phòng thủ đầu tiên của bạn là xác thực đầu vào nghiêm ngặt. Hãy coi mọi tham số mà AI tạo ra là không đáng tin cậy cho đến khi được chứng minh ngược lại. Hãy chạy xác thực JSON-schema tại API gateway của bạn. Nếu tác nhân yêu cầu một hồ sơ khách hàng, gateway nên xác minh rằng payload chỉ chứa một định danh duy nhất như mong đợi, chứ không phải là một ký tự đại diện (wildcard) hoặc một yêu cầu theo lô (batch request) lớn bất thường. Hãy từ chối bất kỳ thứ gì sai định dạng, quá kích thước hoặc kỳ quặc một cách nhân tạo trước khi nó chạm tới backend của bạn.

Thứ hai, triển khai các bộ lọc thất thoát dữ liệu trên luồng phản hồi. Các phản hồi API nên được kiểm tra trước khi chúng đến với AI. Hãy quét các mẫu khớp với thông tin bí mật, mã xác thực hoặc thông tin cá nhân hàng loạt. Nếu một truy vấn CRM trả về mười nghìn bản ghi thay vì một, hãy chặn nó. Nếu payload chứa một API key nội bộ, hãy che nó đi. Agent không cần các thông tin bí mật thô để thực hiện công việc của mình, và các kênh đầu ra không được trở thành con đường vận chuyển trái phép dữ liệu bị đánh cắp.

Thứ ba, thực thi danh sách trắng tên miền (domain whitelisting). Agent cần giao tiếp với dịch vụ lịch, bộ xử lý thanh toán và hệ thống kho nội bộ của bạn. Nó không cần phải kết nối với các trang chia sẻ tệp tùy ý, các dịch vụ pasteboard hoặc các điểm cuối lưu trữ đám mây nước ngoài. Hãy giới hạn việc phân giải DNS đầu ra và các yêu cầu HTTP trong một danh sách cho phép (allow-list) cụ thể. Ngay cả khi kẻ tấn công lừa được agent cố gắng gửi dữ liệu đi nơi khác, tầng mạng sẽ đơn giản là từ chối kết nối.

Xây dựng Kiến trúc Zero-Trust

Zero-trust không phải là một sản phẩm bạn cài đặt. Đó là một triết lý thiết kế được xây dựng trên một giả định duy nhất: agent đã bị xâm nhập. Hãy hành động tương ứng.

Điều đó có nghĩa là phải tách biệt danh tính một cách rõ ràng. Người dùng và agent không phải là cùng một thực thể, ngay cả khi agent đang hành động thay mặt người dùng. Hãy duy trì các danh tính dịch vụ riêng biệt cho chính agent, khác biệt với phiên SSO của con người. Nhật ký kiểm tra (audit logs) của bạn nên ghi lại cả hai danh tính cạnh nhau. Khi có điều gì đó không ổn, bạn