混合设备环境中的仅限 Mac 执行网关

只在 Mac 上运行的网关可以改善混合设备环境的安全性，但前提是试点必须有明确的执行边界。把安装覆盖率当成安全覆盖率，是最常见的错误。真正有用的边界要说明哪些操作必须从已纳管的 Mac 发起，哪些凭据可以放在那里，谁负责例外情况，以及 Linux 或 Windows 工作流需要使用同一服务时该怎么办。

如果部分覆盖保护了有实际意义的一部分高风险操作，同时清楚标明其他部分没有变化，这种做法就站得住脚。如果只是因为几名 Mac 用户安装了网关，大家便以为所有代理操作都经过网关，那就完全站不住脚。试点应尽量避免这种误解：列出受保护的工作流，标记不支持的工作流，统计操作量，并公布决定扩大、维持或撤销网关的日期。

等待的理由听起来很整齐。覆盖整个设备环境的产品能给每位开发者相同的控制。但在现实中，等待也会让当前风险持续一段未知的时间，而且未来的产品仍可能要求调整工作流。因此，正确的比较不是部分一致与完美一致，而是现在就获得有边界的保护，与替代方案真实具备的控制和交付日期之间的比较。

部分覆盖是一项控制选择

团队有意识地选择受控操作，而且能证明控制在哪里生效时，部分部署就能发挥作用。只看设备数量几乎说明不了什么。十名 Mac 用户可能承担大部分生产管理工作，而一百台 Linux 工作站只构建本地测试代码。反过来也完全可能。

先看操作，不要先看操作系统。执行网关控制的是操作真正运行并取得权限的位置。要问哪些 HTTP 请求、SSH 命令和其他外部操作需要凭据边界、审批或审计记录。然后确认这些操作目前由哪些机器和人员发起。按这个顺序分析，设备清单就不会反过来决定安全模型。

试点边界应包含四个部分：

• 可以使用网关的具体人员或角色；
• 必须经过网关的具体操作类别；
• 要迁入受控存储区的具体凭据；
• 明确留在边界之外的工作流，以及每个例外的负责人。

第四部分最重要。例外不只是少装了一份软件，而是一条仍在使用旧凭据和旧控制模型的正式路径。如果没有人负责这条路径，试点就制造了一个被包装成进展的盲区。

不要对公司说网关“覆盖了 Mac 设备”。应该说，例如，它覆盖发布团队从生产环境发起的 SSH 操作，以及两个代理工作流在已纳管 Mac 上运行时调用的部署 API。这种表述更窄，可以验证，也不容易被误解。持怀疑态度的评审人员可以要求查看相应日志、凭据清单和例外列表，而不是争论“覆盖”到底是什么意思。

这种精确性也限制了治理团队能够得出什么结论。有明确边界的试点证据，可以支持针对指定操作和指定评审周期的主张。它不能证明全公司的代理凭据已经获得同等保护。把范围说明放在每项指标和每份审计导出内容旁边，避免图表脱离限定条件后单独流传。

部分覆盖仍然可以实质性地降低风险。只要有一个部署凭据不再进入代理进程，这项改变就是真实的，即使另一个平台仍在使用旧路径。这个诚实的结论比全设备计划小，但比无法把设备与操作对应起来的安装数量更可信。

人员、操作和凭据共同定义试点

有效的试点边界要同时写明人员、操作和凭据，因为其中任何一个维度都可能绕过控制。只有 Mac 用户名单而没有操作范围，已纳管用户仍可直接调用敏感 API。只有 API 名单而没有凭据范围，旧令牌仍可能留在 Linux 环境中。只有凭据清单而没有人员，责任归属仍不清楚。

选择一组工作足够重要、能够检验控制效果，同时人数又少到便于密切观察的人员。发布工程师、基础设施维护人员，以及让自主编程代理访问预发布系统的开发者，通常都是合适人选。不要只因为某些志愿者本来就喜欢新工具而选择他们。他们的工作流通常比那些最终决定网关能否长期使用的棘手情况更干净。

对每个纳入范围的工作流，都要记录准确的操作边界。“云管理”太宽泛。“部署代理使用生产 bearer 凭据调用发布端点”才有用。“服务器访问”也太宽泛。“值班工程师从已纳管 Mac 建立生产 SSH 会话”才能给审计人员提供可检查的对象。

还要同时指定通道和目标。通过网关发起一次 HTTP 调用，并不代表某个厂商命令行客户端、浏览器会话、数据库驱动或本地 SSH 工具也走同一路径。两个工具可以用不同凭据访问同一服务，并留下不同证据。在测试证明它们共享同一控制之前，把每条路径当成独立操作。

代理配置也需要单独检查。代码库可能把获批网关设为常规 MCP 工具，但用户配置仍可能暴露直接的 shell 命令或环境变量令牌。代理会选择其指令和工具允许的路径。对纳入范围的操作，应移除直接能力；如果必须保留，就记录原因以及评审人员如何识别它的使用。

凭据放置决定边界是否完整。凭据迁到网关后，shell 配置、环境文件、代理配置、用于注入的密码管理器和 CI 变量中的副本都可能破坏结果。试点必须为每个可以安全停用的旧副本安排删除任务。如果 Windows 构建仍需要该凭据，就记录这项依赖，不要贸然删除后等到发布时才发现故障。

边界文档的正文应该控制在一页内，详细登记表可以作为附件。它应写明试点组、开始和评审日期、纳入的操作、凭据负责人、审批预期、证据位置和明确排除项。如果核心说明必须依靠一张图和六条脚注才能说清，范围很可能还没有定下来。

可以用一个简单测试来判断准备情况：替班值班工程师能否在不询问试点设计者的情况下回答两个问题，“这个操作必须使用网关吗？”以及“我当前使用的机器有哪些获批路径？”如果任一答案依赖口头传承，试点就还没准备好。

请求来源与执行来源不是一回事

人员或代理开始工作的机器，不一定是特权操作真正执行的机器。团队经常混淆请求来源和执行来源，然后认定 Mac 应用无法帮助 Linux 或 Windows 用户。对于交互式本地工作流，这个结论可能正确，但并非任何情况都如此。

假设一名 Windows 开发者要求自动化服务部署一个构建。请求始于 Windows。如果一台受控 Mac 接收受限任务并执行部署调用，执行边界就在这台 Mac 上。开发者不需要拿到生产凭据。只要交接过程有可靠身份、有限输入和审计记录，这种设计就能让操作覆盖范围超出桌面设备数量。

这种模式也有明确限制。共享 Mac 不能变成通用远程命令主机。如果调用者可以提交任意 shell 文本、上传可执行文件或选择任何目标，团队只是把原有凭据风险搬进了一个能力很强的中继点。远程接口应只开放少量操作，验证每项输入，把请求绑定到身份，并拒绝用途之外的所有内容。

跨越交接点的身份还必须保留在记录中。只记录共享 Mac 账户，只能告诉调查人员操作在哪里执行，却不能说明谁发起了请求。请求记录应关联人员或工作负载身份、允许的操作、重要输入、审批决定和最终调用。否则，委托执行虽然提高了操作覆盖率，却削弱了问责能力。

可用性也会成为安全决策的一部分。如果所有委托发布都依赖一名员工的笔记本电脑，日常休眠、出差或维修就可能触发紧急绕过。对于偶尔执行的预发布操作，试点也许可以接受这种限制。生产用途需要正式的可用性方案，不能把个人 Mac 变成非正式服务器群。

延迟和人工审批也会改变答案。需要交互式 SSH 终端的 Windows 用户，不能在没有设计远程访问路径的情况下直接借用 Mac 菜单栏会话。后台部署操作也许可以接受短暂排队和一次审批。需要连续发出五十个小型认证请求的本地调试循环，大概无法接受。

这个区别为试点提供了三个诚实类别。直接覆盖是指操作来自受支持的本地工作流。委托覆盖是指另一个平台请求一个范围很窄、在边界内执行的操作。无覆盖则表示操作和凭据都留在边界之外。报告中必须分开使用这些标签。把委托执行称为“支持 Windows”会掩盖架构，并制造试点无法兑现的预期。

不支持的工作流必须有公开登记表

在迁移凭据之前记录所有不支持的工作流，因为迁移过程本身会暴露隐藏依赖。登记表是一项正在使用的控制，不是放在项目文件夹里的免责声明。开发者、支持人员、安全评审人员和事件响应人员都应该知道在哪里找到它。

登记项必须描述真实路径：

• 生产发布从 macOS 发起，调用部署 API，属于直接覆盖，由发布负责人管理到试点评审日。
• 紧急数据库会话从 Linux 发起，通过 SSH 访问生产环境，沿用现有访问流程，在 Linux 方案接受测试时交回数据库负责人评估。
• 软件包发布从 Windows 发起，使用现有令牌处理方式上传到注册表，在工作流迁移或合适客户端发布前由构建负责人管理。
• 预发布重启从 Linux CI 发起，调用服务 API，仍是委托候选项，由平台负责人管理到其受限接口通过评审。

状态必须使用固定词汇。“调查中”可能掩盖一个永久缺口。使用直接覆盖、委托覆盖、无覆盖和已停用。只有在试点本身阻止必要工作时才增加“阻塞”，并把这种状态当成有负责人和期限的事件。

当前控制字段可以防止一个有害假设：试点之外并不等于完全没有控制。Linux 生产会话可能已经要求临时凭据和同行审批。Windows 发布令牌可能放在受管理的构建服务里。记录这些事实，再根据各自实际效果与网关比较。试点不应把原有控制的成绩算到自己头上，也不应贬低已经有效的控制。

把不支持的情况发布在设置说明附近。使用不支持机器的用户如果只看到一篇写着“安装网关”的说明，就会自行想办法。他们可能向同事复制凭据，让代理经过未经评审的主机，或者为所有人禁用新路径。可见的登记表会给他们一个获批答案，即使这个答案是“在触发条件出现前继续使用现有流程”。

为每个登记项指定检测方法。目标服务的审计字段、来源地址、凭据标识符或命令记录都可能识别这条路径。如果某一行没有可观察信号，就如实说明，并在把对账当成证据之前补上这个缺口。如果执行后根本无法识别任何路径，满满一张登记表也只是一份清单。

团队人员调整、凭据轮换、部署新代理或值班责任变更后，都要评审登记表。设备比例变化缓慢，但工作流可以在一次拉取请求中跨过边界。

悄悄切换路径会破坏试点

当受控工作流悄悄回退到不受控路径时，试点就失败了。这种故障往往看起来没有问题，因为工作仍然完成了。审计记录、审批和凭据边界消失了，但成功状态仍然是绿色。

假设发布工程师平时在 Mac 上启动代理。代理通过网关发送部署请求，网关持有生产令牌并记录调用。一次事件处理期间，由于 Mac 无法使用，工程师连接到 Linux 工作站。同一代码库里有一个后备脚本，会从环境变量读取 DEPLOY_TOKEN。为了完成发布，一名同事把令牌放进 shell 环境。

部署成功了。此时，团队在服务日志中有一条操作记录，却没有相应的网关记录；生产令牌暴露给代理进程；shell 历史或配置里还多了一份未记录的副本。如果评审只统计 Mac 用户成功完成的部署，它会报告已有覆盖。如果把敏感服务操作与网关活动对账，它就会发现这个缺口。

直接教训不是“事件期间禁止使用 Linux”。事件处理需要可靠的替代方案。真正的教训是，在压力到来前定义回退方式。团队可以把现有 Linux 流程保留为明确例外，要求单独的事件审批，并在例外登记表中记录使用情况。也可以提供一项由已纳管 Mac 执行的受限委托部署操作。哪种答案合适，取决于可用性要求。

有意测试跨界情况。从不受支持的机器运行纳入范围的工作流，在网关锁定时运行，在代理进程重启后运行，并在指定 Mac 离线时运行。预期结果必须属于三种情况之一：明确拒绝、文档化的替代路径或已记录的例外。如果操作通过未知的第四条路径成功，这就是试点缺陷。

同一次测试也要查找凭据。搜索相关代码库配置、开发者设置说明、CI 变量和本地环境中的已停用凭据名称。不要把秘密值复制进报告。记录每个位置、负责人和删除决定。这项工作发现的风险往往比安装动作本身更多。

衡量操作覆盖率，而不是设备覆盖率

应衡量纳入范围的敏感操作中有多少使用了预定路径，同时统计相关例外、拒绝和回退。“百分之二十的笔记本已纳管”是一项运维指标。它无法说明网关究竟保护了一次无关紧要的测试调用，还是每次生产部署。

试点开始前就要定义分母。一个实用分母，是评审周期内边界文档列出的全部操作。尽可能从目标服务统计证据，然后与网关记录和获批例外对账。只看网关日志，无法发现绕过网关的操作。

目标记录本身也可能有缺口。某个服务也许记录凭据身份和时间，却不记录发起人员；也可能把多个操作合并成一个任务。在承诺精确对账前，先测试关联方式。记录用哪些字段连接两边记录、允许多大的时间窗口、如何处理重复项，以及由谁调查未匹配操作。

抽样适合发现工作流类型，但对于少量影响重大的操作，它提供的证据很弱。漏掉一次未经授权的生产部署，比估算一个平均值严重得多。对纳入范围的操作，优先进行完整对账。如果目标服务无法提供所需信息，应在试点结果中说明限制，不要把样本包装成覆盖结论。

只跟踪少量指标：

• 与网关记录匹配的受控操作；
• 通过文档化替代路径执行的获批操作；
• 没有匹配记录或例外的敏感操作；
• 因边界按设计工作而产生的拒绝；
• 因没有可用路径而被阻塞的任务。

拒绝和阻塞要分开解释。拒绝可以证明锁定的保险库或缺失审批阻止了未授权调用。阻塞意味着有权限的人员无法完成必要工作。把两者合并，会让控制因为损害可用性而得到奖励，或者因为正确拒绝访问而受到惩罚。

设备数据仍然有用。它可以解释谁能直接使用网关，以及培训或安装在哪些地方失败。应把它与操作数据配对，而不是把它当成安全结果。一个有用的表述是：“十名符合条件的 Mac 用户中有八名完成纳管，一百次指定部署操作中有九十四次走受控路径；四次使用获批事件回退，两次没有匹配记录。”如果无法支持准确数字，就报告实际记录，不要编造百分比。

还要衡量操作人员的成本。统计重复审批造成的中断、诊断平台缺口所花的时间、例外数量，以及执行 Mac 无法使用时的恢复时间。一项能拦截风险调用，却把用户训练成盲目批准的控制需要重新设计。如果一项控制以很小摩擦保护了少量操作，即使公司多数设备无法运行它，也可能值得扩大。

给试点分配负责人和停止条件

试点需要结构化范围、明确负责人和停止条件，避免因无人处理而永久存在。下面的配置是一份文档材料，不是策略引擎。把它放在试点运行手册旁边，像代码一样评审变更；如果从它生成易读登记表能减少偏差，也可以这样做。

pilot:
  name: agent-action-gateway
  starts: 2026-08-03
  review_by: 2026-09-14
  owners:
    security: sec-platform
    operations: release-engineering
  included_actions:
    - id: production-deploy
      origins: [enrolled-macos]
      credential_owner: release-engineering
      fallback: incident-release-process
  unsupported:
    - id: production-ssh-linux
      owner: infrastructure
      current_control: existing-access-process
      revisit_when: supported-execution-path-tested
  stop_if:
    - undocumented-credential-copy
    - required-work-has-no-approved-route

使用能迫使团队做决定的日期。“每季度评审”很弱，因为没有人知道具体由哪次会议负责。评审应有指定主持人，并限定三种结果：扩大纳入的操作范围；在解决指定缺口期间维持现有边界；或者撤销试点，恢复有文档记录的原流程。

停止条件应和成功标准受到同等重视。如果必要的 Linux 或 Windows 任务没有获批路径，就暂停凭据迁移。如果网关产生了不受控制的远程执行路径，就停止受影响工作流。如果目标服务证据显示有纳入范围的操作，却找不到网关记录或登记例外，应立即调查。

退出并不证明想法本身错误。它可能说明选定工作流依赖本地工具、可用性或平台覆盖，而试点设计忽略了这些条件。保留登记表、对账结果和操作人员记录。这些材料能让下一次产品比较比一句含糊的“用户没有采用”清楚得多。

指定一名负责人管理例外老化。如果没有这个角色，临时凭据和回退脚本会在原因消失后继续存在。负责人不必对每个团队都有管理权，但必须有权要求证据、安排评审和上报逾期决定。

等待的成本也必须进入比较

比较现在的部分覆盖和未来覆盖所有平台的方案时，应评估当前保护、不支持的工作、运维成本和可信的交付时间。不要拿一个正在运行的试点，与一个想象中平台完全一致、迁移成本为零、也没有发布日期的产品比较。

如果受保护操作量很小，Mac 执行会形成脆弱中继，或者计划中的替代方案已经有资金支持的负责人和可测试发布计划，等待就有道理。如果现有控制已经让凭据远离代理，并能提供团队需要的审批和证据，等待也可能胜出。此时再安装一道边界只会增加手续，而不会降低风险。

如果 Mac 用户集中执行一组敏感操作，这组操作的旧凭据副本可以停用，而且不支持的工作流能在已知控制下继续，部分覆盖就有道理。试点产生的证据能与目标日志比较时，这个选择更强。委托执行逐渐变成通用远程服务，或例外需要共享的持久凭据时，这个选择会变弱。

把关于未来方案的主张写下来。记录支持的操作系统、操作通道、凭据模型、审批行为、审计导出、迁移工作、指定负责人和下一个可验证里程碑。“我们预计很快支持 Linux”不是计划。“厂商正在处理”也不是。分支、构建版本、合同承诺或已安排的验收测试，才让主张有分量。

把两边的迁移成本都算进去。Mac 试点可能需要修改代理配置、清理凭据、培训用户和编写回退运行手册。未来方案上线后同样需要集成、验收测试和再次迁移凭据。对有负责人和估算的工作计数，其余标记为未知。在一项尚未规划的迁移旁边写零，是虚假数字。

等待也应该像试点一样有评审日期。如果替代方案错过里程碑，团队应重新考虑仍然暴露的操作，而不是自动把决定继续往后推。没有触发条件的等待，会把产品偏好变成无限期安全例外。

用同一份工作流登记表评估两个选择。对每一项都写明试点会改变什么、等待会改变什么，以及两种情况下哪些风险都不会变化。这样可以防止平台一致性掩盖更重要的差异。一个产品可能到处都能运行，却仍把秘密交给代理。另一个产品可能不让秘密进入进程，但只覆盖一个执行主机。

根据风险和证据确定决定日期，不要根据热情来定。在那次会议上，团队应该能说明哪些敏感操作获得了边界、哪些没有、控制给操作人员带来了多少成本，以及替代方案是否变得更具体。如果这些事实缺失，延长试点只是在延长不确定性。

Sallyport 只适合放在诚实的边界内

Sallyport 可以支持这种 Mac 试点，因为它的应用把 API 和 SSH 凭据保存在加密保险库中，为支持 MCP 的代理执行操作，使用固定审批阶梯，并在经过哈希链处理的加密日志中记录会话和调用。它不会把混合设备环境变成覆盖所有平台的部署，因此边界必须描述使用它的确切 Mac 执行路径，并把其他所有路径留在不支持登记表中。

第一个试点操作应该足够窄，可以从头到尾完成对账。生产部署调用比“所有代理网络流量”更适合，因为团队可以明确其凭据、目标、调用者、预计频率、回退方式和目标记录。把已纳管组使用的这个凭据移到网关之后，删除没有任何未覆盖工作流需要的旧副本，然后测试拒绝和回退行为。

不要只是为了让覆盖率图表更好看，就让所有 Linux 和 Windows 请求都经过一台共享 Mac。只有当远程操作的输入面很小、调用者经过认证、权限有边界、可用性可靠，而且记录能够关联请求者和实际调用时，委托才合理。否则，应保留现有流程并清楚标记。

到达评审日期后，只有记录支持扩展时才扩大范围。成功的试点只有很少无法解释的操作，故障时有可用回退，审批负担可控，负责人也真正评审例外。失败的试点同样能教给团队具体事实：执行实际来自哪里，哪些凭据副本仍然存在，以及为什么一个操作系统无法安全承载该工作流。

混合设备环境很少会因为安全项目提出要求就变得统一。能长期维持的结果，是一个在普通工作日和事件期间都真实有效的边界。如果试点无法用一页纸说明这个事实，并通过操作对账来证明，就不要再称它为覆盖。