Chống prompt injection cho AI agent: lọc đầu vào chưa đủ

Để chống prompt injection cho AI agent, hãy tách nội dung agent đọc khỏi chỉ thị điều hành và kiểm tra quyền trước khi thực thi từng lệnh gọi công cụ. Những thao tác như gửi email, sửa dữ liệu hoặc chuyển thông tin ra ngoài cần được giới hạn theo nhiệm vụ; thao tác nhạy cảm phải được người có thẩm quyền duyệt. Tài liệu Microsoft khuyến nghị kết hợp lọc prompt, xử lý nội dung truy xuất, giới hạn quyền và giám sát.

Bộ lọc đầu vào có thể nhận ra một số mẫu tấn công, nhưng không quyết định được người dùng có quyền yêu cầu hành động mà mô hình đề xuất hay không. Hướng dẫn OWASP về prompt injection nêu các hậu quả gồm rò rỉ dữ liệu, lộ chỉ thị hệ thống và gọi công cụ trái phép; hướng dẫn này đặt lọc nội dung trong một quy trình có kiểm tra quyền, đầu ra và hành động.

Đánh dấu ranh giới tin cậy trên đường đi của dữ liệu

Hãy bắt đầu từ luồng thực tế: người dùng giao việc, agent đọc trang web, email hoặc tài liệu, mô hình tạo câu trả lời hoặc đề xuất gọi công cụ, rồi thành phần thực thi xử lý đề xuất đó. Rủi ro nằm ở chỗ nội dung được đọc có thể trông giống một mệnh lệnh. Một trang web có thể cung cấp thông tin để tóm tắt, nhưng câu chữ trên trang không được thay đổi mục tiêu công việc hay cấp thêm quyền cho agent.

Ở tầng ứng dụng, gắn nguồn cho từng phần nội dung: chỉ thị của ứng dụng, yêu cầu của người dùng đã xác thực, dữ liệu truy xuất và kết quả công cụ. Lưu địa chỉ nguồn hoặc mã tài liệu cùng phiên làm việc để lần theo đề xuất hành động. Tài liệu trong kho nội bộ vẫn cần được xét theo quyền truy cập và tính toàn vẹn; vị trí lưu trữ không tự biến nội dung tài liệu thành chỉ thị điều hành.

Câu hỏi của người dùng cũng có thể chứa chỉ thị độc hại. Vì vậy, ứng dụng cần xác định người yêu cầu được làm gì trước khi đưa yêu cầu vào quy trình; mô hình không thể tự suy ra quyền từ cách diễn đạt của câu hỏi. Với nội dung truy xuất, ranh giới còn rõ hơn: đó là dữ liệu phục vụ nhiệm vụ đã được giao, kể cả khi bên trong có câu tự xưng là thông báo hệ thống.

Giữ nội dung truy xuất ở vai trò dữ liệu

Trước khi đưa nội dung bên ngoài vào ngữ cảnh của mô hình, hãy chuẩn hóa định dạng, chỉ lấy phần cần cho nhiệm vụ và kiểm tra dấu hiệu bất thường như chỉ thị giả danh vai trò hệ thống, chữ ẩn hoặc nội dung được mã hóa. Đặt phần truy xuất trong một vùng có nhãn nguồn rõ ràng để mô hình có cơ sở phân biệt dữ liệu với chỉ thị. Nhãn và dấu phân cách giúp trình bày ranh giới, nhưng không phải cơ chế cấp quyền.

Ví dụ giả định: người dùng yêu cầu tóm tắt một email, còn nội dung email bảo agent chuyển toàn bộ hộp thư đến một địa chỉ khác. Agent có thể tóm tắt email; lệnh chuyển tiếp là một phần của nội dung cần phân tích, không phải yêu cầu mới từ người dùng. Nếu agent trích các trường từ email để dùng ở bước sau, ứng dụng cần kiểm tra kiểu dữ liệu, độ dài và giá trị được phép trước khi chuyển các trường ấy sang công cụ.

Khi bộ lọc phát hiện một đoạn đáng ngờ, hãy ghi lại quyết định xử lý và giữ đủ ngữ cảnh để người dùng vẫn nhận được kết quả hợp lệ khi có thể. Có thể loại phần chèn bất thường khỏi dữ liệu đưa vào mô hình, hoặc chuyển tác vụ sang bước xem xét nếu việc loại bỏ làm mất nghĩa của tài liệu. Cần kiểm tra cả nội dung do công cụ trả về: một đoạn trích tìm kiếm hay kết quả truy vấn cũng có thể mang chỉ thị cài sẵn.

Kiểm tra quyền ngay tại công cụ

Agent được giao đọc tài liệu để trả lời thường chỉ cần quyền đọc đúng tài nguyên liên quan. Tách quyền đọc khỏi quyền ghi và gửi; giới hạn tài khoản dịch vụ, phạm vi API và danh sách công cụ theo từng nhiệm vụ. Hướng dẫn bảo mật agent của OWASP yêu cầu áp dụng quyền tối thiểu và thực thi kiểm tra ủy quyền bên ngoài ngữ cảnh của mô hình.

Trước mỗi lệnh gọi, thành phần thực thi cần đối chiếu danh tính người yêu cầu, công cụ, tài nguyên đích, tham số và quyền của phiên làm việc. Công cụ chưa được khai báo phải bị từ chối; một lời giải thích có vẻ hợp lý do mô hình tạo ra không thay thế được kiểm tra quyền. Trong ví dụ tóm tắt email, phiên chỉ được đọc thư đã chọn thì chỉ thị nằm trong thư không thể tự mở quyền gửi hoặc đọc cả hộp thư.

Kiểm tra tham số quan trọng không kém kiểm tra tên công cụ. Nếu agent được phép lấy một tài liệu, thành phần thực thi vẫn phải xác nhận đường dẫn hoặc mã tài liệu nằm trong phạm vi cho phép. Nếu được phép gửi thông báo tới một nhóm nhận cố định, địa chỉ do nội dung truy xuất đề xuất không được tự động trở thành đích gửi. Giới hạn số lần gọi và phạm vi dữ liệu còn giúp ngăn một chuỗi lệnh hợp lệ riêng lẻ tạo ra tác động vượt quá nhiệm vụ.

Duyệt hành động nhạy cảm và kiểm tra đầu ra

Với thao tác làm thay đổi trạng thái hoặc đưa dữ liệu ra ngoài, agent nên tạo đề xuất để duyệt trước khi thực hiện. Bản xem trước cần nêu thao tác, người nhận hoặc tài nguyên đích, nội dung và các tham số có tác dụng. Quyết định duyệt phải gắn với đúng người yêu cầu và đúng lệnh gọi; đổi địa chỉ nhận, nội dung hoặc tài nguyên thì phải duyệt lại.

Thành phần thực thi phải tự xác minh quyết định duyệt còn hiệu lực và chưa được dùng, thay vì tin vào một cờ xác nhận do agent đưa ra. Việc kiểm tra cần diễn ra ngay trước khi chạy lệnh để đề xuất được duyệt không bị thay tham số ở khoảng giữa. Nếu không xác minh được quyền hoặc trạng thái duyệt, lệnh phải dừng tại công cụ.

Đầu ra cần được kiểm tra theo nơi nó sắp đến. Câu trả lời cho người dùng có thể chứa dữ liệu nhạy cảm hoặc chỉ thị hệ thống bị lộ; tham số gửi sang công cụ cần tuân theo cấu trúc trường, giới hạn độ dài, đích đến và phạm vi quyền. Nếu đầu ra được hiển thị dưới dạng HTML hoặc đưa vào truy vấn ở bước tiếp theo, thành phần nhận phải áp dụng cách kiểm tra phù hợp với định dạng đó. Một câu trả lời cuối cùng có vẻ đúng không cho biết các hành động trung gian đã được phép hay chưa.

Ghi log và thử injection gián tiếp trên đúng kênh

Log nên cho thấy agent đã đọc nguồn nào, đề xuất lệnh gọi gì, chính sách nào cho phép hoặc chặn, ai duyệt và kết quả thực thi ra sao. Ghi mã nguồn, loại hành động, quyết định ủy quyền và trạng thái thực thi thay vì sao chép toàn bộ nội dung nhạy cảm. Khóa truy cập, dữ liệu cá nhân và những đoạn prompt không cần cho điều tra phải được che hoặc loại khỏi log.

Bộ ca thử cần đặt chỉ thị cài thêm vào đúng kênh mà agent sẽ đọc: thân email, trang web, tài liệu hoặc kết quả công cụ. Đưa cùng đoạn chỉ thị vào ô câu hỏi của người dùng chỉ kiểm tra đường tấn công trực tiếp, không kiểm tra ranh giới của dữ liệu truy xuất. Dùng dữ liệu giả và công cụ thử nghiệm để quan sát lệnh nào được đề xuất, lệnh nào bị chặn, đồng thời xem agent có hoàn thành phần việc hợp lệ hay không.

Trong ca tóm tắt email giả định, chèn yêu cầu gửi thư tới hộp thư thử nghiệm; kết quả mong đợi là phần tóm tắt vẫn hữu ích và lệnh gửi không chạy khi chưa được phép.
Trong ca đọc tài liệu, chèn chỉ thị tự xưng là lệnh hệ thống; kiểm tra xem agent có giữ nguyên nhiệm vụ và từ chối công cụ ngoài phạm vi hay không.
Trong ca duyệt hành động, thay đích hoặc nội dung sau khi duyệt; thành phần thực thi phải yêu cầu một quyết định duyệt mới cho tham số đã đổi.

Chạy lại các ca này khi thay mô hình, prompt, nguồn truy xuất, chính sách hoặc quyền công cụ. Lưu kết quả cùng cấu hình đã thử để một lần kiểm thử đạt không bị hiểu nhầm là bảo đảm cho cấu hình khác. Tiêu chí quan sát cần bao gồm cả việc chặn hành động trái quyền lẫn việc hoàn thành yêu cầu hợp lệ; một bộ lọc chặn sạch mọi dữ liệu đầu vào không đáp ứng được nhiệm vụ của agent.

Đọc thêm: