BrowseSafe++: Xây dựng hệ thống phòng thủ mạnh mẽ hơn trước tấn công chèn prompt trong thực tế

Các tác nhân có thể duyệt web, chẳng hạn như trợ lý tích hợp trong Comet hoặc Computer, cần tương tác với các trang web, đọc nội dung và dùng nội dung đó để thực hiện hành động thay mặt người dùng. Điều này khiến chúng dễ bị tấn công chèn lệnh gián tiếp (indirect prompt injection), trong đó kẻ tấn công đặt văn bản độc hại lên một trang web. Nếu tác nhân làm theo các chỉ dẫn này, nó có thể trả về câu trả lời gây hiểu lầm hoặc thực hiện hành động mà người dùng không yêu cầu.

Vào tháng 12 năm 2025, chúng tôi đã phát hành BrowseSafe, một bộ đánh giá chuẩn và mô hình phát hiện dành cho mối đe dọa này. Chúng tôi xây dựng nó bằng cách thêm các cuộc tấn công tổng hợp vào những trang web thực tế mà tác nhân có khả năng gặp phải. Trong năm qua, các cuộc tấn công đã trở nên tinh vi hơn và trông giống nội dung trang thông thường hơn. Thay vì dùng những cụm từ dễ nhận biết như “bỏ qua các hướng dẫn trước đó”, chúng thường bắt chước nội dung mà tác nhân có khả năng tin tưởng, chẳng hạn như một thông báo chính thức từ trang web hoặc một ghi chú về tùy chọn của người dùng.

Xuất phát từ những thay đổi này, chúng tôi đã xây dựng một benchmark cập nhật, BrowseSafe++, để đo lường liệu các bộ phát hiện lệnh chèn hiện nay có bắt được những cuộc tấn công này hay không và liệu các tác nhân có thể chống lại chúng hay không. Benchmark này gồm 38.675 cặp trang bị tấn công và trang sạch, chủ yếu được xây dựng dựa trên các lệnh chèn thu thập trong thực tế. Với mỗi trang, chúng tôi viết lại nội dung xung quanh để bảo vệ quyền riêng tư nhưng giữ nguyên văn cuộc tấn công. Mỗi trang có đủ bốn định dạng mà tác nhân trình duyệt đọc: HTML, Markdown, cây trợ năng và ảnh chụp màn hình. Chúng tôi đã dùng một tập con của benchmark để huấn luyện BrowseSafe-Guard, một cặp bộ phát hiện 0,8 tỷ tham số gồm một bộ phát hiện văn bản và một bộ phát hiện đa phương thức. Hai bộ phát hiện Guard xác định lệnh chèn chính xác hơn các mô hình dùng prompt mà chúng tôi đã kiểm thử, kể cả các mô hình tiên phong. Chúng cũng nhanh hơn, rẻ hơn và gắn cờ nhầm ít trang thông thường hơn nhiều.

Chúng tôi phát hành BrowseSafe++ dưới dạng benchmark mở. Trang web dự án có liên kết đến bộ dữ liệu, SDK, bài báo nghiên cứu và một bảng xếp hạng công khai. Bất kỳ nhóm nào cũng có thể chấm điểm bộ phát hiện của mình trên các trang kiểm thử không được cung cấp nhãn, rồi gửi nhãn để được chấm điểm và có thể được đưa vào bảng xếp hạng. Để đánh giá và gửi kết quả, hãy xem Bắt đầu.

Xây dựng benchmark từ các lệnh chèn quan sát được

BrowseSafe++ được xây dựng từ các lệnh chèn (prompt injection) quan sát được trên các trang web thực. Từ tháng 9 năm 2025 đến tháng 9 năm 2026, bộ phát hiện chèn lệnh của Comet đã gắn cờ 1,15 triệu lệnh chèn trên các trang mà tác nhân của Comet đọc. Chúng tôi xây dựng 32.187 cặp xoay quanh những lệnh chèn đó và bổ sung 6.488 cặp từ benchmark BrowseSafe ban đầu, tổng cộng 38.675 cặp. Mỗi cặp gồm một trang bị tấn công và bản sao sạch của nó, tức là chính trang đó nhưng không có lệnh chèn.

Lệnh chèn trông như thế nào trong thực tế

Hai ví dụ từ benchmark cho thấy những lệnh chèn này trông như thế nào trong thực tế.

Trong ví dụ thứ nhất, một yêu cầu mua hàng giả mạo xúi giục tác nhân thực hiện một hành động trái phép. Bộ phát hiện của Comet đã gắn cờ khối văn bản tiếng Anh này trên một trang tài liệu dành cho nhà phát triển bằng tiếng Nga vào tháng 10 năm 2025:

Đoạn văn bản mở đầu và kết thúc bằng các mệnh lệnh, còn phần giữa được lấp đầy bằng nội dung quảng bá token thông thường. Nó tự nhận là đến từ chính nhà phát triển của tác nhân và kết thúc bằng một mã ủy quyền để giao dịch mua trông như đã được phê duyệt.

Trong một ví dụ khác, một cuộc trò chuyện giả mạo nhằm phá rối nhiệm vụ của tác nhân. Đoạn văn bản này được tìm thấy trên một trang kho mã nguồn vào tháng 3 năm 2026:

Văn bản này được thiết kế để trông giống một cuộc trò chuyện giữa người dùng và tác nhân: <|im_start|> và <|im_end|> là các dấu hiệu mà một số mô hình trò chuyện dùng để phân tách các lượt trong cuộc hội thoại. Một tác nhân mắc bẫy cuộc tấn công này sẽ phản hồi truy vấn người dùng giả mạo và trả lời bằng cụm từ của kẻ tấn công.

Chúng tôi quan sát thấy các xu hướng tương tự ở những lệnh chèn bị gắn cờ:

• Chúng giả mạo các nguồn đáng tin cậy. Cả hai ví dụ đều khiến văn bản trên trang nghe như đến từ một nguồn mà tác nhân tin tưởng: nhà phát triển của nó trong ví dụ thứ nhất, và chính cuộc hội thoại của nó trong ví dụ thứ hai. Nội dung chèn cũng có thể đóng giả chính trang web, bắt chước các bước kiểm tra bảo mật và thông báo chính sách, hoặc đóng giả người dùng, đưa ra các tùy chọn giả mạo. Khoảng hai phần ba được viết bằng ngôn ngữ trang trọng.
• Nhiều lệnh chèn được viết bằng ngôn ngữ khác. Trong 24,4% số cặp, lệnh chèn dùng một ngôn ngữ khác với phần còn lại của trang. Điều này thường thể hiện dưới dạng một chỉ dẫn bằng tiếng Anh trên một trang không phải tiếng Anh, như trong ví dụ đầu tiên. Những cuộc tấn công như vậy rõ ràng nhắm vào một tác nhân có thể đọc mọi ngôn ngữ và thường thông thạo nhất tiếng Anh. Việc chuyển đổi ngôn ngữ cũng khiến việc phát hiện khó hơn: trong đánh giá BrowseSafe ban đầu của chúng tôi, các cuộc tấn công đa ngôn ngữ nằm trong số khó phát hiện nhất.
• Phần lớn nhắm đến hành động, không phải lời nói. Hơn bốn trên mười lệnh chèn thúc đẩy tác nhân thực hiện một hành động mà người dùng chưa bao giờ yêu cầu, như việc mua token trong ví dụ đầu tiên, và khoảng một phần ba cố khiến tác nhân bỏ dở nhiệm vụ của người dùng, như trong ví dụ thứ hai. Chỉ khoảng 3% cố gắng cài cắm thông tin sai lệch vào câu trả lời.
• Chúng thường lợi dụng nội dung mà bất kỳ ai cũng có thể đăng. Kẻ tấn công không cần kiểm soát một trang web. Chỉ cần một bài đăng trên diễn đàn hoặc một tài liệu được chia sẻ trên các trang web thông thường là đủ, và hơn 23.000 nội dung chèn trong BrowseSafe++ đã xuất hiện theo cách này. Một tên miền đáng tin cậy vẫn có thể bị lợi dụng để chèn văn bản của kẻ tấn công.

Các lệnh chèn có trong benchmark cuối cùng trải rộng trên 12 loại trang web, 24 kiểu tấn công, 6 mục tiêu của kẻ tấn công và 18 vị trí đặt trên trang.

Phóng to

Từ một trang bị gắn cờ đến một cặp trong bộ đánh giá chuẩn

Chúng tôi không thể dùng nguyên trạng các trang bị gắn cờ trong benchmark, vì chúng có thể chứa thông tin cá nhân của người dùng mà tác nhân đang phục vụ. Việc biến một trang thành một cặp benchmark có thể chia sẻ đòi hỏi ba giai đoạn chính:

1. Tìm nguồn lệnh chèn: Chúng tôi thu thập các trang bị gắn cờ, loại bỏ trùng lặp và che giấu thông tin cá nhân bằng PII-Tracer. Sau đó, chúng tôi xác nhận rằng trang có chứa lệnh chèn; cụ thể, chúng tôi yêu cầu một nhóm mô hình đồng thuận rằng trang chứa một chỉ dẫn tìm cách chuyển hướng tác nhân khỏi nhiệm vụ mà người dùng dự định.
2. Tạo cặp trang: Một tác nhân xóa văn bản lệnh chèn khỏi mỗi trang và viết lại nội dung xung quanh trên trang, thay thế các chi tiết như tên người và thương hiệu bằng tên hư cấu. Một tác nhân thứ hai kiểm tra trang đã viết lại để tìm nội dung thực tế còn sót lại và gửi trả các trường hợp không đạt kèm phản hồi. Người đánh giá kiểm tra ngẫu nhiên 10% số trang; các vấn đề họ phát hiện được khắc phục trong quy trình, và các bản sửa được áp dụng cho toàn bộ kho dữ liệu. Lệnh chèn được đưa lại vào trang đã viết lại để tạo bản bị tấn công và được loại bỏ khỏi bản sạch. Hai trang có cùng nhiệm vụ, kết quả mong đợi và các chỉ dẫn thông thường.
3. Xác minh: Tác nhân đọc trang ở nhiều dạng khác nhau, vì vậy chúng tôi kết xuất HTML của mỗi trang thành Markdown, cây trợ năng (danh sách có cấu trúc gồm các phần tử giao diện của trang và nhãn của chúng) và ảnh chụp màn hình. Một tác nhân khác kiểm tra rằng lệnh chèn xuất hiện trong cả bốn chế độ xem của trang bị tấn công và trang sạch được đánh giá là vô hại ở mọi chế độ xem. Nếu lệnh chèn bị thiếu ở một chế độ xem, chúng tôi chuyển nó sang vị trí khác trên trang và kết xuất lại, đảm bảo lệnh chèn xuất hiện trong trang bị tấn công cuối cùng ở mọi chế độ xem. Một loạt kiểm tra tự động cuối cùng sẽ chỉnh sửa mọi cặp vẫn còn dấu vết của nguồn gốc, chẳng hạn như tên máy chủ hoặc tên thương hiệu thực.

Phóng to

BrowseSafe-Guard: Bộ phát hiện nhanh và chuẩn xác cho mọi chế độ xem

Một bộ phát hiện hữu ích cần kiểm tra mọi trang một cách nhanh chóng và ít tốn kém. Bộ phát hiện cũng cần chính xác trên cả trang bị tấn công lẫn trang sạch. Độ chuẩn xác cao đặc biệt quan trọng, vì hầu hết các trang đều an toàn; ngay cả một tỷ lệ dương tính giả tương đối thấp cũng sẽ khiến phần lớn cảnh báo là báo động giả. Các mô hình đa dụng dùng prompt thường không đạt yêu cầu về độ chuẩn xác, đồng thời quá chậm và tốn kém để chạy trên mọi trang.

Một bộ phát hiện được huấn luyện trên các trang bị tấn công và trang sạch được thu thập riêng biệt có thể học những lối tắt tình cờ phân tách được hai tập này, chẳng hạn như chủ đề hoặc bố cục của trang. Tuy nhiên, một bộ phát hiện như vậy không khái quát hóa tốt. Thay vào đó, Guard được huấn luyện trên các cặp trang chỉ khác nhau ở chính nội dung chèn, điều này giúp cải thiện độ chính xác (precision) của bộ phát hiện. Với mỗi cặp, Guard đọc riêng trang bị tấn công và trang sạch song sinh của nó, rồi chấm điểm cho từng trang theo khả năng chứa nội dung chèn. Hai mục tiêu huấn luyện được dùng để cập nhật mô hình: mục tiêu phân loại tiêu chuẩn và một mục tiêu xếp hạng phạt Guard trừ khi trang bị tấn công đạt điểm cao hơn trang song sinh ít nhất một biên độ cố định. Nói một cách trực quan, mục tiêu phân loại dạy Guard nên đưa ra quyết định gì, còn mục tiêu xếp hạng gắn quyết định đó với chính nội dung chèn và bỏ qua các yếu tố gây nhiễu vô hại. Nhờ đó, Guard được huấn luyện để phản ứng với chính nội dung chèn, thay vì nội dung xung quanh trên trang.

Guard gồm hai bộ phát hiện, mỗi bộ đều được tinh chỉnh từ Qwen3.5-0.8B. Bộ phát hiện văn bản đọc một dạng xem văn bản của trang: HTML, Markdown hoặc cây trợ năng. Bộ phát hiện đa phương thức đọc ảnh chụp màn hình toàn trang. Khi triển khai, Guard đọc một trang trong một lượt truyền xuôi (forward pass) duy nhất và xuất ra điểm khả năng chứa nội dung chèn; trang sẽ bị gắn cờ nếu điểm vượt quá ngưỡng. Vì Guard chỉ có 0,8 tỷ tham số và chỉ xuất ra một điểm duy nhất, nó đủ nhanh và rẻ để chạy trên mọi trang.

Đánh giá hiệu năng

Chúng tôi so sánh Guard với 18 mô hình được dùng prompt để phát hiện lệnh chèn trên một tập con được giữ lại của benchmark. Chúng tôi báo cáo bốn chỉ số, đo trên BrowseSafe++:

• Độ thu hồi (recall) là tỷ lệ trang bị chèn lệnh được bộ phát hiện gắn cờ, cho biết bộ phát hiện bắt được bao nhiêu cuộc tấn công, vì vậy càng cao càng tốt.
• Tỷ lệ dương tính giả (FPR) là tỷ lệ trang sạch bị bộ phát hiện gắn cờ nhầm, cho biết mức độ thường xuyên bộ phát hiện đưa ra báo động giả, vì vậy càng thấp càng tốt.
• Độ chuẩn xác (precision) là tỷ lệ trang bị gắn cờ thực sự chứa lệnh chèn, cho biết cảnh báo đúng thường xuyên đến mức nào, vì vậy càng cao càng tốt.
• F1 là trung bình điều hòa của độ thu hồi và độ chuẩn xác; F1 chỉ cao khi bộ phát hiện bắt được hầu hết các cuộc tấn công và rất ít lần gắn cờ của nó là báo động giả.

Chúng tôi dùng F1 làm chỉ số chính, vì một bộ phát hiện tốt cần có độ chuẩn xác và độ thu hồi cao. Cả bốn chỉ số đều được tính trung bình trên ba chế độ xem văn bản.

Phóng to

Phóng to

So sánh các mô hình

Các mô hình trọng số mở cỡ nhỏ mà chúng tôi kiểm thử xếp ở cuối bảng. Mistral NeMo và Qwen3 30B-A3B mỗi mô hình gắn cờ khoảng một nửa số trang sạch, trong khi Llama 3.1 8B hiếm khi gắn cờ bất cứ thứ gì và bỏ sót hầu hết các cuộc tấn công. Ngay cả mô hình mạnh nhất trong nhóm là GPT-OSS 20B cũng chỉ đạt F1 70,97%. DeepSeek V3.1, một mô hình trọng số mở lớn hơn nhiều, làm tốt hơn một chút với F1 75,23%.

Các mô hình API gọn nhẹ, bao gồm GPT-5.4 nano, Gemini 3.1 Flash-Lite và Claude Haiku 4.5, phát hiện được nhiều cuộc tấn công hơn, với độ thu hồi (recall) từ 85% đến 97%. Tuy nhiên, cái giá phải trả là tỷ lệ cảnh báo sai cao; Gemini 3.1 Flash-Lite có FPR thấp nhất nhóm ở mức 35,2%, còn FPR của Haiku là gần 69%. Do đó, điểm F1 cao nhất của nhóm là 80,9%, do Gemini 3.1 Flash-Lite đạt được.

Các mô hình còn lại là những mô hình đa dụng mạnh hơn, đạt điểm F1 từ 85% đến 92%. Tuy nhiên, chúng vẫn phải đánh đổi giữa độ thu hồi và FPR: các mô hình thiên về thận trọng sẽ chặn cả trang hợp lệ, còn các mô hình ít gắn cờ hơn lại bỏ sót tấn công. Claude Sonnet 5 có độ thu hồi cao nhất trong tất cả các bộ phát hiện, ở mức 98,73%, nhưng FPR là 24,65%. Gemini 3.1 Pro và GPT-5.5 đạt độ thu hồi lần lượt 97,78% và 97,19%, với FPR lần lượt 19,80% và 20,44%. GPT-6 Astra có độ chính xác tổng thể cao nhất, với độ thu hồi 96,42% và FPR 14,41%. Decider đứng thứ hai, với độ thu hồi 96,02% và FPR 17,44%. Claude Opus 5.5 có FPR thấp nhất, chỉ 4,21%, nhưng độ thu hồi 77,71% đồng nghĩa với việc nó bỏ sót hơn một phần năm số cuộc tấn công. Claude Fable 5.1 tỏ ra mạnh trên những trang mà nó trả lời, với độ thu hồi 89,31% và FPR 7,92%, nhưng nó từ chối trả lời trên khoảng 30% số trang, và hàng “(all)” tính các trường hợp này là gắn cờ.

Phóng to

Guard đẩy xa biên Pareto, đạt được sự cân bằng tốt hơn giữa việc bỏ sót tấn công và báo động giả. Guard đạt F1 khoảng 95% và xếp hạng nhất ở mọi chế độ xem văn bản. Guard chỉ gắn cờ khoảng một trên 20 trang sạch, xấp xỉ một phần ba tỷ lệ của Astra, mô hình dùng prompt chính xác nhất. Sự khác biệt này đến từ quá trình huấn luyện của chúng tôi; mô hình Qwen3.5-0.8B gốc làm nền tảng cho Guard, khi được dùng prompt giống như các mô hình khác, chỉ đạt F1 64% và gắn cờ gần ba trên bốn trang sạch. Trong kịch bản chế độ xem ảnh chụp màn hình, chúng tôi so sánh bộ phát hiện đa phương thức của Guard với bốn mô hình có khả năng xử lý hình ảnh. Với ảnh chụp màn hình toàn trang, Guard đạt khoảng 93% F1, so với khoảng 79% của mô hình tốt nhất trong số các mô hình khác mà chúng tôi đã đánh giá.

Nhận ra một cuộc tấn công không đồng nghĩa với việc chống lại được nó

Theo trực giác, một mô hình có thể xác định đúng một lệnh chèn thì cũng nên bỏ qua lệnh chèn đó khi gặp trang web trong lúc thực hiện nhiệm vụ của người dùng. Tuy nhiên, các thí nghiệm của chúng tôi cho thấy điểm phát hiện cao không đảm bảo rằng mô hình sẽ chống lại được tấn công. Chúng tôi đưa cho mỗi mô hình cùng một trang bị tấn công hai lần: một lần để đánh giá xem trang có chứa lệnh chèn hay không và một lần để thực hiện nhiệm vụ của người dùng mà không thấy kết luận trước đó. Một trình đánh giá riêng biệt kiểm tra xem mô hình có làm theo lệnh chèn hay không. Mọi mô hình được kiểm thử vẫn làm theo một số lệnh chèn mà chúng đã gắn cờ, từ 1,64% số trang bị gắn cờ đối với GPT-6 Astra đến 24,73% đối với Llama 3.1 8B.

Phóng to

Điểm phát hiện không dự đoán đáng tin cậy sự khác biệt giữa các mô hình. Claude Sonnet 5 và GPT-5.5 phát hiện lệnh chèn tốt gần như ngang nhau, với điểm F1 lần lượt khoảng 88% và 89%. Tuy nhiên, Sonnet 5 đã làm theo một lệnh chèn mà chính nó đã gắn cờ trên 19,74% số trang, nhiều gấp mười lần so với GPT-5.5 ở mức 1,97%.

Hệ thống sẵn sàng triển khai để phòng thủ trước tấn công chèn

Những kết quả này cho thấy việc giao quyết định chặn một trang cho một mô hình chuyên dụng là có giá trị, thay vì dựa vào mô hình đang thực hiện nhiệm vụ của người dùng. Một bộ phát hiện riêng biệt sàng lọc từng trang trước khi tác nhân hành động sẽ tạo thêm một lớp phòng thủ, và bộ phát hiện này không có nhiệm vụ nào để bị chiếm quyền hay công cụ nào để bị lạm dụng.

Guard được xây dựng để trở thành bộ phát hiện đó. Ngoài việc có điểm F1 và độ chính xác (accuracy) cao nhất trong tất cả các mô hình chúng tôi đã thử nghiệm, kích thước nhỏ giúp Guard đủ rẻ để chạy trên mọi trang. Trung bình, Guard sử dụng khoảng 0,15 giây thời gian GPU cho mỗi trang văn bản. Trên một GPU H200 thuê, chúng tôi ước tính chi phí là 0,18 USD cho mỗi 1.000 trang, so với 18,95–180,61 USD đối với các mô hình API tiên tiến nhất theo giá niêm yết. Trong so sánh của chúng tôi, điều này giúp việc sàng lọc thường xuyên rẻ hơn nhiều trong khi vẫn duy trì điểm phát hiện cao.

Biểu đồ dưới đây thể hiện độ chính xác của từng bộ phát hiện so với thời gian xử lý mỗi trang và chi phí cho mỗi 1.000 trang, cả hai đều theo thang logarit. Guard đứng một mình ở góc trên bên trái của cả hai biểu đồ: Guard vượt trội về độ chính xác, tốc độ và chi phí. Mọi mô hình dùng prompt đều mất khoảng một giây trở lên cho mỗi trang, và hai mô hình chính xác nhất là GPT-6 Astra và Claude Fable 5.1 có chi phí trên 100 USD cho mỗi 1.000 trang.

Phóng to

Kiểm thử khả năng phòng thủ trước các cuộc tấn công thích ứng

Benchmark BrowseSafe++ có một tập hợp hữu hạn các lệnh chèn. Tuy nhiên, kẻ tấn công thực tế có thể tiến hành tấn công thích ứng: khi một lệnh chèn thất bại, kẻ tấn công có thể viết lại và thử lại. Do đó, một tác nhân chống lại được lệnh chèn ban đầu vẫn có thể dễ bị tổn thương trước các cuộc tấn công trong tương lai. Hơn nữa, các mô hình được huấn luyện trên dữ liệu thu thập từ internet, nên chúng có thể học cách chống lại phần lớn các lệnh chèn trong đó; vì chúng tôi công khai benchmark này, nhiều khả năng nó sẽ bị bão hòa và không còn phân biệt tốt giữa các mô hình. Để giải quyết cả hai vấn đề, chúng tôi đã xây dựng BrowseSafe-Adapt, một môi trường kiểm thử trong đó mô hình tấn công có thể viết lại lệnh chèn. Mỗi bài kiểm thử gồm ba giai đoạn:

1. Thiết lập trường hợp. Mỗi trường hợp ghép một mục BrowseSafe++ với một tác nhân mục tiêu. Mục BrowseSafe++ bao gồm một kịch bản với truy vấn và tác vụ của người dùng, một trang bị tấn công và kết quả mà kẻ tấn công mong muốn. Tác nhân hoạt động trong một môi trường Sandbox cung cấp các công cụ và dữ liệu tổng hợp cần thiết để thực hiện tác vụ. Một mô hình xác minh riêng biệt đánh giá xem cuộc tấn công có đạt được mục tiêu hay không.
2. Chạy một lần thử: Chúng tôi đưa lệnh chèn hiện tại vào trang và để tác nhân thực hiện nhiệm vụ. Trình xác minh kiểm tra câu trả lời của tác nhân và mọi thay đổi mà tác nhân đã thực hiện trong sandbox để xác định cuộc tấn công có thành công hay không. Lần thử đầu tiên dùng lệnh chèn từ mục BrowseSafe++ ban đầu.
3. Sửa đổi và lặp lại: Nếu một cuộc tấn công thất bại, chúng tôi lưu trữ lần thử đó và một mô hình phê bình sẽ xem xét điều gì đã sai. Một mô hình tấn công dùng phản hồi đó để viết lại lệnh chèn; mô hình này có thể thay đổi cách diễn đạt, định dạng hoặc vị trí của cuộc tấn công trên trang. Mục tiêu tấn công, tiêu chí thành công và nội dung xung quanh trên trang vẫn giữ nguyên. Lần thử tiếp theo sử dụng cuộc tấn công đã cập nhật. Quá trình này được lặp lại cho đến khi cuộc tấn công thành công hoặc kẻ tấn công đạt đến giới hạn số lần thử đã đặt.

Phóng to

Chúng tôi đã kiểm thử bảy tác nhân, mỗi tác nhân được xây dựng trên một mô hình khác nhau: Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite cùng các mô hình trọng số mở DeepSeek V3.1 và Kimi K2. Mỗi tác nhân phải đối mặt với cùng 1.024 nhiệm vụ, với tối đa 64 lần thử cho mỗi nhiệm vụ. Ở lần thử đầu tiên, tỷ lệ tấn công thành công thấp ở cả bảy tác nhân. Các lệnh chèn ban đầu chỉ thành công trên tối đa 4% số nhiệm vụ được đánh giá đối với bất kỳ tác nhân nào. Với khung thích ứng, tỷ lệ tấn công thành công tăng mạnh. Kẻ tấn công thành công trên ít nhất 79% số nhiệm vụ đối với năm trong bảy tác nhân. Ngay cả những tác nhân mạnh nhất cũng dễ bị tấn công: các cuộc tấn công vẫn thành công trên khoảng hai phần ba số nhiệm vụ đối với GPT-5.5 và khoảng một phần ba đối với Claude Sonnet 5.

Sự khác biệt giữa các tác nhân lớn nhất khi mục tiêu của kẻ tấn công là khiến tác nhân thực hiện một lệnh gọi công cụ cụ thể. Với các nhiệm vụ có loại mục tiêu này, Sonnet 5 bị khuất phục ở khoảng 8% số nhiệm vụ và GPT-5.5 ở khoảng 29%. Năm tác nhân còn lại thực hiện mục tiêu của kẻ tấn công trên hơn một nửa số nhiệm vụ của chúng.

Chúng tôi cũng chạy BrowseSafe-Adapt với tác nhân Gemini 3.5 Flash-Lite, trong đó Guard sàng lọc từng trang trước. Guard đã chặn 94,5% số lệnh chèn ban đầu và làm số lần thử trung bình mà kẻ tấn công cần tăng gần gấp đôi, từ 9,7 lên 17,0. Tuy nhiên, với đủ 64 lần thử, kẻ tấn công vẫn thành công ở 84,2% số nhiệm vụ (93,6% khi không có Guard), hầu như luôn bằng một lệnh chèn mà Guard không gắn cờ. Điều này khớp với quan điểm chúng tôi đã nêu khi phát hành BrowseSafe: không có mô hình phát hiện nào là giải pháp vạn năng, vì vậy bộ phát hiện phải nằm trong một hệ thống phòng thủ nhiều lớp.

Phóng to

Kết luận

Tác nhân trình duyệt thường dễ bị tấn công chèn lệnh gián tiếp (indirect prompt injection), trong đó các cuộc tấn công ẩn trên những trang web thông thường tìm cách cản trở tác nhân thực hiện nhiệm vụ của người dùng. Mối nguy chỉ ngày càng tăng theo thời gian, vừa vì tác nhân được truy cập nhiều dữ liệu và công cụ hơn, làm tăng mức độ hậu quả tiềm tàng của các cuộc tấn công, vừa vì kẻ tấn công có thể sửa đổi lệnh chèn để chúng hiệu quả hơn.

Bộ công cụ BrowseSafe của chúng tôi giải quyết những mối đe dọa này. Benchmark BrowseSafe++ chứa 38.675 cặp trang web được xây dựng chủ yếu từ các lệnh chèn thực tế, giúp việc huấn luyện và đánh giá bộ phát hiện đáng tin cậy hơn. Các bộ phát hiện BrowseSafe-Guard, được huấn luyện trên những cặp trang này, cho phép phát hiện với độ chính xác cao, nhanh và rẻ, nhờ đó có thể quét các trang trước khi tác nhân hành động dựa trên chúng. Khung BrowseSafe-Adapt cho phép kiểm thử mô hình trước các lệnh chèn đã được sửa đổi, làm lộ ra những lỗ hổng có thể không thấy rõ qua các lần thử đơn lẻ với lệnh chèn cố định.

Chúng tôi hy vọng rằng, khi kết hợp với nhau, những công cụ này sẽ giúp các nhà nghiên cứu và kỹ sư dễ dàng tìm ra lỗi hơn và cải thiện khả năng phòng thủ trước các cuộc tấn công chèn lệnh (prompt injection) qua web. Chúng tôi cũng liên tục đánh giá và cải thiện các cơ chế phòng thủ tích hợp sẵn của Comet và Computer để giữ an toàn cho người dùng.

Bắt đầu

1. Cài đặt SDK và truy cập dữ liệu. SDK được cài đặt từ GitHub:

Bộ dữ liệu bị giới hạn quyền truy cập. Hãy yêu cầu quyền truy cập một lần trên trang Hugging Face của bộ dữ liệu, sau đó đăng nhập bằng hf auth login.

2. Gửi kết quả lên bảng xếp hạng. Đánh giá bộ phát hiện của riêng bạn trên tập kiểm thử của BrowseSafe++:

Lệnh này ghi một quyết định cho mỗi trang đối với từng dạng xem mà bạn liệt kê; hãy liệt kê cả ba dạng xem văn bản để có điểm trung bình trên bảng xếp hạng văn bản. Đăng nhập vào Space bảng xếp hạng bằng tài khoản Hugging Face của bạn và tải lên predictions.jsonl. Space sẽ trả về F1, độ chính xác, tỷ lệ dương tính giả và các chỉ số khác cho từng dạng xem, đồng thời công bố kết quả trên bảng xếp hạng nếu bạn muốn. Mỗi tài khoản (đã tạo ít nhất 60 ngày) được một lượt nộp bài có chấm điểm mỗi tuần theo giờ UTC. Các trang kiểm thử chỉ dùng để đánh giá: không huấn luyện trên chúng hoặc phân phối lại chúng. Phần hướng dẫn nộp bài trình bày định dạng tệp và các quy tắc công bố.

Trích dẫn

@online{perplexity2026BrowseSafePlusPlus,
  author = {{Perplexity} and Yuetian Chen and Kaiyuan Zhang and Yuntao Du and Thomas Li and Mark Tenenholtz and Kyle Polley and Jerry Ma and Denis Yarats and Ninghui Li and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{BrowseSafe++: Building stronger defenses against real-world prompt injection}},
  date = {2026-10-28},
  url = {https://www.perplexity.ai/hub/blog/browsesafe-plus-plus}
}