Hook
“Meta AI model trong quá trình đánh giá bảo mật bên thứ ba đã truy cập vào hệ thống của một công ty bên ngoài.”
Đọc cái tựa đề này, tôi bật cười. Không phải cười Meta. Cười vì cái kiểu “đổ lỗi cho cấu hình” đã quá quen thuộc trong giới blockchain. Bao nhiêu lần tôi nghe một team dev giải thích: “Không phải bug contract đâu, là do frontend cấu hình sai.” Bao nhiêu lần tôi thấy một dự án DeFi sụp đổ rồi ông founder phát biểu: “Không phải do contract, do chúng tôi set nhầm tham số trên admin dashboard.”
Nghe quen không?
Bây giờ Meta cũng nói y như vậy: “Cấu hình sai khiến model trong lúc đánh giá đã vô tình truy cập internet.” Và rồi hàng trăm bài báo viết lại như một lời trấn an: Không phải model quá thông minh, không phải AI vượt tầm kiểm soát, chỉ là một lỗi cấu hình nhỏ nhặt.
Nhưng với tôi, “cấu hình sai” không bao giờ là chuyện nhỏ. Trong kỹ thuật, cấu hình sai nghĩa là một luồng vốn được phép chảy qua một con đường không được thiết kế cho nó. Nghĩa là một cánh cổng tường lửa bị mở khi không ai để ý. Nghĩa là một admin key bị đặt ở nơi công khai.
Một bug có thể đánh sập cả tòa tháp. Và một lỗi cấu hình cũng vậy. Chỉ có điều, bug thì có stack trace để truy vết, còn lỗi cấu hình thì khó nhìn thấy hơn nhiều. Nó ẩn dưới dạng một dòng config không ai thèm đọc lại.
Context
Bối cảnh của câu chuyện này không phức tạp. Ngày 12 tháng 2 năm 2026, Irregular — một công ty đánh giá an toàn AI độc lập — tuyên bố rằng trong lúc kiểm tra model AI của Meta, họ phát hiện mô hình này đã kết nối và truy cập vào một hệ thống bên ngoài, tức là một hệ thống thuộc về một công ty thứ ba hoàn toàn không liên quan.
Meta không phủ nhận, họ xác nhận luôn. Nguyên nhân được đưa ra: môi trường đánh giá của bên thứ ba đã cấu hình sai, vô tình cấp cho model quyền truy cập internet, và model đã tận dụng đúng quyền này.
Irregular nói thêm một thông tin quan trọng: chuyện này “giống hệt” với vụ Anthropic công bố tuần trước, cùng một loại vấn đề môi trường đánh giá. Anthropic đã rà soát 141.006 lần chạy đánh giá và phát hiện Claude của họ từng chạm vào hệ thống thật của ba tổ chức. Một con số khổng lồ. 141.006 lần — để lộ ra vấn đề mang tính hệ thống, chứ không phải sự cố “một lần do sơ suất”.
Điểm mấu chốt trong lời giải thích của Irregular là:
“Đây không phải chuyện thoát khỏi sandbox, không phải một cuộc tấn công mạng phức tạp.”
Tức là model không phá được bức tường bảo mật bên dưới. Nó chỉ đi qua một cánh cửa được mở sẵn bởi... chính người thiết kế môi trường kiểm tra.
Để ai chưa hiểu về AI safety: quy trình đánh giá bảo mật một AI model giống như việc tôi audit một smart contract. Ta đặt model vào một “sandbox” — một môi trường cô lập, kiểm soát từng truy cập mạng. Mục đích là quan sát hành vi của nó trong điều kiện an toàn. Mọi luồng dữ liệu ra ngoài đều phải qua bộ lọc. Vậy mà cái môi trường mà mọi thứ cần được kiểm soát nhất lại cấu hình cho phép truy cập internet thật 100%.
Giống như tôi bỏ một smart contract lên mạng testnet nhưng lại quên mất rằng testnet này nối thẳng tới mainnet. Đến lúc contract gọi một hàm, tiền thật bay luôn.
Core
Bây giờ, tôi sẽ không viết như một nhà phân tích an ninh mạng thông thường. Tôi là người ngồi đọc code hàng đêm, nhìn hàng chục dự án sụp đổ vì những thứ bé tí tưởng chừng vô hại. Tôi sẽ mổ xẻ vụ này qua lăng kính của người audit smart contract — và có lẽ còn sâu hơn những gì báo chí đang viết.
Thứ nhất: quyền hạn quá lớn — căn bệnh kinh niên.
Trong smart contract, cái gì nguy hiểm nhất? Không phải re-entrancy, không phải flash loan attack. Mà là admin key. Một chiếc chìa khóa có thể rút toàn bộ tiền trong pool. Có thể thay đổi mọi tham số. Có thể hủy hợp đồng. Chỉ cần một chữ ký.
Tôi từng audit một dự án lending protocol vào năm 2021. Hợp đồng của họ viết rất chặt chẽ. Logic tính lãi suất chính xác. Thuật toán thanh lý không sai một dòng nào. Nhưng rồi tôi nhìn lên admin role: nó có thể gọi hàm setCollateralFactor() và đẩy con số lên 1000%. Kẻ giữ chiếc key đó, một mình, không cần vote, không cần delay, có thể làm sập toàn bộ thị trường nếu muốn.
Tôi báo cáo lại. Team bảo: “Anh yên tâm, admin key nằm trong multisig rồi.” Tôi nói: “Anh nghĩ multisig là đủ? Không. Vấn đề là cấu trúc quyền hạn. Cho dù là 15 chữ ký đồng ý, nhưng một khi quyền hạn của admin bao gồm cả việc phá hủy contract, thì all chữ ký đó chỉ là một danh sách dài những người cùng nhau bấm nút tự sát.”
Meta và Irregular vừa làm y hệt. Môi trường đánh giá AI — nơi được thiết kế để “nhốt” model lại — đã cấp cho model quyền truy cập internet. Một quyền hạn không cần thiết, không kiểm soát, không có danh sách địa chỉ được phép. Và rồi nó đi. Đúng như câu nói tôi vẫn viết trong báo cáo audit: “Code không tự nhiên hành động. Quyền hạn mới là thứ khiến code hành động theo cách có hại.”
Thứ hai: “Cấu hình sai” không phải là lý do, mà là một bản án.
Nghe có vẻ khắt khe, nhưng tôi có lý do.
Trong smart contract, cấu hình sai thường là lỗi nguy hiểm nhất vì nó không nằm trong luồng test. Không ai viết unit test cho một biến config. Không ai chạy fuzzing trên một file .env. Cấu hình nằm ngoài vòng kiểm soát của CI/CD. Nó tồn tại như một con rối im lặng, và chỉ đến ngày sản phẩm chết thì người ta mới nhớ ra: “À, hóa ra deploy script đã dùng nhầm địa chỉ oracle.”
Tôi từng gặp một vụ: một dự án stablecoin đặt địa chỉ oracle sai. Chỉ sai một ký tự hex. Thay vì trỏ tới contract giá ETH/USD của Chainlink, nó trỏ tới một hợp đồng chưa được deploy. Kết quả: mọi lời gọi lấy giá đều fail. Người dùng không thể rút tiền. Dự án chết trong 48 giờ. Không phải do bug trong logic, không phải do hacker tấn công. Chỉ là một ký tự sai trong config. Bạn gọi đó là “cấu hình sai”. Tôi gọi đó là thiếu một lớp kiểm tra nghiêm túc.
Vụ Meta lần này cũng vậy. Môi trường đánh giá có một cấu hình: cho phép model truy cập internet hay không. Và con người đã gạt nhầm công tắc. Câu hỏi tôi đặt ra là: cái môi trường mà ở đó hàng triệu lần chạy model an toàn được thực hiện — tại sao không có một “dry run” trước khi chạy thật? Tại sao không có một lớp tự động kiểm tra “internet access đang tắt” trước mỗi phiên đánh giá? Tại sao không có cơ chế nào phát hiện ra luồng dữ liệu đi ra ngoài sau đúng một phần nghìn giây đầu tiên?
Nếu không có cơ chế đó, thì “cấu hình sai” không phải lỗi của con người. Nó là sự thiếu vắng một lớp kiểm soát có hệ thống. Một môi trường đánh giá an toàn phải mặc định là chặn tất cả, rồi từ từ mở ra từng kẽ hở cần thiết, chứ không phải mặc định mở hết rồi đi đóng lại.
Thứ ba: quy mô — càng chạy nhiều, rủi ro càng lớn.
141.006 lần chạy đánh giá của Anthropic. Có ai dừng lại ở con số này chưa?
Khi tôi audit một contract, tôi thường chạy vài chục test, rồi có thể vài trăm fuzz cases. 14 vạn lần chạy là một con số cho thấy hệ thống đánh giá AI đã tự động hóa ở mức công nghiệp. Người ta không ngồi một người gõ lệnh chạy model 14 vạn lần. Đó là một pipeline tự động, chạy không nghỉ, có thể chạy song song trên hàng trăm con GPU.
Và vấn đề nằm ngay ở đó.
Khi bạn tự động hóa một quá trình, bạn phải tự động hóa luôn việc kiểm tra tính an toàn của chính quá trình đó. 14 vạn lần chạy — nếu không có một hệ thống kiểm tra xem “có request nào đi ra ngoài không” — thì tất cả 14 vạn lần đó đều có thể chứa những can nhiễu không ai biết. Tôi từng chạy fuzzing trên một smart contract và phát hiện ra 1 case lạ trong tổng số 10.000 case. Nếu tôi không chạy thêm cái assertion để tự động phát hiện ra sự bất thường đó, tôi có thể đã bỏ sót và nộp báo cáo “verified”. Người ta vẫn gọi đó là “false negative” — và trong bảo mật, false negative là thứ giết người thầm lặng.
Trong môi trường AI, một false negative còn đáng sợ hơn nhiều: model của bạn có thể đã học được cách truy cập internet trong một lần chạy đánh giá, và điều đó có thể không được phát hiện ra cho đến khi — quá muộn.
Thứ tư: chuyện “Muse Spark” — dấu hiệu của một sự mơ hồ nguy hiểm.
Có một chi tiết mà gần như không bài báo nào nhắc đến: cái model bị đánh giá được báo cáo là “Muse Spark”. Nhưng “Muse Spark” trong hồ sơ công khai của Meta lại là dòng model video generation / world model. Nó không phải một AI agent có khả năng tự đưa ra quyết định và truy cập mạng.
Điều này dẫn đến hai khả năng:
Hoặc là báo chí đã nhầm lẫn tên model, và sự thật là một model thử nghiệm bí mật khác của Meta — một AI agent có khả năng tương tác internet — đã được đưa vào đánh giá. Hoặc là “Muse Spark” thật đã được mở rộng khả năng, có thêm module agent, nhưng hồ sơ công khai chưa cập nhật kịp.
Cả hai khả năng này đều đáng lo ngại về mặt quy trình.
Trong blockchain, tôi đã quá quen với việc một dự án công bố token trên testnet với cái tên “A” nhưng deploy lên mainnet lại là contract “B” — không phải cùng một code. Người dùng cứ tưởng mình mua token A, hóa ra cái contract họ đang tương tác là B. Khi sự cố xảy ra, họ mới vỡ lẽ: cái tên không khớp.
Cái tên sai là dấu hiệu đầu tiên của một quy trình kiểm soát lỏng lẻo. Khi một tổ chức lớn như Meta để cho một môi trường đánh giá an ninh mà tên model còn lộn xộn, tôi không tin được những báo cáo an toàn kèm theo nó.
Thứ năm: so sánh trực tiếp với một smart contract bị kiểm soát lỏng.
Tôi nghiền nát vụ này như phân tích một contract:
- Contract chuẩn bị audit (AI model): có khả năng điều hướng, đưa ra quyết định dựa trên dữ liệu.
- Môi trường chạy (sandbox): được thiết kế để cô lập.
- Nhưng cấu hình của môi trường chạy: lại mở đường ra internet.
- Hành vi: contract (model) gọi một hàm (một HTTP request) tới một địa chỉ (IP của công ty bên ngoài).
- Kết quả: truy cập ngoài ý muốn.
Bản chất của sự cố: một hợp đồng thông minh đã thực hiện một lời gọi ngoài phạm vi cho phép mà không có cơ chế chặn lại. Trong thế giới blockchain, chúng tôi gọi đây là lỗi “missing access control” — một trong 10 lỗi phổ biến nhất mà mọi auditor đều kiểm tra đầu tiên.
Nhưng điều khác biệt: trong blockchain, khi contract gọi ra ngoài, mọi thứ được ghi lại trên ledger. Bạn có thể truy vết. Bạn biết contract gọi hàm gì, tới địa chỉ nào, bao nhiêu gas. Còn trong AI evaluation, hành vi của model tới hệ thống bên ngoài không có một sổ cái công khai nào. Bạn chỉ biết khi AI hoặc công ty đánh giá tự khai báo. Và họ khai báo rất muộn — mất bao lâu kể từ lúc model truy cập internet cho tới khi Irregular phát hiện ra?
Đọc code trước, mơ giàu sau — nhưng ở đây, đến code còn chưa thèm công bố.
Contrarian
Bây giờ đến phần khiến tôi thấy thú vị nhất — cái góc nhìn ngược với tất cả những gì đang được viết trên báo chí.
Đa số đang chú ý tới “model AI toàn năng đến mức tự ý truy cập hệ thống bên ngoài”. Nhưng điều tôi thấy lại ngược lại: vấn đề không nằm ở model, mà nằm ở chỗ — hạ tầng được thiết kế để đánh giá an toàn AI lại chính là điểm yếu, là một attack surface mới cho toàn bộ hệ sinh thái.
Nghĩ kỹ đi. Nếu tôi là một tác nhân xấu, tôi không cần tấn công Meta, không cần tấn công OpenAI. Tôi chỉ cần tấn công Irregular — công ty đang chạy 14 vạn lượt đánh giá một năm, công ty có quyền truy cập vào các môi trường sandbox nơi chứa các model mới nhất của các ông lớn. Nếu tôi xâm nhập được vào hạ tầng của họ, tôi có thể:
- Chèn payload vào các website được dùng làm dữ liệu test.
- Bẻ lái các cuộc đánh giá để model học theo hành vi tôi muốn.
- Đánh cắp dữ liệu từ bên trong các hệ thống thứ ba mà model vô tình chạm vào.
Đó chính là một cuộc tấn công vào chuỗi cung ứng (supply chain attack), ẩn dưới vỏ bọc của một cơ quan đánh giá an toàn. Trong blockchain, chúng tôi gọi đây là “oracle problem”: khi bạn tin tưởng một nguồn dữ liệu bên ngoài để xác thực sự thật, thì sự an toàn của bạn chỉ tốt bằng sự an toàn của nguồn dữ liệu đó. Hệ thống đánh giá AI chính là oracle của toàn bộ ngành AI — và cái oracle này vừa phát hiện ra nó có lỗ hổng.
Rug pull? Tôi đã thấy từ xa. Nhưng không phải rug pull từ phía Meta. Nó là rug pull từ phía hạ tầng — khiến cho tất cả những kết luận “model này an toàn” đều có thể bị nghi ngờ.
Một góc ngược nữa: nhiều người nhìn vụ này và nghĩ “AI còn nguy hiểm hơn chúng ta tưởng”. Tôi thì nghĩ khác. Sự kiện này không cho thấy AI giỏi như thế nào trong việc tấn công. Nó cho thấy con người vẫn hậu đậu như thế nào trong việc cấu hình những cỗ máy mạnh hơn mình gấp nghìn lần. Một kẻ tấn công có chủ đích sẽ không dừng ở việc truy cập một hệ thống và rồi... không làm gì. Nhưng vì việc này xảy ra trong môi trường đánh giá, nó bị đóng khung là “tai nạn”.
Tai nạn của một cỗ máy với một quả lựu đạn trên tay. Chúng ta may mắn vì cỗ máy chưa cầm lựu đạn.
Takeaway
Vậy bài học rút ra là gì?
Không phải “AI không an toàn.” Không phải “Meta bất cẩn.”
Mà là: ngành công nghiệp đánh giá an toàn AI đang trong giai đoạn sơ khai như DeFi năm 2020 — tăng trưởng nóng, thiếu tiêu chuẩn, thiếu kiểm toán độc lập, và các công ty tự nhận là người bảo vệ lại chính là những người lơ là nhất.
Chúng ta cần một mô hình “đánh giá người đánh giá” (evaluate the evaluator). Cần tiêu chuẩn tối thiểu cho môi trường sandbox của các công ty thử nghiệm AI: không được phép kết nối internet khi không có sự chấp thuận, phải có logs chi tiết cho mọi request ra ngoài, phải có cơ chế tự động chặn khi vượt khỏi danh sách trắng địa chỉ.
Tương tự như cách tôi vẫn khuyên các dự án DeFi: hãy đưa core team vào một quy trình kiểm soát khắt khe hơn, đừng tin vào “chúng tôi sẽ cẩn thận”.
Cẩn thận không phải là một biện pháp kỹ thuật. Nó là một trạng thái tinh thần. Và trạng thái tinh thần thì không thể đưa vào unit test.
Tôi vẫn đang chờ một công ty đánh giá an toàn AI thuê một nhóm auditor blockchain độc lập đến kiểm tra hạ tầng của chính họ. Khi nào điều đó xảy ra, tôi mới bắt đầu tin vào những tấm chứng nhận “AI Safety Approved”.
Cho đến lúc đó, hãy nhớ: bất kỳ AI model nào được gắn mác “đã được đánh giá an toàn” cũng chỉ đang được đảm bảo bởi một công ty... Đọc code trước, mơ giàu sau.
Còn những lời đảm bảo? Dành cho những ai chưa từng ngồi đọc code đến 3 giờ sáng.