KechuAI

nono：Sigstore 团队给 AI Agent 做的"内核级"运行时安全护栏

AI Agent
安全
沙箱
Sigstore
供应链
开源工具
2026/10/3
·

阅读时间: 大约 7 分钟

nono：Sigstore 团队给 AI Agent 做的”内核级”运行时安全护栏

nono 官网首屏：标语"Agent runtime security，内核强制边界，零配置零延迟"，与 curl/brew 安装命令

让编码 Agent 在你机器上跑 shell、读文件、调 GitHub API，最大的顾虑不是”它会不会写错代码”，而是”它拿着你的凭证，能干出什么越权的事”。nono 给的答案是：给 Agent 运行时套一层内核强制的边界。它由 Sigstore 团队打造——Sigstore 正是 PyPI、Homebrew、Maven、Google、GitHub、NVIDIA 在用的软件签名标准，这套血统决定了 nono 从骨子里就是”供应链与运行时安全”的思路。安装很简单：curl -fsSL https://nono.sh/install.sh | sh 或 brew install nono，然后 nono run --profile nolabs-ai/pi -- pi 就能把任意终端 Agent 跑在沙箱里。

一、核心概念：瞬时微工具箱（ephemeral micro toolbox）

nono 不是给整个 Agent 开一个大虚拟机，而是对每一次工具调用单独发一个一次性的微沙箱。官网原话是：“Every tool execution. Isolated and scoped.”——每次执行都按它真正需要的文件、网络路由、参数和凭证来收权，执行完立刻销毁。

二、Broker 架构：Agent 永远不直接碰工具

这是 nono 最关键的设计判断：Agent 从不直接和被隔离的工具对话。请求、凭证、网络流量、stdio、审计事件，全部要穿过 supervisor 这道边界。官网把一次 gh issue view 调用拆成五步：

  1. 可执行体：supervisor 解析并校验可执行文件的身份与 digest；
  2. Argv 策略：按调用者 + 参数做授权；
  3. 能力收放：批准后才生成一个全新的、仅本次调用有效的微沙箱——只读工作区、禁止写盘、拿不到宿主密钥、stdout/stderr 有上限、网络只能走 nono 代理；
  4. 凭证：沙箱拿到的是一个幻影 GH_TOKEN，真凭证留在 supervisor 金库里，从不进子进程；
  5. L7 代理：校验幻影 token、按 HTTP method + path 判策略、在边界注入真凭证、再经 TLS 转发到 api.github.com。

策略外的动作会路由到人在回路：approve / deny / timeout。安全相关事件被哈希串成链，最终用 SHA-256 Merkle 根封印成一份防篡改审计记录，调用结束沙箱即销毁。

三、四种裁决结果（官方给出的场景）

场景行为
Allowed readgh issue view 正常跑，代理放行 POST /graphql，结果回给 Agent
Human approvalgh pr merge 不匹配任何 argv 规则，整条调用挂起等人批准后再在沙箱里执行
Argv deniedgh issue comment 在 argv 授权阶段就被拒，根本不创建沙箱、不发任何出站请求
L7 deniedgh api 过了宽泛的 argv 规则，但代理层发现是 POST 到评论端点，在 L7 被拒，请求到不了 GitHub

这种”argv 一层、L7 一层”的双重检查，意味着即使你给了 gh 比较宽的权限，危险动作仍会在网络层被拦下。

四、兼容面

nono 号称能沙箱住”任意终端 Agent”，不需要改你的 Agent 代码（no wrappers, no rewrites），从注册表拉一个已签名的 profile 就能跑。官网列出的合作 Agent 包括 Claude Code、OpenCode、Codex、Antigravity、Goose 等。

五、口径偏差与现实边界

  1. “零延迟”是有口径的：它指的是内核边界本身的额外开销接近零，并不等于整条链路零开销——每次工具调用都要过 supervisor 解析、argv 判定、L7 代理转发，串行链路上多了一跳；对高频小调用的场景，实测延迟要自己压。
  2. 安全姿态取决于你的策略写得好不好：默认拒绝 + 幻影凭证是好的基线，但 argv/L7 规则需要你自己维护；规则写太松等于没防护，写太严又会天天弹人审。
  3. 它是本地 CLI / supervisor，不是托管平台：审计链 Merkle 根封印得漂亮，但你得自己去存、去看、去告警，封印本身不会主动报警。
  4. “任意 Agent 都能沙箱”是能力声明：深度（能否拦截子进程衍生、能否覆盖所有网络栈）随 Agent 与平台而变，官方以 Linux 内核机制为主，跨平台边界要留意。

六、客观评价

优势：

  1. 血统正：Sigstore 团队做运行时安全，签名 profile + digest 校验把供应链信任也一起考虑了；
  2. 凭证隔离干净：幻影 token + supervisor 金库，真密钥永不进子进程，直击 Agent 凭证泄露这条最大风险；
  3. 双层裁决：argv 层先挡一刀、L7 代理再挡一刀，危险动作能在”不发请求”阶段就被掐掉；
  4. 零侵入：不改 Agent 代码，装个 CLI 就能套上护栏。

局限：

  1. 多了一道代理跳，“零延迟”需实测；
  2. 策略维护是持续成本，默认配置不等于企业级防护；
  3. 审计要自己接存储与告警；
  4. 仍偏早期，跨平台与对各类 Agent 的覆盖深度待验证。

七、适合谁用

  • 已经在生产/本机大量跑编码 Agent、最担心凭证外泄与越权写操作的工程师与团队；
  • 需要一份可审计、防篡改的 Agent 操作记录以满足合规的人；
  • 认同 Sigstore 供应链思路、想把”软件签名”延伸到”运行时边界”的安全团队。

参考来源