AI 代理生产访问：经得起检验的预检审查

赋予代理生产权限是一项运营决策，不是为了方便而打开的设置。代理可能连续九次正确地执行迁移、调用内部 API、建立 SSH 会话或运行部署命令，但第十次仍可能把请求发到错误的目标。一次有用的审查应假设这种情况迟早会发生，并限制它造成的后果。

AI 代理的生产访问应通过与人工紧急凭据相同的检验：是否有明确姓名的负责人能够准确说明代理能做什么，能否在运行期间停止它，能否修复最坏情况下的合理后果，并在事后证明发生了什么？只要有一个答案含糊不清，团队就是在控制措施尚未建立前授予了访问权限。

团队经常只关注模型是否会产生幻觉命令。这个风险确实存在，但并非唯一风险。代理可能过于字面地执行含糊的工单，从 shell 环境继承宽泛凭据，重试不可幂等的请求，或者运行在一个没人真正打算信任的流程中。生产故障往往来自这些普通的基础环节。

生产权限包括所有不可逆的副作用

只要代理能够造成、暴露或授权有意义的变更，生产权限就从那里开始。数据库写入之所以受到关注，是因为它看起来危险。返回客户记录的读取接口、生成访问令牌的接口、DNS 变更、发送邮件，以及重新加载服务的命令，都可能带来同等甚至更严重的后果。

让审查描述操作，而不是描述系统。说「代理可以访问生产环境」无法给审核人员提供有效信息。说「代理可以读取服务 A 当前的部署版本，并重启一个指定的 worker 组」，审核人员才能判断风险。

这一点很重要，因为访问方式会掩盖权限。SSH 账户可以运行看似无害的状态命令，却同时拥有编辑文件、重启服务或读取环境变量的权限。名为「monitoring」的 API 凭据也可能列出用户或暴露客服附件。团队必须检查服务器端的权限集合，不能只相信凭据上的标签。

在变更记录中区分四类权限：

• 读取权限：代理可以获取的数据、日志、配置和元数据。
• 变更权限：代理可以创建、更新、删除、重启或发布的资源。
• 委派权限：代理可以签发或修改的身份、权限、令牌或凭据。
• 外部权限：代理可以触发的消息、付款、工单、DNS 记录和供应商侧变更。

委派权限应单独分类。允许代理添加用户或生成另一份凭据的凭据，实际上允许它扩大未来的活动范围。审核人员经常忽略这一点，因为第一次请求看起来像管理操作，而不是破坏性操作。除非任务离不开这项能力，并且每次使用都由人工批准，否则首次生产运行不要授予委派权限。

OAuth 2.0 授权框架 RFC 6749 将 scope 描述为客户端请求、资源所有者授予的访问范围。这个说法很有用，但团队经常把 scope 当成友好的标签。只有资源服务器在每个接口、每种方法上真正执行限制时，scope 才能限制代理。请用测试账户确认执行情况，不要把 scope 字符串当成证明。

凭据范围必须匹配一项工作、一个目标和一个动词

生产凭据应当只支持一项明确工作，并且只能作用于边界清楚的目标。如果任务是「确认部署健康」，它不需要修改基础设施的权限。如果任务是「修复失败的迁移」，它可能需要写权限，但应只作用于一个数据库或服务，以及一条有文档记录的迁移路径。

最常见的错误做法，是因为团队已经知道某个人工凭据能用，就通过环境变量把它传进去。这个选择很受欢迎，因为它避免了截止时间前的权限调试，但也会破坏归因，让代理拥有该人员的全部权限，并在出问题后迫使团队进行影响广泛的轮换。单独的机器身份需要一些准备工作，却能消除大量歧义。

在签发任何凭据前，先用表格写清楚所需权限。

坚持写清动词。「访问账单」没有说明代理能查看发票、发起退款、修改套餐，还是下载客户数据。API 权限模型通常可以拆分这些操作。SSH 不一定能做到这一点，因此使用受限的包装命令或单独账户，通常比开放通用 shell 更合适。

对于 API，在代理拿到凭据之前，先测试一个允许的操作和一个禁止的操作。最小记录可以是：

agent_job: post-release-check
identity: deploy-check-agent
resource: production/service-a
allowed:
  - GET /v1/releases/current
  - GET /v1/health/summary
forbidden_test:
  request: POST /v1/releases/rollback
  expected_status: 403
expiry: "2025-04-18T18:00:00Z"
owner: service-a-oncall

日期只是示例。你的记录需要与本次运行相符的真实过期时间。真正有用的是 forbidden_test 这一行，它迫使团队证明边界，而不是只描述边界。

不要让代理陷入必须在失败和提升权限之间二选一的处境。如果正常任务需要凭据没有提供的写权限，就停止运行，修改操作手册，或请求明确的人工授权。宽泛的后备凭据会把普通的任务失败变成安全事件。

审批频率必须匹配调用的后果

审批只有在它让人真正评估一个有意义的决定时才有效。如果审批变成重复出现、大家不看内容就通过的障碍，它就失去了作用。因此，审批点应匹配后果发生的单位，而不是任意设置的计时器。

当人工审核过范围明确的工作，并且流程会执行许多可预测、后果较低的读取操作时，为新的代理进程审批一次通常合适。它能在新进程获得权限的时刻完成身份确认。但对于会产生外部承诺或删除数据的操作，这种方式并不合适。

如果每次调用都可能形成一个人希望单独检查的事件，就应逐次审批，例如删除资源、轮换凭据、执行迁移、修改权限、发送面向客户的消息，或运行影响范围较大的远程命令。提示中应使用通俗语言展示调用进程和具体操作。「批准代理请求」会迫使审批人猜测。

不要在操作完成后才要求审批。记录一个已经完成的破坏性调用是证据，不是控制措施。同样，「批准未来所有操作」只有在审查过的运行拥有狭窄且已知的操作集合时才有意义。如果任务转为调查，并开始探索陌生系统，就应结束会话，重新请求权限。

审批疲劳是设计问题。如果代理需要一百次确认才能收集健康信息，就把凭据范围缩小到这些读取操作，并审批整个会话。如果人工连续看到十个破坏性提示，应把工作转为经过审查、带有明确限制的批处理，或者回到人工操作。对话框出现得更频繁，并不会让人更加专注。

审核人员还需要一个能在运行期间生效的停止按钮。如果远程命令已经启动，或者代理可以用同样的权限重新连接，关闭终端并不够。应明确谁可以撤销活动授权、撤销需要多长时间，以及撤销后代理会看到什么。在事故迫使某人摸索流程之前先测试它。

回滚声明必须有经过测试的恢复路径

每次生产授权都应写明最坏情况下合理的副作用，以及对应的恢复操作。「我们有备份」并不能回答如何撤销权限变更、收回已发出的消息、恢复被覆盖的配置值，或停止已经在远程主机上开始运行的命令。

从实际操作开始分析。如果代理能够执行 schema 迁移，就要确定迁移是否可逆，应用代码是否同时兼容两个 schema 版本，以及谁负责决定是否恢复。如果代理能够重启 worker，就要确定如何发现重启循环，并回到之前的版本。如果代理能够调用供应商 API，就要确认供应商是否支持幂等令牌、取消操作或补偿操作。

Google SRE Book 提醒我们，自动化会同时放大正确和错误的操作。这不是反对自动化，而是说明回退和速率限制必须属于自动化设计，而不能成为事故发生后的临时补救。

一份可用的回滚记录应包括：

1. 告诉操作人员停止运行的触发条件，例如错误率阈值、目标异常，或未经过审查的操作请求。
2. 准确的恢复命令、控制台操作，或必须执行恢复的负责人。
3. 恢复后的预期状态，以及用来确认该状态的查询或观察结果。
4. 团队停止尝试修复并升级给事故负责人的节点。
5. 无法逆转的操作，并明确决定接受该风险，或将它们从授权中删除。

条件允许时，应在一次性生产资源上执行这项测试。创建一个名称清楚的测试对象，让代理完成获准的变更，在会话期间移除对象权限，然后执行恢复流程。这个练习能发现一些令人尴尬的问题：操作人员没有控制台权限，回滚命令指向了预发布环境，接口接受请求却异步完成，或者证据日志遗漏了关键请求。

幂等性也属于这项审查。代理会重试。网络可能在服务接受请求后、调用方收到响应前失败。如果没有幂等标识符或操作状态查询，代理就无法判断第一次尝试是否成功，可能因此创建重复记录。如果目标 API 无法让操作安全重试，那么遇到响应不明确时就要求人工决定。

进程身份不同于代理意图

聊天记录可以解释代理为什么采取某个行动，却不能证明是哪一个程序使用了生产权限。生产控制必须识别连接进来的本地进程、它的可执行文件来源，以及获得审批的会话。

这里容易混淆两个不同问题。「模型是否收到合理指令？」涉及意图。「经过批准的进程是否发出了这次调用？」涉及权限。清楚的指令无法保护你免受其他进程复用同一凭据的影响。经过签名的进程身份也无法说明任务请求是否合理。两者都需要，而且会产生不同的证据。

避免把凭据放入代理的上下文窗口、shell 环境、配置目录或工具输出中。一旦代理能够读取秘密，团队就无法可靠区分正常工具使用和意外泄露。在聊天记录中遮盖值有助于显示安全，但不会消除进程可能收到的其他副本。

对于 SSH，当操作人员把自己平时使用的个人身份加载到代理管理的环境中，问题会更加严重。该账户可能访问多台主机、转发到其他主机，或通过组成员身份获得权限。应创建命令范围狭窄的账户，限制可访问的主机，并测试它无法读取任务之外的文件或运行任务之外的命令。

Sallyport 在 macOS 上采用了不同的边界：代理请求本地操作网关执行 HTTP 或 SSH 操作，加密 vault 保留凭据，并返回结果，而不是返回秘密本身。这不能让错误请求变得安全，但能避免把长期有效的生产凭据直接交给代理这一常见错误。

进程身份检查不能只记录终端窗口标题。操作系统能够提供时，应记录可执行文件或代码签名机构、启动时间、用户账户和已批准的会话。如果审批后进程发生变化，就把它视为新进程。不要让通用后台 worker 继承原本为一次性修复运行批准的权限。

证据必须让另一名工程师还原整个运行

保留能够回答五个问题的证据：谁批准了运行，哪个进程执行了操作，进程拥有什么权限，每次调用尝试做什么，以及每次调用之后发生了什么。只写着「代理完成了任务」的审计记录，既无法解决争议，也无法指导恢复。

把授权事件与操作记录分开保存，即使它们来自同一个日志。授权记录说明进程为何获得访问以及何时被撤销。操作记录说明每次操作的方法、目标、结果、时间戳和关联标识符。用一个贯穿重试和交接过程的会话标识符把两类记录关联起来。

不要为了让审计轨迹完整而记录秘密。记录凭据身份或 vault 引用，但不要记录 bearer 值、私钥材料、授权头，或包含敏感数据的完整请求体。明确进行脱敏，然后确认错误日志和调试日志也遵守相同规则。许多泄露都发生在事故期间有人打开详细日志之后的错误路径中。

保存在同一台机器上的追加式日志总比没有好，但如果被入侵的进程可以重写历史，它就不能提供多少证明。哈希链日志可以在审核人员保留链的情况下发现删除或篡改。离线验证很重要，因为调查人员无需解锁凭据存储，就能检查记录。

例如，sp audit verify 可以在不需要 vault 访问权限的情况下，检查 Sallyport 加密且采用哈希链保护的审计记录。将检查作为运行后证据收集的一部分，把结果保存在变更记录中，并在信任日志之前调查任何验证失败。

使用简洁的证据清单，让审核人员不必事后从五个控制台收集信息：

run_id: prd-2025-04-18-017
purpose: repair failed migration 042
approver: service-owner
process_identity: signed-executable-identifier
credential_identity: migration-repair-agent
authorization_started: "2025-04-18T17:05:00Z"
authorization_ended: "2025-04-18T17:21:00Z"
change_reference: CHG-1842
action_log_reference: audit-export-prd-2025-04-18-017
rollback_result: test-object-restored
reviewer: oncall-engineer

这份清单不能替代详细操作记录。它为调查人员提供记录地图，并让团队在关闭变更前发现缺失的证明。目的和审批字段应由人工填写或确认。让代理自行生成证据摘要，可能会让它省略那些尴尬的部分。

预检审查应以签署的决定结束

团队应在授予权限前立即完成审查，此时任务、目标和操作人员都已明确。几个月前完成的通用安全问卷，无法回答今天的代理进程是否需要向今天的生产服务写入数据。

使用下面的审查记录。每一行都需要一个答案、一名负责人，以及明确的「批准」「修改」或「拒绝」结果。

不要把它简化为形式主义。当请求写着「所有生产环境」却没有目标，任务没有结束条件，回滚计划依赖没有文档记录的经验，或凭据负责人说不清如何撤销时，审核人员就应拒绝访问。

决定还应写明哪些情况会让团队停止运行。例如，代理请求不在批准方法列表中的操作，目标不匹配，写入响应不明确，操作人员无法理解授权提示，或审计检查失败。停止条件可以避免操作人员在压力下临时发挥。

没有必要为范围狭窄、可逆的健康检查要求完整的变更委员会。但在授予通用 shell、广泛数据库写入、客户数据访问，或修改授权的能力前，完全有理由采用这种程度的审慎。让审查力度匹配爆炸半径，但不要把跳过事实误认为速度。

在真正需要之前测试拒绝路径

权限边界只有在团队看到它拒绝某项操作后，才算通过审查。成功路径测试显示代理能工作，拒绝路径测试显示边界确实存在。

使用隔离身份和清楚标记的一次性生产资源。确认代理能够执行一项预期读取或变更。然后尝试禁止的方法、禁止的目标，以及撤销权限后的调用。为每次尝试记录响应代码、错误消息和审计条目。具体错误消息可能不同，但被拒绝的请求不能产生副作用。

要使用真实运行将采用的相同路径进行测试。预发布测试不能证明生产审批机制、生产身份绑定或生产日志有效。直接 API 测试不能证明 SSH 包装器有效。模拟测试不能证明供应商接口会遵守幂等标识符。应测试真正承载实际操作的边界。

还要测试中断。启动一个足够温和、且持续时间足够长的操作，在它运行时撤销授权，然后检查当前请求和下一次请求会发生什么。有些系统无法取消已经接受的工作。这一点应写入回滚计划，而不是藏在细则里。

在操作手册中记录预期的拒绝行为。真实运行中出现错误时，操作人员需要知道它代表健康的防护措施、损坏的凭据、目标不匹配，还是远程服务故障。把每次拒绝都当成需要绕过的东西，正是狭窄授权悄悄扩大成广泛访问的方式。

代理退出后，临时访问仍需要负责人

生产权限应在批准的任务结束时终止。为了「以防万一」而继续有效的凭据，最终会成为没有文档记录的依赖，或被忽略的生产入口。

指定一名负责人，在运行结束后删除或禁用授权，验证删除结果，并把证据附加到同一份授权记录中。如果任务变成周期性工作，就设计一个范围固定、审批规则有文档记录、并定期审查的周期性身份。不要因为一次例外曾经有用，就一直保留紧急权限。

关闭工作前，将操作日志与批准的方法列表进行比较。调查额外调用、改变状态的重试、被拒绝的请求，以及产生不明确响应的操作。然后撤销会话或凭据，即使代理报告成功也是如此。代理的报告只是审查输入，不是生产最终接受了什么的权威依据。

第一步很简单：选择一个已有的代理工作流，在下一次生产运行前强制它通过审查表。只要有人必须把内容写下来，宽泛凭据、含糊的任务描述和未经测试的恢复步骤通常很快就会暴露出来。