Đầu tháng 2 năm 2026, GitGuardian công bố một báo cáo đáng lẽ phải khiến mọi lập trình viên đang chạy trợ lý AI cá nhân phải giật mình. Hạ tầng quét bí mật của họ phát hiện hơn 200 thông tin xác thực bị rò rỉ liên quan trực tiếp đến các triển khai OpenClaw — API key, mật khẩu database, OAuth token, và thông tin xác thực nhà cung cấp cloud, nằm rải rác trên các repository công khai, file log, và báo cáo lỗi. Một số thuộc về các công ty y tế. Số khác thuộc về các startup fintech. Tất cả đều còn hoạt động.
Vài ngày sau, Đại học Northeastern đăng một bài viết với tiêu đề cắt sâu hơn bất kỳ mã CVE nào: "Tại Sao Trợ Lý AI OpenClaw Là Một 'Cơn Ác Mộng Quyền Riêng Tư.'" Các nhà nghiên cứu không tập trung vào một lỗ hổng đơn lẻ. Họ tập trung vào chính kiến trúc — cách OpenClaw xử lý dữ liệu, lưu trữ thông tin xác thực, và phơi bày thông tin người dùng theo thiết kế, không phải do tai nạn.
Đây không phải những sự cố đơn lẻ do người dùng bất cẩn. Chúng là kết quả có thể dự đoán được của việc chạy AI agent trong môi trường mà bí mật, dữ liệu người dùng, và mã agent đều chia sẻ cùng không gian địa chỉ mà không có cách ly giữa chúng.
Bí Mật Rò Rỉ Như Thế Nào
Cách thiết lập OpenClaw điển hình hoạt động như sau: bạn cài đặt trên máy, cấu hình API key trong biến môi trường, và bắt đầu chat. Tiến trình agent chạy dưới quyền user của bạn, với quyền hạn của bạn, đọc biến môi trường của bạn. Mọi skill bạn cài đặt đều chạy trong cùng tiến trình, với cùng quyền truy cập.
Điều này có nghĩa là khi bạn nhờ trợ lý AI giúp debug script triển khai, agent có thể thấy thông tin xác thực AWS của bạn. Khi một skill xử lý email, nó có thể đọc mật khẩu database. Khi lỗi xảy ra và stack trace được ghi log, những biến môi trường đó có thể nằm trong file log. Và khi file log đó được commit vào repository, hoặc upload lên báo cáo lỗi, hoặc đồng bộ lên dịch vụ cloud — bí mật của bạn giờ đã công khai.
Hơn 200 bí mật bị rò rỉ mà GitGuardian tìm thấy không phải kết quả của 200 sai lầm riêng biệt. Chúng là kết quả của một sai lầm kiến trúc lặp lại 200 lần: đặt bí mật trong process.env nơi mọi đoạn mã trong tiến trình đều có thể đọc được.
Vấn đề nhân lên với skill và plugin. Hệ thống skill của OpenClaw chạy mã bên thứ ba trong cùng tiến trình với agent chính. Một skill độc hại không cần exploit để đánh cắp thông tin xác thực — nó chỉ cần đọc process.env. Một skill viết kém không cần cố tình rò rỉ dữ liệu — nó chỉ cần đưa ngữ cảnh môi trường vào báo cáo lỗi. Bề mặt tấn công không phải lỗ hổng cần vá. Đó chính là kiến trúc.
Northeastern Đã Đúng Ở Điểm Nào
Các nhà nghiên cứu Northeastern đã nhận ra điều mà cộng đồng bảo mật vẫn đang lảng tránh: vấn đề quyền riêng tư với trợ lý AI không nằm ở mã hóa hay xác thực. Nó nằm ở câu hỏi cơ bản: agent có thể truy cập những gì và ranh giới nào tồn tại giữa thế giới của agent và của bạn.
Khi AI agent chạy dưới quyền user của bạn, với quyền hạn của bạn, trên máy của bạn, không có ranh giới nào cả. Agent có thể đọc file, thông tin xác thực, lịch sử duyệt web, SSH key của bạn. Nó có thể truy cập bất cứ thứ gì bạn truy cập được. Thứ duy nhất ngăn nó làm điều có hại là prompt — và các cuộc tấn công prompt injection đã chứng minh nhiều lần rằng prompt không phải ranh giới bảo mật.
Đây là ý Northeastern khi nói "cơn ác mộng quyền riêng tư." Không phải OpenClaw cố tình đánh cắp dữ liệu, mà kiến trúc khiến việc đảm bảo dữ liệu không rò rỉ là bất khả thi. Quyền truy cập của agent chỉ bị giới hạn bởi quyền user của hệ điều hành, tức là thực tế không bị giới hạn gì cả.
Container Isolation Của NanoClaw Thay Đổi Cục Diện Như Thế Nào
NanoClaw áp dụng cách tiếp cận hoàn toàn khác. Mỗi agent chạy bên trong container Linux riêng — Apple Container trên macOS, Docker trên macOS và Linux. Container không phải tính năng tiện lợi hay tùy chọn triển khai. Nó chính là mô hình bảo mật.
Khi bạn gửi tin nhắn cho NanoClaw, tiến trình host không chạy Claude trực tiếp. Nó khởi tạo container, mount chỉ những thư mục cụ thể mà agent cần truy cập, và truyền ngữ cảnh hội thoại vào. Agent chạy bên trong container với hệ thống file riêng, không gian tiến trình riêng, và network stack riêng. Khi xong, container bị hủy.
Đây là phần thú vị về xử lý bí mật. NanoClaw không bao giờ nạp ANTHROPIC_API_KEY vào process.env. Thay vào đó, nó đọc key từ .env lúc chạy và truyền vào tiến trình container qua stdin dưới dạng JSON payload. Bên trong container, agent-runner nhận key, dùng cho lệnh gọi API, và không bao giờ ghi ra đĩa hay export ra biến môi trường.
Điều này có nghĩa là ngay cả khi prompt độc hại lừa agent chạy `printenv` hoặc `cat /proc/self/environ`, API key không có ở đó. Nó chỉ tồn tại trong bộ nhớ tiến trình agent-runner, trong suốt thời gian của một lượt hội thoại duy nhất. Container bị xâm nhập không thể rò rỉ thứ mà nó không có quyền truy cập.
Hệ thống mount thêm một lớp bảo vệ nữa. NanoClaw duy trì danh sách cho phép các thư mục có thể mount vào container, lưu trữ bên ngoài thư mục gốc dự án. Mỗi nhóm có hệ thống file cô lập riêng — file bộ nhớ CLAUDE.md riêng, workspace ghi được riêng. Danh sách cho phép bao gồm phát hiện thoát symlink, nên liên kết tượng trưng được tạo thủ công không thể lừa hệ thống mount phơi bày thư mục ngoài tập hợp được phép.
Container cũng chạy dưới quyền non-root, với mã nguồn dự án được mount chỉ đọc. Agent có thể đọc codebase để hiểu ngữ cảnh, nhưng không thể sửa đổi file trên host. Đường dẫn ghi được giới hạn theo nhóm và được dọn dẹp khi container thoát.
Mô Hình Cách Ly Theo Nhóm
Cách ly của NanoClaw không chỉ dừng ở việc tách agent khỏi host. Mỗi nhóm WhatsApp có container riêng, bộ nhớ riêng, và hệ thống file riêng. Nhóm A không thể thấy hội thoại, file, hay bộ nhớ CLAUDE.md của Nhóm B — không phải nhờ kiểm soát truy cập cấp ứng dụng, mà vì chúng chạy trong container tách biệt vật lý với mount point riêng.
Điều này quan trọng cho tình huống mà hầu hết trợ lý AI bỏ qua hoàn toàn: thiết bị dùng chung và cài đặt nhiều người dùng. Nếu bạn dùng NanoClaw với gia đình, hội thoại và file của nhóm công việc được cách ly khỏi hội thoại và file của nhóm gia đình ở cấp container. Không có bug ứng dụng nào có thể rò rỉ dữ liệu giữa các nhóm, vì cách ly được thực thi bởi container runtime, không phải ứng dụng.
Kênh WhatsApp chính của bạn — tin nhắn trực tiếp với trợ lý — đóng vai trò giao diện quản trị. Đó là kênh duy nhất có thể quản lý tác vụ lên lịch, sửa đổi cấu hình, và truy cập trạng thái xuyên nhóm. Các kênh nhóm bị giới hạn trong sandbox riêng theo mặc định.
Bài Học Cho Ngành
Báo cáo của GitGuardian và phân tích của Northeastern đều dẫn đến cùng một kết luận: AI agent là hạ tầng, và hạ tầng đòi hỏi bảo mật cấp hạ tầng. Chạy AI agent trong cùng tiến trình với thông tin xác thực, với cùng quyền hạn như tài khoản user, tương đương với chạy web server dưới quyền root không có firewall. Nó hoạt động cho đến khi không, và khi không, phạm vi thiệt hại là tất cả.
Container isolation không phải ý tưởng mới. Ngành hosting web đã nhận ra điều này hai thập kỷ trước — bạn không chạy mã của nhiều khách hàng trong cùng tiến trình. Ngành database nhận ra còn sớm hơn — bạn không cho mọi truy vấn quyền truy cập mọi bảng. Nhưng hệ sinh thái AI agent vẫn đang ở giai đoạn "chạy mọi thứ dưới quyền root," và bí mật bị rò rỉ cùng ác mộng quyền riêng tư là kết quả có thể dự đoán.
Cách tiếp cận của NanoClaw không phải cách duy nhất để giải quyết vấn đề này, nhưng nó chứng minh rằng vấn đề có thể giải quyết mà không hy sinh chức năng. Agent chạy trong container vẫn có thể tìm kiếm web, duyệt trang, đọc ghi file, và thực thi lệnh shell. Chúng chỉ làm điều đó trong sandbox nơi phạm vi thiệt hại của bất kỳ sự cố nào — dù là bug, prompt injection, hay skill độc hại — bị giới hạn trong phạm vi của container đó.
Hơn 200 bí mật bị rò rỉ mà GitGuardian tìm thấy không nhất thiết phải xảy ra. Chúng xảy ra vì kiến trúc khiến chúng trở nên tất yếu. Cách sửa không phải giáo dục người dùng tốt hơn hay quản lý thông tin xác thực cẩn thận hơn. Cách sửa là kiến trúc nơi bí mật không thể rò rỉ vì chúng không bao giờ ở nơi mà việc rò rỉ là khả thi.