Cách SPACE định tuyến yêu cầu đến đúng lần thực thi sandbox
SPACE của Perplexity ràng buộc yêu cầu của tác nhân AI với đúng lần thực thi sandbox bằng kiểm tra danh tính và tuyến đã ký.

Khi ai đó yêu cầu một tác nhân AI phân tích bảng tính hoặc kiểm thử phần mềm, họ đang tin tưởng rằng tác nhân sẽ làm việc an toàn với tệp và dữ liệu của họ. Các tác nhân cần môi trường cô lập để thực hiện công việc đó mà không làm lộ dữ liệu của người dùng khác hoặc ảnh hưởng đến khối lượng công việc của họ.
Khi các tác nhân đảm nhận những tác vụ phức tạp hơn với mức độ tự chủ cao hơn, các môi trường này giúp kiềm chế sai sót và hạn chế thiệt hại mà mã không an toàn hoặc độc hại có thể gây ra. Sandbox cung cấp khả năng cô lập đó trong khi vẫn dùng chung các dịch vụ control plane, nút worker và hạ tầng định tuyến.
Hạ tầng dùng chung đó phải đưa từng thao tác đến đúng lần thực thi được ủy quyền xử lý thao tác đó. Một tuyến cũ có thể gửi một yêu cầu hợp lệ đến sandbox khác, hoặc đến một lần thực thi cũ hơn của đúng sandbox đó. SPACE, nền tảng sandbox bảo mật của Perplexity, ràng buộc mỗi thao tác với một lần thực thi đã chọn và kiểm tra đích đến trước khi chuyển tiếp.
Trong nhiều tháng qua, SPACE đã xử lý hàng triệu lần thực thi mỗi ngày, mỗi lần đều được bảo vệ bằng một danh tính mật mã riêng biệt, với tỷ lệ lỗi dưới 0,0002% và không có kết nối nào bị rớt.
Bài toán định tuyến
Bảo mật sandbox còn phụ thuộc vào việc đưa từng yêu cầu đến đúng đích. Ngay cả một thao tác đọc tệp đơn giản cũng đi qua hạ tầng dùng chung, vốn phải theo dõi nơi sandbox đang chạy khi sandbox tạm dừng, tiếp tục hoặc di chuyển giữa các máy.
Một thao tác đọc tệp đi qua nhiều thành phần. Control plane của SPACE phân giải sandbox thành một lần thực thi và một worker. Yêu cầu đi vào qua node-api, được chuyển đến trình quản lý sandbox, sbx-manager, rồi đi qua một Unix socket đến cầu nối máy chủ, spaced-host. Cầu nối chuyển tiếp yêu cầu qua VSOCK, lớp truyền tải socket từ máy chủ đến guest, tới spaced-guest bên trong microVM Firecracker.
Mỗi quyết định đều dựa vào trạng thái có thể bị chậm so với các thay đổi của hạ tầng. Cơ sở dữ liệu có thể vẫn lưu vị trí đặt cũ, địa chỉ trong bộ nhớ đệm có thể trỏ đến nơi khác, hoặc đường dẫn socket có thể có một listener khác. Một kết nối thành công vẫn có thể đến sai đích. Một thao tác đọc có thể làm lộ dữ liệu của người dùng khác; một thao tác ghi có thể sửa đổi sai hệ thống tệp.
Snapshot đặt ra thêm một vấn đề. Việc tiếp tục một sandbox trên worker khác sẽ giữ nguyên danh tính logic của sandbox nhưng bắt đầu một lần thực thi mới. Một yêu cầu bị trễ hoặc một kết nối còn tồn tại có thể đến lần thực thi trước đó và trả về trạng thái cũ dưới đúng tên sandbox.
Danh tính sandbox và danh tính thực thi
SPACE tách biệt môi trường của người dùng với runtime phục vụ môi trường đó:
- Danh tính sandbox: ID ổn định của môi trường logic. Việc ủy quyền bên gọi xác lập quyền truy cập vào sandbox này.
- Danh tính tuyến/thực thi: Bản thể runtime (incarnation) được chọn và vị trí bố trí của nó, bao gồm worker, tầng nền (substrate) và lần kích hoạt.
Thế hệ thực thi phân biệt các hiện thân runtime. Trên Kubernetes, tuyến còn bao gồm UID của pod. Địa chỉ xác định vị trí điểm cuối; danh tính thực thi quyết định liệu các điểm cuối đó có được phép phục vụ thao tác hay không.
Giả sử sandbox S chạy dưới dạng lần thực thi 7 trên worker A, sau đó tiếp tục dưới dạng lần thực thi 8 trên worker B. Một yêu cầu được chọn cho lần thực thi 8 phải thất bại nếu đến lần thực thi 7. Nếu chỉ kiểm tra ID sandbox, sự không khớp này sẽ bị bỏ sót.
Lựa chọn lần thực thi có chữ ký
Mỗi yêu cầu mang theo bằng chứng đã ký cho biết lần thực thi sandbox nào được phép xử lý yêu cầu và quyền truy cập nào được cho phép. Thành phần phía nhận đối chiếu bằng chứng đó với danh tính runtime của chính mình trước khi cho phép yêu cầu tiếp tục.
Sau khi ủy quyền bên gọi, SPACE cấp một capability đã ký, có thời hạn ngắn, xác định sandbox, lần thực thi, vị trí đặt và quyền truy cập được phép. Capability cho service-port công khai còn chỉ định cổng và giao thức được phép.
Trình quản lý sandbox phía nhận xác minh chữ ký và so sánh toàn bộ danh tính với bản ghi runtime được lưu cục bộ. Chữ ký xác lập ai đã ủy quyền cho lựa chọn đó. Phép so sánh xác lập liệu lựa chọn đó có khớp với bên nhận hay không.
Lưu lượng ServicePort được kiểm tra lần thứ hai tại gateway mạng riêng của từng sandbox, netgtw, trước khi mở kết nối đến guest. Gateway so sánh danh tính với trạng thái kích hoạt đáng tin cậy và kiểm tra cổng cùng giao thức. Các thao tác điều khiển tiếp tục chuyển sang bước xác minh điểm cuối cầu nối.
SPACE dùng chữ ký Ed25519. Khóa ký của control plane cấp capability; các khóa xác minh công khai trên worker và gateway không thể cấp capability.
Capability có hiệu lực trong 120 giây, kèm dung sai lệch đồng hồ tối đa 15 giây khi kiểm tra hết hạn. Chữ ký hợp lệ và token chưa hết hạn vẫn chưa đủ khi danh tính được chọn và danh tính đã cài đặt không khớp nhau.
Từ chối tại đích sai
Worker phía nhận có thể phát hiện lỗi định tuyến ngay cả khi bản thân yêu cầu đã được ủy quyền. Worker kiểm tra xem mình có đang chạy lần thực thi được chọn cho yêu cầu đó hay không và từ chối yêu cầu nếu hai lần thực thi khác nhau.
Nếu một yêu cầu được chọn cho lần thực thi 8 đến worker A, vốn vẫn đang phục vụ lần thực thi 7, worker A sẽ từ chối yêu cầu đó trước khi chuyển tiếp. Khi bên nhận đã cài đặt danh tính của lần thực thi 8, bên nhận cũng sẽ từ chối các quyền hạn (capability) dành cho lần thực thi 7, ngay cả trước khi chúng hết hạn.
Đảm bảo này có một giới hạn quan trọng. Một capability dành cho lần thực thi 7 vẫn có thể khớp với một worker đang phục vụ lần thực thi 7 cho đến khi worker đó biết về việc ngừng hoạt động hoặc capability hết hạn. Việc áp dụng kiểm soát cục bộ và thời hạn giới hạn của capability phối hợp với nhau trong khi các bản cập nhật đang được lan truyền.
Xác minh điểm cuối cầu nối
Một bản ghi runtime khớp sẽ xác lập lần thực thi dự kiến. Cầu nối điều khiển cũng phải đến được các tiến trình và lớp truyền tải thuộc về lần kích hoạt đó, chứ không phải một bản thay thế đã kế thừa cùng địa chỉ.
Trình quản lý sandbox và trình quản lý nút xác minh thông tin xác thực peer của cầu nối máy chủ cũng như danh tính tiến trình của cả cầu nối lẫn Firecracker, bao gồm thời điểm khởi động, nhằm phát hiện ID bị tái sử dụng hoặc tệp thực thi đã bị thay đổi
Các bước kiểm tra lớp truyền tải gắn listener VSOCK với tiến trình Firecracker dự kiến bằng quyền sở hữu socket, danh tính guest và bằng chứng socket từ kernel. Cầu nối chỉ chuyển tiếp thao tác sau khi xác minh và từ chối kết nối lại trong suốt. Mọi kết nối mới đều phải vượt qua lại các bước kiểm tra.
Quy trình xác minh này áp dụng cho cầu nối điều khiển Firecracker trên Kubernetes và trên các máy chủ được quản lý trực tiếp. Lưu lượng ServicePort dùng các bước kiểm tra lần thực thi và cổng tại gateway của nó; cơ chế này không chứng thực danh tính của một ứng dụng bất kỳ bên trong guest.
Vòng đời luồng và khôi phục tuyến
Một số kết nối vẫn mở trong khi lần thực thi của sandbox thay đổi, vì vậy các bước kiểm tra danh tính phải mở rộng ra ngoài yêu cầu ban đầu. SPACE cho ngừng hoạt động các kết nối gắn với lần thực thi cũ và cho phép các thao tác đủ điều kiện kết nối lại với lần thực thi hiện tại theo cùng các bước kiểm tra bảo mật.
Terminal và tác vụ theo dõi tệp có thể tồn tại lâu hơn yêu cầu đã mở chúng. SPACE gắn các luồng backend với một epoch danh tính để luồng không thể tiếp tục gắn với lần thực thi trước sau khi bên nhận cài đặt một lần thực thi thay thế.
SPACE kiểm tra lại danh tính bền vững trước khi mở một luồng. Việc thay thế tuyến hoặc lần thực thi của luồng sẽ hủy lease của luồng, dừng đầu vào và đầu ra.
Thay đổi quyền sở hữu khác với việc thay thế lần thực thi. Việc chuyển giao thao tác vòng đời trên một resident Kubernetes không thay đổi vẫn giữ nguyên danh tính tuyến, các capability chưa hết hạn và các luồng của resident đó. Gateway cũng giữ nguyên các luồng đã thiết lập đối với những thay đổi chỉ liên quan đến lần thử kích hoạt trong cùng thế hệ tuyến và thế hệ thực thi. Các lần mở luồng mới cần danh tính đã cập nhật.
Quá trình khôi phục vẫn giữ nguyên các bước kiểm tra này. Bộ so sánh danh tính có thể trả về RefreshRoute khi bản thể không khớp trong cùng một sandbox, hoặc Deny khi là một sandbox khác. Chỉ tín hiệu làm mới được nhận diện mới kích hoạt việc sửa tuyến sau khi danh tính bị từ chối. Lỗi truyền tải tuân theo các quy tắc khôi phục riêng, cụ thể cho từng thao tác. Chữ ký, mục đích hoặc hồ sơ cổng không hợp lệ vẫn bị từ chối.
Một thao tác đủ điều kiện có thể phân giải lần thực thi hiện tại và thử lại một lần với yêu cầu được dựng lại. Mục trong bộ nhớ đệm chỉ được thay thế nếu mục đó vẫn là tuyến đã bị từ chối, giúp ngăn một lần từ chối bị trễ loại bỏ một mục mới hơn. Việc làm mới phiên gốc giữ nguyên thời điểm hết hạn ban đầu của bộ nhớ đệm, tách biệt việc sửa tuyến khỏi việc gia hạn ủy quyền của bên gọi.
Quy tắc phát lại vẫn tùy thuộc vào từng loại thao tác. Một backend thay thế phải vượt qua lại bước tiếp nhận, ngay cả khi WebSocket phía máy khách vẫn mở.
Các đánh đổi và ranh giới tin cậy
Danh tính thực thi trở thành trạng thái quan trọng về bảo mật. Các bản cập nhật của control plane và gói khóa xác minh phải đến được các thành phần phục vụ, và việc ngừng hoạt động có hiệu lực khi từng bên nhận cài đặt bản cập nhật. Thời hạn ngắn của capability giới hạn việc tái sử dụng trong quá trình lan truyền.
Thiết kế này giả định cơ chế bắt buộc kiểm tra danh tính đã được bật, đồng thời tin cậy bên ký của control plane, kernel của worker và các dịch vụ quản lý cục bộ trên nút. Việc quyền root của worker hoặc quyền quản trị viên cụm đặc quyền bị xâm phạm nằm ngoài mô hình mối đe dọa. Xác minh cầu nối là xác minh tiến trình và lớp truyền tải cục bộ, không phải chứng thực từ xa dựa trên phần cứng.
Xác minh chữ ký, so sánh runtime và xác thực cầu nối làm tăng khối lượng xử lý trên đường đi của yêu cầu. Các bước này dùng trạng thái cục bộ thay vì tra cứu ủy quyền từ xa ở mỗi chặng riêng tư.
So sánh trong ngành
Điểm cần so sánh là cách các nền tảng xử lý một yêu cầu đã được ủy quyền nhưng lại đến sai lần thực thi của đúng sandbox. Những phát hiện này chỉ liên quan đến các bản triển khai đã được kiểm tra, không phản ánh mức độ bảo mật tổng thể của nền tảng. SPACE, OpenShell và E2B được kiểm tra vào ngày 8 tháng 10 năm 2026:
- OpenShell: Cung cấp cơ chế chọn lần thực thi cho lệnh gọi mới và ràng buộc supervisor với runtime tương đương, thông qua các bước kiểm tra thế hệ và ủy quyền tại gateway, xác thực danh tính backend và xác nhận kết nối supervisor đang hoạt động (tiếp nhận tại gateway, xác thực và ràng buộc runtime). SPACE mang lựa chọn đã ký xuyên suốt đường phục vụ của mình và bổ sung bước xác minh tiến trình và lớp truyền tải cục bộ trên worker; OpenShell phân bổ các bước kiểm tra tương ứng trên gateway, danh tính khởi chạy và giao thức runtime đã xác thực của mình (thiết kế runtime).
- E2B: Theo dõi ID thực thi và cô lập các nhóm proxy theo vòng đời Firecracker, nhưng proxy đầu vào của nền tảng này chọn sandbox logic và cổng mà không có danh tính thực thi dự kiến để bên nhận so sánh (công bố tuyến, tiếp nhận tại proxy). Các bước kiểm tra đó không thể phân biệt một lần thực thi cũ hơn, vẫn được đăng ký là đang hoạt động trên một bên nhận cũ với thông tin xác thực khớp, với lần thực thi mới hơn đã được chọn, mặc dù quá trình gỡ bỏ thông thường sẽ xóa các tuyến và đóng các kết nối gắn với vòng đời (thông tin xác thực, gỡ bỏ).
- CubeSandbox: Sửa lại định tuyến khi tiếp tục và vô hiệu hóa bộ nhớ đệm, nhưng ingress riêng tư dùng thông tin xác thực trong phạm vi sandbox và chuyển tiếp mà không có hiện thân runtime dự kiến (định tuyến khi tiếp tục, định tuyến ingress). Việc sửa tuyến giúp thu hẹp khoảng thời gian tồn tại tuyến cũ; capability gắn với lần thực thi của SPACE còn cho bên nhận một cơ sở độc lập để từ chối hiện thân sai.
Danh tính như một ranh giới cô lập
Việc ủy thác an toàn phụ thuộc vào việc giữ công việc của mỗi tác nhân trong phạm vi ranh giới dành cho tác nhân đó. MicroVM cung cấp khả năng cô lập, còn nền tảng xung quanh phải đảm bảo mọi yêu cầu và kết nối đang diễn ra đều đến đúng lần thực thi được ủy quyền xử lý chúng.
SPACE đưa danh tính thực thi trở thành một phần của lớp bảo vệ đó. Bằng cách kiểm tra đích đến, xác minh các điểm cuối của cầu nối và gắn kết nối với lần thực thi đã ủy quyền cho chúng, SPACE duy trì những ranh giới đó khi sandbox tạm dừng, tiếp tục và di chuyển.
Chúng tôi đang tiếp tục công việc này khi hạ tầng phát triển. Đối với SPACE và các nền tảng sandbox khác, bảo mật đòi hỏi phải kiểm thử các đường đi này với cả lỗi định tuyến thông thường lẫn khối lượng công việc độc hại, sau đó củng cố các ranh giới ở bất cứ nơi nào các bài kiểm thử đó phát hiện lỗ hổng.