OpenShell：NemoClaw 背後的安全執行環境

如果說 NemoClaw 是安全堆疊，那麼 OpenShell 就是它的基石。由 NVIDIA 安全工程團隊在過去 18 個月中開發，OpenShell 為 AI 代理執行提供核心層級沙箱化——確保即使代理被完全攻破也無法存取其安全邊界之外的資源。

本文是對 OpenShell 架構、隔離機制以及它如何以最小效能額外負擔執行安全策略的技術深度解析。

為什麼需要核心層級隔離？

傳統的應用程式沙箱化——容器、虛擬機器、程序層級隔離——是為行為可預測的軟體設計的。AI 代理則根本不同。它們在執行階段產生自己的執行計畫，進行與外部系統互動的工具呼叫，並且可以產生任何測試套件都未曾預料到的新行為。

這種不可預測性要求安全模型在盡可能底層的層級運作：即核心層級。OpenShell 攔截代理程序發出的每一個系統呼叫，根據現行安全策略對其進行分類，並在呼叫到達核心之前做出允許/拒絕的決策。

Agent Process
     │
     ▼
OpenShell eBPF Layer  ←── Policy Engine
     │
     ├── ALLOW → System Call → Kernel
     │
     ├── DENY → Error returned to agent
     │
     └── ESCALATE → Human approval queue

eBPF：OpenShell 背後的技術

OpenShell 基於 eBPF（擴充柏克萊封包過濾器）建構，這是一項 Linux 核心技術，允許自訂程式在核心空間執行而無需修改核心本身。NVIDIA 團隊編寫了一套專門針對 AI 代理工作負載最佳化的 eBPF 程式：

系統呼叫攔截器

系統呼叫攔截器掛載到 sys_enter 追蹤點，對每個系統呼叫根據現行策略進行評估：

// Simplified OpenShell eBPF syscall interceptor
SEC("tracepoint/raw_syscalls/sys_enter")
int openshell_syscall_enter(struct trace_event_raw_sys_enter *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    struct sandbox_policy *policy = bpf_map_lookup_elem(&sandbox_policies, &pid);

    if (!policy)
        return 0;  // Not a sandboxed process

    long syscall_nr = ctx->id;
    int decision = evaluate_policy(policy, syscall_nr, ctx->args);

    if (decision == DENY) {
        // Send event to userspace audit log
        emit_security_event(pid, syscall_nr, DENY);
        // Override return value to -EPERM
        bpf_override_return(ctx, -EPERM);
    } else if (decision == ESCALATE) {
        // Pause the process and notify approval queue
        emit_approval_request(pid, syscall_nr, ctx->args);
        send_signal(pid, SIGSTOP);
    }

    return 0;
}

檔案系統守衛

檔案系統守衛限制代理可以存取的檔案和目錄。它在 VFS（虛擬檔案系統）操作層級運作，攔截 open、read、write、unlink 和 rename 呼叫：

yaml

# Filesystem policy for a customer support agent
filesystem:
  # Agent can read its own configuration
  - path: "/etc/nemoclaw/agent.yaml"
    permissions: [read]

  # Agent can read/write to its workspace
  - path: "/var/nemoclaw/workspace/**"
    permissions: [read, write, create]

  # Agent can read shared data
  - path: "/var/nemoclaw/shared/**"
    permissions: [read]

  # Everything else is denied by default
  defaultAction: deny

網路哨兵

網路哨兵掛鉤到通訊端操作，在連線層級控制代理的網路存取：

SEC("cgroup/connect4")
int openshell_connect4(struct bpf_sock_addr *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    struct network_policy *policy = bpf_map_lookup_elem(&net_policies, &pid);

    if (!policy)
        return 1;  // Allow non-sandboxed processes

    __be32 dst_ip = ctx->user_ip4;
    __be16 dst_port = ctx->user_port;

    if (!is_allowed_destination(policy, dst_ip, dst_port)) {
        emit_security_event(pid, NETWORK_BLOCKED, dst_ip, dst_port);
        return 0;  // Block connection
    }

    return 1;  // Allow connection
}

策略執行架構

OpenShell 策略被編譯為 eBPF 位元組碼，以實現最高的執行速度。編譯管線工作流程如下：

1.YAML 策略檔案由安全團隊以人類可讀格式編寫
2.策略編譯器將 YAML 轉換為中間表示（IR）
3.Nemotron 策略驗證器檢查 IR 的邏輯一致性和衝突
4.eBPF 編譯器產生經過驗證的位元組碼並載入到核心中
5.執行階段驗證器確保 eBPF 程式能夠終止且記憶體安全

對於典型策略集，整個編譯管線在 2 秒內完成，策略可以熱重載而無需重新啟動代理。

bash

# Compile and load a policy
nemoclaw policy compile policies/customer-support.yaml
nemoclaw policy load customer-support

# Hot-reload a modified policy (no agent restart required)
nemoclaw policy reload customer-support

# Verify policy is active
nemoclaw policy status
# Output:
# POLICY              STATUS    LOADED AT            RULES
# customer-support    active    2026-03-19 14:30:01  47
# network-default     active    2026-03-19 14:30:01  12
# filesystem-strict   active    2026-03-19 14:30:01  23

操作員審批工作流

OpenShell 最具特色的功能之一是其內建的操作員審批系統。當代理嘗試被分類為高風險的操作時，OpenShell 會暫停代理執行，並將審批請求路由給人工操作員。

審批運作原理

1.代理嘗試高風險系統呼叫（如寫入受保護檔案、連接未核准的端點）
2.OpenShell 的 eBPF 程式向代理程序傳送 SIGSTOP 訊號
3.產生審批請求並透過設定的管道傳送（Slack、Teams、PagerDuty、電子郵件）
4.操作員審查請求上下文並核准或拒絕
5.如果核准，OpenShell 傳送 SIGCONT 恢復代理；如果拒絕，回傳 EPERM

審批請求包含完整的上下文：

json

{
  "request_id": "apr-2026031914-00042",
  "agent": "customer-support-agent-01",
  "action": "email.send",
  "target": "[email protected]",
  "context": {
    "ticket_id": "TKT-12345",
    "customer_name": "[REDACTED]",
    "reason": "Agent wants to send a follow-up email to the customer regarding their refund request",
    "email_preview": "Dear Customer, your refund of $250 has been processed..."
  },
  "risk_level": "medium",
  "policy_rule": "external-communication-requires-approval",
  "timestamp": "2026-03-19T14:30:42Z"
}

審批逾時與預設操作

操作員可以設定審批逾時後的行為：

yaml

approvalConfig:
  timeout: 15m
  onTimeout: deny          # deny | allow | escalate
  onEscalate:
    target: security-team
    channel: pagerduty
  maxPendingApprovals: 10  # Queue limit per agent
  autoApprove:
    # Automatically approve if the same action was approved
    # 3 times in the past 24 hours for this agent
    repeatThreshold: 3
    repeatWindow: 24h

效能特性

OpenShell 專為延遲敏感的生產工作負載設計。以下是在 DGX Spark 上量測的額外負擔：

操作	額外負擔
系統呼叫攔截（允許）	8 微秒
系統呼叫攔截（拒絕）	12 微秒
檔案系統檢查	15 微秒
網路連線檢查	20 微秒
策略熱重載	< 500 毫秒
審批往返（Slack）	2-30 秒（取決於人工回應）

作為對比，典型的 LLM 推論呼叫需要 500 毫秒至 5000 毫秒，因此 OpenShell 的額外負擔在代理工作負載的背景下可以忽略不計。

與現有沙箱方案的比較

特性	OpenShell	Docker/OCI	gVisor	Firecracker
隔離層級	核心（eBPF）	命名空間	使用者空間核心	微虛擬機器
系統呼叫過濾	按策略，可熱重載	靜態 seccomp	完全攔截	完全隔離
網路策略	按代理，L7 感知	iptables	iptables	iptables
人工審批	內建	無	無	無
AI 感知策略	是（Nemotron）	否	否	否
額外負擔	約 10 微秒	約 5 微秒	約 50 微秒	約 100ms 啟動
GPU 直通	原生	NVIDIA CTK	有限	有限

OpenShell 的核心差異化在於它從一開始就是為 AI 代理工作負載設計的，內建支援自然語言策略、人工審批工作流和 GPU 加速策略評估。

開始使用 OpenShell

OpenShell 可以脫離 NemoClaw 堆疊的其餘部分獨立使用：

bash

# Install OpenShell standalone
curl -fsSL https://github.com/NVIDIA/OpenShell | bash

# Create a minimal sandbox policy
cat > my-policy.yaml << 'EOF'
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
  name: my-first-sandbox
spec:
  isolation:
    network: restricted
    filesystem: workspace-only
    syscalls: minimal
EOF

# Run any process inside the sandbox
openshell run --policy my-policy.yaml -- python my_agent.py

OpenShell 以 Apache 2.0 授權條款開源，可在 GitHub 的 nvidia/openshell 取得。在下一篇文章中，我們將探索完整 NemoClaw 堆疊的實際企業部署場景。

OpenShell：NemoClaw 背後的安全執行環境