AI 代理访问试点：能够推动权限扩展的指标

试点应该证明，在赋予 AI 代理更广泛的权限之前，人们能够看见、判断并停止它对外部系统的操作。试点不应只证明代理可以调用 API、建立 SSH 连接，或者更快地完成工单。

团队经常收集一堆事件计数，宣布没有发生事故，然后扩大访问范围。这不是证据。真正有用的指标要回答四个更难的问题：人们批准的请求是否是他们理解的，控制措施是否拦截了应该拦截的请求，代理是否持续以暴露设计缺陷的方式失败，以及有人需要多长时间才能切断正在运行的会话。

AI 代理访问试点需要一组与决策直接相关的少量指标。跟踪审批率、被拦截的请求、重复失败和撤销时间，但不要把任何一项单独当成评分。去掉请求、目标、身份和结果等上下文后，每个指标都可能误导你。

试点要靠控制证据赢得扩展

只有当团队能够解释一批获准、被拒绝和失败的操作，并且能够按需控制正在运行的会话时，AI 代理访问试点才适合扩大范围。输出质量属于评估内容，但不能替代控制证据。

在试点开始前先定义拟议的扩展。写下当前权限、正在考虑的下一阶段权限，以及这次变化可能带来的外部后果。「让编程代理使用我们的问题跟踪器」不是一个范围。「允许这个经过签名的本地代理进程，在开发者发起的运行中，只在一个测试项目里创建问题」才是一个范围。后者能让审核人员有具体内容可以判断。

让第一次试点有意保持狭窄。限制代理进程、负责人、目标系统、凭据路径和操作类型。范围狭窄不是官僚式谨慎，它能帮助你判断一个意外请求究竟来自任务不清、集成损坏、代理困惑，还是一开始授予的权限就过于宽泛。

一份有用的试点记录应该为每个操作回答这些问题：

• 哪个代理进程发起了请求，谁启动了它？
• 它请求执行什么操作，目标是哪个明确命名的对象？
• 哪条访问路径或哪类凭据授权了该操作？
• 有没有人允许或拒绝它，原因是什么？
• 返回了什么结果，包括发生外部错误时的错误信息？

不要把这份记录简化成「代理使用了工具」。读取问题和修改部署设置都可能使用 HTTP，但它们带来的风险不同，也需要不同的审核。

NIST SP 800-53 Rev. 5 在控制措施 AU-6 中规定了审计审核、分析和报告。关键在于「审核」这个词。如果没有人能够还原请求为什么发生、谁批准了它，以及它是否成功，仅仅保留记录并没有达到实际目的。对代理试点来说，审计数据必须支持关于是否扩大访问权限的决定。如果做不到，它只是存储，不是证据。

设置一个负责人确实会遵守的审核频率。每天活跃工作结束后进行简短审核，往往比月底进行一次大型会议更有效，因为任务和意外仍然清晰。批准了奇怪请求的人还能解释当时的背景，负责集成的工程师也还能复现失败。

在有基线数据之前，不要先设定「足够安全」的目标数字。设定决策规则。例如，只要审核人员无法将请求归因到发起进程，只要高后果操作没有经过测试的撤销路径，或者只要重复失败仍然无法解释，就不扩大范围。这些规则会把讨论引向控制质量，而不是一块好看的仪表板。

审批率衡量审核质量，不代表信任程度

审批率告诉你请求得到了多少个「是」，却不能告诉你这些「是」是否经过充分理解。计算方式是：获准请求数除以需要人工决定的请求数。把提示过期、请求放弃和自动拒绝分别记录，不要悄悄将它们从分母中删除。

高审批率可能意味着代理在边界清晰的环境中提出了合理请求，也可能意味着审核人员很忙，只是快速点击提示，或者提示没有包含目标信息。还可能是同一个请求出现得太频繁，导致人们不再阅读。我见过审批系统在几天内变成形式流程，因为每个无害调用都提出同样的问题。这样一来，团队会用对待前二十个无害请求的方式，去对待唯一一个危险提示。

按切片阅读审批率。至少要区分操作类型、目标类别、会话和审核人员。如果把读取操作与账户变更合并，或者把测试环境与生产环境合并，平均值就会掩盖真正需要关注的部分。读取操作的审批率达到 95%，几乎无法说明人们是否认真检查了剩下 5% 的、能够改变状态的请求。

每周进行一次小规模抽样审核。选择几项已批准的请求，其中包括一项在会话后段发生的请求，以及一项涉及敏感目标的请求。让批准人员根据保留的记录回答四个问题：

1. 代理原本想做什么？
2. 哪个进程发出了请求？
3. 哪个外部系统会收到请求？
4. 为什么在当时批准它是合适的？

如果批准人员需要查阅聊天记录、终端滚动内容或第二个系统，才能回答这些基本问题，说明审批界面缺少上下文。如果即使有这些材料也无法回答，说明访问设计让他们在确认自己并不理解的工作。

区分会话授权和敏感操作审批。会话授权回答的是，一个新启动的进程是否可以在约定边界内行动。逐次操作的决定回答的是，这个具体操作是否值得关注。团队经常混淆这两个决定，然后声称自己实现了「人工参与」。实际上，他们可能只批准了一次进程，却没有任何可用方式发现该进程在运行中途改变了工作性质。

相反的错误同样常见：为每个低后果操作请求审批。这种设计会产生看似健康的人工决策数量，却养成毫无价值的审核习惯。减少重复提示的方法，是收窄或重新设计访问路径，而不是教人们更快地批准它们。

诚实记录分母。如果代理绕过审批路径取得了权限，这些调用就属于试点记录中的例外，即使调用成功也一样。排除绕过行为的指标，天然会让控制措施看起来更好。

拒绝请求必须有原因，也必须验证结果

被拦截的请求能够显示边界是否拦住了试点范围之外的工作，但前提是你对拦截原因进行了分类。把所有拒绝都当成胜利，是最容易导致一无所获的做法之一。

使用能够对应操作人员下一步行动的原因分类。大多数试点场景都可以归入以下四类：

• 会话没有获得授权，或者已经结束。
• 请求的操作需要明确审批，但人员拒绝了它。
• 访问路径不可用，因为本地保险库或闸门处于锁定状态。
• 请求与试点有意授予的访问权限不匹配。

本地保险库锁定后出现拒绝，说明有人保住了硬边界。用户拒绝请求可能意味着代理超出了任务范围，也可能意味着请求描述过于含糊。目标超出范围而被拒绝，可能说明边界设计良好，也可能说明设计并不完整。不要把这些原因合并成一根「已拦截」柱状图。

然后验证外部结果。只有当外部操作确实没有通过这条路径发生时，控制决定才有意义。对于 API 调用，保留尝试使用的方法、端点类别和返回的错误。对于 SSH 命令，保留请求访问的主机，以及符合审计设计的命令上下文。如果你的架构可能在决定点之前就发出工作，不要假设本地拒绝意味着远端什么都没看到。

这时团队会发现「阻止」和「失败」之间的区别。被阻止的请求从未到达服务，因为访问边界拒绝了它。失败的请求到达了服务，但收到了错误。两者都需要审核，但它们讲述的是不同的故事。把每个 403 都称为成功拦截，可能掩盖一个事实：代理不断尝试修改某个资源，而你的访问设计却意外地让网络能够接触到它。

发生拒绝时，按真实流程进行审核：

1. 找到代理运行记录，确认哪个进程发出了请求。
2. 阅读请求的操作和目标，再与原始任务进行比较。
3. 确认控制措施是否在外部操作发生前就停止了请求。
4. 判断原因：任务含糊、提示行为、缺少能力、访问范围错误，还是试图突破边界。
5. 决定应该修改任务、代理设置、访问授权，还是不做任何修改。

最后一种选择很重要。有些被拦截的请求就应该继续被拦截。试点很容易让团队产生一种冲动：代理在触及边界前看起来一直很有用，于是每次失败都授予更多访问权限。这样做会让设计逐渐失控。

留意拒绝集中出现的情况。新代理版本发布后，针对一个端点出现十次拒绝，通常说明集成存在假设问题。针对互不相关的目标出现十次拒绝，可能说明代理任务给了模型太大的自由度。审核人员已经拒绝了同一意图，但代理仍然重复请求，这时应该采取更明确的措施：停止会话，保留记录，在重试前检查任务和工具说明。

重复失败会暴露出扩大权限的危险压力

重复失败的请求是早期预警，说明代理、代理指令或访问路径之间存在不匹配。不要只记录一个原始总数，而要按指纹统计。

有用的指纹可以组合操作类别、目标、错误类别、代理版本或配置，以及一个较短的时间窗口。这样你就能区分一次短暂的服务中断和代理重复二十次相同的未授权命令。它还可以显示新的提示或工具更新是否造成了行为变化。

不要把重试当成代理「确实需要」访问授权的证据。代理会重复尝试，是因为它的规划循环认为同一个动作仍然是下一步。循环不会因为遇到决定五次，就理解你的风险判断。为了结束重试而授予凭据，会让团队形成一种习惯：只要代理施加压力，就扩大权限。

检查每组重复失败的第一次和最后一次。第一次告诉你最初的假设，最后一次告诉你代理是否改变策略、停止运行或升级尝试。这个差异很重要。一个发现错误后改用获准替代操作的代理，可能只需要更好的工具说明。一个持续探测被禁止主机的代理，则可能需要更窄的任务和会话停止机制。

为每组重复失败记录四个字段：尝试次数、经过时间、结果类别和人工响应。人工响应经常被遗漏，于是人们会误以为错误自行结束。实际上，可能有人修改了提示、授予了访问权限、重启了代理，或者撤销了会话。这些干预解释了结果。

外部服务返回的失败不一定是访问问题。身份验证错误可能说明凭据路径错误。验证错误通常说明代理输入格式错误。速率限制可能说明重试行为没有得到控制。网络错误可能说明服务本身的状况。要区别对待这些类别。为了解决验证错误而授予更宽权限，只会增加暴露面，同时让请求继续失败。

根据模式设置实际的升级阈值，而不是使用一个适用于所有情况的数字。例如，同一代理会话在人员拒绝后仍然针对敏感目标重复访问被拒绝的权限，应立即审核。新配置对外部服务产生一批错误时，应进行审核。服务已经明确要求调用方停止，但重试仍然继续时，也应进行审核。这些是行为规则，不是虚荣指标。

在原始数据旁边保留一份简短的决定日志。写下「修正端点构造」「保持访问拒绝」或「终止运行并重写任务边界」。这份日志会让试点不断积累经验。没有它，每周审核都会重新发现同一种错误模式，然后把它称为新发现。

撤销时间必须包括发现问题和验证结果

撤销时间衡量控制收敛速度，而收敛从有人意识到需要停止某次运行时就开始。测量从第一个可采取行动的信号出现，到确认该运行无法再执行任何获准操作之间的时间。

标为「撤销」的按钮可能执行得很快。这当然有用，但它只是整个时间段的一部分。在真实事件中，工程师会注意到奇怪请求，确认哪个会话拥有它，找到有权停止它的人，执行操作，并检查代理是否无法继续。如果会话身份不明确，那么寻找会话所浪费的时间也属于指标的一部分。

在演练中记录这些时间戳：

• 可疑操作出现在审核记录中。
• 指定人员决定撤销该运行。
• 该人员发出撤销操作。
• 系统记录撤销操作。
• 同一运行发起的受控后续请求被拒绝。

最后一次检查就是证据。不要通过停止代理进程，再假设访问权限已经结束，来测试撤销。终止进程可能掩盖过期授权、第二个进程、排队中的工作，或者操作人员撤销了错误会话。使用测试范围内的无害操作，并确认撤销后边界会拒绝它。

在正常工作期间进行这项演练，不要只在构建控制措施的人有空时进行。把任务交给没有配置试点的人。如果这个人无法根据记录找到正在运行的会话，说明流程过度依赖个人经验。只有一名工程师能够使用的快速撤销路径，并不能给团队带来有意义的控制能力。

区分撤销会话和轮换凭据。会话撤销会停止一个正在运行的代理会话。凭据轮换会改变秘密或权限本身，并可能影响共享该凭据的正常工作。严重事件中可能两者都需要，但它们解决的是不同问题。把它们当成同一个动作来测量，会让有针对性的响应看起来很慢，也会让范围过宽的响应看起来很高效。

Sallyport 为代理运行保留 Sessions journal，并提供即时撤销功能，同时为单次调用保留 Activity journal。在试点中，这种分离可以让团队练习找到运行、撤销运行，并确认后续调用记录，而不会把会话控制和凭据替换混为一谈。

即使演练结果很糟，也要保留它。较长的时间间隔会暴露出可以修复的弱点：责任不清、会话标记不足、通知缺失，或者人员无法访问撤销操作。隐藏失败的演练，会把第一次真正紧急的撤销变成一场本应更早完成的测试。

审计记录必须经得起分歧

只有当持怀疑态度的审核人员不必相信导出记录的人，也能验证记录内容时，审计轨迹才有用。代理访问试点需要这种属性，因为授权争议往往在事后出现，那时记忆和终端历史都可能已经改变。

对于每条抽样事件，审核人员都应该能够将发起代理运行、授权决定、操作请求、外部结果，以及之后发生的撤销连接起来。保留事件顺序。时钟不同步或事件延迟到达时，仅有时间戳可能会误导人。签名或受保护记录中的序列，才能为还原事件提供依据。

关键区别在于活动日志和防篡改审计记录。活动日志告诉你应用当前显示了什么。防篡改记录让你能够发现历史是否被修改、删除或重新排序。当试点证据决定是否授予更广泛访问权限时，你需要后者。

Sallyport 从加密哈希链审计日志生成 Sessions 和 Activity journal，sp audit verify 命令可以在离线状态下检查哈希链，而且不需要保险库密钥。把验证作为日常审核的一部分，而不是只在发生争议后才执行。没有人执行的检查，无法增加可信度。

sp audit verify

将验证结果和审核记录放在一起，并注明覆盖的时间范围。如果验证报告出现问题，在团队完成调查前，不要再把这份日志当作正常运行的证据。不要悄悄导出可读条目，继续用电子表格工作。这样做只是保留了表面形式，却丢掉了你真正需要的证据属性。

审计记录也能暴露审核疲劳。比较提示出现到获批之间的时间、请求上下文和之后的结果。对于熟悉的低后果工作，极快的审批不一定意味着粗心。可是，如果对陌生目标和敏感操作持续进行即时审批，就应该与审核人员沟通，并重新设计提示。

不要因为原始审计内容有助于监督，就让所有人都能无限制访问它。代理活动可能包含代码仓库名称、主机名、请求元数据和任务细节。明确谁负责审核、谁可以导出记录，以及谁负责解决争议。审计可见性的控制也是访问设计的一部分。

每周审核应该产出决定，而不是图表

每周试点审核应该以关于范围、修复措施和责任人的明确决定结束。如果最后只是参观仪表板，团队测量的只是活动，并没有改变风险状态。

准备一份精简材料包：一小批审批记录、所有涉及敏感操作的拒绝、重复失败最多的几组、最近一次撤销演练，以及审计验证结果。这些材料足够进行认真审核，也不会迫使大家查看每一条常规读取请求。

要求每位负责人做出决定。任务负责人决定代理请求的工作是否符合分配给它的任务。系统负责人决定目标访问是否仍然合适。访问机制负责人决定控制措施是否按预期工作。在小团队中，一个人可以承担多个角色，但仍然要明确写出。没有指定的责任，最后会变成所有人都不在意。

用直白的语言写决定。「允许获准会话在试点项目中创建问题」是可以测试的。「改进防护措施」则不是。每项变化都要配一个能够说明是否有效的指标。如果你减少了低后果读取操作的提示，就抽样检查剩余审批，确认人员现在能获得足够上下文来处理有后果的操作。如果你调整了重试处理，就检查重复失败是否确实减少，同时没有导致被拦截请求再次增加。

不要一次扩大所有维度。扩大目标范围、增加写操作、接受更多代理进程并在同一周移除审批，会破坏归因能力。出了问题，没人知道是哪项变化造成的。一次只扩大一个权限维度，在一个审核周期内观察它，并保留回滚路径。

试点最后可以决定不扩大范围。当指标表明团队还不能审核请求、控制会话或解释失败时，这仍然是一个成功结果。糟糕的做法，是假装这些缺口会在访问范围扩大、代理运行数量增加后自行消失。

更广泛的权限应该遵循一项明确通过的测试

只有当拟议的新权限在当前试点中通过具体测试后，才扩大访问范围。测试应该接近你计划允许的实际后果，而不是使用一个方便的替代品。

如果计划允许更高后果的 API 操作，就用包含相同目标上下文和审批负担的请求来测试审核人员。如果计划允许代理通过 SSH 访问更多主机，就先在具有代表性的非生产主机上测试归因、拒绝处理和撤销能力。只读试点无法证明人员能够正确处理会改变外部状态的操作。

把扩展决定写成一个证据可以推翻的主张：「团队能够在获得足够上下文的情况下授权这类操作，能够发现超出任务范围的请求，并能在约定响应时间内撤销发起请求的会话。」然后根据这项主张检查审批、拒绝、失败、撤销演练和审计记录。

不要因为审批百分比上升就提升试点。审批率上升可能是因为审核人员熟悉了提示，代理不再请求困难的工作，或者团队悄悄将拒绝从分母中删除。提升权限需要有代表性的证据和例外记录。

第一步很简单，也不引人注目：选择一个当前正在运行的代理，追踪一条获准调用和一条被拒绝或失败的调用，然后在受控演练中撤销这个确切的运行。如果团队无法还原这些事件，也无法证明该运行已经失去权限，那么扩大访问范围还为时过早。