Ngày 8 tháng 8 năm 2025, Anthropic thông báo một thay đổi tưởng chừng kỹ thuật nhưng chạm đến nền tảng của cách chúng ta phân phối quyền lực giữa người và máy: bắt đầu từ 14 tháng 8, chế độ phân quyền mặc định của Claude Code dành cho người dùng Pro, Max và Team sẽ chuyển sang chế độ tự động. Theo mô tả chính thức, Claude Code sẽ xem xét các lệnh Shell cũng như các thao tác trước khi thực thi thông qua một bộ phân loại độc lập. Trong thử nghiệm nội bộ, bộ phân loại này xác định được 89% các lệnh nguy hiểm; trong khi đó, chế độ xin phê duyệt thủ công — vốn được coi là tiêu chuẩn vàng về an toàn — chỉ phát hiện được 14%.
Chỉ báo thay đổi chế độ vừa lật. Và nó lật theo hướng đi ngược lại trực giác của hầu hết kỹ sư bảo mật truyền thống: có những thời điểm, cách an toàn nhất để kiểm soát một cỗ máy không phải là giữ nó lại gần mình, mà là đặt nó vào một hệ thống kiểm soát khác.
Để hiểu vì sao một sự kiện liên quan đến dòng lệnh Shell của một trợ lý mã nguồn mở lại quan trọng với ngành tài sản số, cần đặt nó trong bối cảnh AI agents đang thâm nhập vào hạ tầng tài chính phi tập trung. Không còn là những bot chạy theo quy tắc cứng; các tác tử hiện đại sử dụng mô hình ngôn ngữ để diễn giải ý định người dùng, tự lập kế hoạch hành động, và thực thi trên các môi trường có quyền truy cập thực — bao gồm ví, hợp đồng thông minh, và các hệ thống thanh toán.
Khi một AI agent thực thi một lệnh di chuyển tài sản trên chuỗi, quá trình ra quyết định của nó bao gồm một chuỗi xác suất: xác suất lệnh hợp lệ, xác suất địa chỉ đích an toàn, xác suất dữ liệu giao dịch không chứa mã độc. Mỗi xác suất đều có thể bị tác động bởi kẻ tấn công thông qua prompt injection, dữ liệu gây nhiễu, hoặc tối ưu hóa mô hình theo hướng có hại. Khi một smart contract là mã tự thực thi theo quy tắc cứng, một AI agent là mã tự thực thi theo phân tích xác suất. Sự khác biệt không nằm ở cơ chế; nó nằm ở tính không tiên đoán được của quá trình ra quyết định.
Trong 29 năm quan sát ngành tài sản số, tôi liên tục chứng kiến cùng một sai lầm hệ thống: khi các giao thức đối mặt với rủi ro, họ thêm lớp xác nhận, nhân sự phê duyệt, và chữ ký thứ hai — mà không bao giờ định lượng được liệu lớp xác nhận đó có thực sự ngăn chặn được thảm họa tiếp theo hay không. Claude Code vừa đưa ra một con số đáng suy ngẫm: 14%. Đây là lỗ hổng kiến trúc mà chúng ta đã duy trì suốt nhiều thập kỷ, dưới cái tên "kiểm soát thủ công".
Con người không mệt mỏi theo cách chúng ta nghĩ
Trong các cuộc phỏng vấn với đội ngũ vận hành của các giao thức DeFi lớn, một mô thức lặp lại: phần lớn thời gian của những người chịu trách nhiệm phê duyệt giao dịch không dành cho phân tích sâu, mà dành cho việc xử lý khối lượng. Họ mở email, mở dòng lệnh, nhìn thấy một chuỗi cú pháp quen thuộc, và phê duyệt. Khi một lệnh bất thường xuất hiện — ví dụ một lệnh gọi hàm thay đổi quyền sở hữu của một hợp đồng đang nắm giữ 80% tổng thanh khoản — họ vẫn phê duyệt, không phải vì họ không nhận ra rủi ro, mà vì họ đã trải qua 47 lần phê duyệt tương tự trong cùng ngày, và lần nào cũng an toàn.
Đây là điều Claude Code đo lường được qua con số 14%. Nhưng tôi nghĩ con số đó vẫn còn hào phóng. Trong môi trường sản xuất thực tế — nơi có áp lực, có deadline, có sự phân tâm từ nhiều kênh liên lạc cùng lúc — tỷ lệ phát hiện của con người có thể còn thấp hơn. Và tệ hơn, sự tự tin của họ vẫn ở mức cao. Một người bỏ lỡ một dấu hiệu cảnh báo không bao giờ nghĩ rằng mình có thể là người bỏ lỡ. Họ nghĩ người khác mới là người chủ quan.
Khi tôi pull toàn bộ dữ liệu giao dịch của một tổ chức lớn trong đợt sụp đổ FTX, tôi nhận ra rằng các lệnh phê duyệt không an toàn thường xuất hiện vào cuối phiên làm việc — sau hàng giờ xử lý liên tục. Thời gian, không phải ý định, mới là biến số quyết định.
Vì sao một bộ phân loại độc lập lại vượt trội
Bộ phân loại độc lập của Claude Code không được huấn luyện để đưa ra câu trả lời hữu ích. Nó được huấn luyện để trả lời một câu hỏi duy nhất: lệnh này có nguy hiểm không? Mọi mục tiêu khác — hiệu suất, tính hữu ích, tốc độ, sự thuận tiện — đều bị loại bỏ khỏi quá trình tối ưu hóa của nó. Điều này tạo ra một sự khác biệt về cấu trúc mà con người khó lòng đạt được: trong khi một kỹ sư duyệt lệnh phải đồng thời xử lý mục tiêu "hoàn thành công việc" và mục tiêu "đảm bảo an toàn", classifier chỉ có một mục tiêu duy nhất.
Nguyên tắc này gợi nhớ đến kiến trúc tách rời mà blockchain sử dụng giữa các validator và các nút giao tiếp. Một validator không nên kiểm tra khối của chính nó; một nút không nên chia sẻ trạng thái bộ nhớ với một nút khác khi có sự khác biệt về ưu tiên. Trong DeFi, các giao thức triển khai mô hình multi-sig hoặc timelock nên tách biệt hoàn toàn logic xác nhận khỏi logic thực thi. Nhiều giao thức làm điều này — nhưng hiếm khi họ định lượng được hiệu quả của từng lớp.
Con số 89% mà Anthropic công bố không phải là một thành tựu công nghệ — nó là một chỉ báo kiến trúc: khi bạn tách mục tiêu an toàn khỏi mục tiêu hiệu suất, bạn đạt được kết quả tốt hơn. Đây không phải là một phát hiện mới về AI; đây là một sự khẳng định về nguyên lý tách biệt mà ngành blockchain đã tuyên bố theo đuổi nhưng chưa bao giờ áp dụng triệt để.
Cơ chế "mặc định cho phép" và trò chơi phủ quyết
Một chi tiết kỹ thuật đáng chú ý: trong khi chế độ thủ công yêu cầu con người phê duyệt từng lệnh trước khi thực thi, chế độ tự động cho phép mô hình chính thực thi lệnh, sau đó classifier sẽ xem xét theo cơ chế đồng bộ. Điều này có nghĩa là quyết định cuối cùng không đến từ sự đồng ý của con người, mà từ sự không phản đối của một hệ thống khác.
Đây chính là mô hình "default allow with dynamic revocation" — mặc định cho phép, thu hồi động — mà các hệ thống zero-trust theo đuổi trong nhiều năm. Khác biệt là ở đây, khả năng phủ quyết được giao cho một mô hình xác suất chứ không phải một danh sách quy tắc tĩnh. Một mô hình xác suất có thể thay đổi quyết định dựa trên ngữ cảnh, trong khi một danh sách quy tắc chỉ đúng hoặc sai. Điều này tạo ra một lớp linh hoạt chưa từng có: hệ thống xử lý được những tình huống chưa được định nghĩa trước bằng cách suy luận từ tương tự.
Tuy nhiên, sự linh hoạt đó cũng chính là điểm yếu tiềm tàng. Một hệ thống zero-trust dựa trên quy tắc có thể được kiểm chứng; một hệ thống dựa trên xác suất thì khó. Câu hỏi đặt ra cho các kiến trúc sư bảo mật: liệu bạn có sẵn sàng giao quyền phủ quyết cho một hệ thống mà chính bạn không thể giải thích đầy đủ lý do quyết định của nó?
Câu chuyện thống trị chu kỳ này sẽ là câu chuyện về việc con người chấp nhận giao quyền quyết định cho các hệ thống xác suất — không phải vì họ tin tưởng, mà vì họ nhận ra rằng sự chú ý của họ không đáng tin cậy. Điều này có ý nghĩa to lớn với blockchain: các hợp đồng thông minh, vốn được ca ngợi vì tính minh bạch và tuyệt đối, sẽ phải học cách tích hợp các lớp quyết định xác suất ngay trong quy trình thực thi của mình.
Định lượng rủi ro: 89% không phải là con số tuyệt đối
Khi một hệ thống bảo mật được quảng bá bằng một con số ấn tượng, một hiệu ứng tâm lý nguy hiểm diễn ra: sự tin tưởng thái quá. Cảm giác an toàn khi biết rằng 89% các mối đe dọa sẽ bị chặn khiến người dùng chấp nhận rủi ro cao hơn trong 11% còn lại — hay tệ hơn, khiến họ coi nhẹ các tín hiệu cảnh báo khác vì tin rằng hệ thống đã lo phần nguy hiểm.
Tôi từng viết rất nhiều về mối quan hệ giữa APY và TVL trong liquidity mining: những con số lợi nhuận hấp dẫn thường tồn tại để bù đắp cho sự vắng mặt của người dùng thực, và khi incentive dừng, người dùng thực cũng biến mất. Một tỷ lệ phát hiện 89% cũng mang cùng một mô thức: nó là một ưu đãi — một lời hứa an toàn — được dùng để làm giảm bớt sự cần thiết của việc kiểm tra thủ công. Nhưng toàn bộ giá trị của lời hứa đó nằm ở việc 11% kia nằm ở đâu, và kẻ tấn công sẽ học cách diễn đạt mục tiêu của mình để nằm gọn trong phần không được bao phủ.
Một bộ phân loại được huấn luyện trên các mẫu lệnh nguy hiểm đã biết sẽ giỏi phát hiện các biến thể của những mẫu đó. Nó không giỏi trong việc phát hiện các mô thức chưa từng xuất hiện — giống như một trình quét lỗ hổng chỉ tìm được những lỗ hổng đã có trong cơ sở dữ liệu. Đây là lý do vì sao, trong dài hạn, các hệ thống dựa trên xác suất cần liên tục được huấn luyện lại dựa trên dữ liệu từ thực tế tấn công — một vòng lặp mà các giao thức DeFi không có khả năng duy trì do nhịp độ phát triển nhanh và nguồn lực giám sát hạn chế.
Trách nhiệm trong một thế giới quyết định tự động
Đây là khía cạnh mà hiếm ai đặt câu hỏi khi bàn về sự thay đổi của Anthropic: trách nhiệm sẽ thuộc về ai khi một lệnh nguy hiểm vượt qua bộ lọc và gây thiệt hại?
Trong mô hình phê duyệt thủ công, có một cá nhân cụ thể gánh chịu hậu quả pháp lý. Trong mô hình tự động, không ai ký vào quyết định. Có AI đưa ra lệnh, có classifier xem xét, nhưng không có ý chí con người can thiệp trực tiếp tại điểm quyết định. Trong blockchain, chúng ta đã đối mặt với cùng một vấn đề: khi một hợp đồng thông minh bị khai thác gây thiệt hại hàng chục triệu đô la, không một dòng mã nào bị xóa, không một ai bị xử lý. Cộng đồng tự an ủi bằng cách quy kết trách nhiệm cho "mã nguồn". Nhưng mã nguồn không phải là một chủ thể. Người ta không thể kiện một thuật toán.
Khi tôi theo dõi vụ sụp đổ của một trong những nền tảng cho vay lớn nhất lịch sử, tôi nhận ra rằng phần lớn thiệt hại không đến từ một lỗ hổng mã nguồn phức tạp, mà đến từ một chuỗi các quyết định — mỗi quyết định đều được con người phê duyệt với niềm tin rằng người khác cũng đã kiểm tra. Sự phân tán trách nhiệm, không phải kỹ thuật, là kẻ giết người thầm lặng. Nếu chúng ta chuyển sang mô hình tự động mà không giải quyết bài toán trách nhiệm, chúng ta chỉ đang quy cho các thuật toán một sự minh bạch mà chúng không có.
Từ lệnh Shell đến smart contract: một ranh giới đang mờ đi
Có một lý do khiến sự kiện của Claude Code đáng được cộng đồng blockchain theo dõi sát sao: nó cho thấy khoảng cách giữa việc quản lý một AI agent và việc quản lý một giao thức tài chính phi tập trung đang thu hẹp nhanh chóng. Khi một AI agent có thể tự đưa ra lệnh gọi một hợp đồng thông minh, câu hỏi "ai phê duyệt lệnh Shell" trở thành câu hỏi "ai phê duyệt lệnh chuyển tiền".
Tôi đã dành nhiều năm bảo vệ lập trường rằng Layer2 hiện tại không phải là scaling mà là cắt nhỏ thanh khoản vốn khan hiếm — một lập trường thường bị chỉ trích là tiêu cực. Nhưng điều khiến tôi kiên định với lập trường đó là một sự thật kỹ thuật: khi bạn phân tán thanh khoản trên nhiều chuỗi có cùng đặc tính kỹ thuật, bạn tạo ra các điểm yếu giống hệt nhau ở nhiều nơi hơn, làm tăng bề mặt tấn công toàn hệ thống. Tương tự, khi bạn trao quyền quyết định cho các AI agents trên nhiều môi trường — mà không có một cơ chế phê duyệt thống nhất, độc lập và được giám sát — bạn đang nhân bản các lỗ hổng ra khắp hạ tầng. Câu chuyện "omnichain app" được các quỹ đầu tư mạo hiểm sản xuất như một narrative hấp dẫn, nhưng người dùng cuối không quan tâm hợp đồng của bạn triển khai trên bao nhiêu chain; họ chỉ quan tâm tài sản của họ có an toàn khi một AI agent thực thi lệnh.
Bài học từ con số 14% là: nếu một mô hình phê duyệt thủ công không hiệu quả với những lệnh Shell trong một môi trường lập trình, hãy tưởng tượng mức độ tàn phá của nó khi được áp dụng cho các giao dịch tài sản số với giá trị lên đến hàng triệu đô la. Sự thay đổi về quy mô không chỉ là về số lượng — nó làm thay đổi bản chất của rủi ro.
Một thí nghiệm tâm lý mang tên 14%
Tôi muốn dừng lại một chút về con số 14%. Trong các bài kiểm tra bảo mật thông thường, tỷ lệ phát hiện của một người duyệt lệnh bình thường dao động từ 60% đến 90%. Vậy tại sao con số của Anthropic lại thấp đến vậy? Câu trả lời nằm ở cách thử nghiệm được thiết kế: không phải đo khả năng nhận biết, mà là đo khả năng duy trì sự nhận biết trong suốt một phiên làm việc dài.
Con người có một điểm yếu cấu trúc: sự chú ý của họ không phải là một hằng số. Nó suy giảm theo thời gian, bị ảnh hưởng bởi sự mệt mỏi, bởi những phiền nhiễu, và bởi chính những lần phê duyệt thành công trước đó. Một người đã phê duyệt 100 lệnh an toàn liên tiếp sẽ bắt đầu tin rằng lệnh thứ 101 cũng an toàn — không phải vì họ phân tích, mà vì họ đã quen.
Đây là lý do vì sao các cuộc tấn công tinh vi thường thử nghiệm hệ thống bằng những lệnh vô hại trước. Chúng giống như những nghệ sĩ lừa đảo kiểm tra xem người gác cổng có ngủ quên hay không. Khi người gác cổng phê duyệt một lệnh trong trạng thái mệt mỏi, kẻ tấn công biết rằng cánh cửa đã mở — không chỉ cho lần này, mà cho cả những lần sau.
Bộ phân loại của Claude Code, bằng cách loại bỏ yếu tố mệt mỏi, đã vô hiệu hóa một trong những công cụ tấn công mạnh nhất: sự kiệt sức của con người. Nhưng nó chỉ vô hiệu hóa được khía cạnh thời gian thực; nó không vô hiệu hóa được khía cạnh chiến lược, nơi kẻ tấn công có thể dành hàng tháng để nghiên cứu hành vi của classifier và tìm ra những cách diễn đạt nằm ngoài phạm vi phát hiện.
Kinh nghiệm từ một đợt rút tiền hỗn loạn
Tháng 11 năm 2022. Khi FTX bắt đầu có dấu hiệu sụp đổ, tôi đã pull toàn bộ dữ liệu giao dịch rút tiền của sàn và quan sát từng đợt biến động. Trong vòng vài giờ, tôi nhận diện được 137 mô hình rút tiền khác nhau. Điều đáng chú ý không phải là số lượng, mà là tốc độ phê duyệt. Khi tin đồn về khả năng mất thanh khoản lan ra, các lệnh bắt đầu được phê duyệt nhanh hơn, không đồng đều hơn, và ít kiểm tra hơn. Người vận hành hệ thống — vốn được đào tạo để bình tĩnh trong khủng hoảng — đã hành động theo một cách rất con người: họ cố gắng cứu lấy những gì có thể cứu được, và trong quá trình đó, họ vô tình phê duyệt những lệnh đáng lẽ phải bị dừng lại.
Bài học quản lý rủi ro tôi học được một cách đắt giá từ ngày hôm đó: trong khủng hoảng, quy trình không cứu bạn. Kiến trúc cứu bạn. Nếu mỗi lệnh rút tiền trong đợt đó được xử lý bởi một hệ thống độc lập — không vội vàng, không sợ hãi, không cảm nhận được áp lực của thị trường — thì dòng tiền chảy ra có thể đã được kiểm soát. Nhưng không. Chúng ta tin con người xứng đáng được tin tưởng vì họ có lý trí, mà quên rằng lý trí là thứ biến mất đầu tiên khi sự sống còn bị đe dọa.
Điều này không có nghĩa là tôi cổ vũ loại bỏ con người khỏi mọi quy trình. Nó có nghĩa là con người cần được đặt lại ở một vị trí khác: vị trí xác định chính sách, thiết lập ngưỡng, và phán quyết các ngoại lệ — chứ không phải vị trí đứng giữa một luồng lệnh vô tận, nơi sự chú ý của họ cạn kiệt nhanh hơn họ tưởng.
Tuy nhiên, cần nói thẳng: chuyển sang tự động hóa không phải là một nâng cấp tuyến tính, và việc coi 89% như một thành công là một hiểu lầm nguy hiểm. Trong hệ thống tài chính, tỷ lệ phát hiện 89% có thể tệ hơn 14% — vì nó tạo ra cảm giác an toàn giả tạo làm suy yếu sự cảnh giác. Một bộ phân loại độc lập có thể bị đánh lừa bởi những mô thức tấn công nằm ngoài dữ liệu huấn luyện. Điều này cũng giống như một hệ thống quét lỗ hổng blockchain chỉ tìm được những gì nó đã biết, không tìm được những gì chưa từng xảy ra.
Điều trớ trêu nằm ở chỗ: trong khi mô hình thủ công yếu vì lệ thuộc vào sự chú ý của con người, mô hình tự động yếu vì lệ thuộc vào dữ liệu huấn luyện của con người. Cả hai đều thiếu thứ duy nhất cần thiết để đối phó với những mối đe dọa chưa từng tồn tại: trực giác. Nhưng trực giác, đến lượt nó, lại là thứ không thể duy trì được khi mệt mỏi.
Trong một cuộc khủng hoảng thanh khoản, khi làn sóng thanh lý ập đến và các lệnh được xử lý đồng loạt, AI agents sẽ không hoảng sợ — nhưng chúng cũng sẽ không biết đặt câu hỏi về những giả định đã được mã hóa trong thuật toán của chúng. Chúng sẽ thực thi trung thành những gì được lập trình, ngay cả khi điều đó làm trầm trọng thêm cơn khủng hoảng. Con người ít trung thành hơn, nhưng cũng nhiều sáng tạo hơn. Và trong những khoảnh khắc hệ thống sụp đổ, thứ đáng giá nhất không phải là sự tuân thủ — mà là sự không tuân thủ sáng tạo.
Câu hỏi vì thế không nên là "mô hình nào phát hiện tốt hơn" — mà là: mô hình nào, khi mọi thứ sai, vẫn còn khả năng suy nghĩ?
Nếu con số 89% khiến bạn an tâm, hãy dành một phút để hỏi ngược lại: 11% còn lại nằm ở đâu? Trong một hệ thống quản lý tài sản số, câu trả lời cho câu hỏi đó không phải là một thống kê — đó là một danh sách dài những thất bại mà chúng ta chưa từng biết tên. Mô hình bảo mật của tương lai sẽ không được đánh giá bằng tỷ lệ phát hiện trung bình, mà bằng khả năng xử lý các trường hợp ngoại lệ. Và trong những trường hợp đó, vai trò của con người — biết đặt câu hỏi, biết nghi ngờ chính công cụ của mình — vẫn không thể thay thế. Nhưng nó phải được đặt đúng chỗ: không phải ở giữa luồng lệnh, mà ở tầng chiến lược, nơi quyết định hệ thống nên tin ai và tin đến mức nào.