跨 harness 对比：安全与权限（审批门、密钥管理）
一、总览：这个维度的设计谱系
61 个 harness 在”该不该让 agent 执行这一步、密钥怎么管”上的做法，可以归到六条主线，且它们常常叠加：
-
规则引擎流（allow / ask / deny 三态 + 模式匹配）——最主流。一张有序规则表，pattern（
Bash(git *)、Write(**/*.ts)、mcp__server__tool）× action，first-match 或 last-match 定胜负，deny > ask > allow优先级几乎是行业共识。Claude Code 定义了语法，opencode、MiMo-Code、Kimi Code、Qwen Code、Kilo Code、AgentScope、Continue、Amazon Q、Kiro 全是同一套骨架的方言。 -
LLM 介导的动态审批（模型给模型把关）——把”这步危不危险”交给另一个（或同一个）LLM 实时判定，而非静态白名单。这是 2025–2026 最有代表性的分化：Codex 的 Guardian、Gemini CLI 的 ConSeca、Claude Code 的 Auto-mode 分类器、Cursor 的 Auto-review、goose 的 SmartApprove、CAMEL 的 LLMGuardRuntime、Factory 的 Droid Shield LoRA 门控。
-
档位/自主度模型（autonomy level）——用一个从”啥都问”到”啥都不问”的连续旋钮统摄多个开关，把风险等级和自主度对齐。Factory 的 Autonomy Level（Off/Low/Medium/High）、Plandex 的 none/basic/plus/semi/full、goose 的 GooseMode 四态、Warp 的 execution profile。
-
确定性硬地板（不可绕过的拒绝列表）——正则/字符串黑名单，任何模式（含 YOLO）都覆盖不掉。Hermes 的
UNRECOVERABLE_BLOCKLIST、Zed 的HARDCODED_SECURITY_RULES、Factory 的 blocklist、v0 的系统级拒绝列表、Claude Code 沙箱里针对裸 git 仓库 CVE 的防御。 -
框架层 HITL 原语（deferred / interrupt / approval）——SDK 类 harness 不做策略引擎，只给一个”暂停等人批准”的抽象。LangGraph 的
interrupt()、OpenAI Agents SDK 的needs_approval、Pydantic AI 的ApprovalRequired/deferred、Google ADK 的request_confirmation、Agno 的@approval、Letta 的requires_approvaltool rule。 -
无审批门（信任 LLM + 靠隔离兜底）——刻意或疏于设计地不设逐步确认，安全全压在沙箱/容器/域名白名单上。SWE-agent、Trae、browser-use、OpenManus、Agent Zero、UI-TARS、MetaGPT。
正交于审批门的还有两条独立线：hooks 作为确定性安全边界（PreToolUse 退出码 2 硬阻断，被多家明确称为比 prompt 更可信的策略层）与密钥管理（从明文环境变量到 OS keychain、加密 vault、别名注入、端到端 HPKE 信封，跨度极大）。
二、对比表
| harness | 审批门模型 | 不可绕过的硬地板 | LLM 介导判定 | 密钥管理 |
|---|---|---|---|---|
| Claude Code | 三层权限 + plan/bypass 模式 | 沙箱防御性拒写（settings/裸 git CVE） | Auto-mode 两阶段分类器（对推理盲） | 沙箱路径排除 ~/.aws/SSH；web 版凭证永不入沙箱 |
| Codex | AskForApproval 四态 + 静态预检 | workspace-write 下 .git/.codex 恒只读 | Guardian LLM 审查会话，fail-closed | keyring 后端（MCP OAuth）；secrets/ crate |
| Gemini CLI | 5 级优先级 TOML 策略引擎 | admin 策略 OS 层强制所有权 | ConSeca：逐 prompt 生成最小权限 ACL | OS keychain（apiKeyCredentialStorage） |
| Cursor | hooks allow/deny/ask + Auto-review | — | Auto-review 分类器（同 RPC 流，约 4% 拦截） | 1Password 校验、MCP 治理伙伴集成 |
| opencode | 有序 Ruleset，last-match，默认 ask | — | — | 独立 Auth/Credential/McpOAuth 服务 |
| MiMo-Code | allow/deny/ask，deny 恒优先 | FORCED_ASK（bash_delete 永远现场问） | doom-loop 检测强制 ask | auth.json 0600 原子写，CI 可注入不落盘 |
| Kimi Code | 19 步策略链引擎 | 敏感文件/.git 恒 ask（但 Bash 不设防，诚实披露） | — | ~/.kimi-code/credentials/ 0700/0600 原子写 |
| Qwen Code | L3→L4→L5 三层流，plan 强制转 ask | ssrfGuard 封云元数据 IP | 只读 shell 经 AST 分类自动放行 | OS 密钥链（keytar）存 MCP OAuth |
| AgentScope | 独立 PermissionEngine，5 模式 | dangerous_files/dirs 黑名单 | 每工具自判只读 | credential/ 模块，支持跨用户/组织共享 |
| Kilo Code | Ruleset，always 持久化 | ConfigProtection（config 编辑禁 always）、hardRuleset veto | — | oauth/api key，gitleaks，kilo-memory 脱敏 |
| Continue | 三态 allow/ask/exclude，plan/auto 模式 | disabled 策略永远优先 | Bash 接安全评估器 | AuthService，无 secret redaction |
| Roo Code | askApproval + 自动审批上限（次数/成本） | containsDangerousSubstitution 正则恒 ask、写保护 glob | — | 推测 VS Code SecretStorage（未确认） |
| Cline | toolPolicies autoApprove + hub 路由审批 | — | — | VS Code SecretStorage（OS keychain） |
| OpenHands | ConfirmationPolicy + LLM 自报 security_risk | PatternSecurityAnalyzer 正则兜底 | LLM 逐调用自报 LOW/MED/HIGH | SecretRegistry 按引用注入、序列化脱敏 |
| goose | GooseMode 四态 + PermissionInspector | 供应链 OSV.dev 恶意包拒启动 | SmartApprove 的 LLM-as-judge 只读分类 | 未深查（oauth 模块存在） |
| Amazon Q | PermissionEvalResult 逐工具 allow/ask/deny | — | autoAllowReadonly | AWS SSO OIDC/PKCE，只有短期 token，无静态 key |
| Kiro | 统一权限模型 {capability,effect}，5 作用域 | Kiro 作用域硬编码禁写自身权限配置 | — | KMS 静态加密，可自带客户 CMK |
| Factory | Autonomy Level 四档 + 命令风险标签 | blocklist 绝对（--skip-permissions 也拦） | Droid Shield Risk/Downgrade LoRA 门控 | Downgrade 模型架构上看不到真实密钥值 |
| Warp | 按 profile 允许/拒绝列表，带原因编码 | 组织策略强制项用户不可覆盖 | AgentDecided 原因码 | HPKE 信封（Tink）+ 值不可取回 + 工作负载身份联邦 |
| Devin | 接管暂停 + AI Guardrails 消息筛查层 | Guardrails kill_session 档 | Guardrails 分类器（prompt injection/泄露） | 4 类密钥 × 4 作用域体系；cog_ token RBAC |
| Copilot Agent | 逐工具 + 两步 URL 审批 | eligibleForAutoApproval 组织强制人批 | — | BYOK API key 从不落盘，每次由宿主重供 |
| Junie | allowlist.json + Brave 三档 | 项目级 hooks 默认忽略（防仓库注入） | Brave Auto 内部安全分类器 | 订阅 auth / BYOK；日志屏蔽 key |
| Qoder | 5 模式 + 8 层设置优先级 | hook deny 覆盖 bypass（“unbypassable”） | — | OIDC token 交换、::add-mask::、参数脱敏 |
| Amp | 默认不再审批（Neo 后）；Plugin 权限引擎 | Enterprise MCP registry 不可达=fail-closed | amp.ai.ask() 分类高风险 git | 最底层密钥脱敏 [REDACTED]，早于入线程 |
| v0 | 三层审批 + pending task 抽象 | 系统级无条件拒绝列表 | 执行前代码分析 | NEXT_PUBLIC_ 静态分析自动重构 |
| Zed | Agent Profile 三档 + 逐次审批 | HARDCODED_SECURITY_RULES 任何设置不可覆盖 | — | — |
| Hermes | approvals.mode 三态（manual/smart/off） | UNRECOVERABLE_BLOCKLIST 任何机制不可绕过 | smart 模式辅助 LLM 风险评估 | MCP 凭证环境隔离；contextvars 防竞态泄露 |
| QwenPaw | 五层安全栈 + approval_level 四态 | File Guard 保护 ~/.qwenpaw.secret/ | Skill Scanner 静态签名 | secret_store.py 加密存 provider/MCP 凭证 |
| AutoGPT | CommandPermissionManager 分层 + 批准泛化 | — | — | .env 加载，缺失快速失败 |
| deepagents | FilesystemPermission + interrupt 模式 | grep(path=None) 无条件中断 | — | 无 vault，仅环境变量（THREAT_MODEL 承认 gap） |
| LangGraph | interrupt() 原语 + Server 端授权回调 | — | — | 服务端 Auth 类（非图库本身） |
| OpenAI Agents SDK | needs_approval + run 级 interruptions | Guardrail tripwire 中止 run | Input/Output/Tool guardrails | 极少内建；警告 RunState 序列化会嵌密钥 |
| Pydantic AI | ApprovalRequired/CallDeferred 冒泡 | — | 第三方 pydantic-ai-shields | _ssrf.py 防护；无自建 vault |
| Google ADK | request_confirmation 中断 invocation | — | — | 完整 auth/：CredentialManager/token 交换/刷新 |
| Agno | @approval（required 阻塞 / audit 非阻塞）+ 三态 HITL | guardrail 同步先跑全过才放行 | PromptInjection/PII/Moderation guardrails | 无 store，env/参数传 key |
| Letta | requires_approval tool rule + 工具规则闸门 | valid_tools 白名单越界即拒 | — | SandboxCredentialsService webhook 拉凭证 |
| CAMEL | LLMGuardRuntime 每工具 LLM 打风险分 | — | guard ChatAgent 1-3 分量表，>阈值拒 | env 变量；unsafe_mode 默认 False |
| DeerFlow | GuardrailMiddleware + Clarification 审批 | fail_closed 默认 True | 可插拔 GuardrailProvider（OAP） | secret_context.py；Claude OAuth token |
| CrewAI | before_tool_call hook 阻断 | — | — | Fernet 加密 OAuth token 落盘（企业登录） |
| browser-use | 无审批门，靠域名 gating | SecurityWatchdog 拦导航 | — | sensitive_data 占位符 + <secret> 标签、URL 域匹配才注入 |
| UI-TARS | 核心 loop 无强制门，靠 PAUSE/call_user | OS accessibility/录屏权限硬门 | — | env/config；secretlint 防提交 |
| Agent Zero | 无 per-tool 门，靠 Docker + intervention | — | — | 别名 §§secret(KEY)，LLM 永不见明文 + 流式遮蔽 |
| Open Interpreter | Codex 底座：sandbox_mode × approval_policy | fail-closed 无沙箱不裸跑 | — | keyring/secrets crate；memories 脱敏 |
| Plandex | autonomy 五档 + apply 流四道确认 | — | — | BYO-key 仅内存、流结束即擦除 |
| GPT-Pilot | 命令/git 逐次 yes-no 确认 | — | — | INPUT_REQUIRED 交人填写；供应链事件（潜伏 10 月） |
| aider | 交互式 confirm_ask，--yes 全绕过 | — | — | 纯环境/dotenv；scrub_sensitive_info 脱敏日志 |
| smolagents | 无交互门，靠 trust_remote_code opt-in | 反序列化 AGENT_REGISTRY 白名单 | — | 无集中存储，构造函数传 token |
| Comate | 仅 MCP 工具默认审批，内置工具不审 | — | — | MCP 密钥明文存 .comate/mcp.json |
| Trae | 无任何审批门，LLM 调用即执行 | — | — | 明文 api_key，show-config 遮蔽前后 4 位 |
| MetaGPT | 无门，仅 max_react_loop 失控阀 | Terminal 2 条子串黑名单（非安全） | — | 明文 YAML，无 keyring/vault |
| OpenManus | 无门，AskHuman 是自愿问询 | _safe_resolve_path 拒 .. | — | 明文 TOML（VNC 默认 123456） |
| AutoGen | approval_func 可选，默认全自动通过 | — | — | 无密钥层，provider client 自理 |
| Semantic Kernel | 无内建 HITL，terminate 标志 DIY | — | — | 无 vault，构造函数/Pydantic Settings |
| GPT-Researcher | 无工具门（威胁模型 by design）；仅计划评审 | — | — | 环境变量；MCP 配置不写 os.environ 防污染 |
| Claude-Flow | 审批门是 Claude Code 的，Ruflo 只生成规则 | 生成 deny Read(./.env*)/rm -rf / | aidefence 扫描（非门） | encryption/vault.ts + Ed25519 签名 |
| CodeGeeX | 逐工具人工审批 Accept/Reject | — | — | RSA 包裹 AES 密钥交换；VS Code SecretStorage |
| AutoClaw | 自进化 + 飞书动作审批卡片 | 危险脚本智能拦截（无细节） | — | 内置模型免 key；未披露 |
| Anthropic 多智能体 | 仅只读工具限制 + 内容安全指令 | — | — | 未披露 |
| SWE-agent | 无交互门，静态 ToolFilter 黑名单 | — | — | SecretStr 防 repr 泄露；线程轮转多 key |
| Replit Agent | Plan Mode 门 + dev/prod DB 隔离 | Package Firewall 安装时拦恶意包 | 混合扫描（确定性+LLM） | 每部署独立生产库 |
| Augment | allow/deny/ask-user DSL，--print 自动拒 | 系统级 immutable settings 顶层优先 | — | Secrets Manager（未完整抓）；session token |
三、分组讨论
3.1 规则引擎流：Claude Code 定义了方言，一群人在讲
{permission, pattern, action: allow|ask|deny} + deny > ask > allow + Bash(git *) 语法，是这一维度事实上的行业标准，源头是 Claude Code。血缘最直白的是国产/开源 CLI：Qwen Code 的规则语法”与 Claude Code 一致”、ssrfGuard 注释直写”Aligned with Claude Code’s ssrfGuard.ts behavior”；opencode、MiMo-Code、Kilo Code 三家共用几乎同构的 Ruleset + Deferred + reply(once|always|reject) 实现（opencode 是这条线最干净的 224 行参考实现，MiMo/Kilo 是其变体，各自加了 FORCED_ASK/ConfigProtection 这类本地补丁）。Kimi Code 把它推到极致——一条 19 步的策略链，把 plan 模式、swarm 排他、敏感文件、git 目录全塞进同一个”第一个非 undefined 结果生效”的评估序列。
值得单独点名的是 AgentScope：它有一套独立的 PermissionEngine（5 种 PermissionMode），本身就是完整 Claude-Code 式引擎；而它作为 QwenPaw 的底座，QwenPaw 的做法是把 AgentScope 的 mode 设成 BYPASS关掉原生引擎、换上自己的五层 Gate/Governance 系统——这是”底座提供机制、上层替换策略”的典型案例，也解释了为什么 QwenPaw 的安全栈看起来和 AgentScope 完全不同。
在规则引擎之上，几家把作用域与克隆仓库注入当作一等威胁来防：Kiro 把 workspace 权限存在仓库之外（~/.kiro/workspace-roots/<hash>/）按用户隔离，“克隆的恶意仓库无法注入权限规则”；Junie 项目级 hooks 默认被忽略只信用户级；Kilo Code 的 ConfigProtection 让编辑 config 文件强制 ask 且禁 always。Roo Code 则在自动审批里额外加了两个用量上限（次数 allowedMaxRequests + 成本 allowedMaxCost），超限即便在自动会话中途也重新问人——这是别家少见的”自动审批也有预算”设计。
3.2 LLM 介导的动态审批：2025–2026 的分水岭
静态白名单挡不住”模型能拼任意一次性脚本”的现实（Amp 干脆据此论证 Neo 之后默认不再审批，因为对 rm -rf 做正则只给”虚假的安全感”）。于是一批 harness 转向让 LLM 给 LLM 把关：
- Codex 的 Guardian 是最完整的：独立审查会话、严格 JSON 判定、超时/畸形一律 fail-closed、带熔断器防轰炸、带逐字存档的
policy.md风险分类法。 - Gemini CLI 的 ConSeca 走得更前——在主 agent 行动之前，让一个 LLM 为本次 prompt 涉及的每个工具生成一份最小权限 ACL（生成式 ACL），有生产遥测证明它真在门控。
- Claude Code 的 Auto-mode 是两阶段分类器，且设计上对推理内容盲（只看用户消息 + 工具调用，剥离 assistant 文本和工具输出），专防注入到工具结果里的社工攻击；配合独立的服务端 prompt-injection 输入探测器。
- Cursor 的 Auto-review 跑在与父 agent 同一 RPC 流内，把某些企业客户 40% 的中断率压到 7%。
- Factory 的 Droid Shield 2.0 最有工程巧思：两个微调 LoRA 夹住确定性扫描器——Risk 模型补漏报、Downgrade 模型清误报，且 Downgrade 架构上看不到真实密钥值（进上下文前已 mask），把数据最小化植入模型输入层。
- CAMEL 的
LLMGuardRuntime是最朴素的同类：一个 guard ChatAgent 按 1-3 分量表给”函数名+描述+实参”打分，超阈值拒执行——把这套思路做成了可复用的 runtime wrapper。 - 轻量版还有 goose 的 SmartApprove（让同一 LLM 分类只读性并自动放行）、Hermes 的 smart 模式、Junie 的 Brave-Auto 分类器、Devin 的 AI Guardrails（独立筛查层，门控用户→agent 消息通道，可
kill_session）。
3.3 档位模型与硬地板：把旋钮和地板分开
Factory（Autonomy Level 四档）和 Plandex（none→full 五档）代表”一个旋钮统摄一组布尔开关”的思路，goose 的 GooseMode、Warp 的 execution profile 同理。关键洞见是这些档位不是安全边界——Kiro 说得最直白：“Supervised mode is a code review workflow, not a security control”，两档授予的底层能力完全相同，只差何时展示 diff。
真正的安全边界是硬地板：Hermes 的 UNRECOVERABLE_BLOCKLIST（比 YOLO 更底层，--yolo/approvals.mode:off/“always allow” 都绕不过）、Zed 的 HARDCODED_SECURITY_RULES（注释明写”任何设置无法覆盖”）、Factory 的 blocklist（--skip-permissions-unsafe 也拦）、Qoder 的 hook-deny 覆盖 bypass（文档称”unbypassable interception”）、v0 的系统级拒绝列表。这些都在解析层做了反混淆（引号拼接 git pu""sh、bash -c、路径规范化），因为不这么做正则黑名单一戳就破。Claude Code 更进一步，在沙箱里硬编码了针对具名 CVE（裸 git 仓库逃逸 #29316）的防御和事后清理。
3.4 框架层 HITL 原语：SDK 只给抽象，不给策略
Python agent 框架普遍不做策略引擎，只提供”暂停”原语：LangGraph 的 interrupt()（抛 GraphInterrupt、靠 checkpointer 恢复）是这条线的祖型，OpenAI Agents SDK 的 needs_approval + run 级 interruptions、Google ADK 的 request_confirmation（中断 invocation）、Pydantic AI 的 ApprovalRequired/CallDeferred 冒泡、Agno 的 @approval 装饰器（required 阻塞 / audit 非阻塞）、Letta 的 requires_approval tool rule 都是同一形状的变体。
其中 Pydantic AI 的独特点是把审批建在类型化工具 + deferred tool 之上——ToolDefinition.kind='unapproved'，审批走 capability 的 handle_deferred_tool_calls 累积分发，DeferredToolResults 用 ToolApproved/ToolDenied 回填，整套是强类型的。OpenAI Agents SDK 则把guardrail 和审批分成两层：Input/Output/Tool guardrail 的 tripwire 直接抛异常中止 run，审批是另一条 run 级路径（覆盖 handoff 和 agent-as-tool），并明确警告”别把密钥放进会被序列化的 RunContextWrapper.context”。Letta 把审批和它标志性的分层自编辑记忆咬合——requires_approval 是 tool rule 家族的一员，与 max_count_per_step 限频、valid_tools 白名单同层，被拒的调用用 create_tool_returns_for_denials 把理由作为 tool return 回灌，让 agent 自适应而非硬停。DeerFlow 的 GuardrailMiddleware（fail_closed 默认 True、可插拔 OAP provider、决策落审计）是这条线里最接近生产治理的。
一批更薄的：CrewAI 只有 before_tool_call hook 返回 False 阻断（且自己的 SecurityConfig docstring 把 auth/scoping/delegation 列为 *TODO*——罕见的自曝未实现）；AutoGen 的 approval_func 默认 None = 全自动通过（构造时抛 UserWarning 提醒）；Semantic Kernel 连 HITL 都没有，只有 terminate 标志让你 DIY，且 MCP sampling 默认自动通过仅打日志。这三家代表”框架给扩展点、安全责任外推给应用开发者”的一极。
3.5 GUI / computer-use 动作空间的特殊安全面
操作真实桌面/浏览器的 harness 有一套别人没有的门：UI-TARS 的第一道门是 OS 级权限（macOS accessibility 控制鼠标键盘 + screen recording 截屏），没这个 app 根本动不了系统；它核心 loop 无强制审批门，靠 PAUSE/call_user()/USER_STOPPED 这类人在环状态兜底，且 HEAD commit 本身就是把 MCP HTTP server 默认绑到 127.0.0.1 的安全修复。browser-use 则把安全压在域名 gating（SecurityWatchdog 拦导航到 about:blank）而非逐步确认，配一组 watchdog（popups 自动关 JS dialog、captcha 自动等）。这类”动作直接执行、无 HITL”的选择，本质是 GUI 任务里逐步确认不现实（一次任务几十上百个点击），只能退到边界隔离——也因此这两家的密钥方案（见 3.7）反而是全场最讲究的，因为动作空间越自动、密钥越不能让模型碰。
3.6 无审批门的一极：信任 LLM + 靠隔离，或干脆裸跑
光谱最右端是明确不设门的：Trae 全树 grep approval/permission/confirm 零命中，bash/编辑工具 LLM 一调即执行，Docker 是唯一 opt-in 边界；OpenManus、Agent Zero（靠 Docker + intervention）、MetaGPT（设计上”非常薄”，唯一限制是 Terminal 2 条防挂 dev server 的子串黑名单）、SWE-agent（只有静态 ToolFilter 黑名单，无人在环）、GPT-Researcher（SECURITY.md 明写后端默认无鉴权 by design，MCP RCE 是 operator 责任、out of scope）都在这一极。GPT-Pilot 名义上有强门（命令/git 逐次 yes-no），但本维度真正的结论是供应链姿态：README [!CAUTION] 记录了一条伪装成 revert 的恶意 commit 潜伏约 10 个月（Shai-Hulud 类窃密蠕虫）——“项目不再维护 + 长期潜伏”本身就是安全结论。
3.7 密钥管理谱系：从明文到 HPKE 信封
密钥这一子维度的跨度比审批门更大：
- 明文环境变量/配置（最多数）：MetaGPT（明文 YAML）、Trae（明文 api_key）、OpenManus（明文 TOML，VNC 默认
123456）、smolagents、Agno、CAMEL、Pydantic AI、deepagents（THREAT_MODEL 自己承认这是 gap）。 - OS keychain：Cline、CodeGeeX 用 VS Code
SecretStorage；Gemini CLI（有 keychain 可用性遥测）、Qwen Code（keytar）、Codex / Open Interpreter（keyring crate）用系统密钥链。 - 0600 加密/受限落盘：MiMo-Code 与 Kimi Code 都是
auth.json/credentials 0600 + 原子写（tmp→fsync→rename）+ CI 环境变量注入不落盘——几乎同款；CrewAI（Fernet 加密 OAuth token）、Claude-Flow（encryption/vault.ts+ Ed25519 签名）、QwenPaw（secret_store.py加密）。 - 别名/占位符注入（LLM 永不见明文）——这是设计上最优雅的一类：Agent Zero 的
§§secret(KEY)别名 +StreamingSecretsFilter流式遮蔽（模型想复述也被实时 mask 成***）；browser-use 的sensitive_data占位符 +<secret>标签、按当前 URL 域匹配才注入真值、只对 input action 暴露、发往 LLM 时反向 redact（还内建pyotp现算 2FA）；OpenHands 的SecretRegistry（命令引用密钥名才注入）。 - 端到端信封 / 从不落盘：Warp 的 HPKE 混合加密信封（Tink，密文绑定 actor/name/type 作 AAD 防重放）+ 值不可取回 + 工作负载身份联邦（短期云令牌）；Copilot BYOK 与 Plandex BYO-key 都是API key 从不落盘（Copilot 每次由宿主重供，Plandex 仅内存、流结束即擦除）。
- 最底层脱敏：Amp 的
[REDACTED:<type>]在”系统最底层”生效，早于密钥进线程/缓存/发往 LLM；Factory 的 Droid Shield、aider（scrub_sensitive_info）、Kilo Code（gitleaks）、UI-TARS（secretlint 防提交）走同一思路。 - 短期 token 无长期 key：Amazon Q（AWS SSO OIDC/PKCE）、Devin（
cog_前缀 token + RBAC）。其中 Devin 的密钥类型 × 作用域体系最完整——4 类（Raw/Site Cookies/TOTP/KV）× 4 作用域（组织/个人/仓库/session），且”新增密钥只对之后创建的 session 生效、不追溯注入”。
四、最值得借鉴的设计
第一，别名/占位符密钥注入 —— Agent Zero 与 browser-use 的共同答案。 让 LLM 只见 §§secret(KEY) / <secret>name</secret> 这样的别名，真实值在运行时才注入 shell/浏览器 input，且发回 LLM 的上下文里反向 redact、输出流里实时遮蔽。这从架构上消除了”模型把密钥复述进日志/发给攻击者”的整类风险，而不是靠事后脱敏碰运气。browser-use 更把它和”按当前 URL 域匹配才解密、只对特定 action 暴露”绑定，等于给每个密钥加了使用场景约束。Factory 的 Downgrade 模型”架构上看不到真实密钥值”是同一哲学在 ML 门控上的投影。理由：注入类攻击已被 Claude Code 红队证明”仅靠模型层防御无法修复”（被钓鱼员工读 ~/.aws/credentials 外发 24/25 成功），唯一可靠的解法是让密钥根本不进入模型可触及的表面。
第二，“生成式最小权限 ACL + fail-closed 的 LLM 审查” —— Gemini CLI ConSeca 与 Codex Guardian 的组合范式。 静态白名单在”模型能拼任意脚本”面前失效（Amp 已论证），而 ConSeca 让 LLM 在行动前为本次 prompt 现写一份最小权限 ACL、Guardian 用独立审查会话做 JSON 判定并在超时/畸形时一律拒绝（fail-closed 是关键——DeerFlow、Open Interpreter、Augment 的 --print 自动拒都印证了这条默认应”关”不应”开”）。理由：它在”每步都问人”（不可用）与”啥都不问”（不安全）之间给出了可扩展的第三条路，且用一层专门的、对推理内容盲的分类器（Claude Code Auto-mode 的关键设计）挡住了注入攻击的主要入口。两者结合——生成式 ACL 收窄能力面 + fail-closed 审查兜底——是目前把”自主度”和”安全”同时拉高的最成熟工程答案。