BrowseSafe++: สร้างการป้องกันที่แข็งแกร่งยิ่งขึ้นต่อการแทรกพรอมต์ในโลกจริง

เอเจนต์ที่ท่องเว็บได้ เช่น ผู้ช่วยที่มีอยู่ใน Comet หรือ Computer จำเป็นต้องโต้ตอบกับหน้าเว็บ โดยอ่านเนื้อหาและใช้เนื้อหานั้นดำเนินการต่าง ๆ แทนผู้ใช้ ซึ่งทำให้เอเจนต์มีความเสี่ยงต่อการแทรกพรอมต์ทางอ้อม โดยผู้โจมตีจะวางข้อความที่เป็นอันตรายไว้บนหน้าเว็บ หากเอเจนต์ทำตามคำสั่งเหล่านี้ ก็อาจให้คำตอบที่ทำให้เข้าใจผิดหรือดำเนินการที่ผู้ใช้ไม่ได้ร้องขอ

ในเดือนธันวาคม 2025 เราได้เปิดตัว BrowseSafe ซึ่งเป็นเบนช์มาร์กและโมเดลตรวจจับสำหรับภัยคุกคามนี้ เราสร้างขึ้นโดยเพิ่มการโจมตีสังเคราะห์ลงในหน้าเว็บที่สมจริงซึ่งเอเจนต์มีแนวโน้มจะพบ ตลอดปีที่ผ่านมา การโจมตีได้พัฒนาให้ซับซ้อนขึ้นและดูคล้ายเนื้อหาทั่วไปของหน้าเว็บมากขึ้น แทนที่จะใช้วลีที่เห็นได้ชัดอย่าง “ละเว้นคำสั่งก่อนหน้า” การโจมตีมักเลียนแบบเนื้อหาที่เอเจนต์มีแนวโน้มจะเชื่อถือ เช่น ประกาศอย่างเป็นทางการจากเว็บไซต์ หรือบันทึกเกี่ยวกับค่ากำหนดของผู้ใช้

ด้วยแรงผลักดันจากการเปลี่ยนแปลงเหล่านี้ เราจึงสร้างเบนช์มาร์กเวอร์ชันปรับปรุง BrowseSafe++ เพื่อวัดว่าตัวตรวจจับการแทรกคำสั่งในปัจจุบันจับการโจมตีเหล่านี้ได้หรือไม่ และเอเจนต์สามารถต้านทานการโจมตีเหล่านี้ได้หรือไม่ เบนช์มาร์กนี้ประกอบด้วยคู่หน้าเว็บที่ถูกโจมตีและหน้าปกติ 38,675 คู่ ซึ่งส่วนใหญ่สร้างขึ้นจากการแทรกคำสั่งที่รวบรวมได้ในโลกจริง สำหรับแต่ละหน้า เราเขียนเนื้อหาโดยรอบใหม่เพื่อปกป้องความเป็นส่วนตัว แต่คงการโจมตีไว้ตามต้นฉบับทุกคำ ทุกหน้ามีให้ในสี่รูปแบบที่เอเจนต์เบราว์เซอร์อ่าน ได้แก่ HTML, Markdown, แผนผังการช่วยการเข้าถึง และภาพหน้าจอ เราใช้ส่วนย่อยของเบนช์มาร์กเพื่อฝึก BrowseSafe-Guard ซึ่งเป็นตัวตรวจจับขนาด 0.8B พารามิเตอร์หนึ่งคู่ ได้แก่ ตัวตรวจจับข้อความและตัวตรวจจับแบบมัลติโมดัล ตัวตรวจจับ Guard ทั้งสองระบุการแทรกคำสั่งได้แม่นยำกว่าโมเดลที่ใช้การพรอมต์ที่เราทดสอบ รวมถึงโมเดลระดับแนวหน้า อีกทั้งยังเร็วกว่า ถูกกว่า และทำเครื่องหมายหน้าปกติผิดพลาดน้อยกว่ามาก

เรากำลังเผยแพร่ BrowseSafe++ เป็นเบนช์มาร์กแบบเปิด เว็บไซต์โครงการมีลิงก์ไปยังชุดข้อมูล SDK รายงานวิจัย และลีดเดอร์บอร์ดสาธารณะ ทุกทีมสามารถให้คะแนนตัวตรวจจับของตนกับหน้าทดสอบที่ไม่ได้เปิดเผยป้ายกำกับ และส่งป้ายกำกับเพื่อรับการให้คะแนนและอาจได้รับการบรรจุในลีดเดอร์บอร์ด หากต้องการประเมินและส่งผลลัพธ์ของคุณ โปรดดูเริ่มต้นใช้งาน

การสร้างเบนช์มาร์กจากการแทรกคำสั่งที่พบจริง

BrowseSafe++ สร้างขึ้นจากการแทรกพรอมต์ที่พบบนเว็บไซต์จริง ระหว่างเดือนกันยายน 2025 ถึงกันยายน 2026 ตัวตรวจจับการแทรกพรอมต์ของ Comet ทำเครื่องหมายการแทรกคำสั่ง 1.15 ล้านรายการบนหน้าที่เอเจนต์ของ Comet อ่าน เราสร้างคู่หน้าเว็บ 32,187 คู่จากการแทรกคำสั่งเหล่านั้น และเพิ่มอีก 6,488 คู่จากเบนช์มาร์ก BrowseSafe ดั้งเดิม รวมทั้งหมด 38,675 คู่ แต่ละคู่ประกอบด้วยหน้าที่ถูกโจมตีและหน้าแฝดที่ปกติ ซึ่งเป็นหน้าเดียวกันแต่ไม่มีการแทรกคำสั่ง

การแทรกคำสั่งในโลกจริงมีลักษณะอย่างไร

ตัวอย่างสองรายการจากเบนช์มาร์กแสดงให้เห็นว่าการแทรกคำสั่งเหล่านี้มีลักษณะอย่างไรในทางปฏิบัติ

ในตัวอย่างหนึ่ง คำขอซื้อปลอมกระตุ้นให้เอเจนต์ดำเนินการที่ไม่ได้รับอนุญาต ตัวตรวจจับของ Comet ทำเครื่องหมายบล็อกข้อความภาษาอังกฤษนี้บนหน้าเอกสารสำหรับนักพัฒนาภาษารัสเซียในเดือนตุลาคม 2025:

ข้อความนี้เปิดและปิดท้ายด้วยคำสั่ง และเติมช่วงกลางด้วยเนื้อหาการตลาดโทเค็นทั่วไป โดยอ้างว่ามาจากผู้พัฒนาของเอเจนต์เอง และปิดท้ายด้วยรหัสอนุญาตเพื่อทำให้การซื้อดูเหมือนได้รับการอนุมัติแล้ว

ในอีกตัวอย่างหนึ่ง บทสนทนาปลอมมุ่งขัดขวางงานของเอเจนต์ ข้อความนี้พบบนหน้าคลังโค้ดในเดือนมีนาคม 2026:

ข้อความนี้ถูกออกแบบให้ดูเหมือนบทสนทนาระหว่างผู้ใช้กับเอเจนต์ โดย <|im_start|> และ <|im_end|> เป็นเครื่องหมายที่โมเดลแชทบางตัวใช้แบ่งแต่ละรอบของบทสนทนา เอเจนต์ที่หลงกลการโจมตีนี้จะตอบสนองต่อข้อความของผู้ใช้ที่ถูกปลอมขึ้นและตอบกลับด้วยวลีของผู้โจมตี

เราพบรูปแบบที่คล้ายกันในการแทรกคำสั่งที่ถูกทำเครื่องหมาย:

• เลียนแบบแหล่งที่มาที่น่าเชื่อถือ ทั้งสองตัวอย่างทำให้ข้อความบนหน้าเว็บฟังดูเหมือนมาจากแหล่งที่เอเจนต์เชื่อถือ ได้แก่ ผู้พัฒนาของเอเจนต์ในตัวอย่างแรก และบทสนทนาของเอเจนต์เองในตัวอย่างที่สอง การแทรกพรอมต์ยังอาจแอบอ้างเป็นตัวเว็บไซต์เองโดยเลียนแบบการตรวจสอบความปลอดภัยและประกาศนโยบาย หรือแอบอ้างเป็นผู้ใช้โดยเสนอค่ากำหนดปลอม การแทรกพรอมต์ราวสองในสามเขียนด้วยภาษาทางการ
• หลายรายการเขียนด้วยภาษาที่ต่างออกไป ใน 24.4% ของคู่หน้าเว็บ การแทรกคำสั่งใช้ภาษาที่ต่างจากส่วนอื่นของหน้า โดยทั่วไปจะอยู่ในรูปของคำสั่งภาษาอังกฤษบนหน้าที่ไม่ใช่ภาษาอังกฤษ ดังเช่นในตัวอย่างแรก การโจมตีลักษณะนี้มุ่งเป้าไปที่เอเจนต์อย่างชัดเจน เพราะเอเจนต์อ่านได้ทุกภาษาและมักใช้ภาษาอังกฤษเป็นภาษาหลัก การสลับภาษายังทำให้การตรวจจับยากขึ้นด้วย ในการประเมิน BrowseSafe ดั้งเดิมของเรา การโจมตีหลายภาษาเป็นหนึ่งในการโจมตีที่ตรวจจับได้ยากที่สุด
• ส่วนใหญ่ต้องการการกระทำ ไม่ใช่คำพูด มากกว่าสี่ในสิบรายการผลักดันให้เอเจนต์ดำเนินการที่ผู้ใช้ไม่เคยร้องขอ เช่น การซื้อโทเค็นในตัวอย่างแรก และประมาณหนึ่งในสามพยายามทำให้เอเจนต์ละทิ้งงานของผู้ใช้ ดังเช่นในตัวอย่างที่สอง มีเพียงประมาณ 3% เท่านั้นที่พยายามแทรกข้อมูลเท็จลงในคำตอบ
• มักแฝงมากับเนื้อหาที่ใครก็โพสต์ได้ ผู้โจมตีไม่จำเป็นต้องควบคุมเว็บไซต์ เพียงโพสต์ในฟอรัมหรือเอกสารที่แชร์บนเว็บไซต์ทั่วไปก็เพียงพอแล้ว และการแทรกพรอมต์มากกว่า 23,000 รายการใน BrowseSafe++ ก็มาในรูปแบบนี้ โดเมนที่น่าเชื่อถือก็ยังอาจถูกใช้เพื่อแทรกข้อความของผู้โจมตีได้

การแทรกคำสั่งในเบนช์มาร์กฉบับสุดท้ายครอบคลุมเว็บไซต์ 12 ประเภท การโจมตี 24 ประเภท เป้าหมายของผู้โจมตี 6 แบบ และตำแหน่งบนหน้า 18 ตำแหน่ง

ขยาย

จากหน้าเว็บที่ถูกทำเครื่องหมายสู่คู่ข้อมูลในเบนช์มาร์ก

เราไม่สามารถใช้หน้าที่ถูกทำเครื่องหมายในเบนช์มาร์กตามสภาพเดิมได้ เนื่องจากหน้าเหล่านั้นอาจมีข้อมูลส่วนบุคคลของผู้ใช้ที่เอเจนต์ทำงานให้ การเปลี่ยนหน้าเว็บให้เป็นคู่เบนช์มาร์กที่แชร์ได้ต้องผ่านสามขั้นตอนหลัก:

1. จัดหาการแทรกคำสั่ง: เรารวบรวมหน้าที่ถูกทำเครื่องหมาย ลบรายการที่ซ้ำกัน และปกปิดข้อมูลส่วนบุคคลด้วย PII-Tracer จากนั้นเรายืนยันว่าหน้านั้นมีการแทรกคำสั่ง โดยเรากำหนดให้คณะโมเดลเห็นพ้องกันว่าหน้านั้นมีคำสั่งที่พยายามเบี่ยงเบนเอเจนต์ออกจากงานที่ผู้ใช้ตั้งใจไว้
2. สร้างคู่หน้าเว็บ: เอเจนต์จะนำข้อความที่แทรกออกจากแต่ละหน้าและเขียนเนื้อหาโดยรอบใหม่ โดยแทนที่รายละเอียดอย่างชื่อบุคคลและแบรนด์ด้วยชื่อสมมติ เอเจนต์ตัวที่สองจะตรวจสอบหน้าที่เขียนใหม่ว่ามีเนื้อหาจากโลกจริงหลงเหลืออยู่หรือไม่ และส่งหน้าที่ไม่ผ่านกลับไปพร้อมข้อเสนอแนะ ผู้ตรวจทานที่เป็นมนุษย์จะสุ่มตรวจ 10% ของหน้า ปัญหาที่พบจะได้รับการแก้ไขในไปป์ไลน์ และการแก้ไขจะถูกนำไปใช้กับคลังข้อมูลทั้งหมด การแทรกคำสั่งจะถูกใส่กลับเข้าไปในหน้าที่เขียนใหม่เพื่อสร้างสำเนาที่ถูกโจมตี และไม่ใส่ในสำเนาปกติ ทั้งสองหน้ามีงาน ผลลัพธ์ที่คาดหวัง และคำสั่งทั่วไปเหมือนกัน
3. ตรวจสอบ: เอเจนต์อ่านหน้าเว็บในรูปแบบที่แตกต่างกัน เราจึงเรนเดอร์ HTML ของแต่ละหน้าเป็น Markdown, แผนผังการช่วยการเข้าถึง (รายการแบบมีโครงสร้างขององค์ประกอบอินเทอร์เฟซและป้ายกำกับบนหน้า) และภาพหน้าจอ เอเจนต์อีกตัวจะตรวจสอบว่าการแทรกคำสั่งปรากฏในทั้งสี่มุมมองของหน้าที่ถูกโจมตี และหน้าปกติถูกตัดสินว่าไม่เป็นอันตรายในทุกมุมมอง หากการแทรกคำสั่งไม่ปรากฏในมุมมองใดมุมมองหนึ่ง เราจะย้ายไปไว้ที่ตำแหน่งอื่นบนหน้าและเรนเดอร์อีกครั้ง เพื่อให้แน่ใจว่าการแทรกคำสั่งปรากฏในหน้าที่ถูกโจมตีฉบับสุดท้ายในทุกมุมมอง ชุดการตรวจสอบอัตโนมัติขั้นสุดท้ายจะแก้ไขคู่หน้าเว็บที่ยังมีร่องรอยของแหล่งที่มา เช่น ชื่อโฮสต์หรือชื่อแบรนด์จริง

ขยาย

BrowseSafe-Guard: ตัวตรวจจับที่รวดเร็วและแม่นยำสำหรับทุกมุมมอง

ตัวตรวจจับที่มีประโยชน์ต้องตรวจสอบทุกหน้าได้อย่างรวดเร็วและประหยัด และยังต้องแม่นยำทั้งกับหน้าที่ถูกโจมตีและหน้าปกติ ความแม่นยำ (precision) ที่สูงมีความสำคัญเป็นพิเศษ เนื่องจากหน้าเว็บส่วนใหญ่ปลอดภัย แม้อัตราผลบวกลวงจะค่อนข้างต่ำ ก็อาจทำให้การแจ้งเตือนส่วนใหญ่เป็นการแจ้งเตือนผิดพลาดได้ โมเดลอเนกประสงค์ที่ใช้การพรอมต์มักมีความแม่นยำไม่เพียงพอ อีกทั้งยังช้าและมีค่าใช้จ่ายสูงเกินกว่าจะใช้กับทุกหน้า

ตัวตรวจจับที่ฝึกด้วยหน้าเว็บที่ถูกโจมตีและหน้าเว็บที่สะอาดซึ่งรวบรวมแยกกันอาจเรียนรู้ทางลัดที่บังเอิญแยกข้อมูลทั้งสองชุดออกจากกันได้ เช่น หัวข้อหรือเลย์เอาต์ของหน้าเว็บ อย่างไรก็ตาม ตัวตรวจจับลักษณะนี้ไม่สามารถนำไปใช้กับข้อมูลใหม่ได้ดี (generalize) Guard จึงฝึกด้วยคู่หน้าเว็บที่แตกต่างกันเพียงที่ตัวการแทรกพรอมต์เท่านั้น ซึ่งช่วยเพิ่มความแม่นยำ (precision) ของตัวตรวจจับ สำหรับแต่ละคู่ Guard จะอ่านหน้าเว็บที่ถูกโจมตีและหน้าเว็บคู่แฝดที่สะอาดแยกกัน แล้วให้คะแนนแต่ละหน้าตามโอกาสที่หน้านั้นจะมีการแทรกพรอมต์ เราใช้วัตถุประสงค์การฝึกสองแบบเพื่ออัปเดตโมเดล ได้แก่ วัตถุประสงค์การจำแนกประเภทมาตรฐาน และวัตถุประสงค์การจัดอันดับที่จะลงโทษ Guard เว้นแต่หน้าเว็บที่ถูกโจมตีจะได้คะแนนสูงกว่าหน้าคู่แฝดอย่างน้อยตามส่วนต่างคงที่ที่กำหนด หากมองตามสัญชาตญาณ วัตถุประสงค์การจำแนกประเภทจะสอน Guard ว่าควรตัดสินใจอย่างไร ส่วนวัตถุประสงค์การจัดอันดับจะผูกการตัดสินใจนั้นไว้กับตัวการแทรกพรอมต์และไม่สนใจสิ่งรบกวนที่ไม่เป็นอันตราย วิธีนี้ฝึกให้ Guard ตอบสนองต่อตัวการแทรกพรอมต์เอง แทนที่จะตอบสนองต่อเนื้อหาโดยรอบของหน้าเว็บ

Guard ประกอบด้วยตัวตรวจจับสองตัว ซึ่งแต่ละตัวผ่านการปรับแต่ง (fine-tune) จาก Qwen3.5-0.8B ตัวตรวจจับข้อความจะอ่านมุมมองข้อความหนึ่งแบบของหน้าเว็บ ได้แก่ HTML, Markdown หรือแผนผังการเข้าถึง (accessibility tree) ส่วนตัวตรวจจับแบบมัลติโมดัลจะอ่านภาพหน้าจอแบบเต็มหน้า เมื่อใช้งานจริง Guard จะอ่านหน้าเว็บด้วยการส่งผ่านไปข้างหน้า (forward pass) เพียงครั้งเดียวและให้ผลลัพธ์เป็นคะแนนการแทรกพรอมต์ โดยหน้าเว็บจะถูกทำเครื่องหมายหากคะแนนเกินเกณฑ์ที่กำหนด เนื่องจาก Guard มีพารามิเตอร์เพียง 0.8B และให้ผลลัพธ์เป็นคะแนนเพียงค่าเดียว จึงทำงานได้เร็วและมีต้นทุนต่ำพอที่จะรันกับทุกหน้าได้

การวัดประสิทธิภาพด้วยเบนช์มาร์ก

เราเปรียบเทียบ Guard กับโมเดล 18 ตัวที่ใช้การพรอมต์ให้ตรวจจับการแทรกคำสั่งบนส่วนย่อยของเบนช์มาร์กที่กันไว้ไม่ใช้ในการฝึก เรารายงานตัวชี้วัดสี่ตัวที่วัดบน BrowseSafe++:

• ค่าความครบถ้วน (recall) คือสัดส่วนของหน้าที่มีการแทรกคำสั่งซึ่งตัวตรวจจับทำเครื่องหมาย ซึ่งวัดว่าตัวตรวจจับจับการโจมตีได้มากเพียงใด ดังนั้นยิ่งสูงยิ่งดี
• อัตราผลบวกลวง (FPR) คือสัดส่วนของหน้าปกติที่ตัวตรวจจับทำเครื่องหมายผิดพลาด ซึ่งวัดว่าตัวตรวจจับแจ้งเตือนผิดพลาดบ่อยเพียงใด ดังนั้นยิ่งต่ำยิ่งดี
• ความแม่นยำ (precision) คือสัดส่วนของหน้าที่ถูกทำเครื่องหมายซึ่งมีการแทรกคำสั่งอยู่จริง ซึ่งวัดว่าการแจ้งเตือนถูกต้องบ่อยเพียงใด ดังนั้นยิ่งสูงยิ่งดี
• F1 คือค่าเฉลี่ยฮาร์มอนิกของค่าความครบถ้วนและความแม่นยำ ซึ่งจะสูงก็ต่อเมื่อตัวตรวจจับจับการโจมตีได้เกือบทั้งหมด และการทำเครื่องหมายมีเพียงไม่กี่ครั้งที่เป็นการแจ้งเตือนผิดพลาด

เราใช้ F1 เป็นตัวชี้วัดหลัก เนื่องจากตัวตรวจจับที่ดีควรมีทั้งความแม่นยำและค่าความครบถ้วนสูง ตัวชี้วัดทั้งสี่ตัวคำนวณเป็นค่าเฉลี่ยจากมุมมองข้อความทั้งสามแบบ

ขยาย

ขยาย

การเปรียบเทียบโมเดล

โมเดลแบบโอเพนเวตขนาดเล็กที่เราทดสอบอยู่ในอันดับท้ายสุด Mistral NeMo และ Qwen3 30B-A3B ต่างทำเครื่องหมายหน้าปกติประมาณครึ่งหนึ่ง ขณะที่ Llama 3.1 8B แทบไม่ทำเครื่องหมายสิ่งใดเลยและพลาดการโจมตีส่วนใหญ่ แม้แต่โมเดลที่แข็งแกร่งที่สุดในกลุ่มนี้อย่าง GPT-OSS 20B ก็มีค่า F1 เพียง 70.97% ส่วน DeepSeek V3.1 ซึ่งเป็นโมเดลแบบโอเพนเวตที่ใหญ่กว่ามาก ทำได้ดีกว่าเล็กน้อยด้วยค่า F1 75.23%

โมเดล API น้ำหนักเบา รวมถึง GPT-5.4 nano, Gemini 3.1 Flash-Lite และ Claude Haiku 4.5 ตรวจจับการโจมตีได้มากกว่า โดยมีค่า recall ระหว่าง 85% ถึง 97% อย่างไรก็ตาม ต้องแลกมากับสัดส่วนการแจ้งเตือนผิดพลาดที่สูง โดย Gemini 3.1 Flash-Lite มี FPR ต่ำที่สุดในกลุ่มที่ 35.2% ส่วน FPR ของ Haiku สูงเกือบ 69% ส่งผลให้คะแนน F1 สูงสุดของกลุ่มอยู่ที่ 80.9% ซึ่งทำได้โดย Gemini 3.1 Flash-Lite

โมเดลที่เหลือเป็นโมเดลอเนกประสงค์ที่แข็งแกร่งกว่า โดยมีคะแนน F1 ระหว่าง 85% ถึง 92% อย่างไรก็ตาม โมเดลเหล่านี้ยังต้องแลกเปลี่ยนระหว่างค่าความครบถ้วนกับ FPR โมเดลที่เน้นความระมัดระวังจะบล็อกหน้าที่ถูกต้องตามปกติ ส่วนโมเดลที่ทำเครื่องหมายน้อยกว่าจะพลาดการโจมตี Claude Sonnet 5 มีค่าความครบถ้วนสูงสุดในบรรดาตัวตรวจจับทั้งหมดที่ 98.73% แต่มี FPR 24.65% Gemini 3.1 Pro และ GPT-5.5 มีค่าความครบถ้วน 97.78% และ 97.19% โดยมี FPR 19.80% และ 20.44% ตามลำดับ GPT-6 Astra มีความถูกต้องโดยรวมสูงสุด โดยมีค่าความครบถ้วน 96.42% และ FPR 14.41% Decider ตามมาเป็นอันดับสอง โดยมีค่าความครบถ้วน 96.02% และ FPR 17.44% Claude Opus 5.5 มี FPR ต่ำสุดเพียง 4.21% แต่ค่าความครบถ้วน 77.71% หมายความว่าโมเดลนี้พลาดการโจมตีมากกว่าหนึ่งในห้า Claude Fable 5.1 ดูแข็งแกร่งในหน้าที่โมเดลตอบ โดยมีค่าความครบถ้วน 89.31% และ FPR 7.92% แต่ปฏิเสธที่จะตอบในประมาณ 30% ของหน้า ซึ่งแถว “(all)” นับเป็นการทำเครื่องหมาย

ขยาย

Guard ผลักแนวพาเรโต (Pareto frontier) ให้ก้าวหน้าขึ้น โดยให้สมดุลระหว่างการพลาดการโจมตีกับการแจ้งเตือนผิดพลาดได้ดีกว่า Guard มีค่า F1 ประมาณ 95% และอยู่อันดับหนึ่งในทุกมุมมองข้อความ โดยทำเครื่องหมายหน้าปกติเพียงประมาณหนึ่งใน 20 หน้า หรือราวหนึ่งในสามของอัตราของ Astra ซึ่งเป็นโมเดลที่ใช้การพรอมต์ที่ถูกต้องที่สุด ความแตกต่างนี้มาจากการฝึกของเรา เพราะ Qwen3.5-0.8B ดั้งเดิมที่ Guard ใช้เป็นฐาน เมื่อใช้การพรอมต์แบบเดียวกับโมเดลอื่น ๆ มีค่า F1 เพียง 64% และทำเครื่องหมายหน้าปกติเกือบสามในสี่หน้า ในสถานการณ์มุมมองภาพหน้าจอ เราเปรียบเทียบตัวตรวจจับแบบมัลติโมดัลของ Guard กับโมเดลที่รองรับรูปภาพสี่ตัว เมื่อได้รับภาพหน้าจอแบบเต็มหน้า Guard ได้คะแนน F1 ประมาณ 93% เทียบกับประมาณ 79% ของโมเดลที่ดีที่สุดในบรรดาโมเดลอื่นที่เราประเมิน

การรู้ว่าเป็นการโจมตีไม่ได้หมายความว่าจะต้านทานได้

โดยสัญชาตญาณแล้ว โมเดลที่สามารถระบุการแทรกคำสั่งได้อย่างถูกต้องก็ควรเพิกเฉยต่อการแทรกคำสั่งนั้นเมื่อพบหน้าดังกล่าวขณะทำงานของผู้ใช้ อย่างไรก็ตาม การทดลองของเราแสดงให้เห็นว่าคะแนนการตรวจจับที่สูงไม่ได้รับประกันว่าโมเดลจะต้านทานการโจมตีได้ เราให้หน้าที่ถูกโจมตีหน้าเดียวกันแก่แต่ละโมเดลสองครั้ง ครั้งแรกเพื่อตัดสินว่าหน้านั้นมีการแทรกคำสั่งหรือไม่ และอีกครั้งเพื่อทำงานของผู้ใช้โดยไม่เห็นผลการตัดสินก่อนหน้า จากนั้นผู้ตัดสินอีกตัวหนึ่งจะตรวจสอบว่าโมเดลทำตามการแทรกคำสั่งหรือไม่ ทุกโมเดลที่ทดสอบยังคงทำตามการแทรกคำสั่งบางรายการที่ตัวเองทำเครื่องหมายไว้ ตั้งแต่ 1.64% ของหน้าที่ถูกทำเครื่องหมายสำหรับ GPT-6 Astra ไปจนถึง 24.73% สำหรับ Llama 3.1 8B

ขยาย

คะแนนการตรวจจับไม่สามารถใช้คาดการณ์ความแตกต่างระหว่างโมเดลได้อย่างน่าเชื่อถือ Claude Sonnet 5 และ GPT-5.5 ตรวจจับการแทรกคำสั่งได้ดีพอ ๆ กัน โดยมีคะแนน F1 ประมาณ 88% และ 89% ตามลำดับ อย่างไรก็ตาม Sonnet 5 ทำตามการแทรกคำสั่งที่ตัวเองทำเครื่องหมายไว้ใน 19.74% ของหน้า ซึ่งบ่อยกว่า GPT-5.5 ที่ 1.97% ถึงสิบเท่า

ระบบป้องกันการแทรกพรอมต์ที่พร้อมใช้งานจริง

ผลลัพธ์เหล่านี้ชี้ให้เห็นว่าการมอบหมายการตัดสินใจบล็อกหน้าเว็บให้กับโมเดลเฉพาะทางมีประโยชน์ แทนที่จะพึ่งพาโมเดลที่ทำงานของผู้ใช้ ตัวตรวจจับแยกต่างหากที่คัดกรองแต่ละหน้าก่อนที่เอเจนต์จะดำเนินการช่วยเพิ่มการป้องกันอีกชั้นหนึ่ง และไม่มีงานให้ถูกยึดครองหรือเครื่องมือให้ถูกนำไปใช้ในทางที่ผิด

Guard ถูกสร้างขึ้นมาเพื่อเป็นตัวตรวจจับดังกล่าว นอกจากจะมีคะแนน F1 และความถูกต้อง (accuracy) สูงสุดในบรรดาโมเดลทั้งหมดที่เราทดสอบแล้ว ขนาดที่เล็กยังทำให้มีต้นทุนต่ำพอที่จะรันกับทุกหน้าได้ โดยเฉลี่ย Guard ใช้เวลา GPU ประมาณ 0.15 วินาทีต่อหน้าข้อความ บน H200 แบบเช่า เราประเมินต้นทุนไว้ที่ $0.18 ต่อ 1,000 หน้า เทียบกับ $18.95–180.61 สำหรับโมเดล API ระดับแนวหน้าตามราคาที่ประกาศ ในการเปรียบเทียบของเรา สิ่งนี้ทำให้การคัดกรองบ่อยครั้งมีต้นทุนต่ำกว่ามาก ขณะที่ยังคงคะแนนการตรวจจับที่สูงไว้ได้

รูปด้านล่างแสดงความถูกต้องของตัวตรวจจับแต่ละตัวเทียบกับเวลาที่ใช้ต่อหน้าและค่าใช้จ่ายต่อ 1,000 หน้า โดยทั้งสองแบบใช้สเกลลอการิทึม Guard อยู่โดดเดี่ยวที่มุมซ้ายบนของทั้งสองแผง โดยชนะทั้งด้านความถูกต้อง ความเร็ว และค่าใช้จ่าย โมเดลที่ใช้การพรอมต์ทุกตัวใช้เวลาประมาณหนึ่งวินาทีหรือมากกว่าต่อหน้า และสองโมเดลที่ถูกต้องที่สุดอย่าง GPT-6 Astra และ Claude Fable 5.1 มีค่าใช้จ่ายมากกว่า $100 ต่อ 1,000 หน้า

ขยาย

การทดสอบการป้องกันต่อการโจมตีแบบปรับตัว

เบนช์มาร์ก BrowseSafe++ มีชุดการแทรกคำสั่งที่จำกัด อย่างไรก็ตาม ผู้โจมตีจริงสามารถใช้การโจมตีแบบปรับตัวได้ เมื่อการแทรกคำสั่งล้มเหลว ผู้โจมตีสามารถเขียนใหม่และลองอีกครั้ง ด้วยเหตุนี้ เอเจนต์ที่ต้านทานการแทรกคำสั่งดั้งเดิมได้จึงอาจยังมีความเสี่ยงต่อการโจมตีในอนาคต นอกจากนี้ โมเดลยังได้รับการฝึกด้วยข้อมูลที่รวบรวมจากอินเทอร์เน็ต จึงอาจเรียนรู้ที่จะต้านทานการแทรกคำสั่งส่วนใหญ่ในนั้นได้ และเนื่องจากเราเผยแพร่เบนช์มาร์กต่อสาธารณะ เบนช์มาร์กจึงมีแนวโน้มที่จะอิ่มตัวและแยกแยะความแตกต่างระหว่างโมเดลได้ไม่ดี เพื่อแก้ปัญหาทั้งสองข้อ เราจึงสร้าง BrowseSafe-Adapt ซึ่งเป็นสภาพแวดล้อมการทดสอบที่โมเดลผู้โจมตีสามารถเขียนการแทรกคำสั่งใหม่ได้ การทดสอบแต่ละครั้งมีสามขั้นตอน:

1. ตั้งค่ากรณีทดสอบ กรณีทดสอบหนึ่งจะจับคู่รายการ BrowseSafe++ กับเอเจนต์เป้าหมาย รายการ BrowseSafe++ ประกอบด้วยสถานการณ์ที่มีคำค้นหาและงานของผู้ใช้ หน้าเว็บที่ถูกโจมตี และผลลัพธ์ที่ผู้โจมตีต้องการ เอเจนต์ทำงานในแซนด์บ็อกซ์ที่มีเครื่องมือและข้อมูลสังเคราะห์ที่จำเป็นต่อการดำเนินงานนั้น โมเดลผู้ตรวจสอบที่แยกต่างหากจะประเมินว่าการโจมตีบรรลุเป้าหมายหรือไม่
2. ทดลองโจมตี: เราใส่การแทรกคำสั่งปัจจุบันลงในหน้าเว็บและให้เอเจนต์ทำงาน ตัวตรวจสอบจะตรวจคำตอบของเอเจนต์และการเปลี่ยนแปลงใด ๆ ที่เอเจนต์ทำกับแซนด์บ็อกซ์เพื่อพิจารณาว่าการโจมตีสำเร็จหรือไม่ ความพยายามครั้งแรกใช้การแทรกคำสั่งจากรายการดั้งเดิมใน BrowseSafe++
3. ปรับแก้และทำซ้ำ: หากการโจมตีล้มเหลว เราจะเก็บถาวรความพยายามนั้น และโมเดลวิจารณ์จะตรวจทานว่าเกิดข้อผิดพลาดตรงไหน โมเดลผู้โจมตีจะใช้ข้อเสนอแนะนั้นเขียนการแทรกคำสั่งใหม่ โดยสามารถเปลี่ยนถ้อยคำ การจัดรูปแบบ หรือตำแหน่งของการโจมตีบนหน้าได้ ส่วนเป้าหมายการโจมตี เกณฑ์ความสำเร็จ และเนื้อหาโดยรอบบนหน้ายังคงเหมือนเดิม ความพยายามครั้งถัดไปจะใช้การโจมตีที่ปรับปรุงแล้ว กระบวนการนี้จะทำซ้ำจนกว่าการโจมตีจะสำเร็จหรือผู้โจมตีถึงขีดจำกัดจำนวนครั้งที่กำหนดไว้

ขยาย

เราทดสอบเอเจนต์เจ็ดตัว ซึ่งแต่ละตัวสร้างขึ้นบนโมเดลที่แตกต่างกัน ได้แก่ Claude Sonnet 5, Claude Haiku 4.5, GPT-5.5, Gemini 3.1 Pro, Gemini 3.5 Flash-Lite และโมเดลแบบโอเพนเวต DeepSeek V3.1 และ Kimi K2 เอเจนต์แต่ละตัวต้องเผชิญกับงานชุดเดียวกัน 1,024 งาน โดยพยายามได้สูงสุด 64 ครั้งต่องาน ในความพยายามครั้งแรก อัตราความสำเร็จของการโจมตีต่ำในเอเจนต์ทั้งเจ็ดตัว การแทรกคำสั่งดั้งเดิมสำเร็จไม่เกิน 4% ของงานที่ประเมินกับเอเจนต์ใดก็ตาม แต่ภายใต้เฟรมเวิร์กแบบปรับตัว อัตราความสำเร็จของการโจมตีเพิ่มขึ้นอย่างมาก ผู้โจมตีสำเร็จอย่างน้อย 79% ของงานกับเอเจนต์ห้าในเจ็ดตัว แม้แต่เอเจนต์ที่แข็งแกร่งที่สุดก็ยังมีช่องโหว่ โดยการโจมตียังคงสำเร็จประมาณสองในสามของงานกับ GPT-5.5 และประมาณหนึ่งในสามกับ Claude Sonnet 5

ความแตกต่างระหว่างเอเจนต์เห็นได้ชัดที่สุดเมื่อเป้าหมายของผู้โจมตีคือการทำให้เอเจนต์เรียกใช้เครื่องมือบางอย่าง สำหรับงานที่มีเป้าหมายประเภทนี้ Sonnet 5 ยอมทำตามผู้โจมตีในประมาณ 8% ของงาน และ GPT-5.5 ประมาณ 29% ส่วนอีกห้าตัวที่เหลือทำตามเป้าหมายของผู้โจมตีในงานมากกว่าครึ่งหนึ่ง

นอกจากนี้ เรายังทดสอบ BrowseSafe-Adapt กับเอเจนต์ Gemini 3.5 Flash-Lite โดยให้ Guard คัดกรองแต่ละหน้าก่อน Guard บล็อกการแทรกคำสั่งดั้งเดิมได้ 94.5% และทำให้จำนวนครั้งเฉลี่ยที่ผู้โจมตีต้องพยายามเพิ่มขึ้นเกือบเท่าตัว จาก 9.7 เป็น 17.0 ครั้ง อย่างไรก็ตาม เมื่อให้พยายามได้ครบทั้ง 64 ครั้ง ผู้โจมตียังคงสำเร็จใน 84.2% ของงาน (93.6% เมื่อไม่มี Guard) และเกือบทุกครั้งเป็นการแทรกคำสั่งที่ Guard ไม่ได้ทำเครื่องหมาย ผลลัพธ์นี้สอดคล้องกับมุมมองที่เราได้นำเสนอไว้เมื่อเปิดตัว BrowseSafe ว่าไม่มีโมเดลตรวจจับใดเป็นยาวิเศษ ตัวตรวจจับจึงต้องเป็นส่วนหนึ่งของการป้องกันแบบหลายชั้น

ขยาย

บทสรุป

เอเจนต์เบราว์เซอร์มักมีความเสี่ยงต่อการแทรกพรอมต์ทางอ้อม ซึ่งเป็นการโจมตีที่ซ่อนอยู่ในหน้าเว็บทั่วไปเพื่อขัดขวางความสามารถของเอเจนต์ในการทำงานของผู้ใช้ อันตรายนี้มีแต่จะเพิ่มขึ้นเมื่อเวลาผ่านไป ทั้งจากการที่เอเจนต์เข้าถึงข้อมูลและเครื่องมือได้มากขึ้น ซึ่งเพิ่มความเสียหายที่อาจเกิดจากการโจมตี และจากการที่ผู้โจมตีสามารถปรับแก้การแทรกคำสั่งให้มีประสิทธิภาพมากขึ้น

ชุดเครื่องมือ BrowseSafe ของเรารับมือกับภัยคุกคามเหล่านี้ เบนช์มาร์ก BrowseSafe++ ประกอบด้วยคู่หน้าเว็บ 38,675 คู่ที่สร้างขึ้นจากการแทรกคำสั่งจริงเป็นหลัก ช่วยให้การฝึกและการประเมินตัวตรวจจับน่าเชื่อถือยิ่งขึ้น ตัวตรวจจับ BrowseSafe-Guard ซึ่งได้รับการฝึกด้วยคู่หน้าเว็บเหล่านี้ ช่วยให้ตรวจจับได้อย่างแม่นยำสูง รวดเร็ว และประหยัด ทำให้สามารถสแกนหน้าเว็บก่อนที่เอเจนต์จะดำเนินการกับหน้านั้นได้ ส่วนเฟรมเวิร์ก BrowseSafe-Adapt ช่วยให้ทดสอบโมเดลกับการแทรกคำสั่งที่ถูกปรับแก้ได้ โดยชี้ให้เห็นช่องโหว่ที่อาจไม่ปรากฏจากการพยายามเพียงครั้งเดียวด้วยการแทรกคำสั่งแบบตายตัว

เราหวังว่าเครื่องมือเหล่านี้เมื่อใช้ร่วมกันจะช่วยให้นักวิจัยและวิศวกรค้นหาจุดล้มเหลวและปรับปรุงการป้องกันการโจมตีด้วยการแทรกพรอมต์บนเว็บได้ง่ายขึ้น นอกจากนี้ เรายังประเมินและปรับปรุงการป้องกันในตัวของ Comet และ Computer อย่างต่อเนื่องเพื่อให้ผู้ใช้ของเราปลอดภัย

เริ่มต้นใช้งาน

1. ติดตั้ง SDK และรับสิทธิ์เข้าถึงข้อมูล SDK ติดตั้งได้จาก GitHub:

ชุดข้อมูลนี้จำกัดการเข้าถึง ให้ส่งคำขอสิทธิ์เข้าถึงหนึ่งครั้งที่หน้า Hugging Face ของชุดข้อมูล จากนั้นเข้าสู่ระบบด้วย hf auth login

2. ส่งผลลัพธ์ไปยังลีดเดอร์บอร์ด ประเมินตัวตรวจจับของคุณเองบนชุดทดสอบของ BrowseSafe++:

คำสั่งนี้จะบันทึกการตัดสินใจหนึ่งรายการต่อหน้าสำหรับแต่ละมุมมองที่คุณระบุ ให้ระบุมุมมองข้อความทั้งสามแบบเพื่อรับค่าเฉลี่ยบนลีดเดอร์บอร์ดข้อความ ลงชื่อเข้าใช้ Space ของลีดเดอร์บอร์ดด้วยบัญชี Hugging Face ของคุณ แล้วอัปโหลด predictions.jsonl จากนั้น Space จะแสดงค่า F1 ความถูกต้อง อัตราผลบวกลวง และเมตริกอื่นๆ สำหรับแต่ละมุมมอง และหากคุณเลือก ก็จะเผยแพร่ผลลัพธ์บน ลีดเดอร์บอร์ด แต่ละบัญชี (ที่มีอายุอย่างน้อย 60 วัน) จะส่งผลงานที่ได้รับการให้คะแนนได้หนึ่งครั้งต่อสัปดาห์ตามเวลา UTC หน้าทดสอบมีไว้สำหรับการประเมินผลเท่านั้น ห้ามนำไปใช้ฝึกโมเดลหรือเผยแพร่ซ้ำ คู่มือการส่งผลงานอธิบายรูปแบบไฟล์และกฎการเผยแพร่

การอ้างอิง

@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}
}