Jev Guard
为多种编码代理逐次评估工具调用，并拦截危险操作与提示注入。
按维度查看评分与理由
最小权限为2：只评估经宿主钩子或ACP代理经过的调用，并跳过只读工具，但安装会修改多个用户级代理配置，且会读取会话、转录和指令文件。用户确认为2：deny/ask/allow策略、ACP确认和多宿主适配均有代码测试，但Codex、Gemini等部分宿主无法原生ask，只能警告。数据流透明度为3：README明确列出发送的字段、两个服务端点、本地会话和缓存位置、密钥优先级及未覆盖路径。敏感数据处理为2：密钥文件使用0600且声称不交给代理，但工具结果可能含任意敏感内容并被发送给第三方；零保留只是请求，材料未证明服务端执行。依赖安全为2：运行时宣称零直接依赖并限定Node版本，降低供应链面，但可选peer依赖使用通配版本，且核心判断依赖远程模型/API。外部效果为2：危险操作可阻断或请求确认，安装具有幂等测试；然而默认故障开放，并允许明确用户请求把中风险ask提升为allow。回滚为1：易撤销操作进入风险模型，但未提供卸载命令、配置备份或恢复流程。来源归因为2：仓库、作者、许可证、Jev及价格资料来源均有标示，但发布者身份未经验证，维护主体仅以账号呈现。
自洽性为3：README中的阈值、宿主差异、上下文规则、注入判定和安装行为均与所示测试相互吻合。依赖可用性为2：API调用有三次重试、总超时、双后端和可配置故障关闭；但默认故障开放会在服务不可用时取消保护，且功能仍依赖外部Jev服务。失败消息为3：deny、ask、注入、技能异常、HTTP错误和超时均有明确消息或退出语义，并有相应静态测试；满分仅表示材料中的错误呈现充分，不代表已执行验证。
受众与场景为3：覆盖八类代理/协议、CI检查、技能扫描、GUI宿主和多种风险场景，并分别说明安装方式。能力边界为3：明确声明其是护栏而非沙箱，只能看到经过代理或钩子的路径，模型可能出错且应保留其他控制。触发精度为2：提供分级阈值、用户请求和不可信来源上下文、讨论内容豁免及大量测试，但短于200字符的结果、本地编辑/搜索结果和可配置跳过项会形成盲区，概率阈值也存在模型误判空间。环境适配为3：针对各宿主输出方言、绝对Node路径、GUI密钥读取、ACP及可调环境变量均有具体支持和测试证据。
信息架构为3：安装、决策、调优、CLI、开发、安全与源码布局清晰。安装说明为3：每个宿主都有命令、行为差异、密钥位置及通用CLI流程。命名稳定性为2：命令和环境变量体系一致，但项目仍处于0.3.1，且描述字段列举的宿主少于README，显示接口仍可能演进。示例与FAQ为3：包含危险调用、ACP配置、CI用法、阈值表和校准样例；虽无独立FAQ，常见操作问题已充分覆盖。已知限制为3：明确记录默认故障开放、钩子绕过、ACP可见范围、短结果跳过及非沙箱性质。许可证为3：MIT元数据与完整LICENSE一致。版本与变更记录为1：有明确包版本，但材料中没有CHANGELOG、发布历史或升级兼容说明。维护责任为2：提供作者、问题跟踪和私密安全报告渠道，但没有维护团队、响应时限或长期支持政策，且发布者身份未知。
输出可用性为3：决策被转换为各宿主可消费的deny、ask、warning、flag、异常和退出码，并包含原因与概率信息。边际价值为3：统一多宿主策略，将调用前风险、结果注入检测、会话上下文和技能扫描组合在一个工具中，材料显示相对于宿主原生控制有明确增量。成本收益为2：给出价格、延迟和缓存设计，零直接依赖也降低部署成本；但测量样本仅21次、部分性能与价格来自外部声明，且每次调用的网络延迟、隐私暴露和默认故障开放构成实际成本。
声明可追溯性为2：关键策略可定位到源码模块、环境变量、阈值和测试，外部价格与隐私声明也标出来源；但未提供相关核心源码文件、宿主清单文件或原始校准记录供本次材料内核验。跨来源印证为2：README、SECURITY、package元数据、许可证和广泛测试彼此支持，尤其印证阈值、安装、密钥权限和宿主方言；然而实时API、速度、662个技能扫描及端到端结果主要是仓库自述，未在所给材料中独立复核。事实与推断分离为2：文档多次区分claimed、measured、tested及限制，但仍用“正是”“不会注意”等推广性表述，并把静态可见的测试代码与已实际通过或线上测量的断言并列呈现。
- 默认故障开放：Jev不可达或超时时，保护可能只发出警告并允许调用；高风险环境应评估启用JEV_GUARD_FAIL_CLOSED=1的可用性影响。
- 工具调用、工作目录和工具结果会发送至TypeSafe或Vercel端点；敏感仓库可能因此向第三方披露源码、日志、凭据或个人数据。
- 覆盖取决于宿主钩子语义。内建网络访问、未经过钩子的工具路径、短于200字符的结果、部分本地工具结果和显式跳过列表可能绕过检查。
- 部分宿主不能真正暂停并询问用户，风险调用可能仅收到警告；部署前应逐宿主确认实际强制语义。
- 材料未提供卸载或配置恢复流程；安装前宜备份各代理的用户级配置。
- 本评估未执行代码、测试或联网复核；实时API表现、外部隐私承诺、价格、延迟和端到端兼容性仍需独立验证。
这个 Agent 能做什么，适合哪些场景？
Jev Guard 是一个面向编码代理的安全钩子，在工具执行前后调用 Jev 进行结构化风险判断。核心由 src/guard.js 的策略、src/context.js 与 src/session.js 的会话上下文、src/skills.js 的指令文件扫描，以及各宿主适配器组成。它把调用分为允许、询问或拒绝，并将工具结果中的提示注入和 canary 标记为不可信内容。项目支持 Claude Code、Codex、Copilot CLI、Gemini CLI、Cursor、pi、OpenCode，以及通过代理接入的 ACP 客户端，但不同宿主的审批能力并不一致。它通过 npm 包、原生钩子、插件或 ACP 代理部署；数据边界仍包含向 TypeSafe API 或 Vercel AI Gateway 发送工具调用或结果。
工具运行前，src/hook.js、src/opencode.js、extensions/jev-guard.ts 或 src/acp.js 接收宿主事件，并将工具名称、参数、当前目录和会话上下文交给 src/guard.js。守卫向 Jev 提交 risk、approval、user_requested 和 from_untrusted 等类型化问题：from_untrusted 达到 0.7 或 risk 达到 2.5 时拒绝；risk 达到 1.5 或 approval 达到 0.75 时通常要求审批；明确由用户请求的操作可从 ask 降为 allow，但不能解除 deny。工具返回后，它用 directed 和 kind 检测面向 AI 的 injection 或 canary，将命中内容写入会话的不可信上下文并警告代理不要执行。src/skills.js 还会扫描技能、插件、规则、CLAUDE.md 和 AGENTS.md，识别数据外传、隐蔽执行、指令覆盖、canary 与无关副作用，并按内容哈希缓存结果。CLI 提供 hook、acp、check、scan、scan-skills、install 和 key 命令，分别用于宿主集成、单次判定、内容扫描与配置。
- 同时使用 Claude Code、Codex 和其他编码代理的团队，希望用相同阈值与会话记忆审查各宿主的工具调用。
- 允许代理运行 shell、Git、部署或数据库命令，但希望破坏性操作被拒绝、敏感操作先征求人工批准的开发者。
- 让代理读取网页、命令输出或 MCP 结果，并担心外部内容夹带提示注入或 canary 指令的用户。
- 安装第三方技能、插件或规则文件前，需要筛查数据外传、隐蔽执行和指令覆盖行为的维护者。
- 希望在 CI 中用 jev-guard check 或 jev-guard scan 对自定义风险样例和阈值进行校准的安全工程师。
- 使用 Zed、JetBrains 等 ACP 客户端，需要在客户端与代理之间增加权限检查代理的团队。
这个 Agent 有哪些优点和局限？
- 同一核心覆盖八类编码代理或协议接入，并为不同宿主提供薄适配器和一致的会话策略。
- 不仅评估单次风险，还结合用户最近请求和已读取的不可信内容，能区分用户明确授权与外部内容植入的指令。
- 同时覆盖执行前判定、执行后提示注入检测和技能或插件指令文件扫描，而非只保护 shell 命令。
- 策略阈值、问题类型和判定顺序均有明确记录，并提供 check、scan 与 scan-skills 命令用于测试和校准。
- npm 包无运行时依赖，且 README 报告典型调用成本约为每次 0.00004 美元。
- 核心判定依赖 Jev 及外部 TypeSafe API 或 Vercel AI Gateway，需要网络连接、API 凭据，并会把工具调用或结果发送到外部服务。
- 它是安全护栏而非沙箱；配置错误、未经过钩子的内建工具或代理绕过路径都不在其完整控制范围内。
- Codex 和 Gemini 的相关钩子目前不能原生弹出 ask，因此风险操作只能转成警告；不同宿主的保护语义并不完全一致。
- 默认采用 fail-open，Jev 不可达时会警告后允许执行；要求强制阻断的环境必须显式设置 JEV_GUARD_FAIL_CLOSED。
- 短于 200 字符的结果以及本地编辑或搜索工具结果不会扫描，ACP 代理也只能看到实际经过客户端协议的数据。
- README 仅报告 Claude Code 和 OpenCode 的实时端到端验证；Codex、Copilot CLI、Gemini CLI 与 Cursor 主要按文档载荷格式测试。
如何安装或部署这个 Agent？
需要 Node.js 20.3 或更高版本，以及 TypeSafe 控制台密钥、vck_… Vercel AI Gateway 密钥，或有效的 VERCEL_OIDC_TOKEN。通用安装：
npm i -g jev-guardjev-guard key "你的密钥"
jev-guard install claude最后一条可将 claude 替换为 codex、copilot、gemini、cursor、pi 或 opencode。原生安装方式包括：Claude Code 运行 /plugin marketplace add leepokai/jev-guard 后运行 /plugin install jev-guard@jev-guard；Codex 运行 codex plugin marketplace add leepokai/jev-guard，随后从插件浏览器安装并用 /hooks 授予信任；Gemini CLI 运行 gemini extensions install https://github.com/leepokai/jev-guard；pi 运行 pi install npm:jev-guard；OpenCode 0.2.1 及以上版本在 opencode.json 中配置 "plugin": ["jev-guard"]。jev-guard key 默认把密钥以 0600 权限保存到 ~/.jev-guard/config.json。
如何使用这个 Agent？
先验证一个工具调用：
jev-guard check Bash '{"command":"rm -rf ~/"}'退出码 0、1、2 分别表示 allow、ask、deny。扫描文件可运行 jev-guard scan path/to/file，扫描已安装的技能、插件、规则及项目指令文件可运行 jev-guard scan-skills。宿主通过 jev-guard hook [--agent codex|copilot] 以 stdin/stdout JSON 调用统一钩子；ACP 场景使用 jev-guard acp -- <agent command...> 启动代理。可用 JEV_GUARD_DENY_SCORE、JEV_GUARD_ASK_SCORE、JEV_GUARD_ASK_P、JEV_GUARD_INJECT_P、JEV_GUARD_UNTRUSTED_P 和 JEV_GUARD_USER_P 调整策略。默认 API 不可用时会警告并放行；设置 JEV_GUARD_FAIL_CLOSED 后则改为拒绝。
这个 Agent 与同类方案有什么区别？
Claude Code 的 auto mode 使用独立分类模型审查操作；Jev Guard 用 risk、user_requested 和 from_untrusted 等类型化 Jev 问题实现相近的允许、询问和拒绝流程。它的主要差异是同一策略还能用于 Codex、Copilot CLI、Gemini CLI、Cursor、pi、OpenCode 和 ACP，并可在 Claude Code 内作为第二层判断；代价是依赖外部 Jev 服务，且部分宿主无法提供原生 ask 流程。