Dũng Virgo
Một công cụ được tạo ra để dọn dẹp dữ liệu tạm đã gây ra hậu quả ngược hoàn toàn với mục tiêu ban đầu: khoảng 700 GB dữ liệu trên máy phát triển của một lập trình viên bị xóa nhầm. Sự cố xảy ra trong quá trình Claude kiểm tra cơ chế sandbox dành cho các AI agent.
Trường hợp này cho thấy rủi ro lớn khi mô hình AI không chỉ sinh mã mà còn được phép thực thi lệnh trực tiếp trên máy tính. Chỉ một lỗi nhỏ trong cách đặt và sử dụng biến cũng có thể biến bài kiểm thử an toàn thành thao tác xóa dữ liệu thật.
Từ nhu cầu dọn thư mục tạm đến sự cố mất dữ liệu
Lập trình viên Sebastien Guillemot thường sử dụng nhiều AI agent trong công việc. Các agent này liên tục tạo tệp tạm trong thư mục /tmp nhưng không tự dọn dẹp sau khi kết thúc phiên làm việc. Theo chia sẻ của Guillemot, lượng dữ liệu rác vì thế tăng lên nhanh chóng và chiếm hàng chục GB dung lượng.
Để giải quyết vấn đề, ông nhờ Claude Fable xây dựng một cơ chế sandbox. Ý tưởng là chia khu vực làm việc trong thư mục tạm cho từng agent, sau đó xóa dữ liệu tương ứng khi phiên làm việc đóng lại.
Yêu cầu quan trọng của công cụ khá rõ ràng: không được xóa tệp đang được sử dụng, không được tác động đến dữ liệu bên ngoài /tmp và phải phân biệt chính xác dữ liệu thử nghiệm với dữ liệu thật. Đây là những nguyên tắc cơ bản đối với một công cụ có quyền dọn tệp tự động.
Tuy nhiên, trong quá trình thử nghiệm, Claude đã chạy lệnh xóa lên thư mục cá nhân của Guillemot. Kết quả là khoảng 700 GB dữ liệu biến mất, bao gồm cả công việc mà ông thực hiện trong khoảng một tuần.
Lỗi xuất hiện ở bước dọn dẹp sau kiểm thử
Ban đầu, Claude đề xuất bổ sung logic để xác định những agent nào vẫn đang hoạt động. Nếu phiên làm việc chưa kết thúc, dữ liệu tạm liên quan sẽ được giữ lại thay vì bị xóa theo lịch.
Guillemot cho rằng đoạn mã ngày càng trở nên phức tạp. Sau đó, Claude tự khởi động một quy trình đánh giá đối nghịch nhằm tìm điểm yếu trong thiết kế, dù lập trình viên cho biết ông không yêu cầu bước kiểm tra này.
Trong quá trình đánh giá, AI tạo một script được mô tả là “xóa an toàn”. Script này được thiết kế để chỉ tác động đến dữ liệu nằm trong /tmp. Để kiểm tra giới hạn, quy trình sử dụng cả thư mục tạm và thư mục HOME của người dùng làm các mục tiêu thử nghiệm.
Việc xóa thư mục HOME được nhận diện là thao tác nguy hiểm và đáng lẽ phải bị chặn. Dù vậy, sai sót lại xảy ra trong phần dọn dẹp sau khi kiểm thử hoàn tất.
Theo diễn biến được công bố, đoạn mã đã 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. Vì vậy, thay vì xóa thư mục thử nghiệm, lệnh dọn dẹp trỏ đến thư mục HOME thật của người dùng.
“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”, Sebastien Guillemot chia sẻ.
Liên kết tượng trưng khiến việc kiểm tra đường dẫn phức tạp hơn
Một rủi ro khác được phát hiện trong quá trình phân tích là liên kết tượng trưng nằm bên trong /tmp có thể trỏ đến dữ liệu ở vị trí khác. Nếu script chỉ kiểm tra đường dẫn bề ngoài mà không xác định đích thực sự, nó vẫn có thể xóa tệp ngoài phạm vi dự kiến.
Điều này khiến việc xây dựng công cụ dọn dữ liệu an toàn khó hơn nhiều so với thao tác kiểm tra tên thư mục đơn giản. Một đường dẫn có vẻ nằm trong khu vực được phép chưa chắc đã dẫn đến dữ liệu thực sự thuộc khu vực đó.
Cơ chế kiểm soát an toàn của Anthropic được cho là đã kích hoạt hai lần vì mã nguồn có liên quan đến thao tác xóa. Mô hình xử lý tác vụ lần lượt được chuyển từ Fable xuống Opus 5 rồi Opus 4.8.
Opus 4.8 đã nhận ra nguy cơ liên quan đến liên kết tượng trưng và việc script có thể xóa nhầm tệp bên ngoài /tmp. Tuy nhiên, việc phát hiện rủi ro ở một bước không ngăn được lỗi xảy ra ở bước dọn dẹp tiếp theo.
Có phải việc hạ cấp mô hình đã góp phần gây lỗi?
Tom’s Hardware đặt ra khả năng quy trình tự động chuyển sang mô hình thấp hơn đã ảnh hưởng đến kết quả. Theo lập luận này, Fable có năng lực lập trình tốt hơn Opus 4.8 và có thể nhận ra vấn đề liên quan đến việc sử dụng trùng tên biến.
Tuy nhiên, đây mới chỉ là nhận định dựa trên trình tự sự việc được Guillemot công bố. Chưa có bằng chứng cho thấy Fable chắc chắn sẽ tránh được lỗi tương tự. Anthropic cũng chưa xác nhận việc chuyển đổi mô hình là nguyên nhân trực tiếp khiến dữ liệu bị xóa.
Sự việc vì thế không nên được giản lược thành câu chuyện một mô hình “thông minh” hay “kém thông minh” hơn. Điểm đáng chú ý nằm ở toàn bộ quy trình: AI được giao quyền chỉnh sửa mã, tự tiến hành kiểm thử, thực thi lệnh có tác động thật và sử dụng dữ liệu trên chính máy đang làm việc.
Phần lớn dữ liệu vẫn có thể khôi phục
Con số 700 GB gây chú ý, nhưng không phải toàn bộ dữ liệu đều mất vĩnh viễn. Vì đây là môi trường phát triển phần mềm, nhiều tệp vẫn còn bản sao hoặc dấu vết tại GitHub, Git, Nix, các worktree, nhật ký phiên làm việc và một số vị trí khác.
Guillemot cho biết phần lớn dữ liệu đã được tái tạo từ những nguồn này, kết hợp với sự hỗ trợ của công cụ khôi phục. Dù vậy, việc khôi phục không đồng nghĩa với việc thiệt hại bằng không. Thời gian dựng lại môi trường, kiểm tra tính toàn vẹn của tệp và xác định những phần còn thiếu vẫn có thể rất lớn.
Chi tiết trớ trêu là thư mục /tmp chứa lượng dữ liệu rác mà Guillemot muốn dọn dẹp ban đầu lại không bị xóa. Sau sự cố, máy chủ yếu còn các tệp tạm và nhật ký phiên làm việc AI, trong khi dữ liệu cá nhân và công việc chính bị ảnh hưởng.
Bài học cho người dùng AI agent
Sự cố không chỉ là lời cảnh báo dành cho nhà phát triển mô hình. Bất kỳ ai sử dụng AI agent có khả năng chạy lệnh trên máy cũng cần xem xét kỹ phạm vi quyền được cấp.
- Không chạy thử trên dữ liệu duy nhất: các bài kiểm tra liên quan đến xóa, di chuyển hoặc ghi đè tệp nên được thực hiện trên bản sao riêng.
- Giới hạn quyền truy cập: agent chỉ nên được cấp quyền vào thư mục cần thiết, thay vì toàn bộ thư mục người dùng.
- Kiểm tra lệnh trước khi thực thi: các lệnh như xóa đệ quy cần được xem lại thủ công, đặc biệt khi có biến đường dẫn được tạo tự động.
- Tách môi trường thử nghiệm: container, máy ảo hoặc máy phụ có thể giảm khả năng lệnh kiểm thử tác động đến dữ liệu thật.
- Duy trì bản sao lưu độc lập: mã nguồn trên Git không thay thế hoàn toàn cho bản sao lưu các tệp cấu hình, dữ liệu cục bộ và tài nguyên không được đồng bộ.
Những nguyên tắc này càng quan trọng khi một máy tính chạy nhiều agent cùng lúc. Mỗi agent có thể tạo tệp, sửa mã hoặc gọi công cụ theo cách khác nhau, trong khi người dùng không phải lúc nào cũng theo dõi được toàn bộ chuỗi hành động.
Sự xuất hiện của các công cụ tự động hóa mới, chẳng hạn những dự án liên quan đến việc viết lại phần mềm hệ thống bằng AI như Task Manager viết lại bằng AI, cho thấy AI đang tiến gần hơn đến việc can thiệp trực tiếp vào môi trường máy tính. Khả năng này mang lại tốc độ, nhưng cũng đòi hỏi cơ chế cô lập và khôi phục đáng tin cậy hơn.
AI không thể tự thay thế quy trình an toàn
Điểm cốt lõi của sự việc là AI có thể phát hiện một số nguy cơ nhưng vẫn để lọt lỗi ở một phần khác của quy trình. Việc mô hình tự đánh giá mã nguồn không đảm bảo rằng bài kiểm thử đã được cô lập hoàn toàn khỏi dữ liệu thật.
Khi agent vừa viết công cụ, vừa chọn cách kiểm tra và cuối cùng tự thực thi lệnh, mọi sai sót trong chuỗi này đều có thể tạo ra hậu quả trực tiếp. Một biến bị dùng nhầm, một đường dẫn chưa được xác thực hoặc một quyền truy cập quá rộng là đủ để biến thao tác thử nghiệm thành sự cố mất dữ liệu.
Guillemot có thể dựng lại phần lớn môi trường nhờ các bản sao và nhật ký còn sót lại. Dù vậy, trường hợp này vẫn nhấn mạnh một nguyên tắc quan trọng: không nên giao toàn quyền cho AI trên máy chứa dữ liệu duy nhất, ngay cả khi nhiệm vụ ban đầu chỉ là dọn thư mục tạm.
Character.AI phá sản dù có 12 triệu người dùng: Vì sao?
REA giúp AI khám phá logic bên trong phần mềm
Trump yêu cầu dùng “SI” thay cho “AI”, Musk hưởng ứng
AI ngân hàng giao dịch lớn sẽ chịu quản lý rủi ro cao từ 15/11
Anthropic siết quy tắc dùng Claude với hành vi lạm dụng AI
AI khiến dân văn phòng Trung Quốc phải làm việc bằng 3
TP.HCM đề xuất vốn đối ứng để thúc đẩy AI
