E2B cách ly code do agent sinh ra, nhưng đường ra internet mở sẵn

Mỗi sandbox của E2B đều có đường ra internet theo mặc định. Chi tiết đó nằm ngay trong tài liệu chính thức của một công cụ sinh ra để chạy code trong môi trường tách biệt.

Vì thế, FDE không thể hứa với đội bảo mật của khách rằng cứ vào sandbox là code hết đường đi. Agent của bạn viết code mà chưa ai đọc, và code đó cần một nơi để chạy. E2B trả lời câu hỏi “chạy ở đâu”; câu hỏi “code được phép đi đâu” vẫn là việc của bạn.

Công cụ này thực sự làm gì?

E2B tự mô tả là hạ tầng mã nguồn mở để chạy code do AI sinh ra trong sandbox cô lập trên đám mây. Repo chính dùng giấy phép Apache-2.0.

Thử hình dung một ca điển hình. Khách là công ty logistics muốn agent đối soát hóa đơn: agent đọc một file, tự viết Python, chạy, thấy lỗi rồi sửa. Nếu vòng lặp đó chạy trên laptop của bạn hay trên một máy của khách, một dòng code sai có thể xóa nhầm file hoặc chạm vào hệ thống nội bộ.

Đó là lúc nên dùng đến E2B: code chưa được người đọc, chạy nhiều vòng, và bạn không muốn xin quyền trên hạ tầng của khách chỉ để làm proof of concept. Nếu code đã được review và phải nằm cạnh dữ liệu trong mạng nội bộ, bài toán lại khác, và sandbox trên đám mây chưa chắc là câu trả lời.

Làm thử: đối soát hóa đơn với mạng đã tắt

Bước 1, đóng mạng. Khi tạo sandbox, hãy tắt allowInternetAccess; làm vậy tương đương đặt denyOut thành 0.0.0.0/0, tức chặn mọi đường ra. Lưu lại đoạn cấu hình này, vì đó là bằng chứng đầu tiên của bạn.

Bước 2, chứng minh mạng đã đóng. Viết một script ngắn gọi tới một địa chỉ công khai mà bạn biết đang hoạt động, rồi chạy trên máy của bạn và trong sandbox. Máy của bạn phải gọi được, sandbox phải thất bại; nếu sandbox gọi được, dừng lại ngay. Lưu cả hai log, vì log đối chứng cho thấy lỗi đến từ luật mạng chứ không phải từ địa chỉ đích.

Bước 3, đưa dữ liệu vào. Chỉ đến lúc này mới chuyển vào sandbox một bản mẫu khách đã duyệt, giả sử file CSV 200 dòng hóa đơn đã ẩn tên. Đếm lại ngay trong sandbox: phải đúng 200 dòng. Lưu con số đó cùng văn bản khách đồng ý.

Bước 4, chạy code của agent. Cho đoạn Python do agent viết chạy trên file vừa đưa vào. Nó có thể trả về một file ghi 188 hóa đơn khớp và 12 hóa đơn lệch, tổng vẫn đúng 200. Lưu nguyên đoạn code và file kết quả để người của khách đối chiếu.

Thiết kế này có một hệ quả dễ bị bỏ sót. Khi internet đã tắt, một agent đặt bên trong sandbox cũng không gọi được API của model ở bên ngoài. Vì thế, hãy để vòng lặp agent nằm ngoài: agent viết code ở phía bạn, còn sandbox chỉ chạy code đó.

Giả sử job đối soát thật cần 3 giờ. Sandbox chạy liên tục được tối đa 1 giờ ở gói Hobby và 24 giờ ở gói Pro, nên với Pro, job này chạy một mạch là xong.

Ở Hobby, bạn phải dùng pause, vì mỗi lần pause giờ chạy được tính lại từ đầu mà trạng thái vẫn còn nguyên. Nếu pause ở mỗi phút thứ 50 cho an toàn, job được chia thành các đoạn 50, 50, 50 và 30 phút, tức ba lần pause. Code của bạn vì thế phải dừng giữa chừng rồi chạy tiếp được, nên hãy thử điều đó sớm.

Về chi phí, E2B có mức giá $0.000014 cho mỗi vCPU-giây. Với 2 vCPU chạy 3 giờ là 21.600 vCPU-giây, tức $0.3024 riêng phần CPU.

Gói Hobby có $100 tín dụng dùng một lần và cho 20 sandbox chạy đồng thời. Chỉ tính phần CPU, khoản đó đủ cho hơn 330 lần chạy job này, nên Hobby hợp với proof of concept dùng dữ liệu giả hoặc bản mẫu khách đã duyệt.

Trước khi làm việc thật với khách, hãy kiểm tra xem gói đang dùng có qua được security review của họ không. Về mặt kỹ thuật, Pro đáng cân nhắc khi job không thể dừng giữa chừng, hoặc khi bạn cần hơn 20 sandbox cùng lúc.

Code trong sandbox vẫn đi được tới đâu?

Trong ví dụ trên, code không chạy trên máy của khách. Nhưng nếu chưa đổi cấu hình, nó vẫn có đường gửi dữ liệu ra internet, và nội dung một hóa đơn độc hại có thể lái agent đi đúng đường đó.

Đội AI Red Team của NVIDIA xếp indirect prompt injection là mối đe dọa chính với công cụ của agent. Họ coi chặn đường ra là kiểm soát bắt buộc, vì nó ngăn việc đẩy dữ liệu ra ngoài hoặc mở remote shell. E2B cho ba lựa chọn, mỗi lựa chọn hợp với một giai đoạn khác nhau.

Cấu hình	Sandbox đi được tới đâu	Dùng khi
Mặc định	Có outbound ra internet	Demo với dữ liệu giả
Tắt internet	Không có kết nối outbound nào	Code xử lý dữ liệu của khách và không cần gọi ra ngoài
Luật allow/deny	Theo luật, allow luôn thắng deny	Code phải gọi một vài đích cố định

Hàng cuối cùng là nơi dễ sai nhất, vì allow luôn thắng deny. Giả sử một luật allow phủ mọi địa chỉ của hãng vận chuyển đối tác, còn một luật deny nhắm riêng vào máy chủ thử nghiệm 203.0.113.50 của hãng đó. Code vẫn gọi được 203.0.113.50, nên hãy viết allow thật hẹp thay vì trông vào deny để vá.

Tên miền được khai trong allowOut, nên công thức dễ giải trình là chặn toàn bộ rồi chỉ mở đúng hostname cần dùng. Hãy kiểm thử cả hai chiều: đích được mở phải gọi được, đích khác phải thất bại. Khi có thể, tắt hẳn internet vẫn là lựa chọn dễ giải trình nhất với đội bảo mật của khách.

NVIDIA cũng khuyên sandbox không thừa hưởng credential của máy chủ mà chỉ nhận secret được cấp rõ ràng. Ở ca đối soát, code chỉ cần đọc một file, nên câu trả lời đơn giản nhất là không cấp secret nào.

Những giới hạn phải nói trước với khách

Giới hạn lớn nhất đến từ chính nơi code chạy: sandbox nằm trên đám mây. Đưa dữ liệu của khách vào sandbox nghĩa là dữ liệu đã rời khỏi hạ tầng của họ, và giấy phép mã nguồn mở không tự trả lời câu hỏi dữ liệu nằm ở đâu. Hãy nêu chuyện này ngay từ buổi đầu, đừng để đến tuần cuối.

Giới hạn thứ hai ít người để ý hơn. Sandbox đã pause được giữ nguyên toàn bộ trạng thái vô thời hạn. Tiện cho job dài, nhưng một sandbox bị quên có thể giữ dữ liệu của khách lâu sau khi hợp đồng kết thúc, nên bước hủy sandbox phải có trong quy trình bàn giao.

Giới hạn thứ ba là quy mô: gói Pro cho tối đa 100 sandbox đồng thời. Nếu thiết kế cho mỗi người dùng cuối một sandbox, bạn cần so con số này với lượng người dùng cùng lúc trước khi hứa về khả năng mở rộng.

Nếu bị hỏi về tầng ảo hóa, đừng trả lời vội. Firecracker của AWS chạy workload trong microVM dùng KVM của Linux, và bài báo NSDI 2020 mô tả nó giữ cô lập an ninh mạnh trong Lambda và Fargate.

Nhưng các tài liệu của E2B dẫn ở đây không xác nhận E2B dùng tầng ảo hóa nào, nên đừng mặc định đó là Firecracker; hãy xin E2B xác nhận trực tiếp.

Học gì trước, và ghi gì vào CV?

Thứ tự hợp lý là bắt đầu từ mạng, không phải từ cách gọi API của E2B. Phần khó hơn là nhìn vào một agent và kể ra được nó đọc gì, ghi gì, gọi đi đâu. Sau đó mới đến kỹ năng thiết kế job có thể dừng giữa chừng rồi chạy tiếp mà không hỏng kết quả.

Khi đọc job description, nếu gặp những cụm như code execution hay sandboxing, hãy hỏi người phỏng vấn: code của agent chạy ở đâu và được phép gọi tới đâu? Trong CV, đừng chỉ ghi “đã dùng E2B”. Hãy viết rằng bạn chạy code do agent sinh ra trong sandbox tắt outbound, có test xác nhận code không gọi được ra ngoài và quy trình hủy sandbox khi bàn giao.

Khách hàng hiếm khi cần nghe rằng sandbox của bạn an toàn. Họ cần xem dòng log cho thấy nó đã bị chặn khi cố đi ra ngoài.