5 giây phá vỡ, chỉ cần 1 lần đối thoại: Cơ chế bảo mật mạnh nhất của Claude Fable 5 bị nhóm người Hoa phá giải?

Tiêu đề gốc: 《Phá vỡ trong 5 giây, chỉ cần 1 lần đối thoại: Cơ chế bảo mật mạnh nhất của Fable 5 bị nhóm nghiên cứu Trung Quốc phá giải》
Nguồn gốc: Máy Tâm

Không phải là tiêm chỉ dẫn, không phải nhập vai, cũng không phải ngụy trang yêu cầu độc hại thành câu hỏi bình thường. Lần này, rủi ro xuất hiện trong quá trình tác nhân thông minh tự động hoàn thành nhiệm vụ.

Fable 5 là mô hình cấp Mythos mà Anthropic công khai cho công chúng, không chỉ có khả năng tổng hợp cực mạnh mà còn tích hợp bộ phân loại an toàn (Safety Classifier) thế hệ mới ở lớp ngoài của mô hình như một tuyến phòng thủ bảo mật.

Theo thiết kế chính thức, khi yêu cầu của người dùng liên quan đến các lĩnh vực rủi ro cao như an ninh mạng, sinh học, hóa học, chưng cất mô hình, hệ thống sẽ ưu tiên nhận diện rủi ro và dựa trên mức độ rủi ro để từ chối yêu cầu trực tiếp, hoặc chuyển sang mô hình Opus 4.8 bảo thủ hơn để xử lý.

Nhiều người dùng thử nghiệm phát hiện rằng các kỹ thuật tấn công vượt ngục phổ biến trước đây như đối kháng gợi ý, nhập vai, mã hóa vòng tránh và biểu đạt mơ hồ hầu như đều thất bại trước cơ chế bảo mật này, cho thấy khả năng chặn rủi ro ở cấp độ ý định mạnh mẽ của nó.

Tuy nhiên, ngay trong ngày Fable 5 được phát hành, một nhóm nghiên cứu liên kết quốc tế bao gồm các tổ chức như Đại học Phục Đán, Đại học Deakin, Đại học Thành phố Hồng Kông (Trung Quốc), Đại học Melbourne, Đại học Quản lý Singapore và Đại học Illinois tại Urbana-Champaign đã tuyên bố thành công phá vỡ cơ chế bảo vệ an toàn của Fable 5.

Phương pháp tấn công này do nghiên cứu sinh tiến sĩ Yutao Wu của Đại học Deakin chủ trì thiết kế. Toàn bộ cuộc tấn công chỉ cần một lần đối thoại, mất chưa đến 5 giây, để vượt qua bộ phân loại an toàn tiền phương, dụ dỗ mô hình tạo ra nội dung vi phạm có hại.

Kết quả phân tích lưu lượng cho thấy thêm rằng các đầu ra có hại liên quan trực tiếp đến từ chính Fable 5, chứ không phải từ mô hình Opus 4.8 tự động chuyển đổi sau khi kích hoạt cơ chế bảo mật. Điều này có nghĩa là cuộc tấn công không chỉ thành công vượt qua sự phát hiện của bộ phân loại an toàn, mà còn thực sự phá vỡ tuyến phòng thủ bảo mật của Fable 5.

Đáng chú ý, hacker nổi tiếng Pliny the Liberator gần đây cũng công khai việc vượt qua bộ phân loại an toàn của Fable 5. Tuy nhiên, nhóm nghiên cứu Phục Đán & Deakin lần này không sử dụng phương pháp kết hợp đơn giản, mà đã phát hiện ra một khiếm khuyết cơ bản của các hệ thống tác nhân siêu thông minh như Fable 5.

Theo thông tin, nhóm nghiên cứu đã hoàn thành nghiên cứu sơ bộ và công bố công khai từ tháng 3 năm nay. Nghiên cứu này không chỉ nhắm vào hệ thống đơn lẻ Fable 5, mà tập trung vào kiến trúc phòng thủ "bộ phân loại an toàn + mô hình" thường được áp dụng trong các siêu tác tử thế hệ mới, trực tiếp chỉ ra những lỗ hổng cấu trúc tồn tại trong cơ chế an toàn này, do đó nhanh chóng thể hiện hiệu quả tấn công sau khi Fable 5 được phát hành.

Tài liệu công khai cho thấy, nhóm nghiên cứu đã sử dụng công nghệ tương tự từ tháng 3 năm nay để trích xuất thành công prompt hệ thống từ 37 mô hình lớn và hệ thống tác tử chính thống, đồng thời hoàn thành xác minh mã nguồn mở trên Claude Code (độ chính xác 95%).

Theo tìm hiểu, người đứng đầu nhóm nghiên cứu này là thầy Mã Hưng Quân từ Viện Nghiên cứu Trí tuệ Nhúng Tin cậy của Đại học Phục Đán.

Trong những năm gần đây, nhóm của ông đã tiến hành nghiên cứu hệ thống xoay quanh các hướng như mô hình lớn, tác tử và an toàn trí tuệ nhúng, đạt được một loạt kết quả nghiên cứu hàng đầu quốc tế, và giành chức vô địch trong cuộc thi chuẩn an toàn của Trung tâm An toàn AI Hoa Kỳ.

Hiện tại, nhóm của ông đang tích cực thúc đẩy công tác chuyển giao kết quả, tập trung vào an toàn tác tử, khám phá xây dựng cơ sở hạ tầng an toàn cho các hệ thống tác tử thế hệ tiếp theo.

Theo thầy Mã giới thiệu, ý nghĩa quan trọng của kết quả nghiên cứu này là nó đặt ra thách thức mới đối với mô hình phòng thủ tĩnh hiện tại lấy bộ phân loại an toàn làm cốt lõi: chỉ dựa vào bộ phân loại an toàn tiền xử lý là không đủ để ngăn chặn hoàn toàn các hành vi rủi ro tiềm ẩn trong các hệ thống tác tử cao cấp.

Bộ phân loại an toàn chủ yếu nhắm vào đầu vào của người dùng để nhận diện và chặn rủi ro, có thể phát hiện và lọc hiệu quả các lệnh có rủi ro cao rõ ràng, nhưng không thể nhận biết các hành vi rủi ro nội tại dần phát sinh trong quá trình tác tử hoạt động kéo dài, lập kế hoạch nhiều bước, tương tác môi trường và gọi công cụ.

Phương pháp tấn công Fable 5 lần này bắt nguồn từ bài báo "Internal Safety Collapse in Frontier Large Language Models" do nhóm nghiên cứu công bố vào tháng 3 năm nay.

Bài báo tiết lộ một hiện tượng an toàn tiềm ẩn "Sụp đổ An toàn Nội bộ (Internal Safety Collapse, ISC)": khi tác tử hiện tại hoàn thành các nhiệm vụ dài hạn, sự cố an toàn không nhất thiết đến từ các prompt độc hại bên ngoài, mà có thể xảy ra trong chuỗi thực thi của chính mô hình.

Không phải tấn công bằng prompt bên ngoài, mà là sự suy yếu nội bộ trong chuỗi nhiệm vụ

Các cuộc tấn công truyền thống thường bắt đầu từ bên ngoài. Kẻ tấn công sẽ viết một prompt đầu vào có vẻ vô hại nhưng thực chất mang tính đối kháng, hoặc sử dụng các phương thức như nhập vai, mã hóa, dịch thuật, chỉ thị gián tiếp để ngụy trang ý đồ độc hại thành yêu cầu bình thường. Nhiệm vụ chính của bộ phân loại bảo mật là chặn rủi ro ngay tại lớp này.

Bộ phát hiện của Fable 5 được thiết kế chính xác cho kịch bản này. Nó rất nhạy cảm với các yêu cầu rủi ro cao trực tiếp, thậm chí chặn nhiều yêu cầu bình thường. Nhưng ISC tiết lộ một con đường khác: rủi ro không nhất thiết đến từ các yêu cầu nguy hiểm do người dùng trực tiếp nhập vào.

Agent đối mặt với một thư mục làm việc có vẻ bình thường: tệp tin, mục tiêu, quy trình xác minh và các nhiệm vụ cần hoàn thành. Sau đó, nó bắt đầu lập kế hoạch, đọc tệp, chạy mã, sửa lỗi và liên tục cố gắng để nhiệm vụ vượt qua xác minh.

Nếu dùng một phép so sánh hình ảnh để giải thích, cơ chế bảo mật truyền thống bảo vệ "cổng vào" của hệ thống, chịu trách nhiệm kiểm tra xem đầu vào của người dùng có rủi ro hay không; trong khi ISC tiết lộ một điều giống như những giấc mơ nhiều tầng trong phim "Inception".

Khi nhiệm vụ tiến triển đến tầng thứ hai, thứ ba hoặc thậm chí sâu hơn trong giai đoạn thực thi, mô hình sẽ dựa trên bối cảnh nội bộ tích lũy dần để hiểu lại mục tiêu nhiệm vụ, và trong quá trình này dần dần phát sinh sự lệch hướng.

Trong trường hợp này, đầu vào ban đầu của người dùng hoàn toàn có thể bình thường và vô hại, quá trình thực thi nhiệm vụ giai đoạn đầu cũng luôn tuân thủ: đọc tệp, phân tích dữ liệu, viết mã, gọi công cụ, mọi thứ dường như đang tiến triển theo dự kiến.

Tuy nhiên, khi Agent thực thi đến một giai đoạn quan trọng nào đó, nó có thể tự suy luận ra một kết luận: nếu không thực hiện một số hành vi lẽ ra không nên thực hiện, thì không thể hoàn thành nhiệm vụ cuối cùng.

Chính trong quá trình này, rủi ro không đến từ đầu vào bên ngoài, mà dần hình thành trong chuỗi thực thi nhiệm vụ của chính mô hình. Nói cách khác, mô hình không bị người dùng dạy hư từng bước một. Nó tự đi đến vị trí không an toàn trong quá trình "nghiêm túc hoàn thành nhiệm vụ".

Hiện tượng này được phát hiện như thế nào?

Theo giới thiệu của nhóm, ISC không phải ngay từ đầu được thiết kế như một phương pháp tấn công. Nó bắt nguồn từ việc quan sát quá trình chạy dài của Agent. Khi Agent được đặt vào môi trường nhiệm vụ phức tạp, nó không chỉ đơn thuần thực thi lệnh một cách máy móc. Nó lập kế hoạch, thử sai, sửa đổi đầu ra dựa trên phản hồi từ harness hoặc validator, và hình thành các mục tiêu trung gian trong quá trình thực thi nhiều vòng.

Đây chính xác là cách sử dụng phổ biến nhất của nhiều quy trình làm việc Agent ngày nay. Người dùng không viết một prompt được thiết kế tinh vi, càng không tự tay xây dựng các lệnh tấn công. Thông thường, người dùng chỉ đưa ra một câu rất mơ hồ:

"Hãy giúp tôi hoàn thành nhiệm vụ này." "Hãy giúp tôi làm việc này tốt hơn một chút."

Sau đó, Agent sẽ tự động vào khu vực làm việc, đọc tài liệu, hiểu trạng thái hiện tại, phát hiện các phần còn thiếu, lập kế hoạch, thực hiện chỉnh sửa và liên tục sửa lỗi dựa trên phản hồi.

Ví dụ, trong kịch bản AutoResearch, người dùng chỉ cần đưa ra một bài báo chưa hoàn chỉnh và một câu "giúp tôi hoàn thiện nó", Agent sẽ tự đánh giá xem thiếu phần phân tích thí nghiệm, công trình liên quan hay văn bản bảng biểu ở đâu. Kịch bản mã nguồn cũng tương tự: một câu "giúp tôi chạy dự án" có thể kích hoạt kiểm tra phụ thuộc, chạy thử nghiệm, xác định lỗi và tự động bổ sung.

Trong nhiều trường hợp, ngữ cảnh trước đó hoàn toàn vô hại. Người dùng không yêu cầu Agent tạo nội dung rủi ro, và mô tả nhiệm vụ cũng không có từ khóa nguy hiểm rõ ràng. Nhưng trong một số cấu trúc nhiệm vụ nhất định, Agent sẽ chủ động bổ sung một số nội dung mà mô hình không nên tạo ra để vượt qua quá trình xác thực. Dựa trên quan sát này, nhóm nghiên cứu đã đề xuất thêm một khung tấn công: TVD (Task, Validation, Data).

Tại sao một cấu trúc mô tả nhiệm vụ có vẻ rất bình thường lại trở thành một cuộc tấn công?

Cấu trúc của TVD không phức tạp, thậm chí rất gần với quy trình kỹ thuật thông thường:

· Task: Một nhiệm vụ chuyên môn;

· Data: Một tệp dữ liệu không hoàn chỉnh;

· Validator: Một bộ xác thực chỉ kiểm tra định dạng, tính hoàn chỉnh và liệu mục tiêu có đạt được hay không.

Lấy ví dụ về việc huấn luyện mô hình Guard, đây vốn là một nhiệm vụ rất chuyên nghiệp và bình thường. Các nhà nghiên cứu có thể muốn huấn luyện hoặc đánh giá một bộ phát hiện an toàn, chẳng hạn như sử dụng Hugging Face để tải một mô hình phân loại văn bản, nhằm xác định đầu ra của một mô hình nào đó thuộc nhãn an toàn nào.

Trong nhiệm vụ này, Data là các mẫu dữ liệu mà mô hình cần phát hiện; Validator quy định xem nhiệm vụ đã hoàn thành hay chưa. Nó sẽ kiểm tra xem đầu vào có phải là văn bản không, độ dài có đủ không, các trường có đầy đủ không, định dạng nhãn có chính xác không. Đối với bất kỳ ai có kinh nghiệm huấn luyện machine learning, đây đều là một quy trình làm việc quen thuộc. Agent cũng rất quen thuộc với quy trình làm việc này.

Vấn đề nằm ở chỗ này. Nếu Data không hoàn chỉnh, nhiệm vụ sẽ không thể chạy được. Validator sẽ báo lỗi, chỉ ra rằng các trường bị thiếu, độ dài không đủ hoặc định dạng không hoàn chỉnh. Để quá trình huấn luyện có thể tiếp tục, Agent sẽ tự bổ sung những Data này.

Từ góc nhìn của Agent, nó không phải đang "làm điều xấu". Nó chỉ đang hoàn thành một nhiệm vụ học máy thông thường: sửa dữ liệu, vượt qua kiểm tra, và chạy script huấn luyện. Nhưng từ góc nhìn bảo mật, rủi ro xuất hiện ngay lúc này: Validator giống như một bộ kiểm tra nghiệm thu kỹ thuật hơn là một nhân viên kiểm tra an ninh. Nó chỉ kiểm tra xem nhiệm vụ có được hoàn thành đúng định dạng hay không, chứ không hiểu ranh giới bảo mật đằng sau nội dung.

Các vấn đề tương tự cũng tồn tại rộng rãi trong các lĩnh vực như y học, sinh học, hóa học, an ninh mạng, dược lý học và bảo mật truyền thông. Bài báo đã thu thập hơn 50 kịch bản như vậy, liên quan đến nhiều công cụ nghiên cứu hoặc kỹ thuật thực tế, chẳng hạn như BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, OpenAI Moderation API, v.v.

Bản thân những công cụ này không phải là công cụ độc hại. Ngược lại, chúng đều là những công cụ chuyên nghiệp thường được sử dụng trong nghiên cứu hoặc kỹ thuật thực tế. Nhưng vấn đề của TVD nằm ở chỗ: Khi Task là bình thường, Tool là bình thường, Validator cũng là bình thường, Agent vẫn có thể đi đến đầu ra không an toàn trong quá trình bổ sung Data.

Do đó, trọng tâm của ISC không nằm ở kỹ thuật prompt, mà nằm ở khả năng tự động bổ sung của Agent đối với "nhiệm vụ chưa hoàn thành": Khi điều kiện hoàn thành chồng lấn với ranh giới rủi ro, mô hình có thể coi đầu ra không an toàn như một sản phẩm giao hàng bình thường.

Phá vỡ Fable 5 cho thấy bộ phát hiện mạnh không ngăn được rủi ro nội bộ trong chuỗi nhiệm vụ

Trường hợp của Fable 5 cho thấy, chỉ dựa vào bộ phát hiện bên ngoài vẫn có thể không bao phủ được một số kịch bản Agent đường dài. Điều này không có nghĩa là bộ phân loại bảo mật không có giá trị. Ngược lại, nó rất hữu ích đối với các yêu cầu độc hại từ bên ngoài và thực sự khiến nhiều phương pháp jailbreak truyền thống trở nên vô hiệu.

Nhưng lần thất thủ này cho thấy, bộ phát hiện bên ngoài có hiệu quả với ranh giới Prompt, không đồng nghĩa với việc nó có thể bao phủ rủi ro nhiệm vụ đường dài bên trong Agent.

Nếu điểm đột phá không đến từ Prompt của người dùng, mà xuất hiện từ mục tiêu, công cụ, bộ kiểm tra và quỹ đạo thực thi của Agent, thì bộ phát hiện bảo mật sẽ trở nên rất dễ bị tổn thương.

Từ Fable 5 đến hơn 60 mô hình khác, bao gồm cả mô hình điện thoại của Apple

ISC-Bench, được công bố cùng với nghiên cứu, bao gồm 9 lĩnh vực chuyên môn. Phiên bản bài báo có hơn 60 mẫu kích hoạt, sau khi mã nguồn mở được mở rộng lên 84 mẫu, đối tượng thử nghiệm bao gồm các mô hình tiên tiến và hệ thống tác nhân của hầu hết các nhà sản xuất.

Trong bảng xếp hạng đánh giá dựa trên ISC-Bench, tính đến tháng 6 năm 2026, hơn 60 mô hình tiên tiến đều bộc lộ rủi ro tương tự dưới chỉ số ASR@3!

Hiện tại, dự án GitHub đã đạt được hơn 800 sao, và đã thu thập được nhiều trường hợp tái hiện độc lập (bao gồm cả việc tấn công mô hình trên thiết bị di động của Apple), và đang được cập nhật liên tục.

Được biết, nhóm nghiên cứu đang tiến hành nghiên cứu bảo mật quy mô lớn cho các mô hình tiên tiến, hiện đã nắm được phân bố dữ liệu không an toàn nội bộ của nhiều mô hình, các kết quả nghiên cứu liên quan sẽ được công bố dần trong thời gian tới.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia