# 如何选择执行网关而不是密钥代理

如果智能体运行在受管的 Mac 上，对外操作限于 HTTP 和 SSH，而且团队希望在本季度就获得实用控制，平台团队应该采用桌面执行网关。当所需通道、操作系统、身份边界或中央服务模式差异太大，以至于改造现有网关等同于维护分支时，自建密钥代理才可能胜出。

许可证费用并不是最难的部分。Apache-2.0 消除了采购障碍，但它不会替你运行软件、证明谁调用了凭据，也不会在事故后回答审计人员的问题。决策取决于明文会出现在哪里、什么身份能取得权限、能否发现记录被删除，以及未来两年由谁负责每一次安全更新。

下面的评分基于一个具体部署：自主编程智能体作为本地进程运行在公司的 Mac 上；它们调用使用 bearer、basic 或自定义请求头认证的 HTTP API，也使用 SSH；人可以批准高风险操作；公司需要证据链。只要这些假设改变，评分也应该改变。事实已经变化却仍保留漂亮的总分，正是平台团队选错控制措施的常见原因。

## 评分前先定义边界

执行网关和密钥代理解决的是不同问题，尽管两者都可能从加密凭据库开始。代理通常验证工作负载，然后返回密钥或短期凭据。网关保留密钥，代替调用方执行对外操作。最后这一跳决定了受损智能体能否读取、打印、缓存或重复使用凭据材料。

在比较实现之前，先为每条信任边界写一句话：

- 智能体进程可能已经受损，绝不能拿到明文凭据。
- 桌面网关可以使用凭据，但凭据库锁定时必须拒绝工作。
- 远程 API 或 SSH 主机会收到协议正常需要的凭据。
- 操作人员可以查看结果和证据，但不能因此日常访问密钥。
- 本地管理员仍是能力很强的对手，需要另外的终端控制。

第四行和第五行能制止一种常见的自我安慰。加密凭据库保护的是存储字节，并不能阻止已获授权的组件泄露解密后的密钥，也不能让一台完全被控制的终端变得可信。如果威胁模型要求 Mac 上的 root 无法影响或观察任何操作，那么普通桌面应用和自建本地代理都无法解决问题。你需要更强的执行边界，例如由另一团队管理的服务或硬件支持的工作负载隔离，并在设计评审中把终端当作敌对环境。

用滥用场景而不是功能名词来检验边界。问清智能体能否请求 `GET /me`、诱使网关调用任意主机、把密钥放入 URL、在批准后替换可执行文件、重放已批准操作，或者删除一次失败尝试的记录。每个答案都要有执行控制点和负责人。一张只在智能体和网络之间写着“凭据库”的图无法回答这些问题。

这种区别也会改变迁移成本。用返回相同值的代理替换环境变量，几乎不需要改变智能体集成，所以看起来很容易。改用操作网关，则要定义有类型的 HTTP 和 SSH 请求，并返回受限结果。这些工作是让明文远离最不可信进程的代价。把它计入集成工作，但不要因为兼容性方便，就悄悄抹掉隔离带来的安全收益。

## 在既定假设下，评分支持采用

采用五分制：1 分表示该路径不满足要求或需要大量新工程，3 分表示可以工作但有明显缺口，5 分表示满足要求并能提供可操作的证据。我给凭据隔离最高权重，因为把密钥交给智能体的设计，无法靠更好的日志挽回这个损失。

| 维度 | 权重 | 采用 | 自建 | 高分条件 |
| --- | ---: | ---: | ---: | --- |
| 凭据隔离 | 30% | 5 | 2 | 智能体从不收到密钥，也不能重定向凭据注入 |
| 签名进程检查 | 15% | 4 | 2 | 批准界面显示已验证的代码身份，并能发现进程替换 |
| 篡改证据 | 20% | 5 | 2 | 具备追加语义、密码链和独立验证器 |
| 更新工作 | 20% | 4 | 1 | 有明确上游负责发布，团队仍能检查并固定版本 |
| 审计支持 | 15% | 4 | 2 | 审查者能关联进程运行、批准、调用、结果和撤销 |
| 加权总分 | 100% | 4.5 | 1.8 | 测试后重新计算，不要凭印象接受这些数字 |

在采用路径中，Sallyport 符合假设的 Mac、HTTP 和 SSH 边界：加密凭据库不会向智能体暴露密钥，会话批准首先显示进程的代码签名权威，选定密钥可要求每次使用都批准，加密哈希链日志还可通过 `sp audit verify` 离线验证。Apache-2.0 源码和进程内菜单栏形态减少了采购与服务运维工作，但团队仍要检查版本、测试智能体集成、定义保留期并支持用户。

自建分数假设一个有能力的平台团队从传统密钥服务起步，而不是已经拥有成熟的内部委托执行产品。原型可以很快存储和返回密钥，因此演示往往让这条路显得更好。演示跳过的部分才是失分所在：调用方证明、操作中介、批准状态、取消、不可改写的事件排序、验证工具、恢复、模式演进、安装程序、签名和支持。

不要用平均分掩盖强制要求。如果智能体必须运行在另一种操作系统上，Mac 桌面网关的适配分就应该是零，无论它的安全控制多好。如果对外工作需要数据库线协议、云签名 API 或交互式终端转发，就要逐项测试这些通道。加权评分帮助你在可行路径中选择，却不能让不兼容的路径突然可行。

评分要做两遍。第一遍衡量今天的软件。第二遍衡量 24 个月后的可能状态，包括团队可用维护人员、上游响应、发布验证和支持队列。如果自建方案因为你已拥有大部分组件而得分提高，就记录这些组件当前的维护成本。“我们有代码”和“我们运营着安全产品”不是一回事。

## 凭据隔离终止于执行而不是存储

最强的隔离属性很容易描述：智能体提交预期操作，可信组件在固定目标处加入凭据，可信组件执行操作，智能体只收到允许返回的结果。智能体始终无法请求原始密钥。这与给凭据库 API 套上更好的身份验证有本质区别。

看一个常见故障过程。编程智能体需要创建代码仓库问题，于是代理把 API 令牌返回到智能体进程。智能体上下文里包含不可信的问题文本。文本中的恶意指令要求智能体通过打印环境变量或把请求头发送到诊断端点来排查认证。代理完全正确地完成了职责，但令牌已经进入一个会解释攻击者文本并能发起网络请求的进程。缩短令牌寿命可以缩小窗口，却不能维持隔离。

网关只有约束操作，才能避开这类故障。凭据注入必须绑定到预期主机和协议位置。处理重定向时不能把授权请求头转发到另一个源。日志和错误对象必须删除凭据值。响应大小和内容处理也需要限制，因为恶意服务器可能返回专门攻击智能体或淹没上下文的数据。SSH 主机验证、目标约束和命令表示也要同样谨慎。

NIST SP 800-57 把密钥管理视为一个生命周期，其中包括受保护的密钥材料、访问控制、元数据、泄露处理和可追责性。团队经常引用其中的存储部分，却跳过使用阶段。对自主智能体来说，使用阶段面对的输入最有创造性，也最危险。设计评审应跟随密钥经历创建、每一次解密和协议插入，再标记所有可能复制它的缓冲区、日志路径、崩溃报告、子进程和响应。

让自建团队提供跟踪结果，而不是一句保证。在开发凭据库中放一个唯一的诱饵值，运行成功和失败的操作，然后在进程输出、采集日志、崩溃文件、临时目录、shell 历史和智能体记录中搜索它。再用重定向、认证失败、超时、超大响应和取消重复测试。什么都没找到并不能证明绝对不干扰，但只要找到诱饵值，就立刻推翻了隔离声明。

采用现成产品同样需要这个测试。开源让审查者可以检查注入位置以及返回类型能否包含密钥，但源码可见不等于运行证据。固定被评估的版本，通过受控流程构建或取得准确制品，并在安全相关更新后重跑诱饵测试套件。

## 签名能识别代码但不能批准意图

相比进程名或文件路径，macOS 代码签名能给网关提供更强的调用方证据。Apple 的代码签名文档解释说，指定要求用来识别同一代码的不同版本，而代码要求会评估签名锚点和标识符等属性。这能区分由获准开发者发布的签名智能体和一个同名的未签名副本。

Apple 对签名标识符、签名身份和代码身份的区分在这里很重要。标识符是签名者选择的字符串。签名身份包含证书和私钥。代码身份是系统对两个版本是否属于同一代码的判断。只记录 bundle 标识符或可执行路径，会丢掉让检查真正有用的权威证据。

签名仍然不能说明当前提示是否安全。正确签名的代码可能有漏洞、加载不安全扩展、执行项目提供的钩子，或忠实遵循恶意指令。应把签名权威当成授权输入：它告诉批准会话的人，哪个发布者控制这个进程。不要把它变成每个 API 调用都值得批准的永久证明。

评估时测试四次状态转换：

1. 启动预期的签名智能体，确认批准界面显示其签名权威。
2. 退出并重启同一二进制，确认新的进程会话需要重新授权。
3. 在同一路径换成未签名二进制，确认身份明显变化或调用失败。
4. 安装合法更新版本，确认网关识别预期权威，同时不会静默接受另一个签名者。

第三项能发现基于路径的信任。第二项能发现把一次运行授权存成永久应用许可的做法。第四项能发现过于僵硬的固定方式，因为它要么阻止日常更新，要么诱使操作人员批准范围过宽的要求。把每次转换的截图或结构化结果存入决策记录。

自建实现还必须处理时序。如果系统检查路径、批准操作，随后却启动或连接另一个进程，替换攻击就能绕过检查。在操作系统支持的地方，把证据绑定到实时审计令牌或连接，在特权操作前验证，并定义进程祖先关系不明确时如何处理。这是专业的终端安全代码，不是给密钥 API 周末加上的小功能。

## 篡改证据需要验证器和失败策略

数据库的只追加标志是一种访问策略。当每条记录都承诺前一状态，并且验证器能在方案声明的范围内发现修改、删除、插入或重排时，哈希链日志才具备篡改证据。这两种属性都不能保证事件一开始就被正确记录，也不能阻止攻击者销毁所有本地副本。

OWASP 的 Logging Cheat Sheet 要求实现方加入篡改检测，还要能够发现日志停止。第二条经常被忽略。如果网关无法追加日志却继续执行特权操作，它就在可用性和证据之间选择了可用性。对某些凭据这或许可以接受，但选择必须明确、经过测试，并向操作人员显示。

要求提供可运行的验证制品。对于本次评估中的现成网关，基本操作检查是：

```sh
sp audit verify
```

预期结果应清楚显示成功，或者以非零退出码指出第一个无法验证的位置和原因。试点期间，复制加密日志，验证未改动副本，在另一个副本中翻转一个字节；如果存储格式允许受控操作，再删除中间记录，然后重新验证。保留命令和实际退出码。日志界面上一张绿色截图不是密码验证。

在密文上离线验证有两个运维优势。审查人员无需解锁可能含有敏感内容的记录就能检查连续性，事故响应人员也能在获准查看解密细节之前保存并验证副本。它也有限制：如果验证器不与外部锚定检查点或预期链头比较，有效的本地前缀可能掩盖尾部被删。要问清当前链头如何记录到机器之外、记录频率以及谁负责发现检查点缺失。

自建提案不能只写“我们会给日志做哈希”。它要说明记录规范化、链初始化、崩溃恢复、并发排序、密钥或哈希选择、格式版本、验证器分发以及损坏响应。还要决定在承诺前还是之后删除敏感字段，因为意外写入加密日志的密钥会让支持和保留更复杂。导出时也不能丢失验证顺序所需的证据。

把篡改证据和审计完整性分开。完全未被改动的记录仍可能缺少请求目标、调用方身份、批准决定、结果状态或撤销信息。相反，内容丰富但管理员能静默改写的活动表或许有助于调试，却不能支撑强完整性声明。把两者作为相连但不可互换的控制来评分。

## 两年的更新工作会改变经济账

开发者机器上的安全软件同时承受两侧变化。操作系统版本会改变签名、权限、密钥存储和后台行为。智能体工具会改变进程树和 MCP 行为。远程 API 会改变认证与错误格式。SSH 库和密码依赖会发布修复。采用项目让团队拥有上游，自建产品则让团队自己成为上游。

按重复职责统计负责人时间，不要只看最初的编程估算。使用下面的工作表，让具名工程师填写范围：

| 24 个月内的职责 | 采用网关 | 自建代理 |
| --- | --- | --- |
| 源码与架构评审 | 初次评审和重要版本差异 | 每个子系统持续设计评审 |
| 发布工程 | 固定、验证、打包、分阶段发布和回滚 | 构建、签名、公证、打包、分阶段发布和回滚 |
| 兼容性测试 | 支持的通道和智能体版本 | 每个自有客户端、协议和部署目标 |
| 漏洞响应 | 判断上游修复和受影响范围 | 判断、设计、修复、披露和回移补丁 |
| 用户支持 | 集成和策略问题 | 集成、产品行为、恢复和缺陷 |
| 审计请求 | 解释已配置控制并导出证据 | 为设计、实现、运行和证据负责 |

每行记录四个数字：每季度预期工时、糟糕季度的工时、实际响应时长，以及真正能做这件事的人。实际时长很重要，因为签名专家的十小时工作可能要排三周。把事故演练、证书续期、依赖评审和恢复测试放进账本。乐观的自建估算会遗漏它们，因为功能演示不依赖这些工作。

Apache-2.0 允许在满足条款的前提下使用、修改和分发，其中包括保留必要声明并标记修改文件。它还包含贡献者明确授予的专利许可，以及与专利诉讼相关的终止条款。让律师把这些条款应用到你的分发计划，但不要把宽松许可证误解为更新会按你的计划到达，或上游必须提供支持。

分支维护需要单独计费。小补丁可能合理，但每项本地修改都会带来合并和重测义务。采用前先设分支预算：哪些改动可以保留在本地、最多落后几个版本，以及何时必须贡献上游或转向自建。如果没有这条规则，团队嘴上说“采用”，实际上却慢慢变成私有版本的维护者。

如果公司已经有发布工程、终端部署、审计管道和接受责任的值班轮换，自建路径在第一年后可能改善。应该承认共享基础设施的收益，但只计算真正减少的边际工作。中央日志服务不能替你创建正确的网关事件、在中断期间缓存事件、保护本地密钥或测试证据导出。

## 审计支持始于问题而非保留期

审计员或事故负责人很少只问是否启用了日志。他们会问谁授权了智能体、运行了什么代码、使用哪类凭据、请求了什么目标和操作、调用是否成功、操作人员撤销了什么，以及记录后来是否改变。事件模型应从这些问题倒推设计。

每次智能体运行要保留稳定的会话标识、进程身份凭据、批准人和批准方式、开始与结束边界以及撤销状态。每次调用要保留会话关联、时间、通道、规范化目标、凭据引用而非值、批准结果、受限操作摘要、结果状态和链位置。明确哪些请求或响应字段必须省略或删除敏感内容。如果回答简单问题都要解密包含大量客户数据的任意载荷，审计支持就失败了。

为两条路径使用同一份评估材料，其中应包括：

- 带有信任边界和滥用场景的威胁模型。
- 每个数字背后都有证据和具名负责人的评分矩阵。
- 密钥诱饵、进程替换、日志修改和日志中断测试结果。
- 含正常与糟糕季度估算的 24 个月职责账本。
- 能回答一次事故时间线的会话与调用导出样例。

演练事故必须让人不舒服。假设一个签名编程智能体在 09:12 获批，执行了两次预期的代码仓库 API 调用，尝试用需要逐次批准的密钥通过 SSH 连接生产主机但被拒绝，然后退出。09:40，操作人员撤销了看起来像同一次的运行。证据应该说明它是否是同一会话、谁拒绝了 SSH 调用、凭据是否进入智能体、为何在退出后撤销，以及这段时间的记录是否连续。

确定内容后再定保留期。根据法律、合同、隐私和事故响应需求设定期限，然后测试到期删除。加密日志仍可能包含个人数据、命令、主机名和响应片段。限制解密权限，记录对日志本身的访问，并在调查需要保全时单独保存加密证据。

除非漂亮的仪表盘能导出持久证据并说明字段含义，否则它几乎不该得分。审计人员需要可重复的答案，而不是在开发者笔记本上观看现场演示。命令行验证器、版本化模式和一小组有文档的查询，往往比一页图表更有用。

## 边界确实不同时，自建才胜出

当强制要求超出现有项目的设计形态，而且这种差异会长期存在时，自建代理或网关。例如，为非 Mac 工作负载提供中央服务、支持 HTTP 与 SSH 之外的协议、采用组织特有硬件证明、通过现有特权访问系统批准，或要求证据直接写入公司控制的透明服务。这些是架构差异，不是再加一个偏好开关就能解决的请求。

如果团队已经运营委托签名或请求执行服务，并拥有大部分困难控制，自建也有道理。这时剩余工作可能只是智能体适配器加桌面身份凭据，而不是全新的安全产品。要展示继承属性，不能因为另一项内部服务的图看起来相似就给分。

三个常见的自建理由没有听起来那么有力。“代理只是一层薄包装”忽略了操作解析、目标绑定、批准状态、审计排序和恢复。“我们需要完全控制”也意味着完全负责补丁和支持。“开源意味着随时可以分支”在许可证意义上没错，但分支会把采用原本想节省的更新工作交回同一批人。

采用路径也有一个薄弱论点：“控制已经存在，所以工作结束了。”团队仍要把产品边界映射到威胁模型、测试分发二进制、管理允许的集成、保护导出日志并定义支持。如果普通操作触发太多提示，批准卡片还会造成疲劳。一次运行使用会话批准，只有每次使用都值得人工决策的凭据才启用逐次批准，否则用户会养成不阅读就点击的习惯。

只有为这些最低工作流指定负责人后才选择自建：终端身份和 IPC、凭据生命周期与注入、协议执行器、批准体验、篡改证据与验证、发布安全、运维支持。一名工程师可以负责多项，但写着“平台团队”的一行不是责任归属。还要记录休假和事故期间谁来替补。

短期验证可以消除不确定性，而无需先承诺产品。给两条路径相同的两个集成和攻击测试，运行三周。限制将被丢弃的原型代码，禁止使用生产密钥，只对已经展示的行为评分。如果自建路径无法在验证中显示实时进程身份并发现日志变化，就把这些控制视为未来工作，不要为路线图加分。

## 在不削弱控制的前提下保留可逆性

采用时准备退出包，自建时则放在操作契约后面。共享契约应描述智能体请求而不暴露供应商密钥：通道、目标、操作、受限参数、凭据引用、批准类别和结构化结果。把供应商特有认证留在执行器里。这样团队以后可以替换可信组件，而不必教智能体保存密钥。

使用下面的两年决策顺序：

1. 第零个月固定威胁模型、强制平台、通道、证据问题和评分权重。淘汰任何不满足强制边界的路径。
2. 试点期间运行诱饵、签名者替换、会话重启、重定向、日志修改、日志中断、撤销和导出测试。把原始结果附在每项评分后。
3. 推出时固定已评审版本、记录恢复流程、设定更新窗口、培训支持人员。如果尾部删除很重要，为审计链头保存外部检查点。
4. 每季度审查上游变化或自建积压、失败操作、批准模式、验证结果、依赖通知，以及实际负责人时间与账本的差异。
5. 第 12 和第 24 个月重新评分两条路径。当平台适配、分支规模、响应时间或缺失通道越过第零个月约定的阈值时，触发迁移或获得资金的自建项目。

不要以可逆为借口接受泄漏密钥的兼容模式。如果临时适配器把原始凭据返回给智能体，系统就改变了主要安全属性。把这条路径明确标成代理，按代理评分，并限制其运行范围。

在既定 Mac 部署中，采用路径一开始领先 2.7 个加权分。自建提案应该用运行证据缩小差距，而不是依赖团队“可以做出来”的信心。如果独特要求确实值得投入，就把它当作内部安全产品，为完整两年的发布、审计和支持安排负责人。如果不值得，把这些工程时间花在测试和运营今天就能检查的网关上。