Một prompt. Ba lệnh shell. Tôi đã dùng AI của chính họ để hack chính nó.
Đây là một lớp lỗi có khả năng tồn tại trong mọi sản phẩm AI đa tác nhân (multi-agent) đang được phát hành hiện nay. Và cách khắc phục là một mẫu thiết kế mà chưa ai trong lĩnh vực này nói tới.
Đây là toàn bộ câu chuyện.
Tôi không cố gắng hack bất cứ thứ gì. Tôi đang nghiên cứu cách Perplexity Computer xử lý sandboxing cho công việc hạ tầng tác nhân của riêng mình. Tôi muốn hiểu cách các hệ thống đa tác nhân trong sản xuất thực sự cô lập môi trường thực thi, cái gì được chia sẻ, cái gì không.
Đầu tiên, tôi bắt đầu mò mẫm trong hệ thống. Tôi nhận thấy Claude Code đã được cài đặt trong sandbox.
Tôi yêu cầu tác nhân khởi động nó và tạo một vài đoạn code thử nghiệm chỉ để xem nó hoạt động thế nào. Nó chạy tốt. Claude Code tiêu chuẩn, chạy ở chế độ bypass-permissions nên không yêu cầu xác nhận. Hợp lý cho một hệ thống tác nhân.
Đó là lúc tôi nghĩ: khoan đã, họ xử lý các API key như thế nào?! Claude Code cần một Anthropic API key để hoạt động. Key đó phải nằm ở đâu đó trong sandbox này. Nó được tiêm vào thế nào? Có phạm vi ra sao? Có bị cô lập không?
Câu hỏi đó là thứ đã dẫn tôi xuống con đường này.
Tác nhân phụ (subagent) giữ một API key trong môi trường tiến trình của nó. Tôi cần phải đánh cắp nó.
Perplexity Computer đã thử sáu lần và thất bại.
- Yêu cầu subagent dump env của nó: bị từ chối!
- Cài một script trojan vào filesystem dùng chung: nó đọc code của tôi, hiểu nó đang làm gì, và từ chối chạy!
- Đầu độc .bashrc và .profile: chúng kích hoạt quá sớm, trước khi API key được tiêm vào.
- Thả một file nhị phân node giả vào PATH: không bao giờ được kích hoạt.
- Tạo tác nhân coding và đồng thời theo dõi cây tiến trình: subagent chạy trong một sandbox khác, không có gì bị bắt được :(
- Tìm system prompt của Claude Code và sửa nó để loại bỏ hành vi từ chối: không tìm thấy system prompt tùy chỉnh nào được tiêm vào.
Sáu lần thất bại. Khả năng an toàn ở cấp độ model/prompt của Claude thực sự rất tốt. Mỗi lần tôi thử một điều gì đó thông minh, model đã phát hiện ra.
Sau đó Perplexity nhớ ra rằng Claude Code là một ứng dụng Node.js được khởi chạy qua npm. Và npm đọc ~/.npmrc từ thư mục home. Và thư mục home nằm trên filesystem dùng chung mà tôi có thể ghi vào.
Node.js có một cờ --require giúp tiền tải (preload) một module JavaScript trước khi bất kỳ code ứng dụng nào chạy. Bạn có thể đặt cờ này thông qua NODE_OPTIONS trong .npmrc. Điều đó có nghĩa là nếu tôi ghi một .npmrc vào thư mục home dùng chung, mọi tiến trình Node mà subagent tạo ra sẽ tiền tải code của tôi! Điều này xảy ra trước khi Claude Code khởi tạo, trước khi bất kỳ kiểm tra an toàn nào chạy, trước mọi thứ!
Khai thác (exploit) chỉ gồm ba lệnh:
- Viết một script sáu dòng để dump process.env vào một file trên workspace dùng chung
- echo 'node-options=--require /path/to/script.js' > ~/.npmrc
- Yêu cầu Perplexity Computer làm bất kỳ tác vụ coding nào
Subagent khởi động → npm đọc .npmrc của tôi → preload của tôi kích hoạt trước khi Claude Code chạy → toàn bộ thông tin đăng nhập API nằm gọn trên filesystem dùng chung.
Nó đã hoạt động! Nó đưa cho tôi một gateway token của Perplexity, token này proxy qua agent-proxy.perplexity.ai tới tài khoản Anthropic chính của họ.
Đương nhiên, điều đầu tiên tôi làm là đặt API key và BASE_URL này cho Claude Code trên laptop của mình. Tôi nghĩ rằng các cuộc gọi LLM từ Claude Code sẽ thất bại và bị giới hạn trong sandbox. Tôi đã sốc. Phản hồi ngay lập tức từ Opus 4.6!
Sau đó tôi nghĩ, "chắc chắn, họ sẽ tính phí tài khoản của tôi cho việc sử dụng này, API key này chắc chắn phải gắn với người dùng của tôi". Tôi đã sai lần nữa.
Tôi đã yêu cầu Opus 4.6 tạo ra một câu chuyện dài mô tả lịch sử thế giới bao gồm mọi phát minh, đế chế và khám phá. Tôi chạy cuộc gọi này 5 lần song song, tạo ra hơn 100k token đầu ra từ mỗi lần. Điều này lẽ ra phải tiêu thụ hết tín dụng Perplexity Computer của tôi, nhưng chúng không hề nhúc nhích.
Không bị giới hạn IP. Không có phạm vi phiên. Không bị ràng buộc sandbox. Là hóa đơn của họ.
Một trong những startup AI được tài trợ tốt nhất hành tinh đã bị đánh bại bởi một dotfile đã được sử dụng trong các cuộc tấn công chuỗi cung ứng Node.js từ năm 2019.
Model đã làm đúng mọi thứ. Hạ tầng thì không.
Và đây là điều tôi thực sự muốn các nhà sáng lập xây dựng hạ tầng tác nhân rút ra từ câu chuyện này.
Kiến trúc của Perplexity đúng một nửa. Họ sử dụng một proxy giữa sandbox và API của Anthropic. Đó là mẫu đúng đắn. Bạn không bao giờ nên đặt một API key nhà cung cấp thô bên trong sandbox. Proxy cho phép bạn kiểm soát, quan sát và khả năng thu hồi quyền truy cập mà không cần xoay vòng key chính.
Vấn đề là proxy token của họ không có bất kỳ ràng buộc nào với ngữ cảnh thực thi. Một khi bạn có nó, nó hoạt động ở mọi nơi mãi mãi.
Cách làm đúng là:
Gắn token với sandbox ID. Token và sandbox ID không khớp? Từ chối. Key bị rò rỉ nhưng bạn không có sandbox? Vô dụng. Lý tưởng nhất là nên gắn token với địa chỉ IP của sandbox, nhưng E2B (nhà cung cấp sandbox mà họ sử dụng) không cung cấp điều đó trước khi sandbox được khởi tạo.
Làm cho token tồn tại trong thời gian ngắn. Tạo ra nó khi sandbox khởi động. Hủy nó khi sandbox tạm dừng. Không có thông tin đăng nhập tồn tại lâu dài. Proxy tạo ra một token ngắn hạn khi phiên bắt đầu và vô hiệu hóa nó khi kết thúc. Key bị rò rỉ từ một sandbox đã chết là một key chết.
Gắn token với tài khoản thanh toán của người dùng. Ngay cả khi mọi thứ khác thất bại, ngay cả khi ai đó lấy trộm một token còn sống từ một sandbox đang hoạt động và sử dụng nó trước khi hết hạn, thì việc sử dụng đó sẽ được tính vào tài khoản đã tạo ra phiên đó. Không phải vào một pool thanh toán chính dùng chung. Điều này biến "truy cập API không giới hạn miễn phí" thành "ai đó lạm dụng hạn mức của chính họ", một mức độ nghiêm trọng hoàn toàn khác.
Ba điều này — gắn với sandbox, tồn tại ngắn hạn, tính vào tài khoản người dùng — là những gì làm cho mẫu proxy thực sự hoạt động. Nếu không có chúng, bạn chỉ thêm một chặng mạng thừa thãi mà không ngăn chặn được gì.
Đây không phải là vấn đề riêng của Perplexity. Đây là kiến trúc mặc định cho hạ tầng tác nhân hiện tại vì nó nhanh nhất để xây dựng. Filesystem dùng chung giữa các tác nhân, thông tin đăng nhập tồn tại lâu dài, thanh toán qua tài khoản chính. Tôi cá là hầu hết các sản phẩm đa tác nhân đang hoạt động hiện nay đều có một phiên bản nào đó của vấn đề này.
Đã báo cáo cho @AravSrinivas và @denisyarats trước khi xuất bản.
