OpenShell: runtime policy cho fleet AI agent của NVIDIA

OpenShell cô lập AI agent trong sandbox, thực thi policy ở cấp kernel và chỉ gắn credential vào endpoint được duyệt. Với DevOps/SRE, đây là một lớp kiểm soát để agent đọc file, gọi API và chạy tác vụ mà không được trao quyền truy cập không giới hạn.

Một AI agent được giao xử lý pipeline lỗi có thể cần đọc mã nguồn, cài công cụ, gọi API và dùng credential. Vấn đề không nằm ở việc cho agent làm được bao nhiêu việc, mà là giới hạn chính xác nó được làm gì, ở đâu và với credential nào.

OpenShell của NVIDIA nhắm vào lớp runtime này. Dự án mô tả đây là runtime an toàn, riêng tư cho các fleet AI agent tự chủ: agent có thể làm việc trong sandbox, nhưng không được mặc định truy cập không giới hạn vào dữ liệu, secrets hay mạng.

Với DevOps, SRE và platform engineer, điểm đáng chú ý là quyền của agent được đưa về các thành phần có thể quản trị: sandbox, policy, gateway và luồng phê duyệt.

OpenShell kiểm soát agent như thế nào?

Theo README, OpenShell thực thi policy theo hai hướng:

Thực thi ở cấp kernel: mỗi agent chạy trong sandbox cô lập. Các kiểm soát kernel giới hạn file agent có thể truy cập, system call agent có thể thực hiện và kết nối mạng agent có thể tạo. Kiểm tra kết nối mạng theo policy: mọi kết nối mạng được kiểm tra trước khi rời sandbox. Credential chỉ xuất hiện tại endpoint được duyệt: agent không nhìn thấy credential thật; OpenShell chỉ thêm credential vào request đi tới endpoint đã được phê duyệt. Kiểm chứng thay đổi policy: trước khi một thay đổi policy được phê duyệt, OpenShell dùng formal verification để đánh dấu quyền truy cập mới có rủi ro — ví dụ gọi host mới bằng credential hoặc dùng API method mới. Những thay đổi đó cần chờ người review.

Kiến trúc của dự án gồm gateway, supervisor và sandbox. Trong đó, gateway là control plane cho sandbox, policy và quyền truy cập.

Điều này tạo ra một cách mô tả quyền cụ thể hơn thay vì chỉ nói “agent được deploy”: agent chạy trong sandbox nào, chạm vào vùng file nào, được gọi endpoint nào và khi nào credential được gắn vào request.

Thử nhanh: tạo sandbox trước

OpenShell hỗ trợ Linux, macOS trên Apple Silicon và Windows qua WSL 2 ở trạng thái thử nghiệm. Môi trường cần có Docker, Podman hoặc host virtualization.

Quickstart của dự án là:

shell curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh openshell sandbox create --name demo

Trình cài đặt thiết lập CLI cùng local gateway. Lệnh thứ hai tạo sandbox tên demo.

README lưu ý image sandbox mặc định là Ubuntu tối giản và chưa có agent được cài sẵn. Vì vậy, việc tạo sandbox không đồng nghĩa agent đã có sẵn framework, quyền truy cập repository hay quyền mạng.

Để chạy một agent thực tế, tài liệu chính thức có hướng dẫn chạy OpenCode với một model OpenRouter miễn phí, đồng thời cho phép phê duyệt quyền mới khi agent cần.

Với đội platform, nên bắt đầu bằng workload có phạm vi hẹp: phân tích log đã được lọc, đọc source code không nhạy cảm hoặc đề xuất thay đổi trong một repository thử nghiệm.

Skills cho coding agent: hữu ích, nhưng không thay human review

OpenShell có public skills cho coding agent:

shell npx skills add NVIDIA/OpenShell

Theo README, các skills này hướng dẫn agent dùng OpenShell CLI, viết sandbox policy và debug gateway hoặc inference routing.

Đây là lớp hỗ trợ thao tác, không phải cơ chế phê duyệt quyền. Một agent có thể đề xuất policy; người chịu trách nhiệm platform hoặc security vẫn cần review phạm vi truy cập trước khi policy được áp dụng.

Đưa vào Kubernetes: gateway, Helm và NetworkPolicy

OpenShell có các thành phần mở rộng được nêu trong tài liệu:

Sandbox: image, runtime, GPU và lifecycle. Policy: quy tắc filesystem, network và process. Provider: credential chỉ hoạt động tại endpoint được phê duyệt, bao gồm inference. Gateway: control plane cho sandbox, policy và access. Extensibility: middleware, interceptor và compute driver.

Trên Kubernetes, gateway có thể được triển khai bằng Helm. README nêu một điều kiện rõ ràng: CNI của cluster phải thực thi NetworkPolicy.

Đây là điểm cần đưa vào checklist triển khai. Trước khi dùng OpenShell trong cluster, đội SRE nên xác nhận cơ chế thực thi network policy của CNI đang dùng và kiểm tra kỹ policy egress/ingress liên quan đến agent workload.

Một luồng vận hành có thể giữ agent trong vai trò hỗ trợ thay vì trao quyền kiểm soát hạ tầng:

Agent nhận issue, log hoặc diff đã được chọn lọc. Agent phân tích trong sandbox và tạo đề xuất hoặc patch. Agent chỉ gọi các endpoint đã có policy. Mọi nhu cầu mở thêm host, API method hoặc phạm vi credential được đưa vào review. Con người review thay đổi trước khi merge hoặc apply qua CI/CD hiện có.

Prompt để review policy, không tự cấp quyền

Không nên đưa kubeconfig, token, .env, credential cloud hoặc log có dữ liệu nhạy cảm vào prompt. Thay vào đó, hãy cung cấp dữ liệu đã redacted và yêu cầu agent tạo đầu ra có thể review.

text Bạn là platform engineer hỗ trợ review policy cho AI agent.

Bối cảnh: Nhiệm vụ agent: <môtảtácvụ> Dữ liệu agent cần đọc: <danhsáchvùngdữliệuđãlọc> Endpoint được phép gọi: <danhsáchendpoint> Các thao tác bị cấm: <danhsáchthaotác> Môi trường: <dev/staging/production>

Hãy: Liệt kê quyền tối thiểu theo filesystem, network và process. Chỉ ra quyền nào có thể làm tăng phạm vi ảnh hưởng. Đề xuất các câu hỏi cần human review trước khi mở thêm quyền. Không yêu cầu, suy đoán hoặc tạo secrets, token, kubeconfig hay credential thật. Trả lời bằng bảng: quyền / lý do / rủi ro / người cần duyệt.

Đầu ra mong muốn không phải là một policy mở rộng để “dễ debug”, mà là danh sách quyền hẹp, các ngoại lệ được gắn cờ và câu hỏi rõ ràng cho reviewer.

Formal verification không thay thế change management

OpenShell cho biết họ dùng formal verification để kiểm tra quyền mới mà thay đổi policy có thể mở ra trước khi áp dụng. Đây là một lớp kiểm soát cho policy, nhưng vẫn nên được đặt trong quy trình vận hành hiện có.

Trước khi áp dụng thay đổi do AI đề xuất, đội platform có thể duy trì các cổng kiểm soát quen thuộc:

So sánh diff với policy hiện hành. Xác định host, API method, file path hoặc process mới được mở. Chạy plan hoặc dry-run khi công cụ IaC hay manifest hỗ trợ. Chạy linter, scanner và policy-as-code của tổ chức. Review thay đổi liên quan đến egress, credential provider và môi trường production. Thử nghiệm ngoài production trước khi áp dụng rộng hơn.

Mục tiêu là tách rõ hai vai trò: agent có thể đề xuất, còn việc thay đổi hạ tầng vẫn đi qua các control của CI/CD và người có trách nhiệm phê duyệt.

Telemetry và phiên bản cần lưu ý

OpenShell cho biết họ thu thập telemetry ẩn danh, giới hạn ở các danh mục vận hành và số lượng. Theo dự án, telemetry không thu sandbox name, hostname, file path, prompt, credential, tên provider/model hoặc nội dung người dùng.

Có thể tắt telemetry tại gateway bằng:

shell OPENSHELLTELEMETRYENABLED=false

Với Helm, cấu hình được nêu là:

text server.telemetryEnabled=false

Dự án cũng cho biết có thể biên dịch để loại telemetry hoàn toàn. Đội security vẫn nên đối chiếu cấu hình này với chính sách dữ liệu nội bộ và kiểm tra triển khai thực tế của mình.

README đánh dấu dòng 0.1.x với stable release cadence, isolation primitives mới, extension surface mở rộng và API mới. Khi dùng SDK, dự án khuyến nghị dùng cùng release với gateway khi có thể.

Checklist trước khi mở rộng thành fleet

[ ] Bắt đầu ở máy lab hoặc namespace không production. [ ] Tạo một sandbox và thử một tác vụ phạm vi hẹp. [ ] Xác định rõ file, process, endpoint và credential cần thiết. [ ] Xác nhận CNI thực thi NetworkPolicy nếu triển khai trên Kubernetes. [ ] Không đưa secrets hay credential thật vào prompt hoặc context của agent. [ ] Review các policy mở thêm host, API method hoặc phạm vi credential. [ ] Kiểm tra thay đổi qua quy trình CI/CD, review và môi trường thử nghiệm. [ ] Quyết định cấu hình telemetry theo chính sách dữ liệu của tổ chức.

OpenShell không thay thế quy trình bảo mật hay change management. Giá trị của nó nằm ở việc cung cấp một runtime có sandbox, policy, gateway và kiểm tra quyền truy cập — các điểm kiểm soát mà platform team cần khi AI agent bắt đầu thực hiện tác vụ có khả năng chạm tới hệ thống thật.