Khi tôi mở báo cáo SADF công bố tại DEF CON 34, con số đầu tiên khiến tôi dừng lại không phải là 5.119 dòng đánh giá, cũng không phải 8 kiểu tấn công được phân loại. Mà là khoảng cách 2,6 lần giữa hai framework: CrewAI đạt tỉ lệ hoàn thành tấn công 11,9%, trong khi SmolAgents lên tới 31,1%. Cùng một model nền – Claude Sonnet – cùng một bộ kịch bản mô phỏng, nhưng kết quả khác nhau đến vậy. Tôi nhận ra rằng, với AI agent, chọn framework có thể quan trọng hơn chọn model.
Bạn có bao giờ nghĩ rằng việc chọn framework để xây dựng một AI agent quan trọng hơn việc chọn model? Tôi đã từng nghĩ ngược lại. Sau nhiều năm phân tích các giao thức DeFi, tôi quen với việc săn tìm lỗ hổng trong hợp đồng thông minh – nơi mọi thứ có thể kiểm chứng. Nhưng với AI agent, câu chuyện khác hẳn. Agent không chỉ là code; nó là một vòng lặp quyết định được nối với các công cụ bên ngoài, và mỗi nút nối đều có thể bị chèn ép. Trong Web3, những nút nối này ngày càng được dùng để ký giao dịch, quản lý thanh khoản và điều phối bot giao dịch.
SADF – tên đầy đủ là Security Assessment of Agentic Frameworks – là nghiên cứu của nhóm tác giả Julie Brunias, được trình bày trong khuôn khổ AI Village tại DEF CON 34. Thay vì hỏi 'model nào an toàn?', nhóm nghiên cứu đặt một câu hỏi khác: 'Khi chúng ta đặt một model vào bên trong một framework orchestration như LangChain, AutoGen, CrewAI hay SmolAgents, thì framework đó đang mở ra bao nhiêu cánh cửa cho kẻ tấn công?' Câu hỏi này đặc biệt quan trọng với Web3, nơi ngày càng nhiều giao thức dùng AI agent để quản lý kho quỹ, tự động hóa giao dịch hoặc điều phối bot. Một agent có thể đọc ví, ký giao dịch, tương tác với hợp đồng thông minh. Nếu kẻ tấn công chiếm được agent, tài sản người dùng coi như mất.
Thiết kế thí nghiệm của SADF rất rõ ràng. Họ cố định model nền là Claude Sonnet, sử dụng một nhóm đối chứng gọi là Direct API – tức là không thông qua framework nào – và đặt nó cạnh bốn framework phổ biến. Tất cả được thả vào một môi trường công cụ mô phỏng, nơi các lời gọi API và tương tác hệ thống đều giả lập. Điều này giúp cô lập biến số: nếu có khác biệt về tỉ lệ tấn công, thì nguyên nhân phải nằm ở lớp framework. Đây là một bước đi đúng đắn về mặt phương pháp, bởi vì nó tránh được lỗi quy hồi quy cho model.
Kết quả là một bảng xếp hạng bất ngờ: Direct API đạt 15,5% Attack Completion Rate – tức tỉ lệ kẻ tấn công hoàn thành mục tiêu thành công. CrewAI thấp hơn cả đối chứng với 11,9%, nhờ kiến trúc cô lập tác vụ rời rạc. LangChain là 18,1%. AutoGen là 20,0%. Và SmolAgents gây lo ngại lớn nhất với 31,1%. Bảng xếp hạng này cần được đọc cùng với bối cảnh. CrewAI không phải là 'bất khả chiến bại'; nó có thể chỉ là framework mà các cuộc tấn công trong bộ dữ liệu chưa được tối ưu hóa. Nhưng trong giới hạn bộ dữ liệu, nó cho thấy kiến trúc cô lập tác vụ có thể giảm thiểu rủi ro leo thang. Ngược lại, SmolAgents với thiết kế tối giản, tự do lại đẩy trách nhiệm bảo mật lên vai nhà phát triển – và đó là một lựa chọn thiết kế, không phải một lỗi lập trình.
Nhưng khoảng cách 2,6 lần không phải là con số duy nhất đáng chú ý. Điều thú vị hơn là cách nhóm nghiên cứu phát hiện ra sai lệch trong phương pháp đánh giá cũ. Khi dùng phép so khớp chuỗi con đơn giản – một kỹ thuật phổ biến để xác định xem model có bị tấn công hay không – họ thấy Claude bị điểm rủi ro cao hơn thực tế từ 4 đến 6 lần. Nguyên nhân là model từ chối trả lời theo cách khác với kịch bản kỳ vọng, khiến bộ kiểm tra hiểu nhầm thành thành công. Sau khi áp dụng bộ lọc refusal – tức chỉ tính những phản hồi không phải dạng từ chối – điểm của Claude Sonnet rơi từ mức bị thổi phồng xuống còn 15,5%. Claude Haiku, model nhỏ hơn, cũng được ghi nhận ở mức 22,3%.
Đây chính là điểm mù. Hầu hết các bài đánh giá AI hiện nay đều dùng phép so khớp đơn giản để chấm điểm. Nếu chính công cụ chấm điểm bị lệch, thì mọi xếp hạng model an toàn mà chúng ta đọc trong quảng cáo đều có thể là ảo. Điều này giống với việc dùng TVL làm thước đo sức khỏe của một giao thức DeFi; nó chỉ đúng khi không ai khai thác nó. Một giao thức có thể có TVL hàng tỷ đô la, nhưng nếu một lỗi trong oracle cho phép kẻ tấn công rút sạch thanh khoản, thì TVL chỉ là con số trang trí. Tương tự, một model có thể đạt điểm an toàn cao trong bài kiểm tra, nhưng khi đặt trong một framework với quyền truy cập công cụ rộng mở, con số đó trở nên vô nghĩa.
Ngoài tỉ lệ tấn công, SADF còn đóng góp một bộ từ vựng chung cho ngành. Họ mô tả 8 kiểu thất bại, bao gồm Tool Call Hijacking – kẻ tấn công chiếm quyền điều khiển lời gọi công cụ; Output Poisoning – đầu ra bị nhiễm độc để đánh lừa các agent khác; Memory Poisoning – tiêm dữ liệu xấu vào bộ nhớ dài hạn của agent; RAG Poisoning – đầu độc kho tri thức dùng trong quá trình truy hồi; và Context Boundary Violation – vượt qua ranh giới ngữ cảnh của một tác vụ. Việc có một bộ từ vựng thống nhất không phải chuyện nhỏ. Khi các nhà nghiên cứu và kỹ sư nói cùng một ngôn ngữ, các lỗ hổng có thể được phát hiện sớm hơn, giống như cách danh sách CWE đã giúp ngành bảo mật phần mềm truyền thống.
Trong đó, SmolAgents không chỉ dẫn đầu về ACR mà còn có các vấn đề riêng: RAG Poisoning đạt 20% và Context Boundary Violation lên tới 64%. Con số 64% nói lên rằng framework được thiết kế linh hoạt nhưng lại không kiểm soát được ranh giới giữa các ngữ cảnh, cho phép dữ liệu từ một tác vụ tràn sang tác vụ khác. Trong một sàn giao dịch phi tập trung, điều đó giống như một lệnh hoán đổi bị rò rỉ thông tin sang một lệnh khác. Nếu agent của một nhà tạo lập thị trường đang xử lý lệnh mua và bị một kẻ tấn công tiêm nội dung vào bộ nhớ của một tác vụ khác, thì toàn bộ chiến lược giao dịch có thể bị thao túng.
Một điều làm tăng độ tin cậy của nghiên cứu là sự tồn tại của các CVE thực tế. Azure SRE Agent (CVE-2026-62830) và Langflow (CVE-2026-9198) chứng minh rằng lỗ hổng framework không còn là lý thuyết. Với một nhà nghiên cứu DeFi, những mã định danh CVE như vậy tương tự như một vụ hack cầu nối được ghi nhận – nó chuyển cảnh báo từ sách vở thành hiện thực. Các công ty bảo mật lớn có thể sẽ biến phương pháp của SADF thành một dịch vụ đánh giá định kỳ, tích hợp vào CI/CD pipeline, biến một bài nghiên cứu thành nguồn doanh thu. Điều này có thể dẫn đến một thị trường mới: Security-Evaluation-as-a-Service cho AI agent.
Những gì SADF làm được không chỉ là một bảng điểm. Nó thay đổi cách chúng ta đặt câu hỏi. Trước đây, khi một dự án crypto nói 'agent của chúng tôi an toàn', họ thường đưa ra benchmark trên các bài kiểm tra model như MMLU hay HELM. Nhưng những benchmark đó không bao gồm kịch bản kẻ tấn công chủ động tiêm prompt vào bộ nhớ dài hạn hoặc thao túng công cụ. SADF cho thấy rằng sự an toàn của một hệ thống AI nằm ở cách hệ thống đó được lắp ráp, không phải ở bộ não bên trong. Điều này giống với lời khuyên mà tôi vẫn dành cho các đội ngũ DeFi: đừng khoe rằng hợp đồng thông minh của bạn đã được audit; hãy chứng minh rằng bạn biết ai có thể làm gì trong hệ thống của bạn.
Tuy nhiên, nghiên cứu vẫn còn những hạn chế. Tổng cộng chỉ có 32 payload được sử dụng, dù được trải rộng trên 5.119 dòng đánh giá. Các bài kiểm tra diễn ra trong môi trường mô phỏng, nên các biến số thực tế như độ trễ phản hồi, quyền hạn thực và cạnh tranh tài nguyên chưa được khai thác. Quan trọng hơn, mọi kết quả đều dựa trên một model duy nhất là Claude Sonnet. Nếu chuyển sang GPT-5.4, DeepSeek hay Llama, bảng xếp hạng này có thể thay đổi. Ngoài ra, nghiên cứu tuyên bố bao phủ 8 kiến trúc, nhưng chỉ công bố dữ liệu đầy đủ cho 5 mục tiêu; điều đó có nghĩa là một phần bức tranh vẫn chưa được phơi bày.
Dựa trên kinh nghiệm đánh giá bảo mật của tôi, tôi tin rằng sự tương tác giữa model và framework là một biến số chưa được giải mã. Một framework có thể có kiến trúc tốt, nhưng nếu model nền quá 'dễ tính' trong việc làm theo các hướng dẫn xung đột, thì kết quả vẫn có thể tệ. SADF đã mở ra hướng nghiên cứu, nhưng chưa trả lời câu hỏi. Cần có thêm những thí nghiệm hoán đổi model trên cùng một framework để xác định mức độ ảnh hưởng chéo.
Giới đầu tư và một phần báo chí có thể sẽ đọc báo cáo này như một bảng xếp hạng để chọn framework. Nhưng đó là cách đọc hời hợt. Nếu nhìn kỹ, tin tốt không phải là CrewAI an toàn hơn SmolAgents; tin tốt là vấn đề an toàn của agent cuối cùng cũng có thể đo lường được. Trong thị trường giảm, khi mọi người đều sợ hãi, các dự án có thể dùng con số ACR để gây dựng niềm tin. Nhưng hãy nhớ rằng một phép đo trong phòng thí nghiệm không phải là một hệ thống phòng thủ sản xuất.
Điều phản trực giác ở đây là: sự khác biệt giữa các framework có thể chỉ phản ánh cách họ cấu hình mặc định, chứ không phải giới hạn về kiến trúc. Một framework có thể được tinh chỉnh để chặn tấn công, nhưng nếu nhà phát triển cần tốc độ, họ sẽ mở quyền rộng hơn. Vậy nên, đổ lỗi cho framework cũng giống như đổ lỗi cho một chiếc két sắt vì người dùng dán mã PIN lên nắp.
Điểm mù thứ hai nằm ở chính câu chuyện truyền thông. Một báo cáo bảo mật kỹ thuật như SADF lại được phát tán rộng rãi trên các kênh tin tức blockchain. Điều đó cho thấy 'bảo mật AI' đang trở thành một narrative – một câu chuyện có thể bán được. Trong ngành của tôi, khi một câu chuyện bắt đầu được bán, nó cũng bắt đầu bị lạm dụng. Hãy cẩn thận với những ai dùng SADF như một 'chứng chỉ an toàn' cho riêng sản phẩm của họ, bởi vì nghiên cứu này chỉ ra bề mặt tấn công, không phải là sự bảo đảm chống lại mọi mối đe dọa.
Vậy nên, trước khi lựa chọn một framework cho agent của mình, hãy đặt câu hỏi đúng: bạn có kiểm soát được các quyền hạn mà agent có thể chạm tới không? Bạn có giới hạn được phạm vi ngữ cảnh giữa các tác vụ không? Câu trả lời không nằm trong bảng xếp hạng ACR, mà nằm trong kiến trúc bạn xây dựng. Mô hình có thể thông minh, nhưng framework mới là nơi kẻ tấn công đang đứng.
Trong một thị trường mà sự sống còn quan trọng hơn lợi nhuận, tài sản an toàn không đến từ việc chọn model mạnh nhất. Nó đến từ việc biết chính xác bề mặt tấn công của bạn nằm ở đâu. SADF đã cho chúng ta một tấm bản đồ. Phần còn lại là hành động của bạn.