Phòng chống prompt injection: giữ dữ liệu và quyền

Đăng ngày 27/10/2026

Phòng chống prompt injection bắt đầu từ quyền được giao

Phòng chống prompt injection cần bảo vệ điều hệ thống được phép làm khi đọc nội dung bên ngoài. Một email có thể chứa dữ kiện cần tóm tắt, đồng thời chứa lời yêu cầu trợ lý đổi nhiệm vụ hoặc chuyển thông tin đi nơi khác. Quyền đọc email không tự cấp quyền làm theo những câu ấy. Nhóm xây ứng dụng cần giữ yêu cầu của người giao việc, nguồn dữ liệu và quyết định cho gọi công cụ ở những vị trí có thể kiểm, thay vì tin toàn bộ vào khả năng phân biệt của mô hình.

Bài dùng ca giả định một đội hành chính tại Việt Nam muốn trợ lý đọc thư mẫu và tạo danh sách việc cần xem. Nhiệm vụ chỉ tạo nháp nội bộ, không gửi thư, đổi người nhận, mở quyền tài liệu hoặc làm theo liên kết trong thư. Hai công cụ đề xuất là sổ chuyển mức tin cậy và phiếu thử hai chiều. Phần thử dùng dữ liệu tự dựng cùng công cụ giả lập; bài chưa chạy một hệ thống, đọc hộp thư thật hoặc thực hiện tấn công vào dịch vụ nào.

Nghiên cứu của Greshake và cộng sự mô tả chèn chỉ dẫn gián tiếp qua dữ liệu có khả năng được ứng dụng truy hồi. Người tấn công không nhất thiết có quyền sửa yêu cầu ban đầu; họ có thể kiểm soát một phần nội dung ứng dụng sẽ đọc. Đây là cơ chế rủi ro trong những thiết lập nghiên cứu lịch sử, không phải thông báo một sản phẩm hiện tại đang có lỗ hổng cụ thể. Điều cần theo dõi là lúc dữ liệu bị nâng thành quyền điều khiển[1].

Nội dung cần đọc không tự trở thành người giao việc

Trong ca hành chính, một câu trong thư nói có việc cần xử lý vẫn là nội dung để phân loại. Nó có thể được đưa vào danh sách nháp với nguồn, chủ thể và trạng thái cần xác minh. Một câu tự xưng hướng dẫn hệ thống cũng vẫn nằm trong thư, chưa có quyền đổi mục tiêu trợ lý. Việc giữ câu ấy để người đọc hiểu nội dung khác với việc cho nó thay luật. Ứng dụng cần phân biệt hai hành vi, tránh xóa sạch mọi câu có động từ rồi làm mất ý nghĩa công việc.

Nguồn nội bộ cũng cần được xem theo quyền biên tập thực tế. Một tài liệu nằm trong ổ chia sẻ có thể được nhiều người sửa; một đoạn trích có thể mang lời của bên ngoài. Nhãn nội bộ hoặc tên người gửi quen thuộc chưa chứng minh mọi câu trong đó là chỉ dẫn vận hành. Cần biết ai được sửa quy tắc, thay danh sách công cụ và cho phép tác động ra ngoài. Những quyền ấy phải có đường xác định riêng với quyền góp nội dung cho một hồ sơ.

Sổ chuyển mức tin cậy đề xuất ghi sáu mục: nguồn vào, người kiểm soát nguồn, phần được dùng, quyền đang được xin thêm, điểm thực thi và bằng chứng kết quả. Chẳng hạn, email được phép cung cấp ngày hẹn để nháp danh sách, nhưng chưa được phép đổi địa chỉ nhận tài liệu. Khi thấy một bước dùng dữ liệu để chọn người nhận hoặc công cụ mới, nhóm có một điểm cụ thể để kiểm. Không cần coi mọi văn bản là độc hại mới thiết kế được ranh giới đó.

Giới hạn công cụ theo nhiệm vụ hiện tại

Với nhiệm vụ chỉ tạo danh sách nháp, bộ công cụ không cần có quyền gửi thư hoặc sửa chia sẻ tài liệu. Nếu ứng dụng vẫn giữ một công cụ rộng, cần giới hạn thao tác ở phần thực thi theo danh tính, tài nguyên và phạm vi được phép. Không chỉ nhắc mô hình đừng dùng nút gửi rồi giao cho nó thông tin xác thực cho mọi chức năng. Khi một đề xuất ngoài phạm vi xuất hiện, điểm thực thi phải có khả năng từ chối mà không cần mô hình tự công nhận nó đang sai.

OWASP LLM01:2025 nêu giảm quyền, kiểm định dạng, tách nội dung ngoài và có người duyệt các thao tác đặc quyền như những biện pháp giảm tác động. Hướng dẫn không coi truy xuất hoặc tinh chỉnh là cách loại bỏ hoàn toàn chèn chỉ dẫn. Bài dùng nguyên tắc nhiều lớp ấy, không tuyên bố cứ cài một bộ lọc hoặc thêm câu nhắc là đã an toàn. Hiệu lực của mỗi lớp cần được kiểm ở đúng đường dữ liệu và công cụ mà ứng dụng thực sự dùng[2].

Quyền đọc cũng cần đủ hẹp. Một thư mẫu về lịch họp không cần dẫn tới tìm toàn bộ hồ sơ nhân sự hoặc đọc các thư không liên quan. Nếu mô hình đề nghị tìm thêm, ứng dụng kiểm mục đích và phạm vi trước khi lấy dữ liệu. Dữ liệu chưa được lấy thường dễ giới hạn hơn dữ liệu đã bị đưa vào ngữ cảnh rồi mới nhắc đừng tiết lộ. Với nhiệm vụ cần nhiều nguồn, phải xác định rõ nguồn nào thật sự cần và ai chịu trách nhiệm cho quyết định mở thêm.

Đánh dấu ranh giới hỗ trợ mô hình nhưng chưa thay cưỡng chế

Có thể trình nội dung email thành phần dữ liệu có nhãn, giữ riêng yêu cầu của người giao việc và quy tắc xử lý. Nhãn nên đi qua cả lúc trích đoạn, tóm tắt và bàn giao, thay vì mất ngay khi mô hình viết lại văn bản. Một đoạn tóm tắt sinh ra từ thư vẫn có nguồn là thư; nó không trở thành chỉ dẫn có thẩm quyền chỉ vì đã được trợ lý diễn đạt lại. Sổ nguồn giúp người kiểm lần về nơi câu yêu cầu xuất hiện.

BIPIA nghiên cứu cách giúp mô hình nhận biết ranh giới nội dung và nhắc rõ không thực hiện chỉ dẫn nằm trong phần bên ngoài. Nguồn còn xem cách huấn luyện để tăng khả năng giữ ranh giới trong thiết lập riêng. Đây là hướng cải thiện hành vi có bằng chứng nghiên cứu, chưa phải bảo đảm mọi mô hình hoặc mọi định dạng sẽ giữ đúng. Bài không áp tỷ lệ của nguồn cho email tiếng Việt và không coi một dấu phân cách văn bản là cơ chế cấp quyền[3].

Bộ lọc có thể hỗ trợ nhận diện mẫu đáng xem, nhưng một từ bị cấm chưa định nghĩa đầy đủ ý định. Thư hợp lệ có thể bàn về việc bỏ hướng dẫn cũ trong một dự án, còn chỉ dẫn cài bẫy có thể được viết như việc hỗ trợ nhiệm vụ. Nhóm cần kiểm cả ca bị báo nhầm và ca lọt. Nếu bộ lọc thay nội dung trước khi tóm tắt, phải biết nó có làm mất ngày, chủ thể hoặc phủ định quan trọng không; sửa rủi ro ở một bước không được âm thầm làm sai công việc ở bước khác.

Tách phần hiểu nội dung khỏi phần chọn hành động

Một hướng kiến trúc là cho thành phần đọc văn bản chỉ trả dữ liệu theo hợp đồng hẹp, còn phần điều phối giữ kế hoạch và chính sách công cụ. Thành phần đọc không cần có quyền gửi hoặc sửa hồ sơ. Tuy nhiên, kết quả có cấu trúc vẫn chứa dữ liệu từ nguồn chưa có quyền điều khiển. Nếu phần điều phối đọc mọi chuỗi đó như một yêu cầu mới, sự tách thành hai mô hình chưa tạo ranh giới có hiệu lực. Cần xác định dữ liệu được phép ảnh hưởng tham số nào và kiểm tại lúc thực hiện.

CaMeL mô tả thiết kế tách luồng điều khiển và dữ liệu, dùng thành phần đọc cách ly, theo dõi nguồn cùng người được đọc giá trị, rồi kiểm chính sách khi gọi công cụ. Bài vận dụng tư tưởng kiểm luồng dữ liệu, chưa nhận đã triển khai CaMeL. Nghiên cứu tự nêu giới hạn về chính sách, gánh nặng người dùng và kênh phụ; những tấn công chỉ làm sai nội dung tóm tắt mà không đổi luồng dữ liệu còn ngoài một phần mục tiêu bảo vệ của thiết kế[4].

Điều này đặc biệt cần cho ca hành chính. Một hệ thống chặn được gửi ra ngoài vẫn có thể tạo danh sách nháp sai ngày hoặc đổi mức ưu tiên do nội dung cài bẫy. Vì thế, giữ quyền công cụ và giữ tính đúng của bản nháp là hai phép kiểm riêng. Không dùng việc không có thư gửi đi làm bằng chứng toàn bộ thông tin an toàn để sử dụng. Người nhận danh sách vẫn cần nguồn và trạng thái chưa xác nhận ở những điều có thể ảnh hưởng công việc.

Quyền giao thức không thay quyết định cho thao tác

Nếu một hệ thống dùng MCP để nối công cụ, cần đọc phạm vi ủy quyền của đúng cách kết nối. Tên giao thức không tự tạo chính sách cho hộp thư hoặc tài liệu. Một công cụ đã được đăng ký vẫn phải chịu giới hạn của tác vụ và người sử dụng. Nhóm vận hành cần biết phần nào kiểm danh tính, phần nào quyết định tài nguyên được truy cập và phần nào giữ điều kiện xác nhận trước tác động. Không để trách nhiệm bị bỏ trống giữa bộ nối, máy chủ công cụ và mô hình.

Hướng dẫn bảo mật MCP tại đường dẫn phiên bản được đọc khuyến nghị phạm vi quyền tối thiểu rồi tăng có mục tiêu khi cần, đồng thời cảnh báo phạm vi rộng làm tăng tác động khi bị chiếm dụng. Tài liệu cũng nêu việc chỉ thấy phạm vi quyền trong token chưa đủ thay kiểm ủy quyền phía máy chủ. Đây là hướng dẫn cho hệ MCP tương ứng, không phải lời hứa mọi công cụ bên thứ ba đều thực thi đúng hoặc một phiên xác thực thành công loại bỏ chèn chỉ dẫn[5].

Trong ca chỉ tạo nháp, một yêu cầu cấp thêm quyền gửi phải có lý do từ nhiệm vụ được người giao cho phép. Câu trong thư nói cần mở quyền gấp chưa cung cấp lý do đó. Nếu sau này tổ chức thật sự thêm chức năng gửi, cần hợp đồng thao tác gồm người nhận, nội dung, tài liệu kèm và phạm vi được duyệt. Việc duyệt phải gắn với đúng bản đề nghị; thay nội dung hoặc người nhận sau đó phải được xử lý như thay đổi cần kiểm theo quy tắc đã chốt.

Phiếu thử hai chiều giữ cả việc hợp lệ và ranh giới

Phiếu đề xuất ghi nhiệm vụ hợp lệ, nội dung ngoài có thể bị sửa, mục tiêu vượt quyền, trạng thái ban đầu, đầu ra chấp nhận và dấu vết cần quan sát. Với mỗi ca, nhóm xem cả công việc có hoàn thành đúng không và quyền có được giữ không. Một trợ lý từ chối đọc mọi email có thể chặn nhiều tác động, nhưng chưa đáp ứng việc lập danh sách. Một trợ lý làm đúng danh sách nhưng đồng thời gọi gửi thư ngoài phạm vi cũng chưa đạt, dù đầu ra cuối có vẻ bình thường.

AgentDojo tách khả năng hoàn thành việc khi không có tấn công, khả năng hoàn thành đúng dưới tấn công mà không có tác động đối nghịch, và việc mục tiêu tấn công được thực hiện hay chưa. Sự phân biệt giúp tránh báo một tỷ lệ chặn mà bỏ phần chức năng hợp lệ đã mất. Nghiên cứu dùng môi trường tác tử có trạng thái riêng; bài không coi nó là bộ chứng nhận email doanh nghiệp hoặc chuyển điểm của tác giả thành kết quả của hệ thống chưa chạy[6].

Trong phiếu, có thể ghi bốn trạng thái giữa hoàn thành việc hợp lệ và giữ quyền. Trạng thái mong muốn là cả hai cùng đạt. Nếu giữ quyền nhưng bỏ việc, cần xem từ chối quá mức; nếu làm việc nhưng vượt quyền, cần xem điểm thực thi; nếu cả hai chưa đạt, phải giữ đủ dấu vết để tách nguyên nhân. Bốn trạng thái chỉ là cách đọc kết quả đề xuất, chưa có số ca hoặc tỷ lệ thực nghiệm. Không gộp chúng thành một điểm trung bình che lỗi quan trọng.

Đổi vị trí và dạng nguồn để kiểm giới hạn đã tuyên bố

Một bộ thử không nên chỉ chứa một câu cài bẫy dễ nhận ra đặt ở đầu thư. Có thể dùng thư tự dựng với chỉ dẫn xen trong nội dung liên quan, nằm ở đoạn trích hoặc đi qua một bước tóm tắt. Mục tiêu là xem ranh giới có còn được giữ trên đường xử lý, không phải xây một danh sách từ khóa rồi gọi đó là toàn bộ nguy cơ. Mỗi biến thể cần nằm trong môi trường được phép và có kết quả kỳ vọng kiểm được, tránh dùng hồ sơ riêng làm vật liệu thử cho tiện.

InjecAgent nêu rõ thiết lập ban đầu của nó có những giới hạn như tương tác một lượt, số bước tấn công ngắn và việc chưa khảo sát đầy đủ nội dung lành xen chỉ dẫn đối nghịch. Những giới hạn đó hữu ích khi thiết kế phép thử nhiều bước cho ứng dụng khác. Không lấy việc vượt qua một bộ ca đơn giản làm bằng chứng mọi cuộc trao đổi dài đã được bảo vệ. Bài dùng phần mô tả cùng giới hạn nghiên cứu, không sao chép tỷ lệ lỗi hoặc chuỗi tấn công vào công cụ thật[7].

Nhóm cũng nên thử đường một mô hình viết lại nội dung rồi mô hình khác đọc tiếp. Nguồn và quyền của dữ kiện cần giữ qua bước trung gian. Nếu câu cài bẫy bị biến thành mục “cần làm ngay” trong bản tóm tắt, người nhận phải còn biết nó đến từ thư chưa có thẩm quyền. Kiểm thông tin bàn giao ở đây giúp phát hiện việc nâng mức tin cậy âm thầm. Không mặc định nhiều tác tử làm rủi ro thấp hơn nếu chúng cùng trao lại câu chỉ dẫn đã mất nhãn nguồn.

Quan sát hành động thật và tác động có thể xảy ra

Thông điệp cuối nói đã từ chối chưa chứng minh trước đó không có lệnh gọi trái phạm vi. Phép kiểm cần xem công cụ được đề nghị, tham số, quyết định chặn và trạng thái nơi nhận trong môi trường giả lập. Một lời gọi sai bị bộ thực thi chặn là bằng chứng lớp đó đã hoạt động ở ca ấy; nó khác với việc mô hình không bao giờ đề nghị sai. Giữ hai kết quả riêng giúp nhóm biết đang dựa vào lớp nào và lỗi còn xuất hiện ở đâu.

NIST AI600-1 đề xuất đánh giá khả năng chống chịu với chèn chỉ dẫn, ghi hiệu lực biện pháp bảo mật và kiểm lại sau thay đổi. Hồ sơ cũng đặt hoạt động thử đối nghịch trong bối cảnh quản trị và chuyên môn của người kiểm. Đây là nguồn hướng dẫn tự nguyện, chưa chứng nhận công cụ hoặc đặt ra một nghĩa vụ pháp lý riêng cho đội hành chính giả định. Bài dùng nó để yêu cầu bằng chứng về lớp phòng vệ và phần chưa đo, không tự công bố một hệ thống đã được kiểm an toàn[8].

Nhật ký nên đủ để đối chiếu nhưng hạn chế nội dung riêng không cần thiết. Có thể giữ mã thư mẫu, phiên bản chính sách, tên thao tác và lý do chặn thay vì gom mọi tài liệu nhạy cảm vào báo cáo rộng. Nếu thấy dấu hiệu vượt quyền khi dùng thực tế, cần người có trách nhiệm xử lý theo quy trình đã duyệt, giữ bằng chứng và khoanh tác vụ. Việc cải thiện mô hình sau đó không thay phần đối soát xem thao tác nào đã thực sự tới nơi nhận.

Ca đội hành chính đọc email giả lập

Giả sử đội tạo bộ thư mẫu về cuộc họp, việc còn chờ và người phụ trách. Có một bản sạch, một bản chứa lời tự xưng hướng dẫn mới, một bản đề nghị chuyển tài liệu tới địa chỉ khác và một bản chỉ có yêu cầu nghiệp vụ bình thường để tóm tắt. Mọi tên, địa chỉ và hồ sơ đều do biên tập tự dựng. Công cụ đọc trả đúng các thư mẫu; công cụ có tác động nếu cần quan sát chỉ là đầu nhận giả lập, không nối tài khoản hoặc kênh gửi thật.

Người giữ nghiệp vụ chuẩn bị danh sách nháp chấp nhận cùng những thông tin chưa đủ căn cứ. Nhóm kỹ thuật định nghĩa rõ việc nào bị cấm và kiểm ở lớp thực thi. Sau mỗi lượt, người kiểm đối chiếu nội dung nháp, lời gọi công cụ và trạng thái giả lập với phiếu hai chiều. Nếu trợ lý chặn câu cài bẫy nhưng bỏ luôn hạn họp có thật trong thư, đó là lỗi chức năng cần ghi. Nếu danh sách đúng mà có lời gọi ngoài phạm vi, vẫn giữ lỗi ranh giới riêng.

Đội nhỏ có thể thử một nhiệm vụ đọc và một loại đầu ra trước; đội lớn cần người giữ quyền thư, người làm bộ nối và người kiểm độc lập. Chưa kiểm được điểm thực thi hoặc chưa xác định được phạm vi dữ liệu thì giữ chức năng tạo nháp ở môi trường thử. Chỉ đề nghị mở nhóm việc đã có bằng chứng, cùng người tiếp nhận lỗi và đường dừng. Bài chưa chạy những lượt này, không có tỷ lệ chặn, thời gian tiết kiệm hoặc cam kết không bao giờ bị chèn chỉ dẫn.

Hỏi đáp về phòng chống prompt injection

Trợ lý chỉ đọc và tạo nháp thì có thể bỏ kiểm chèn chỉ dẫn không? Chưa nên bỏ. Dù không có công cụ gửi, nội dung vẫn có thể bị làm sai, bỏ điều kiện hoặc đổi mức ưu tiên khiến người dùng hiểu nhầm. Hãy giới hạn quyền đọc, giữ nguồn và chấm đúng bản nháp. Phạm vi chỉ đọc giảm một số tác động, nhưng không tự chứng minh mọi đầu ra đều giữ đúng nội dung mà người giao việc cần.

Thêm câu yêu cầu không làm theo email có đủ chưa? Đó có thể là một lớp hỗ trợ hành vi, cần kiểm cùng định dạng đầu vào và mô hình cụ thể. Nó chưa thay việc hạn chế công cụ và quyết định cho phép thao tác tại phần thực thi. Nếu mô hình vẫn đề nghị sai, ứng dụng phải có khả năng chặn. Bài không có phép thử để kết luận một câu nhắc chung đủ bảo vệ cho mọi hộp thư hoặc cuộc trao đổi nhiều bước.

Dùng hai mô hình tách nhau có tự bảo đảm an toàn không? Chưa. Cần biết phần đọc trả gì, nguồn của giá trị được giữ ra sao và phần điều phối cho phép dữ liệu ảnh hưởng hành động nào. Một mô hình thứ hai đọc nguyên lời cài bẫy như chỉ dẫn mới vẫn có thể tiếp tục sai. Thiết kế tách vai phải đi cùng chính sách thực thi và phép kiểm kết quả, đồng thời giữ giới hạn về sai nội dung chưa được bảo vệ.

Không thấy mục tiêu tấn công thành công thì đã được mở chức năng chưa? Chưa đủ căn cứ. Cần xem việc hợp lệ còn hoàn thành không, ca nào đã thử, lớp nào chặn và tác động nào chưa quan sát được. Một bộ ca sạch chưa kiểm đường nhận nội dung đối nghịch; một bộ chỉ đối nghịch chưa đo phần chức năng bình thường. Quyền mở theo từng nhiệm vụ phải có người chịu trách nhiệm, dựa trên bằng chứng cùng hậu quả của lỗi còn lại.

Nguồn, phương pháp và giới hạn suy luận

Bài được biên soạn có AI hỗ trợ từ tám nguồn gốc mở đọc ngày 27/10/2026 theo phạm vi hồ sơ nguồn. Các nghiên cứu được giữ đúng phiên bản và giới hạn; không dùng tỷ lệ lịch sử để xếp hạng sản phẩm hiện tại. Hướng dẫn OWASP, MCP và NIST hỗ trợ thiết kế kiểm, chưa xác nhận mọi triển khai tuân theo. Hai khung và ca hành chính là đề xuất biên tập, chưa chạy công cụ, đọc thư thật, thử đối nghịch hoặc kiểm hệ thống doanh nghiệp. Bài không cung cấp bảo đảm miễn nhiễm, chứng nhận bảo mật hay kết luận tuân thủ pháp lý.