SOC kiểm thử prompt injection: từ RAG, email đến cảnh báo tool call
Khi ứng dụng LLM đọc email, tài liệu RAG và dữ liệu do người dùng gửi, chỉ lọc đầu vào là chưa đủ. Từ trao đổi cộng đồng, bài viết gợi ý nhóm ca kiểm thử, cách theo dõi tool call và câu hỏi cần chốt trong quy trình xử lý.
Một bộ lọc ở ô chat không bao quát hết rủi ro khi ứng dụng LLM còn đọc email, tài liệu RAG hoặc dữ liệu do người dùng gửi.
Điểm cần kiểm thử không chỉ là câu hỏi của người dùng, mà là toàn bộ đường đi của nội dung: agent đã đọc gì, nội dung đó có làm lệch tác vụ hay không, và sau đó agent có đề xuất hoặc gọi tool bất thường không.
Ba nhóm tình huống nên tách riêng
Một thành viên cộng đồng chia bộ test thành ba nhóm khá thực dụng:
Chỉ dẫn trực tiếp trong câu hỏi
Kiểm tra cách ứng dụng phản ứng khi người dùng cố đưa yêu cầu xung đột với chỉ dẫn của hệ thống.
Chỉ dẫn nằm trong tài liệu RAG
Kiểm tra liệu nội dung được truy xuất có bị agent hiểu như một mệnh lệnh thay vì tài liệu tham khảo hay không.
Chỉ dẫn trong email mà agent đọc
Đây là tình huống đáng chú ý vì email có thể là dữ liệu hợp lệ cho tác vụ, nhưng không nên tự động trở thành chỉ dẫn để agent thực hiện hành động.
Hai nhóm sau thường sát với môi trường thực tế hơn: agent không chỉ nhận một câu hỏi đơn lẻ mà còn phải xử lý nhiều nguồn nội dung trong cùng một luồng.
Khi kiểm thử, cần quan sát điều gì?
Thay vì chỉ chấm câu trả lời cuối cùng là “đúng” hay “sai”, đội SOC có thể đặt các câu hỏi sau cho từng ca test:
Agent đã dùng nguồn nào để hình thành câu trả lời hoặc đề xuất?
Nội dung từ email hay tài liệu RAG có làm agent đổi mục tiêu tác vụ không?
Agent chỉ tạo phản hồi, hay đã đề xuất một tool call?
Nếu có tool call, cảnh báo có được tạo và có người nhận xử lý không?
Hành vi bất thường có thể được truy ngược về một phiên, một nguồn dữ liệu hoặc một workflow cụ thể không?
Mục tiêu là phát hiện tình huống agent vượt khỏi phạm vi tác vụ sau khi tiếp xúc với dữ liệu không đáng tin cậy, thay vì chỉ cố chặn một câu chữ cụ thể.
Tool call là điểm cần theo dõi sát
Một ý kiến trong thảo luận cho rằng lớp phòng thủ khó nhưng đáng đầu tư là tách quyền: sau khi agent đọc nội dung từ bên ngoài, agent không nên có quyền gọi các tool tạo tác động.
Đây là điểm đáng đưa vào ca kiểm thử. Chẳng hạn, khi agent đọc email hoặc tài liệu RAG, đội có thể kiểm tra xem nó có chuyển từ việc đọc, tóm tắt hoặc đề xuất sang yêu cầu thực hiện hành động hay không.
Câu hỏi then chốt không chỉ là “agent có bị ảnh hưởng không?”, mà là:
> Nếu bị ảnh hưởng, agent có thể làm được gì tiếp theo?
Nếu quyền gọi tool được giới hạn theo tác vụ và nguồn dữ liệu, một phản hồi bất thường sẽ khó chuyển thành tác động lớn hơn.
Cảnh báo phải đi vào luồng trực vận hành
Một thành viên cho biết cảnh báo tool call bất thường được đưa vào cùng kênh với cảnh báo hệ thống và có người trực xử lý.
Đây là một lựa chọn vận hành đáng tham khảo. Cảnh báo liên quan đến agent sẽ khó có giá trị nếu nằm ở một nơi tách biệt, không có chủ sở hữu hoặc không được đưa vào quy trình theo dõi hiện hữu.
Với mỗi cảnh báo, đội có thể thống nhất trước các điểm cần làm rõ:
Đây là câu trả lời bất thường, đề xuất tool hay tool call đã phát sinh?
Agent vừa đọc những nguồn dữ liệu nào?
Workflow nào chịu trách nhiệm xử lý?
Ai là người nhận cảnh báo đầu tiên?
Khi nào cần dừng hoặc rà soát workflow liên quan?
Gợi ý khung trao đổi cho đội SOC
Để biến chủ đề thành một buổi kiểm thử có kết quả cụ thể, nhóm có thể lần lượt trả lời:
Ứng dụng LLM của chúng ta đang đọc những nguồn dữ liệu nào?
Nguồn nào được xem là không đáng tin cậy hoặc chỉ nên dùng làm tham khảo?
Có ca test riêng cho chat, RAG, email và dữ liệu người dùng gửi chưa?
Agent có thể đề xuất hoặc gọi những tool nào sau khi đọc từng loại nguồn?
Cảnh báo hành vi bất thường đi đến đâu, và ai đang trực tiếp nhận xử lý?
Lớp tách quyền nào chưa có nhưng cần ưu tiên triển khai?
Prompt injection không chỉ là vấn đề ở đầu vào. Với môi trường có RAG, email và tool call, đây là bài toán kiểm thử cách dữ liệu đi vào ngữ cảnh, ảnh hưởng đến hành vi của agent và được theo dõi trong vận hành.
Chia sẻ thêm từ các đội SOC: tình huống kiểm thử nào của bạn đã phát hiện được hành vi vượt chỉ dẫn rõ nhất?