Node9
拦截、审计并约束 AI 编程代理执行的高风险操作。
按维度查看评分与理由
证据展示了按需启用的规则包、只读 CI 默认权限、非 root 沙箱、作用域挂载、默认拒绝的网络出口，以及云端审批不能被内联自批绕过，最小权限和人工确认设计充分。README 还明确区分本地处理、登录后上传、--ship 的脱敏快照、审计日志位置及扫描目录，并说明密钥会在存储前脱敏；外部效果和数据流因此较透明。依赖采用固定提交的 CI Action、生产依赖审计、独立引擎审计和关键覆盖版本，但普通 npm 依赖仍为范围版本，所给材料没有锁文件或审计结果，故依赖安全扣分。logout、uninstall、pin reset 和一次性容器提供部分恢复路径，但没有完整的配置还原、审计数据恢复或项目文件回滚说明。作者、仓库、相关项目和许可证有归属信息，但发布者身份未经验证且材料没有更完整的组织责任链，因此来源归属未满分。
README、SECURITY.md、包元数据和 CI 总体描述同一个拦截、审批、审计产品，且 CI 覆盖 Node 20/22、Windows/Linux、构建、类型检查、单元测试和端到端测试。主要不一致是 README 写 Node.js 18+，而 package.json 明确要求 >=20；这直接降低自洽性和环境依赖说明。依赖可通过 npm 或 Homebrew 获取，并有构建及审计流程，但材料没有锁文件、离线依赖策略或依赖服务故障的完整行为证据。错误处理可见审计“未运行”第三状态、不可读基线时从严回退、损坏 pin 状态失败关闭和卸载失败提示，但没有系统性的错误目录、退出码或故障排查示例，所以未满分。
材料清楚覆盖个人开发机、团队审批、CI、MCP、Python Agent、实时监控、历史扫描和容器隔离等受众与场景。能力边界明确指出本地主机代码执行者可绕过守护进程、Phase 1 沙箱以 Claude 为先、凭据仍在容器中、Response DLP 只告警不阻断，并区分 Node9 可修复和用户负责的问题。触发条件以具体 Git、SQL、Shell、云服务和 MCP 操作列举，还说明 Bash AST 分析、状态规则及审批路由，精度证据充分。环境适配涵盖 macOS/Linux、npm 跨平台、Windows CI、多种 Agent 与 Docker，但 README 与 package.json 的 Node 版本冲突，且沙箱的实际平台前提没有完整矩阵，因此 environment_fit 扣分。
README 的发现、保护、复盘、安装、规则包、审批、沙箱、MCP、数据解释和底层实现组织清楚，命令示例和输出样例丰富，已知限制也直接披露。Apache-2.0 元数据与完整 LICENSE 一致，可给满分。安装说明包含 Homebrew/npm、初始化、登录、诊断和 Node 要求，但 Node 18+ 与 package.json 的 >=20 冲突，且缺少升级与故障卸载的完整步骤。品牌与 CLI 基本稳定，但包名同时出现 node9-ai 与 @node9/proxy，容易让发行物关系产生疑问。semantic-release 配置和明确版本号支持自动版本管理，但没有提供 CHANGELOG 或用户可见的迁移记录。SECURITY.md 给出安全邮箱和响应时限，package.json 给出作者及问题入口；不过发布者未经企业注册验证，也没有维护团队、接班机制或一般支持承诺，故维护责任未满分。
输出包括终端记分卡、JSON、PR 评论、检查运行、实时仪表板、报告、审计日志以及每项发现的修复命令，能直接支持人工处置和 CI 门禁。它将历史发现、执行前治理、DLP、MCP 变更隔离和容器网络限制整合在同一工作流，相对于单纯日志或单点规则具有明显增量价值。成本方面，本地执行、无需账户的基本保护、公开仓库无令牌扫描和按需规则包降低采用成本，但代理挂钩、后台扫描、Docker、审批延迟、仪表板登录以及 Pro 功能边界的运营成本没有量化，效果主张也未由运行证据验证，因此 cost_benefit 未满分。
多数主张可对应到具体命令、配置字段、文件路径、CI 步骤、权限和威胁边界；README 的核心产品描述也由 SECURITY.md、package.json 和工作流在结构上交叉支持。扣分在于所给材料主要是项目自身文档和配置，截图分数、运行时性能、阻断效果、“原子”写入、AST 抗混淆效果及自扫描徽章结果没有独立报告或实现代码佐证。文档确实标注了 Phase 1、告警与阻断差异、从严回退及责任边界，但部分宣传性安全结论仍与事实陈述混排，未持续区分已证明结果、设计意图和示例输出。
- README 声称需要 Node.js 18+，但 package.json 要求 >=20；安装前应以包引擎约束为准并验证实际兼容版本。
- 守护进程不是安全沙箱；SECURITY.md 明确说明，已有本地代码执行权限的攻击者可以绕过它。需要强隔离时应另行验证 Docker 沙箱、挂载范围和内核出口规则。
- 登录和 node9 posture --ship 会引入远程数据流；尽管文档称上传内容会脱敏，部署前仍应审查实际字段、保留策略、密钥撤销和企业数据处理条款。
- Response DLP 只告警而不阻断；检测到响应或工具结果中的密钥后仍需轮换凭据并清理历史记录。
- 本次仅依据所给静态材料，未执行软件、测试依赖审计结果、规则绕过、审批路由、卸载恢复或沙箱隔离。
这个 Agent 能做什么，适合哪些场景？
Node9 是部署在 AI 代理与其工具之间的执行安全层，为工具调用提供规则评估、审批、阻断和审计。它通过执行前钩子接入 Claude Code、Codex CLI 等客户端，也能作为 stdio MCP 网关包装任意 MCP 服务器。命令行工具可以扫描历史会话与本机暴露面、评估仓库中的代理 CI 风险，并生成按时间窗口汇总的成本、工具使用、规则触发和影响范围报告。运行期防护包括命令与 SQL 检查、凭据 DLP、MCP 工具定义固定，以及针对 Git、数据库、云平台和文件系统的可选 shields。核心策略可在本机离线执行；登录后可把机器连接到 Node9 仪表盘，而可选的 Docker 沙箱提供受限挂载和内核级出站网络白名单。
典型流程从 node9 init 开始：它检测并接线本机代理与 MCP 服务器，使 Node9 在工具执行前通过钩子或 node9 mcp --upstream ... 网关检查调用。策略引擎分析 Shell、Git 和 SQL 操作，对 git push --force、无 WHERE 的 DELETE、curl | bash、凭据读取或密钥泄露等行为执行允许、审批或阻断，并把决定原子写入 ~/.node9/audit.log。node9 scan 读取 Claude、Gemini、Copilot 和 Codex 的本地历史目录，查找凭据泄露、循环和受阻操作；node9 posture 评估隔离、出站连接、磁盘密钥、供应链与权限风险。node9 scan-repo 以静态、只解析方式检查已提交的工作流和代理配置，输出 CI-1、CI-2、CI-3、CI-4、CI-6 等发现；GitHub Action node9-ai/node9-proxy@v2 可将其用作 PR 门禁。node9 monitor、node9 report、node9 tail 和 node9 sessions 提供实时活动或历史报告；node9 sandbox run 则在一次性 Docker 容器中运行代理，并限制挂载目录和允许访问的主机。
- 使用 Claude Code 或 Codex CLI 的开发者，希望在高风险 Shell、Git、SQL 或凭据操作真正执行前进行审批或阻断。
- 安全工程师需要回溯扫描本机代理会话，识别密钥泄露、重复循环、受阻操作以及代理当前可读取的凭据文件。
- 维护带有 AI 代理 GitHub Actions 的团队，希望在 PR 中检测可注入工作流、可外泄 secrets、未固定的 MCP 服务和被污染的指令文件。
- 运行 MCP 服务器的团队，需要代理无感的工具调用网关，并在工具名称、描述或 schema 发生变化时隔离连接。
- 希望缩小代理影响范围的开发者，可通过 Docker 沙箱限制文件挂载和出站主机，同时保留 Node9 的钩子、审批及审计。
- 平台或安全负责人需要按今天、周、月或 90 天查看不同代理的成本、常用工具、shields 触发和影响范围。
这个 Agent 有哪些优点和局限？
- 同时覆盖事后发现、执行前治理和按时间窗口复盘，并将结果统一落入本地审计日志。
- 支持钩子与透明 stdio MCP 网关两种接入模式，可覆盖多种编程代理、桌面客户端和任意 MCP 服务器。
- 策略不只做字符串匹配：Shell 分析使用 mvdan-sh AST，并提供 DLP、响应 DLP、skills 哈希校验和 MCP 工具定义固定。
scan-repo为静态、只解析检查，不执行仓库代码；GitHub Action 还可仅阻断当前 PR 新引入的问题。- 本地 enforcement 可离线运行；需要更强边界时，可选 Docker 沙箱增加受限挂载和内核级出站白名单。
- 核心 CLI 要求 Node.js 18+；完整沙箱功能还依赖 Docker。
- 沙箱目前标注为 Phase 1、单容器且 Claude 优先，Codex 支持仍在后续计划中。
- 沙箱内的代理仍持有自身凭据；当前依赖出站网络墙限制凭据用途，并未实现凭据代理。
- 只有 Claude Code 和 GitHub Copilot CLI 默认使用原生内联审批；Codex、Gemini、Cursor 等改用 Node9 自己的 approver。
- 仪表盘和机队视图需要执行
node9 login并连接 Node9 服务；完全离线使用时这些集中视图不可用。 - Node9 Pro 的治理锁定、SAML/SSO、集中审计导出和 VPC 部署不属于基础功能。
如何安装或部署这个 Agent？
需要 Node.js 18 或更高版本。macOS/Linux 可运行 brew tap node9-ai/node9 && brew install node9；任意受支持平台也可运行 npm install -g node9-ai。随后执行 node9 init 自动接线检测到的代理和 MCP 服务器，再运行 node9 doctor 验证配置。仅本地执行规则、shields、DLP 和审批不要求账户；如需仪表盘与机队视图，运行 node9 login，在浏览器中批准该机器。使用 node9 sandbox 还需要 Docker。
如何使用这个 Agent？
首次评估可在安装前运行 npx node9-ai scan，安装后使用 node9 scan。运行 node9 posture 获取本机安全评分及修复命令，用 node9 shield list 查看规则包，并按需执行如 node9 shield enable bash-safe 或 node9 shield enable project-jail。实时观察执行活动可运行 node9 monitor，文本流使用 node9 tail，七日报告使用 node9 report --period 7d。扫描公开仓库可运行 npx node9-ai scan-repo <owner/repo>；扫描本地检出则运行 node9 scan-repo .。要保护任意 MCP 服务，可将服务命令改为 node9 mcp --upstream <原始命令>，也可让 node9 init 自动包装。需要更强隔离时，在项目目录执行 node9 sandbox new、node9 sandbox run，并从宿主机运行 node9 sandbox tail。
常见问题
不登录 Node9 账户还能提供保护吗？
node9 init 后，本机规则、shields、DLP 和审批可以离线执行；未运行 node9 login 时，数据不会进入 Mission Control，仪表盘也会保持为空。Node9 会执行被扫描仓库中的代码吗？
node9 scan-repo 被描述为静态、只解析扫描，只读取已提交的配置；本地目录模式也不需要网络。被阻止或审批的操作如何留痕？
~/.node9/audit.log；之后可通过 monitor、report、tail 或 sessions 查看。