Thử nghiệm trên 40.000 lượt chơi: Con người bỏ lỡ 1/3 lệnh độc hại từ AI

Vài tháng trước, tôi đã phát hành một trò chơi nhỏ trên trình duyệt: bạn đóng vai trò "human-in-the-loop" (con người trong vòng lặp) cho một AI coding agent, thực hiện phê duyệt hoặc từ chối các lệnh của nó dưới áp lực thời gian. Một số lệnh là thông thường (git status, npm test) và một số lệnh khác cho thấy agent của bạn đã bị chiếm quyền điều khiển và đang gửi các thông tin bí mật của bạn đến một máy chủ từ xa (cat ~/.aws/credentials). Thông tin chi tiết hơn về các mối đe dọa liên quan đến việc agent chạy lệnh và cách giảm thiểu chúng có thể được tìm thấy trong bài viết gốc.

Trò chơi đã thu hút được sự quan tâm trên Hacker News, và sau khi thêm vào các số liệu thống kê (thật không may là hơi muộn), chúng ta có thể xem xét kỹ hơn dữ liệu từ hơn 40.000 lượt chơi và 409.000 quyết định phê duyệt/từ chối riêng lẻ. Hãy cùng xem "human-in-the-loop", tuyến phòng thủ cuối cùng của chúng ta trước các agent độc hại, đã thể hiện như thế nào.

Các con số tiêu đề

Một lưu ý nhỏ: đây là một trò chơi, nơi khoảng 34% các lệnh mà người chơi thấy là mối đe dọa. Trong công việc hàng ngày, những mối đe dọa này hiếm khi xuất hiện. Người chơi biết rằng họ đang được kiểm tra trong một thử thách giới hạn thời gian. Tuy nhiên, các con số dưới đây có thể hữu ích để thu thập một số thông tin chi tiết về việc so sánh các mối đe dọa và nhận thức chung của mọi người về chúng.

Các danh mục mối đe dọa và tỷ lệ bỏ sót

Các lệnh phá hoại trắng trợn được phát hiện đáng tin cậy nhất. Các lệnh thực sự đánh cắp thông tin xác thực của bạn lại bị bỏ sót nhiều gấp ba lần.

Điểm mù của npm run

Lệnh bị bỏ sót nhiều nhất trong trò chơi là npm run analyze, được phê duyệt 64,7% thời gian. Bản thân lệnh này thường vô hại. Nhưng những gì npm run thực sự làm là chạy một tập lệnh được định nghĩa trong file package.json của dự án. Đó có thể là mã lành tính như chạy một trình phân tích bundle, hoặc mã độc đã được chèn vào file trước đó.

Trò chơi có hiển thị cho bạn trong nhật ký lịch sử của agent nội dung thực sự của tập lệnh đó:

Hai phần ba người chơi vẫn phê duyệt nó, cho thấy nhật ký lịch sử ngay phía trên lời nhắc cấp quyền có thể đã không được đọc kỹ. Có ba lệnh như vậy trong trò chơi và chúng xuất hiện trong danh sách bị bỏ sót nhiều nhất:

Tổng hợp lại, ba lệnh này bị bỏ sót 52,5% thời gian (n=9.482) so với 28,4% đối với mọi cuộc tấn công kiểu đánh cắp thông tin khác. Việc ẩn một payload đằng sau một tên tập lệnh quen thuộc làm tăng tỷ lệ thành công lên gấp đôi ngay cả khi payload đó được hiển thị trong nhật ký lịch sử.

Điều này thực sự là một triệu chứng của vấn đề lớn hơn, được dns_snek diễn đạt rất hay trong luồng thảo luận trên Hacker News:

Đó là một ví dụ tuyệt vời về việc các hành động nguy hiểm bị coi là vô hại như thế nào. Toàn bộ mô hình phê duyệt các lệnh cụ thể là hoàn toàn điên rồ.

npm run build = chạy một lệnh shell tùy ý được viết trong package.json

Trong khi đó, agent có thể đã thực hiện bất kỳ hành động nào sau đây mà không cần phê duyệt:

Việc yêu cầu người dùng xác thực các lệnh - vốn hầu như luôn an toàn, nhưng lại không còn an toàn nữa do các file đã bị sửa đổi - không phải là một biện pháp bảo vệ mạnh mẽ.

Tỷ lệ bỏ sót tăng lên dưới áp lực

Anthropic trước đây đã lưu ý rằng "permission fatigue" (sự mệt mỏi khi cấp quyền) là có thật trong claude code, với trích dẫn sau:

Người dùng càng thấy nhiều yêu cầu phê duyệt, họ càng ít chú ý đến từng yêu cầu, và theo thời gian, họ trở nên ít cẩn trọng hơn trong việc giám sát.

Và mặc dù đây là một trò chơi ngắn nơi người dùng được cảnh báo về các mối đe dọa, chúng ta có thể thấy một số dấu hiệu suy giảm sự tập trung về cuối các lượt chơi:

Biểu đồ trên cho thấy tỷ lệ bỏ sót mối đe dọa trong suốt phiên chơi, với các lượt chơi được nhóm lại theo số lượng lệnh mà người dùng đã hoàn thành. Người dùng hoàn thành ít lệnh hơn có thể là do họ dành nhiều thời gian hơn để xem xét, hoặc do trò chơi bị đóng băng trong vài giây sau khi thực hiện sai như một hình phạt. Tôi đã loại bỏ tất cả những người dùng chỉ đơn giản là chặn mọi thứ.

Mọi nhóm đều cải thiện sau vài lệnh đầu tiên (khởi động?) và sau đó tỷ lệ bỏ sót lại tăng lên về cuối. Mặc dù điều này cũng có thể do áp lực thời gian sắp hết và người chơi có xu hướng mắc lỗi nhiều hơn để cố gắng thực hiện thêm một vài lệnh.

Cái giá của sự cảnh giác: chặn quá mức

Các lệnh sau đây có ý định lành tính, nhưng thường xuyên bị chặn:

Đây là mặt khác của tình thế tiến thoái lưỡng nan đối với "human-in-the-loop". Người dùng được yêu cầu phê duyệt các lệnh thực sự lành tính, và việc chặn chúng làm chậm tiến độ của agent. Theo thời gian, sự nhiễu này có khả năng khiến người dùng mất cảnh giác và phê duyệt các lệnh độc hại. Các tính năng như 'Auto Mode' của Anthropic cố gắng giảm thiểu điều này bằng cách tự động xác định xem một lệnh có an toàn hay không trước khi hỏi bạn, nhưng chúng không hoàn hảo như đã đề cập trong bài viết trước.

Lệnh cat gây tranh cãi

cat ~/.zshrc đã được 45,9% người chơi phê duyệt, đây là lệnh gây chia rẽ nhất trong trò chơi. Sự phản đối (được nêu trên HN) là hợp lý: nhiều lập trình viên không lưu giữ bí mật nào trong profile shell của họ, vì vậy đối với họ, nó vô hại. Đối với nhiều người xuất các khóa API ở đó, đó là hành vi tiết lộ thông tin xác thực. Rủi ro của lệnh này phụ thuộc hoàn toàn vào thiết lập mà agent không thể nhìn thấy. Nếu bạn source một file bí mật riêng biệt từ.zshrc của mình, rủi ro agent có thêm quyền truy cập sẽ giảm đi.

Bài học rút ra

Tôi rất thích theo dõi các cuộc thảo luận về "human-in-the-loop" và học hỏi thêm về các mô hình cấp quyền trong quá trình này. Mặc dù chỉ là một trò chơi, tôi thấy nó chứng minh được một số vấn đề với con người trong vòng lặp như một biện pháp bảo vệ cho các AI coding agent. Lượng nhiễu cao gây ra sự mệt mỏi, và các lập trình viên không phải lúc nào cũng có ngữ cảnh về những gì đã thay đổi để xác định rủi ro một cách nhanh chóng.

Đối với các lập trình viên, chúng ta cần nắm rõ các đánh đổi của các mô hình cấp quyền khác nhau và cách giảm thiểu các rủi ro liên quan như áp dụng sandboxing và tách biệt thông tin xác thực cũng như các biến môi trường bí mật. Bài viết gốc đề cập đến một số biện pháp giảm thiểu thực tế này.

Nếu bạn muốn thử vận may với trò chơi này, bạn có thể tìm thấy nó tại đây: https://llmgame.scalex.dev

Alex Wauters

Xin chào - Tôi là Alex. Tôi viết về bảo mật dành cho nhà phát triển và những đánh đổi khi xây dựng và mở rộng quy mô các hệ thống phần mềm. Cựu Staff Engineer tại Uber.