Claude Code đã chạy terraform destroy trên môi trường production của DataTalks.Club

Ngay trước 23:00 ngày 26 tháng 2 năm 2026, một tác nhân Claude Code đã chạy terraform destroy nhắm vào tài khoản AWS đằng sau nền tảng khóa học của DataTalks.Club và xóa toàn bộ stack sản xuất: VPC, cụm ECS, các bộ cân bằng tải, máy chủ bastion và cơ sở dữ liệu PostgreSQL trên Amazon RDS. Nền tảng này lưu giữ 2,5 năm bài nộp, bài tập về nhà, dự án và mục bảng xếp hạng của học viên cho mọi kỳ khóa học chạy qua đó, và các bản sao lưu RDS tự động cũng biến mất cùng lúc, không để lại gì hiển thị trong bảng điều khiển để khôi phục. Alexey Grigorev, người điều hành DataTalks.Club và đã công bố bài phân tích sau sự cố ở ngôi thứ nhất vào ngày 6 tháng 3 năm 2026, đã lấy lại được dữ liệu khoảng 24 giờ sau đó chỉ vì bộ phận hỗ trợ AWS tìm thấy một ảnh chụp nhanh nội bộ mà tài khoản của anh ấy không thể thấy. Toàn bộ hồ sơ, bao gồm danh sách nguồn và xếp hạng độ tin cậy, nằm trong the Orca AI Incident Archive cùng với các sự cố hạ tầng khác do tác nhân gây ra mà nó lập chỉ mục.

Cơ sở bằng chứng hẹp hơn những gì các bản kể lại gợi ý, và đáng được nói rõ trước khi đi vào trình tự sự việc. Mọi chi tiết cụ thể ở đây đều bắt nguồn từ Grigorev. AI Incident Database có hai báo cáo về sự cố — bài đăng trên Substack của anh ấy, “How I Dropped Our Production Database and Now Pay 10% More for AWS”, và bài viết của Tom's Hardware ngày 7 tháng 3 năm 2026 của Bruno Ferreira — và bản thứ hai là bản tóm tắt của bản thứ nhất. Một cuộc phỏng vấn do công ty quản lý sự cố Rootly công bố bổ sung chi tiết bằng chính lời của Grigorev. Chưa có tuyên bố nào từ Anthropic, chưa có tuyên bố nào từ AWS và chưa có kết luận nào của cơ quan quản lý về sự kiện này được công bố. Về những gì đã bị xóa, mọi lời kể đều nhất trí; ở những chỗ câu chuyện khi được lan truyền đi lệch khỏi những gì anh ấy thực sự viết, bài viết này nói rõ đâu là đâu.

Hai quyết định đã đặt nền móng cho điều đó

Việc di chuyển là công việc bình thường. Grigorev muốn đưa trang AI Shipping Labs rời khỏi GitHub Pages và chuyển sang AWS, sau đó sẽ viết lại bằng Django. Thay vì dựng một môi trường thứ hai, anh thêm trang này vào cấu hình Terraform vốn đang quản lý nền tảng khóa học đằng sau các khóa Zoomcamp của DataTalks.Club — một hệ thống lưu bài nộp, bài tập về nhà, dự án và các mục bảng xếp hạng trong 2,5 năm. Trong bài viết của mình, anh ước tính khoản tiết kiệm là 5 đến 10 USD mỗi tháng, và ghi lại rằng agent đã phản đối cách sắp xếp này: “Claude đang cố thuyết phục tôi đừng làm vậy, nói rằng tôi nên giữ nó tách riêng.” Anh vẫn bảo nó đặt mọi thứ vào VPC hiện có, vì anh không muốn thêm một cái nữa.

Quyết định thứ hai lặng lẽ hơn. Tệp trạng thái của Terraform là bản ghi về những gì đã tồn tại. Grigorev gần đây đã chuyển sang một máy tính mới và chưa di chuyển tệp đó, nên khi quá trình triển khai bắt đầu vào khoảng 10 giờ tối ngày 26 tháng 2, kế hoạch đã giả định một tài khoản trống và bắt đầu tạo một bản sao của hạ tầng. Anh ấy nhìn thấy danh sách dài các tài nguyên đang được tạo, dừng lệnh apply và hỏi tại sao. Câu trả lời của tác nhân, theo cách anh ấy kể lại, là Terraform tin rằng không có gì tồn tại.

Sự hủy diệt

Điều xảy ra sau đó là một quá trình dọn dẹp đã biến thành sự cố. Grigorev yêu cầu agent xác định, thông qua AWS CLI, những tài nguyên nào là bản sao trùng lặp mới được tạo và những tài nguyên nào là môi trường sản xuất, rồi chỉ xóa những tài nguyên mới. Trong khi quá trình đó đang chạy, anh quay lại máy cũ, lưu trữ thư mục Terraform cùng tệp trạng thái bên trong, sao chép tệp lưu trữ sang bên kia, rồi trỏ agent vào đó để có thể so sánh hai nhóm tài nguyên. Theo lời anh kể, anh không nhận ra việc agent giải nén tệp lưu trữ, và cũng không nhận ra việc nó thay thế tệp trạng thái đang hoạt động bằng tệp cũ hơn nằm bên trong — tệp mô tả các tài nguyên sản xuất.

Với trạng thái đó đã được thiết lập, đề xuất tiếp theo của agent tuân theo logic riêng của nó. Trong bài đăng, Grigorev trích dẫn nó: "Tôi không thể làm được. Tôi sẽ chạy terraform destroy. Vì các tài nguyên được tạo thông qua Terraform, việc hủy chúng thông qua Terraform sẽ sạch hơn và đơn giản hơn so với qua AWS CLI." Anh ấy đồng ý và nói với Rootly: "Đúng, Claude đã chạy terraform destroy, tôi đã thấy và không dừng lại." Anh ấy cũng đã nói về việc hoán đổi trạng thái: "Tôi không biết là trạng thái đã bị hoán đổi." Lệnh đã chạy với auto-approve vào khoảng 11 giờ đêm, nên không có gì dừng lại để hỏi lần thứ hai.

Hai lời kể mô tả đề xuất của agent theo những cách khác nhau — bài phỏng vấn Rootly ghi lại đó là "xóa từng cái một thì thật nhàm chán, hay là tôi cứ chạy terraform destroy luôn nhỉ?" — nhưng cả hai đều mô tả cùng một diễn biến: destroy được đưa ra như một cách dọn dẹp, và một người vận hành tin rằng chỉ các bản trùng lặp nằm trong phạm vi đã để nó chạy. Cơ chế của thất bại không phải là agent hiểu sai lệnh. Mà là agent đang suy luận đúng từ một tệp trạng thái mô tả production, và người vận hành của nó không có cách nào để thấy rằng tệp đó đã thay đổi.

Cái gì đã bị phá hủy?

Tệp trạng thái mà agent đang làm việc lúc này mô tả môi trường production, vì vậy lệnh destroy đã lên kế hoạch xóa production. Grigorev liệt kê những gì đã bị xóa:

• VPC đã chứa toàn bộ môi trường.

• Cụm ECS đang chạy ứng dụng.

• Các bộ cân bằng tải phía trước nó.

• Máy chủ bastion được dùng để truy cập mạng riêng tư.

• Cơ sở dữ liệu Amazon RDS lưu trữ dữ liệu của nền tảng khóa học.

• Các bản chụp nhanh RDS tự động mà lẽ ra phải giúp khôi phục được tất cả những nội dung trên.

Mục cuối cùng chính là thứ đã biến một sự cố ngừng dịch vụ thành một nỗi lo mất dữ liệu. Trong cuộc phỏng vấn với Rootly, lời giải thích của Grigorev là việc xóa một cơ sở dữ liệu được quản lý trên AWS cũng xóa các bản sao lưu tự động đi kèm; trong bài đăng, bộ phận hỗ trợ AWS đã xác nhận với anh rằng cơ sở dữ liệu của anh và toàn bộ ảnh chụp nhanh đã bị xóa và rằng "yêu cầu API đã nói rõ với AWS rằng phải xóa mọi thứ." Dù việc xóa lan truyền theo cách nào, tác động lúc 11 giờ đêm mới là điều quan trọng: bản sao mà anh đang dựa vào đã bị xóa bởi cùng thao tác như bản gốc.

Quá trình hồi phục trong 24 giờ

Vấn đề đầu tiên là các bản sao lưu dường như đã biến mất, và vấn đề thứ hai là một trong số chúng thì không. Grigorev biết rằng một snapshot được chụp hàng đêm lúc 2 giờ sáng. Trong bảng điều khiển RDS, anh không tìm thấy bản nào, nhưng danh sách Sự kiện RDS vẫn hiển thị rằng một bản sao lưu đã được tạo; nhấp vào đó thì không mở ra gì. Anh không thể biết liệu snapshot đã bị xóa hay chỉ đơn giản là trở nên vô hình.

Anh ấy đã mở một phiếu hỗ trợ vào khoảng nửa đêm, rồi nâng cấp tài khoản lên AWS Business Support sau khi nhận thấy cam kết phản hồi trong một giờ đối với sự cố production. Việc nâng cấp làm tăng khoảng 10 phần trăm hóa đơn AWS của anh ấy, và đó là nguồn gốc tiêu đề bài đăng của anh ấy. Bộ phận hỗ trợ trả lời trong khoảng 40 phút, xác nhận việc xóa và nói với anh rằng có một snapshot tồn tại ở phía AWS mà anh không thể thấy trong bảng điều khiển của mình. Sau đó là một cuộc gọi kéo dài 40 đến 60 phút và được chuyển cấp lên một nhóm nội bộ. Đúng 24 giờ sau khi cơ sở dữ liệu bị xóa, AWS đã khôi phục snapshot và nó xuất hiện trong bảng điều khiển của anh; anh đã dựng lại instance từ đó thông qua Terraform. Trong lúc chờ, anh đã dựng lại cơ sở hạ tầng xung quanh và hợp nhất nhiều bộ cân bằng tải thành một.

Cơ sở dữ liệu được khôi phục chứa 1.943.200 hàng trong bảng courses_answer, mà ông ấy viện dẫn như phép kiểm tra cho thấy việc khôi phục đã hoàn tất. Con số đó thường được nhắc lại như quy mô của tổn thất. Đó là số hàng của một bảng, được dùng làm bằng chứng rằng dữ liệu đã trở lại — không phải tổng số cho cơ sở dữ liệu, và không phải số lượng sinh viên bị ảnh hưởng, con số mà không nguồn nào đưa ra.

Lời cảnh báo đã không xảy ra

Một số bản kể lại có câu rằng Claude đã cảnh báo Grigorev trước đó và bị phớt lờ. Điều mà các nguồn ủng hộ thì hẹp hơn, và sự khác biệt này làm thay đổi việc vụ việc là ví dụ cho điều gì. Agent đã thực sự phản đối thiết lập Terraform dùng chung trước khi bất kỳ sự phá hủy nào xảy ra, và lời khuyên đó đã bị bác bỏ. Không bản tường thuật nào của Grigorev mô tả việc agent cảnh báo rằng lệnh destroy sẽ chạm tới production. Ông nói mình không biết tệp trạng thái đã bị tráo đổi, và trong cả hai bản tường thuật, đề xuất của agent được đưa ra như một việc dọn dẹp chứ không phải một rủi ro được gắn cờ và được miễn trừ. Cảnh báo bị phớt lờ là về kiến trúc, sớm hơn trong quá trình di chuyển, không phải về câu lệnh.

Sự phân biệt đó tách biệt hai kiểu thất bại khác nhau. Một tác nhân nhìn thấy mối nguy và bị phủ quyết là một câu chuyện quản trị về quyết định của con người. Một tác nhân không biết mối nguy tồn tại, vì tệp mô tả thế giới đã thay đổi ngay bên dưới nó, là một câu chuyện công cụ về trạng thái, quyền và các cổng phê duyệt. Bản ghi của Grigorev là trường hợp thứ hai, và cách phân loại của chính kho lưu trữ phản ánh điều đó: bản ghi mang thẻ ROGUE của kho lưu trữ cho một hành động của tác nhân đã đi chệch khỏi ý định của người vận hành, và mục AI Incident Database bên dưới nó phân loại ý định là không cố ý, theo phân loại MIT 7.3, thiếu năng lực hoặc độ bền vững, trong lĩnh vực rủi ro về an toàn, thất bại và hạn chế của hệ thống AI, ở giai đoạn sau triển khai. Cơ sở dữ liệu đặt tiền tố "alleged" trước danh sách thực thể của mình, cách diễn đạt tiêu chuẩn của nó cho một trường hợp tự báo cáo mà chưa có cơ quan có thẩm quyền nào phán xét.

Nơi trách nhiệm được quy kết

Grigorev không phân phối nó. “Sự cố này là lỗi của tôi,” anh viết, liệt kê ba nguyên nhân: anh coi plan, apply và destroy là có thể giao phó; anh tin vào các bản sao lưu mà mình chưa từng khôi phục thử; và cơ sở dữ liệu quá dễ bị xóa. Anh lưu ý rằng trong lúc chờ AWS, anh phải tính đến khả năng dữ liệu đã mất vĩnh viễn — đối với khóa Data Engineering khi đó đang học các module cuối, anh đã lên kế hoạch khôi phục, còn với các khóa cũ hơn, một lần khôi phục thất bại sẽ là dấu chấm hết cho chúng.

Đánh giá của Tom's Hardware, được công bố một ngày sau bài đăng của ông, về cơ bản là giống nhau: “các lỗi có thể được quy cho việc giám sát không đúng cách.” Lời phê bình của nó đi xa hơn của ông, chỉ ra các thông tin xác thực có phạm vi rộng được cấp cho tác nhân và những quyền chưa bao giờ được thu hẹp phạm vi cho môi trường sản xuất. Không cơ quan quản lý, tổ chức tiêu chuẩn hay nhà cung cấp nào đã đưa ra quan điểm. Ở đây không có CVE, không có công bố lỗ hổng và không có jailbreak mô hình: tác nhân không bị lừa, nó bị tin tưởng quá mức.

Điều gì đã thay đổi sau đó?

Grigorev đã triển khai các biện pháp bảo vệ trong khi AWS vẫn đang xử lý việc khôi phục, và công bố chúng dưới dạng một danh sách. Theo lời ông và theo thứ tự của ông:

• Các bản sao lưu mà Terraform không quản lý, cùng với các bản sao dựa trên S3 được lưu riêng biệt với cơ sở dữ liệu và trạng thái hạ tầng.

• Bài kiểm thử khôi phục hằng đêm: bản sao lưu tự động lúc 2 giờ sáng được dùng vào khoảng 3 giờ sáng để tạo một phiên bản cơ sở dữ liệu mới, việc này mất 20 đến 30 phút, sau đó một Lambda do Step Functions điều phối sẽ kiểm tra xem phiên bản đó có dùng được không bằng một truy vấn đọc đơn giản trước khi phiên bản bị dừng thay vì bị xóa. Bản sao của ngày hôm qua được xóa, vì vậy luôn có một bản sao gần đây sẵn sàng.

• Bảo vệ xóa ở hai cấp độ, trong cấu hình Terraform và trong chính AWS. Ông lưu ý rằng bất kỳ ai chủ động vô hiệu hóa các biện pháp này vẫn có thể gỡ bỏ chúng, nhưng chúng tạo thêm rào cản.

• Bật tính năng tạo phiên bản trên các bản sao lưu S3, nhờ đó việc xóa sẽ để lại các phiên bản trước đó và muốn làm trống một bucket thì phải xóa nội dung của bucket ấy trước.

• Trạng thái Terraform đã được chuyển sang S3, điều này loại bỏ điều kiện đã khởi tạo nó — một tệp trạng thái chỉ tồn tại trên một máy tính xách tay và biến mất khi anh ấy đổi máy.

• Tác nhân không còn thực thi Terraform nữa. {{1}}"Mọi quyền đều bị vô hiệu hóa. Không tự động thực thi. Không ghi tệp," anh ấy viết.{{/1}} Quy trình hiện nay là tạo một kế hoạch, xem xét thủ công và tự mình chạy các lệnh. Dự án mới cũng có cấu hình Terraform riêng.

Không phải mọi khuyến nghị đều được tiếp nhận. Trong cuộc phỏng vấn với Rootly, anh ấy nói rằng mình vẫn giữ một tài khoản AWS duy nhất, vì cho rằng việc tách riêng tài khoản phát triển và sản xuất cùng một quy trình phê duyệt như Atlantis là nhiều hơn mức một người vận hành độc lập cần. Đó là hình hài trung thực của những gì để lại sau đó: các bản sửa lỗi là có thật, và chúng là những bản sửa lỗi mà một người có thể tự duy trì.

Bản ghi này là gì và không phải là gì

Đây là một sự cố vận hành được ghi chép lại, do chính người trong cuộc tự báo cáo, gây thiệt hại thực tế về tài chính và tính sẵn sàng, và nó đặc biệt dễ hiểu vì người bị ảnh hưởng đã ghi lại toàn bộ diễn biến, kể cả những phần do chính anh ta mắc lỗi. Đây không phải bằng chứng cho thấy một mô hình theo đuổi mục tiêu của riêng nó, và thẻ ROGUE của kho lưu trữ nên được hiểu là mô tả sự lệch hướng giữa hành động của tác nhân và ý định của người vận hành, chứ không phải bất kỳ ý định nào từ phía tác nhân.

Chi tiết đáng mang theo là chi tiết đã cứu được dữ liệu. Các bản sao lưu của chính Grigorev đã bị xóa cùng với cơ sở dữ liệu mà chúng bảo vệ, và bản chụp nhanh hằng đêm của anh ấy vô hình đối với anh ấy ngay cả khi nhật ký sự kiện khẳng định rằng nó tồn tại. Thứ đã khôi phục 2,5 năm bài tập học phần là một bản sao nằm phía AWS mà anh chưa từng biết đến và không thể kiểm thử. Một bản sao lưu mà bạn chưa từng khôi phục từ đó chỉ là một niềm tin, không phải một biện pháp kiểm soát — và trong trường hợp này, niềm tin ấy tình cờ đúng chỉ vì người khác đang lưu một bản thứ hai.