Mở thách thức bảo mật AI: Pipelock công bố điểm chuẩn và mời cộng đồng tham gia

Vào tháng 3 năm nay, tôi đã phát hành agent-egress-bench, một bộ dữ liệu kiểm thử dùng để đánh giá các công cụ bảo mật hoạt động giữa các tác nhân AI (AI agents) và mạng lưới internet. Lúc bấy giờ, bộ dữ liệu chỉ bao gồm 72 trường hợp. Ý tưởng rất đơn giản: nếu công cụ của bạn tuyên bố có khả năng bắt được hành vi trích xuất trái phép thông tin đăng nhập (credential exfiltration), hãy chứng minh điều đó trên một tập hợp các cuộc tấn công chia sẻ chung.

Hiện tại, bộ dữ liệu đó đã phát triển lên 151 trường hợp trải rộng trên 17 danh mục. Và quan trọng hơn, giờ đây đã có một bảng xếp hạng công khai.

Thử thách bảo mật

Tại địa chỉ pipelab.org/gauntlet, bạn có thể xem kết quả đánh giá chuẩn (benchmark) của bất kỳ công cụ nào chạy bộ kiểm thử này và gửi lên điểm số. Hiện tại, chỉ có Pipelock xuất hiện trên bảng xếp hạng vì chưa có ai khác gửi kết quả. Đó chính là lý do tôi viết bài này.

Các điểm số được chia nhỏ thành 4 chỉ số cho mỗi danh mục:

Containment (Khả năng ngăn chặn) là chỉ số quan trọng nhất. Nó đo lường phần trăm các cuộc tấn công mà công cụ thực sự chặn được. Không phải chỉ phát hiện, không phải ghi log, cũng không phải gắn cờ để xem xét lại, mà là chặn hoàn toàn. Nếu một thông tin đăng nhập rời khỏi mạng lưới, khả năng ngăn chặn được coi là thất bại.

False positive rate (Tỷ lệ dương tính giả) đo lường tần suất công cụ chặn nhầm lưu lượng truy cập sạch. Một công cụ chặn mọi thứ sẽ đạt 100% khả năng ngăn chặn nhưng có tỷ lệ dương tính giả vô dụng. Cả hai số liệu này đều quan trọng.

Detection (Phát hiện) và Evidence (Bằng chứng) đo lường xem công cụ có xác định được loại tấn công mà nó đã dừng lại hay không và có tạo ra bằng chứng có cấu trúc hay không. Một công cụ có thể chặn cuộc tấn công mà không cần biết trình quét nào đã bắt được nó, và không cần tạo ra phát hiện có thể đọc được bằng máy. Khả năng ngăn chặn chỉ là điều kiện cơ bản. Phát hiện và bằng chứng mới là yếu tố giúp quá trình chặn có thể kiểm toán được.

Nội dung của 151 trường hợp kiểm thử

Bộ dữ liệu này bao gồm bề mặt tấn công nằm giữa tác nhân AI và mạng lưới. Không phải hành vi của mô hình (model behavior), không phải chất lượng của prompt (prompt quality), mà là kết nối mạng (the wire).

Nó bao gồm các mảng như: DLP URL, DLP nội dung yêu cầu (request body), DLP tiêu đề (header). Tiêm lệnh prompt (prompt injection) trong nội dung được lấy về và trong phản hồi bị chặn bởi TLS. Quét đầu vào MCP, đầu độc công cụ (tool poisoning), phát hiện chuỗi (chain detection). Quét tin nhắn A2A và đầu độc Agent Card. DLP qua WebSocket. Kỹ thuật vượt qua SSRF. Tránh né bằng mã hóa đa lớp. Làm rối mã lệnh shell (shell obfuscation). Phát hiện thông tin đăng nhập tiền điện tử và tài chính. Và một bộ dương tính giả gồm 37 trường hợp lành mạnh không được phép chặn.

Mỗi trường hợp là một tệp JSON khép kín chứa tải trọng (payload), phán quyết mong đợi, mức độ nghiêm trọng và giải thích có thể đọc được bằng máy về lý do. Không bị phụ thuộc vào nhà cung cấp (vendor lock-in). Bộ chạy (runner) chỉ là vài trăm dòng ngôn ngữ Go với độ phụ bằng 0 ngoài thư viện chuẩn.

Pipelock đạt điểm số như thế nào

Phiên bản Pipelock v2.1.2 chạy trên toàn bộ bộ dữ liệu: đạt 96,2% khả năng ngăn chặn trên các trường hợp áp dụng, và 89,4% trên toàn bộ bộ dữ liệu, với 0% tỷ lệ dương tính giả. Trong số 151 trường hợp, có 142 trường hợp áp dụng. 9 trường hợp không áp dụng yêu cầu thiết bị kiểm tra liên kết lại DNS (DNS rebinding), điều không khả thi trong các lần chạy tự động.

Hầu hết các danh mục đều đạt 100%. Hai danh mục không đạt, và tôi biết chính xác lý do tại sao.

Request body ở mức 50%: API quét chưa thực hiện giải mã base64/đa phần (multipart) đệ quy. Bốn trường hợp bị bỏ lỡ vì bí mật được mã hóa kép trong nội dung multipart và trình quét chỉ bóc được lớp đầu tiên.

Headers ở mức 80%: một trường hợp token SendGrid sử dụng định dạng mà mẫu DLP header chưa khớp.

Cả hai đều đã được đưa vào hàng đợi sửa đổi. Tôi lựa chọn phát hành phiên bản này với các lỗ hổng đó hiển thị thay vì che giấu chúng.

Bạn cũng sẽ thấy một số cột phát hiện/bằng chứng ở mức 0% cho response_fetch, ssrf_bypass và url (ở mức 72,7%). Đó là những danh mục mà Pipelock chặn chính xác nhưng điểm cuối lấy về (fetch endpoint) trả về fetch_blocked mà không có nhãn thuộc tính của trình quét. Việc chặn hoạt động tốt. Bằng chứng có cấu trúc về "cái gì đã bắt được nó" thì chưa có. Tính năng này cũng đang trong hàng đợi.

Không có gì bị thụt lùi. Đây là những khoảng trống đã biết mà tôi cố tình chọn để lại không gian. Công bố điểm số cũng đồng nghĩa với việc công bố cả những điểm yếu.

Tôi đưa ra các con số này vì tôi nghĩ rằng các công cụ bảo mật nên chứng minh chúng hoạt động hiệu quả với thứ gì đó khác ngoài bộ kiểm thử nội bộ của chính mình. Các bài kiểm tra nội bộ chỉ là mức sàn, không phải mức trần.

Cách gửi kết quả của bạn

Hãy xây dựng bộ chạy, hướng nó tới hồ sơ công cụ của bạn, và chạy nó:

git clone https://github.com/luckyPipewrench/agent-egress-bench.git
cd agent-egress-bench/runner
go build -o aeb-gauntlet .
./aeb-gauntlet --cases ../cases --profile your-tool-profile.json --output results.json

Hồ sơ sẽ cho bộ chạy biết công cụ của bạn hỗ trợ những gì (các phương thức vận chuyển, khả năng nào) để nó chỉ chấm điểm các trường hợp áp dụng. Gửi kết quả của bạn tại pipelab.org/gauntlet/submit hoặc mở một cuộc thảo luận trên GitHub.

Tài liệu phương pháp (methodology docs) giải thích chi tiết về cách chấm điểm. Hướng dẫn áp dụng (adoption guide) sẽ hướng dẫn bạn cách xây dựng bộ chạy cho công cụ của mình.

Tại sao điều này quan trọng

Mọi công cụ trong lĩnh vực này đều nói rằng họ ngăn chặn rò rỉ thông tin đăng nhập. Hầu hết họ đều cho thấy một bản demo nơi họ bắt được chuỗi AKIA trong một URL. Đó là trường hợp dễ dàng.

Nhưng điều gì sẽ xảy ra khi khóa được mã hóa base64 trong nội dung POST? Khi nó bị chia nhỏ thành năm yêu cầu? Khi nó được mã hóa hex bên trong một đối số công cụ lồng nhau ba cấp sâu trong một cuộc gọi JSON-RPC? Khi đường dẫn trích xuất là một mảnh khung WebSocket?

Đó là những trường hợp phân biệt một công cụ bảo mật thực thụ với một bản demo hời hợt. Thử thách này kiểm tra tất cả chúng dựa trên một bộ dữ liệu chung để bạn có thể so sánh công bằng trên cùng một tiêu chuẩn (so sánh táo với táo).

Nếu công cụ của bạn tốt, điểm số sẽ chứng minh điều đó. Nếu không, bạn sẽ biết chính xác các danh mục nào cần cải thiện. Dù bằng cách nào, dữ liệu đều công khai.

Xem thử thách hoặc gửi kết quả của bạn ngay.