Prompt injection là gì và vì sao chatbot có thể bị đánh lừa?

Bạn nhờ trợ lý AI đọc một trang web và tóm tắt. Trong trang có một đoạn yêu cầu công cụ bỏ nhiệm vụ đang làm và thực hiện việc khác. Người đọc bình thường có thể xem đó là chữ vô nghĩa. Nhưng nếu ứng dụng xử lý không đúng, nội dung cần đọc lại có thể làm lệch hành vi của trợ lý. Đây là một tình huống cần nghĩ tới khi AI tiếp nhận nguồn bên ngoài.

Prompt injection là cách dùng nội dung đầu vào để dẫn mô hình làm trái với nhiệm vụ hoặc giới hạn dự kiến. Nó có thể xuất hiện trực tiếp trong lời người dùng hoặc gián tiếp qua tài liệu, email và trang web. Giảm rủi ro cần nhiều lớp: phân biệt nguồn, giới hạn quyền, kiểm hành động và có cách dừng. Một câu nhắc thật mạnh trong prompt không đủ để bảo vệ toàn bộ ứng dụng.

Điều gì xảy ra khi mô hình bị dẫn dắt?

Giả sử nhóm của Nam dùng AI đọc email hỗ trợ rồi soạn bản nháp. Một email chứa lời yêu cầu coi nội dung trong thư là chỉ dẫn ưu tiên. Nếu trợ lý làm theo, bản trả lời có thể rời khỏi việc hỗ trợ khách. Rủi ro lớn hơn khi công cụ còn có quyền đọc dữ liệu khác hoặc gửi nội dung ra ngoài mà không cần bước kiểm phù hợp.

OWASP mô tả prompt injection như một rủi ro của ứng dụng dùng mô hình ngôn ngữ, đồng thời lưu ý RAG và fine-tuning không tự loại bỏ nó. Điều này quan trọng với nhóm đang nghĩ rằng chỉ dùng tài liệu nội bộ là đủ an toàn. Tài liệu nội bộ vẫn có thể chứa nội dung từ người khác hoặc phần chưa được kiểm soát.

Không phải mọi câu trả lời sai đều là prompt injection. Mô hình có thể hiểu nhầm, thiếu nguồn hoặc suy diễn. Khi điều tra, cần xem đầu vào, hành vi và quyền liên quan thay vì gắn nhãn ngay. Phân biệt đúng loại lỗi giúp nhóm chọn cách sửa phù hợp, tránh tập trung vào bộ lọc câu chữ trong khi vấn đề thật nằm ở quyền công cụ quá rộng.

Với người sử dụng, dấu hiệu đáng chú ý là trợ lý đổi việc không có lý do từ yêu cầu của bạn. Chẳng hạn, đang tóm tắt lại muốn gửi thông tin hoặc truy cập tài nguyên ngoài phạm vi. Đừng duyệt chỉ vì lời giải thích nghe tự tin. Kiểm hành động cụ thể và nguồn yêu cầu trước khi cho phép bước có ảnh hưởng.

Hỏi ứng dụng có quyền gì

Nam bắt đầu bằng bản đồ quyền của ứng dụng. Trợ lý được đọc những hộp thư nào, mở tài liệu nào và có thể gửi gì? Quyền soạn bản nháp khác quyền gửi thư. Quyền tìm một tài liệu khác quyền đọc toàn bộ kho. Khi biết phạm vi thực tế, nhóm mới hiểu một lần bị dẫn lệch có thể ảnh hưởng tới đâu.

Cấp quyền theo nhiệm vụ và vai trò của người dùng bằng cơ chế hệ thống. Đừng chỉ nói trong prompt rằng trợ lý không được đọc phần nào rồi vẫn cấp khả năng đọc đó. Lời nhắc có thể hỗ trợ hành vi, nhưng ranh giới dữ liệu cần được thực thi ở nơi truy cập. Đây là phần nhóm kỹ thuật và người phụ trách bảo mật phải thiết kế cùng nhau.

Những thao tác có ảnh hưởng cần bước kiểm phù hợp với mức rủi ro. Người duyệt nên thấy việc sắp xảy ra, dữ liệu liên quan và nơi nhận nếu có. Một nút đồng ý chung chung dưới lời giải thích dài dễ bị bỏ qua. Bài thiết kế bước duyệt của con người giúp biến việc duyệt thành nhiệm vụ cụ thể.

Đừng trộn lệnh với nội dung cần đọc

Ứng dụng cần phân biệt chỉ dẫn của hệ thống với nội dung được lấy về để đọc. Người dùng nghiệp vụ có thể hỗ trợ bằng cách đánh dấu nguồn và mục đích của tài liệu, nhưng phần thực thi thuộc thiết kế ứng dụng. Không nên coi một đoạn trích có câu mệnh lệnh là quyền mới cho trợ lý chỉ vì nó xuất hiện gần nhiệm vụ đang làm.

Hướng dẫn phòng ngừa của OWASP đề cập các biện pháp nhiều lớp, gồm xử lý đầu vào, giới hạn công cụ và giám sát. Bộ lọc có thể hỗ trợ nhưng không nên được quảng bá như cách chặn mọi trường hợp. Nội dung có nhiều cách biểu đạt, còn hành vi ứng dụng phụ thuộc cả chuỗi xử lý phía sau.

Đừng đưa bí mật vào ngữ cảnh nếu nhiệm vụ không cần. Thông tin đã được cung cấp cho mô hình có thể tạo thêm yêu cầu bảo vệ ở đầu ra và hành động. Giảm dữ liệu không cần thiết vừa giúp kiểm dễ hơn vừa thu hẹp phần có thể bị ảnh hưởng. Đây là lựa chọn thiết kế cần làm từ đầu, không phải chỉ thêm một lời nhắc ở cuối prompt.

Với RAG, kiểm nguồn nào được lấy và quyền của người hỏi trước khi nội dung đi vào câu trả lời. Bài RAG dựa trên tài liệu doanh nghiệp giải thích luồng tìm nguồn và soạn câu. Tách rõ các bước giúp nhóm kiểm xem vấn đề xuất hiện ở tìm kiếm, xử lý nguồn hay quyền hành động.

Thử các tình huống tấn công có chủ đích

Thử trong môi trường và phạm vi được phép, dùng dữ liệu giả phù hợp. Nhóm của Nam chuẩn bị các email có nội dung cố làm trợ lý đổi nhiệm vụ. Họ kiểm xem hệ thống có tiếp tục soạn bản nháp đúng yêu cầu và giữ giới hạn công cụ không. Không cần đưa dữ liệu khách thật vào bài thử để chứng minh khả năng xử lý tình huống này.

Các ca thử nên phản ánh những nguồn ứng dụng thực sự đọc: tài liệu, email, trang web hoặc dữ liệu qua công cụ. Không chỉ thử một câu trực tiếp trong ô chat rồi kết luận đã xong. Ghi rõ kết quả mong đợi và hành động không được xảy ra. Khi lỗi xuất hiện, lưu đủ thông tin để người phụ trách tái hiện trong điều kiện phù hợp.

Thử lại sau các thay đổi quan trọng của mô hình, công cụ hoặc cách cấp quyền. Một lớp bảo vệ hoạt động với luồng cũ chưa chắc bao phủ luồng mới. Bộ thử giúp phát hiện một số lỗi đã biết, không chứng minh không còn lỗi khác. Khi báo cáo, nói rõ phạm vi đã kiểm để người quyết định hiểu giới hạn của kết quả.

Giữ một lối thoát khi có sự cố

Chuẩn bị cách tạm dừng những khả năng có ảnh hưởng nếu phát hiện hành vi bất thường. Ai có quyền dừng, ai kiểm nhật ký và ai xử lý phần dữ liệu liên quan? Những câu hỏi này nên có câu trả lời trước khi triển khai rộng. Một ứng dụng cần người vận hành hiểu cách can thiệp, không chỉ một trang hướng dẫn khuyên người dùng cẩn thận.

Nhật ký cần đủ để xem điều đã xảy ra nhưng cũng phải được bảo vệ phù hợp. Không ghi mọi bí mật chỉ để dễ điều tra. Nhóm cần cân bằng thông tin phục vụ kiểm tra với phạm vi dữ liệu được phép lưu. Khi có sự cố, xác định hành động và ảnh hưởng thực tế trước khi mở lại quyền hoặc tiếp tục quy trình.

Prompt injection nhắc chúng ta xem AI như một phần của hệ thống có dữ liệu và quyền, không chỉ một ô trả lời. Với người dùng, kiểm hành động trước khi duyệt. Với nhóm xây dựng, giới hạn khả năng và thử các đường nhận dữ liệu. Những bước cụ thể ấy giúp giảm rủi ro rõ hơn việc trông chờ mô hình luôn tự phân biệt được đâu là nội dung cần đọc và đâu là việc được phép làm.