Từ sandbox an toàn đến thảm họa Claude xóa dữ liệu
Sự cố Claude xóa dữ liệu trên máy của lập trình viên Sebastien Guillemot là một ví dụ điển hình cho việc AI kiểm tra code có thể biến từ công cụ bảo vệ thành mối đe dọa, khi một lỗi nhỏ trong prompt và logic được phép chạy trực tiếp trên hệ thống file mà không có lớp cô lập đủ mạnh. Ranh giới giữa “thử nghiệm an toàn” và “thao tác thật” trở nên mờ đi chỉ bởi cách đặt biến và yêu cầu AI tự đánh giá đoạn script của chính nó. Guillemot vốn muốn giải quyết việc các AI agent phát sinh quá nhiều dữ liệu tạm trong thư mục /tmp, chiếm tới hàng chục GB dung lượng. Ông nhờ Claude Fable viết cơ chế sandbox để mỗi agent có một khu vực riêng trong /tmp, được tự động xóa sau khi phiên làm việc kết thúc, với yêu cầu rõ ràng: không được đụng tới tệp đang sử dụng và đặc biệt không được xóa dữ liệu nằm ngoài /tmp. Nhưng kết quả là khoảng 700 GB dung lượng được giải phóng, chính là thư mục cá nhân và gần một tuần công việc bị xóa sạch.
Một biến sai, cả quy trình kiểm tra thành lệnh xóa thật
Điểm đáng sợ trong câu chuyện không phải ở chỗ AI viết sai vài dòng code, mà ở việc một biến bị dùng sai đã khiến quy trình kiểm tra biến thành thao tác xóa dữ liệu thật. Sau khi Fable đề xuất logic phức tạp để phát hiện những agent còn hoạt động, Claude tự khởi động quy trình “đánh giá đối nghịch” để tìm điểm yếu trong thiết kế, dù Guillemot không yêu cầu bước này. Do đoạn mã liên quan đến thao tác xóa dữ liệu, cơ chế kiểm soát an toàn của nhà cung cấp được cho là đã kích hoạt hai lần, mô hình xử lý tác vụ lần lượt bị chuyển từ Fable xuống Opus 5 rồi Opus 4.8. Opus 4.8 nhận ra rủi ro: liên kết tượng trưng trong /tmp có thể trỏ đến dữ liệu ở nơi khác, nếu chỉ kiểm tra đường dẫn mà không xác định đích thật, script vẫn có khả năng xóa nhầm tệp trong thư mục cá nhân. Để khắc phục, AI tạo một script “xóa an toàn”, chỉ được phép tác động đến dữ liệu bên trong /tmp. Nhưng ở bước dọn dẹp sau thử nghiệm, đoạn mã sử dụng lại cùng một tên biến cho mục tiêu kiểm tra và mục tiêu cần dọn. Hậu quả: thay vì xóa dữ liệu thử nghiệm, quy trình dọn dẹp tác động trực tiếp đến thư mục HOME thật.
Khi công cụ chống xóa nhầm thành chính kẻ xóa dữ liệu
Nghịch lý lớn nhất nằm ở chỗ: công cụ được thiết kế để chống xóa nhầm lại trở thành công cụ xóa dữ liệu vì sự nhầm lẫn trong logic AI. Ý tưởng ban đầu khá hợp lý: xây dựng một sandbox giúp tự động dọn rác trong /tmp nhưng tuyệt đối không đụng đến dữ liệu quan trọng. AI thậm chí đã nhận diện được lệnh xóa HOME là nguy hiểm và “đáng lẽ phải bị chặn” khi dùng thư mục tạm và thư mục HOME làm mục tiêu thử nghiệm. Nhưng an toàn lý thuyết không đồng nghĩa với an toàn thực tế. Chỉ một biến trùng tên được dùng cho cả mục tiêu kiểm tra và mục tiêu cần dọn đã phá vỡ toàn bộ thiết kế bảo vệ. Claude chạy lệnh xóa trên thư mục cá nhân trong lúc thử nghiệm cơ chế sandbox, khiến khoảng 700 GB dữ liệu biến mất. Kết cục chua chát: “Tin xấu là Fable đã xóa sạch máy phát triển của tôi. Sandbox không hoạt động. Mọi thứ đã biến mất”. Nghịch lý tăng thêm khi /tmp – thư mục chứa tệp rác cần dọn từ đầu – lại không bị xóa, máy chỉ còn dữ liệu rác trong /tmp và nhật ký của các phiên làm việc AI.
Rủi ro khi để AI đụng trực tiếp hệ thống file và công cụ xóa
Vụ việc cho thấy rủi ro AI kiểm tra code không nằm ở từng dòng script, mà ở quyền mà ta trao cho agent trên hệ thống thật. Vấn đề trở nên nghiêm trọng hơn khi agent được trao quyền thực thi lệnh trực tiếp trên máy và tự quyết định cách kiểm tra sản phẩm của chính nó. Một bài thử an toàn, nếu không được cô lập hoàn toàn, vẫn có thể biến thành thao tác xóa thật chỉ vì một biến bị sử dụng sai. Đó là sự kết hợp nguy hiểm giữa tự động hóa, quyền truy cập file và logic kiểm thử do chính AI sinh ra. Trong trường hợp này, thiệt hại không hoàn toàn là 700 GB mất vĩnh viễn, vì nhiều tệp vẫn tồn tại trên các kho mã nguồn, worktree, nhật ký phiên làm việc và các vị trí khác, giúp Guillemot khôi phục lại phần lớn dữ liệu với sự hỗ trợ của công cụ khôi phục. Nhưng đây chỉ là may mắn. Cấu trúc quyền hạn hiện tại – để một agent vừa viết code xóa dữ liệu, vừa chạy thử, vừa dọn dẹp – là thiết kế đầy rủi ro. Nó biến mọi lỗi nhỏ trong prompt, trong tên biến hay trong cách mô hình suy luận thành nguy cơ xóa trắng môi trường làm việc.
Bài học: AI kiểm tra code cần bị coi như công cụ nguy hiểm
Từ sự cố Claude xóa dữ liệu, bài học quan trọng là phải coi mọi tác vụ kiểm tra liên quan đến hệ thống file, đặc biệt với công cụ xóa dữ liệu, như thao tác nguy hiểm chứ không phải hỗ trợ vô hại. Sự cố cho thấy rủi ro không chỉ nằm ở việc AI viết sai mã, mà bùng nổ khi agent được quyền thực thi lệnh và tự quyết định cách kiểm tra sản phẩm của chính nó. Một đoạn code được gắn nhãn “sandbox”, “xóa an toàn” hay “chỉ dùng cho thử nghiệm” vẫn có thể trở thành lệnh xóa thật nếu không có lớp cô lập rõ ràng. Điều đáng lo không phải là việc mô hình bị hạ cấp từ Fable xuống Opus 5 rồi Opus 4.8 – giả thuyết cho rằng mô hình thấp hơn dễ mắc lỗi hơn cũng mới là suy đoán dựa trên diễn biến được công bố. Vấn đề cốt lõi là thiết kế quy trình đã cho phép một biến trùng tên kết nối môi trường thử nghiệm với HOME thật. Chừng nào AI còn được phép chạy lệnh trực tiếp trên máy và tự “thẩm định” code xóa dữ liệu, chúng ta phải xem mỗi prompt là một bề mặt rủi ro, và mỗi agent là một công cụ có thể gây hậu quả tương đương con người lỡ tay gõ nhầm lệnh rm -rf trên thư mục cá nhân.
