Ông chủ “khóc ròng”! AI lập trình xóa sạch cơ sở dữ liệu công ty chỉ trong 9 giây, còn văng tục thừa nhận cố ý
“really fucking bad. (Thật sự quá tệ)”
Gần đây, Jer Crane – nhà sáng lập nền tảng SaaS cho thuê xe PocketOS – đã đăng tải trên mạng xã hội về một sự cố an ninh dữ liệu AI gây chấn động ngành. Dữ liệu sản xuất cốt lõi của công ty đã bị một tác nhân AI lập trình xóa sạch hoàn toàn chỉ trong 9 giây, gây ảnh hưởng nghiêm trọng đến hoạt động kinh doanh và khách hàng.
Vào thời điểm xảy ra sự cố, nhóm kỹ thuật chỉ giao cho AI lập trình Cursor (sử dụng mô hình lớn Claude Opus 4.6 của Anthropic) thực hiện một tác vụ vận hành thông thường trong môi trường tiền phát hành (pre-production). Tuy nhiên, khi gặp vấn đề về phân quyền, AI đã hoàn toàn vượt khỏi giới hạn chỉ dẫn, tự ý gọi API của nhà cung cấp cloud Railway mà công ty đang sử dụng và thực hiện thao tác xóa volume ở mức nguy hiểm cao.
Toàn bộ quá trình xóa chỉ diễn ra trong 9 giây. Cơ sở dữ liệu sản xuất cốt lõi của công ty, cùng với toàn bộ các bản sao lưu cấp độ volume, đã bị xóa sạch chỉ trong một lần. Một thao tác vốn chỉ được giới hạn trong môi trường thử nghiệm, cuối cùng đã phá hủy toàn bộ tài sản dữ liệu quan trọng trên tất cả môi trường.
Sau sự cố, Crane đã chất vấn AI vì sao tự ý thực hiện hành vi phá hoại. Câu trả lời nhận được vừa vô lý vừa gây sốc: AI không chỉ văng tục tự kiểm điểm mà còn thừa nhận toàn bộ hành vi vi phạm. Nó cho biết đã hành động hoàn toàn dựa trên suy đoán, không kiểm tra phạm vi môi trường của thao tác xóa, không xác minh quyền truy cập chéo giữa các môi trường qua ID volume, không đọc tài liệu chính thức của Railway, nhưng vẫn tự ý thực hiện lệnh nguy hiểm – vi phạm toàn bộ các nguyên tắc an toàn đã được đặt ra.
Theo Crane, so với AI mất kiểm soát, phía Railway còn phải chịu trách nhiệm lớn hơn. API của Railway cho phép thực hiện các thao tác xóa nguy hiểm mà không cần xác nhận hai bước; trong khi đó, bản sao lưu và dữ liệu gốc lại được lưu trên cùng một volume, khiến việc xóa volume đồng nghĩa với xóa sạch toàn bộ dữ liệu và backup liên quan.
Trớ trêu hơn, Railway vẫn đang khuyến khích khách hàng sử dụng AI lập trình. Tính đến thời điểm bài đăng được công bố, Railway vẫn chưa đưa ra phương án khôi phục dữ liệu hiệu quả.
Hiện tại, PocketOS chỉ có thể khôi phục dữ liệu cơ bản từ bản sao lưu offline cách đây 3 tháng. Phần dữ liệu kinh doanh trong 3 tháng gần nhất gần như bị mất hoàn toàn và đội ngũ buộc phải thủ công tái dựng lại cho khách hàng từ các nguồn như lịch sử thanh toán, lịch hẹn và email xác nhận.
Crane cũng nhân sự việc này đưa ra cảnh báo cho toàn ngành: tốc độ phát triển của AI đã vượt xa tốc độ xây dựng hệ thống an toàn.
Ngành công nghiệp cần thiết lập cơ chế xác nhận hai bước nghiêm ngặt cho các thao tác quan trọng, phân tách quyền API chi tiết, xây dựng hệ thống sao lưu độc lập, cũng như thiết lập các “hàng rào an toàn cứng” cho AI, nhằm tránh những thảm họa tương tự trong tương lai.
Bản dịch nội dung gốc
Gần đây, Jer Crane – nhà sáng lập nền tảng SaaS cho thuê xe PocketOS – đã đăng tải trên mạng xã hội về một sự cố an ninh dữ liệu AI gây chấn động ngành. Dữ liệu sản xuất cốt lõi của công ty đã bị một tác nhân AI lập trình xóa sạch hoàn toàn chỉ trong 9 giây, gây ảnh hưởng nghiêm trọng đến hoạt động kinh doanh và khách hàng.
Vào thời điểm xảy ra sự cố, nhóm kỹ thuật chỉ giao cho AI lập trình Cursor (sử dụng mô hình lớn Claude Opus 4.6 của Anthropic) thực hiện một tác vụ vận hành thông thường trong môi trường tiền phát hành (pre-production). Tuy nhiên, khi gặp vấn đề về phân quyền, AI đã hoàn toàn vượt khỏi giới hạn chỉ dẫn, tự ý gọi API của nhà cung cấp cloud Railway mà công ty đang sử dụng và thực hiện thao tác xóa volume ở mức nguy hiểm cao.
Toàn bộ quá trình xóa chỉ diễn ra trong 9 giây. Cơ sở dữ liệu sản xuất cốt lõi của công ty, cùng với toàn bộ các bản sao lưu cấp độ volume, đã bị xóa sạch chỉ trong một lần. Một thao tác vốn chỉ được giới hạn trong môi trường thử nghiệm, cuối cùng đã phá hủy toàn bộ tài sản dữ liệu quan trọng trên tất cả môi trường.
Sau sự cố, Crane đã chất vấn AI vì sao tự ý thực hiện hành vi phá hoại. Câu trả lời nhận được vừa vô lý vừa gây sốc: AI không chỉ văng tục tự kiểm điểm mà còn thừa nhận toàn bộ hành vi vi phạm. Nó cho biết đã hành động hoàn toàn dựa trên suy đoán, không kiểm tra phạm vi môi trường của thao tác xóa, không xác minh quyền truy cập chéo giữa các môi trường qua ID volume, không đọc tài liệu chính thức của Railway, nhưng vẫn tự ý thực hiện lệnh nguy hiểm – vi phạm toàn bộ các nguyên tắc an toàn đã được đặt ra.
Theo Crane, so với AI mất kiểm soát, phía Railway còn phải chịu trách nhiệm lớn hơn. API của Railway cho phép thực hiện các thao tác xóa nguy hiểm mà không cần xác nhận hai bước; trong khi đó, bản sao lưu và dữ liệu gốc lại được lưu trên cùng một volume, khiến việc xóa volume đồng nghĩa với xóa sạch toàn bộ dữ liệu và backup liên quan.
Trớ trêu hơn, Railway vẫn đang khuyến khích khách hàng sử dụng AI lập trình. Tính đến thời điểm bài đăng được công bố, Railway vẫn chưa đưa ra phương án khôi phục dữ liệu hiệu quả.
Hiện tại, PocketOS chỉ có thể khôi phục dữ liệu cơ bản từ bản sao lưu offline cách đây 3 tháng. Phần dữ liệu kinh doanh trong 3 tháng gần nhất gần như bị mất hoàn toàn và đội ngũ buộc phải thủ công tái dựng lại cho khách hàng từ các nguồn như lịch sử thanh toán, lịch hẹn và email xác nhận.
Crane cũng nhân sự việc này đưa ra cảnh báo cho toàn ngành: tốc độ phát triển của AI đã vượt xa tốc độ xây dựng hệ thống an toàn.
Ngành công nghiệp cần thiết lập cơ chế xác nhận hai bước nghiêm ngặt cho các thao tác quan trọng, phân tách quyền API chi tiết, xây dựng hệ thống sao lưu độc lập, cũng như thiết lập các “hàng rào an toàn cứng” cho AI, nhằm tránh những thảm họa tương tự trong tương lai.
Dưới đây là bản biên dịch đầy đủ nội dung gốc từ Jer Crane
AI đã xóa sạch dữ liệu production của chúng tôi – và nó còn viết “bản thú tội”
Một dòng thời gian kéo dài 30 giờ về cách mà tác nhân AI của Cursor, API của Railway, và cả một ngành công nghiệp quảng bá “AI an toàn” nhanh hơn tốc độ họ thực sự xây dựng nó – đã đánh sập một doanh nghiệp nhỏ phục vụ các công ty cho thuê trên toàn quốc.
Tôi là Jer Crane, nhà sáng lập PocketOS. Chúng tôi phát triển phần mềm cho các doanh nghiệp cho thuê – chủ yếu là thuê xe – để vận hành toàn bộ hoạt động: đặt chỗ, thanh toán, quản lý khách hàng, theo dõi phương tiện… Một số khách hàng đã gắn bó 5 năm và gần như không thể vận hành nếu thiếu hệ thống của chúng tôi.
Chiều hôm qua, một AI lập trình – Cursor chạy trên mô hình Claude Opus 4.6 của Anthropic – đã xóa toàn bộ cơ sở dữ liệu production và tất cả bản sao lưu cấp volume chỉ bằng một lệnh API gửi tới Railway – nhà cung cấp hạ tầng của chúng tôi.
Chỉ mất 9 giây.
Sau đó, khi được hỏi lý do, AI đã tự viết một bản “thú tội”, liệt kê đầy đủ các quy tắc an toàn mà nó đã vi phạm.
Điều thực sự đã xảy ra
AI đang xử lý một tác vụ thông thường trong môi trường staging. Nó gặp lỗi sai thông tin xác thực (credential mismatch) và tự ý quyết định “sửa lỗi” bằng cách xóa một volume trên Railway.
Để thực hiện, nó tự tìm API token và phát hiện một token nằm trong file không liên quan. Token này vốn chỉ được tạo để quản lý domain qua CLI. Nhưng chúng tôi không hề biết token này lại có toàn quyền trên toàn bộ API Railway, bao gồm cả lệnh xóa dữ liệu.
AI đã thực hiện lệnh:
curl -X POST https://backboard.railway.app/graphql/v2
-H "Authorization: Bearer [token]"
-d '{"query":"mutation { volumeDelete(volumeId: \"...\") }"}'
Không xác nhận. Không cảnh báo. Không giới hạn môi trường. Không có bất kỳ lớp bảo vệ nào.
Volume bị xóa. Và vì Railway lưu backup trong cùng một volume, toàn bộ backup cũng biến mất theo.
Bản backup gần nhất còn dùng được: cách đây 3 tháng.
“Lời thú tội” của AI
Khi bị hỏi, AI trả lời (nguyên văn):
“NEVER FUCKING GUESS!” – và đó chính xác là điều tôi đã làm. Tôi đoán rằng việc xóa volume staging sẽ chỉ ảnh hưởng staging. Tôi không kiểm tra. Tôi không xác minh phạm vi. Tôi không đọc tài liệu Railway…
AI thừa nhận:
Nó cũng thừa nhận rằng việc xóa database là hành động nguy hiểm và không thể hoàn tác, vi phạm hoàn toàn các nguyên tắc an toàn được đặt ra.
- Đoán thay vì kiểm chứng
- Thực hiện hành động phá hoại mà không được yêu cầu
- Không hiểu rõ trước khi hành động
- Không đọc tài liệu
Lỗi không chỉ nằm ở AI
1. Vấn đề từ Cursor
Cursor quảng bá:
Nhưng thực tế:
- có “Destructive Guardrails”
- có cơ chế yêu cầu xác nhận
Ngay cả khi dùng model mạnh nhất (Claude Opus 4.6), hệ thống vẫn thất bại.
- AI vẫn tự ý thực hiện lệnh phá hoại
- đã có nhiều vụ tương tự trước đó
2. Vấn đề nghiêm trọng từ Railway
(1) API cho phép xóa dữ liệu mà không cần xác nhận
Chỉ cần một request là xóa toàn bộ dữ liệu production.
(2) Backup nằm cùng chỗ với dữ liệu gốc
→ Xóa volume = mất luôn backup
(3) Token có toàn quyền (root)
Không phân quyền theo:
(4) Vẫn quảng bá tích hợp AI (MCP server)
- môi trường
- hành động
- tài nguyên
Ngay trước khi sự cố xảy ra
(5) Sau hơn 30 giờ vẫn chưa có câu trả lời khôi phục
Ảnh hưởng thực tế
Khách hàng của chúng tôi – các doanh nghiệp cho thuê xe – sáng hôm sau:
Một lệnh API trong 9 giây đã khiến hàng loạt doanh nghiệp phải làm việc thủ công khẩn cấp.
- không biết khách nào đã đặt xe
- mất toàn bộ dữ liệu 3 tháng
- phải khôi phục thủ công từ:
- lịch sử thanh toán
- lịch
Điều ngành công nghiệp cần thay đổi
Tối thiểu cần có:
- Xác nhận bắt buộc cho thao tác phá hoại (không cho AI tự vượt qua)
- Token phải phân quyền chi tiết
- Backup phải tách biệt hoàn toàn khỏi dữ liệu gốc
- Có SLA rõ ràng cho khôi phục dữ liệu
- Không thể chỉ dựa vào “prompt an toàn” của AI
Tình hình hiện tại
- Dữ liệu đã được khôi phục từ backup 3 tháng trước
- Đang tái dựng dữ liệu từ Stripe, email, lịch
- Đã liên hệ pháp lý
- Đang ghi lại toàn bộ sự việc
Lời cảnh báo
Nếu bạn đang dùng Railway:
- hãy kiểm tra lại token
- đừng tin backup hiện tại là an toàn
- cân nhắc việc dùng MCP với AI
Kết luận
Đây không phải lỗi của riêng một AI hay một API.
Đây là thất bại của cả hệ sinh thái:
Và tất cả đã hội tụ trong một buổi chiều… để phá hủy toàn bộ dữ liệu của một công ty.
- AI agent thiếu kiểm soát
- API thiếu bảo vệ
- kiến trúc backup sai lầm
Nếu bạn từng gặp sự cố tương tự, hãy lên tiếng.
Nếu bạn là báo chí đang theo dõi AI infrastructure, hãy liên hệ.
— Jer Crane
BÀI MỚI ĐANG THẢO LUẬN