紧急断路运行手册：重新掌控 AI 代理

代理控制的系统需要先准备好紧急流程，而不是等到需要更多权限设置时才开始准备。当代理可以调用 API、打开 SSH 会话、修改部署或向外部服务发送数据时，人类必须能够在压力下停止工作、移除权限，并还原事情经过。

紧急访问运行手册无法让不安全的设计变得安全。它能让人们在不确定性变成损害之前控制局面。实用的版本应该能在前十五分钟内用一页纸说明重点，识别真正拥有权限的人，而不只写职位名称，并且已经由没有参与编写的人实际测试过。

紧急权限必须归属于明确指定的角色

紧急访问运行手册只有在写明谁可以无需继续请示就采取行动时才有用。

“平台团队”和“安全团队”在凌晨两点并不是答案，尤其是在几个人都以为别人负责决策的时候。

指定四个角色，再把每个角色对应到当前人员和替补人员。小团队里同一个人可以承担两个角色，但不要让一个人承担全部角色。

• 事件负责人宣布进入紧急模式，设定当前目标，并记录决策。
• 权限撤销人禁用代理会话、代理的操作通道，或代理能够接触到的凭据。
• 服务负责人决定关键工作负载是否可以安全暂停，并验证恢复结果。
• 记录员维护带时间戳的事件日志，并保护证据包。

权限撤销人在事件发生前就需要具备技术权限。这意味着他们能够禁用相关代理进程，在操作边界移除访问权限，并在需要时请求轮换凭据。只给他们一个紧急电话号码，却不给他们必要的控制台权限，这样的角色只是摆设。

尽可能安排两名来自不同汇报线的撤销人，一名主责，一名替补。服务负责人可以反对长时间中断，但在事件负责人认为活跃代理可能不安全时，不应拥有否决初步遏制行动的权力。了解情况后可以恢复服务，但无法撤回已经发出的外部 API 请求，也无法撤销已经执行的破坏性 SSH 命令。

针对每个角色，把以下信息写入运行手册：姓名、替补人员、工作联系方式、如果设有值班制度则写明非工作时间的联系方式，以及他们实际能够控制的系统。团队发生变动后要检查这份名单。过期的联系人列表不是小小的行政问题。它会让响应人员在本应直接执行的时候被迫临时发挥。

把权限和咨询分开。根据受影响的工作，法务、合规、客户支持和高级管理层可能需要收到通知，但他们不应排在遏制行动之前形成等待队列。除非有明确的法律义务要求，否则事件负责人应在完成第一次安全操作后再通知他们。

停止、撤销和保留是三种不同的操作

停止代理进程、撤销它的权限和保留证据分别解决不同问题。团队经常把它们混为一谈，然后误以为不活跃的进程已经失去访问权限。

停止操作会阻止该进程继续工作。它可能意味着终止本地进程、禁用计划任务、暂停代理运行器，或移除代码库触发器。如果进程仍在运行且行为不确定，应先停止。

撤销操作会移除使操作得以进行的权限。它可能包括禁用操作会话、撤销服务身份、锁定访问保险库、替换上游令牌，或阻断范围明确的集成。今天停止的代理可能明天从重试队列或另一台机器上重新启动。不能让它的权限因为疏忽而继续可用。

保留操作会在常规恢复覆盖信息之前，保存响应人员需要的内容。记录进程身份、源代码版本，或在相关时记录提示上下文、操作员账户、启动和停止时间、目标服务，以及最后一次确认的操作。按照保留规则保存日志和配置快照。收集证据时不要把密钥粘贴到事件工单里。

在最初几分钟使用下面这张决策卡：

Incident ID:
Declared by / time:
Affected agent process or session:
Immediate risk: active calls / possible credential exposure / unknown

[ ] Stop current run
[ ] Revoke agent authorization
[ ] Lock or rotate affected credential path
[ ] Preserve process identity and action records
[ ] Notify service owner

Revoker / time:
Recorder / time:
Recovery is prohibited until incident lead approves it.

最后一行可以阻止一种常见故障。开发者看到生产工作暂停，就重启代理让队列继续运行，结果破坏了响应人员刚刚建立的清晰边界。恢复需要单独决策，因为它会再次改变风险。

不要要求响应人员先证明恶意行为才能行动。奇怪的目标地址、失败的审批流程、无法停止的代理，或者预期操作与实际操作之间的差异，都足以先进行遏制。之后的审查可以再区分这是缺陷、错误配置还是攻击。

紧急工作需要范围狭窄的审批路径

有些紧急工作不能等待正常负责人，但“紧急”经常被用来跳过本来可以暴露异常请求的控制措施。运行手册应允许范围狭窄的例外，同时避免把每次事件都变成全面授权。

将紧急工作定义为一种具体的服务结果，如果等待正常流程，会遭受重大损害。因为有人想在午饭前完成部署而提出的待处理发布不算紧急。恢复失败的生产依赖可能是紧急事项。描述必须明确具体操作、目标、预期结果和最晚的有效完成时间。

采用以下审批顺序：

1. 请求人说明服务影响、拟执行的准确操作、受影响的账户或环境，以及过期时间。
2. 事件负责人确认遏制措施仍然有效，并指定服务负责人或其代理人验证范围。
3. 撤销人只授予该操作所需的权限，明确过期时间并记录审批人。
4. 请求人执行工作，记录员同时记录产生的操作记录和结果。
5. 结果验证后，撤销人立即移除临时权限。

审批记录应该完整而平淡。不要接受聊天中的“已批准，请修复”。要求使用类似下面的表述：

Emergency work authorization
Request ID: IR-2025-041
Requested action: restart payment-worker deployment in production
Scope: one named deployment, no repository writes, no account changes
Reason: queue is failing and manual recovery window expires at 14:30 UTC
Approver: service owner delegate
Granting revoker: access revoker
Expires: 14:30 UTC
Result and removal time:

这个例子并没有授予响应人员重启任何东西的权限。它展示的是防止范围扩大所需的具体程度。“恢复生产”隐藏了几十种可能的操作。明确指定部署对象和过期时间后，审批范围就可以被检查。

如果可以避免，不要为这条路径使用长期存在的紧急凭据。团队喜欢长期紧急访问，因为它看起来很快，但它也会制造一个永久的高价值目标。最终，人们会因为方便而把它用于普通工作。应授予范围明确的临时权限，完成后立即移除。

如果没有获授权的人可以批准紧急操作，就保持遏制措施，并沿着责任链升级。恢复延迟会带来损失，但未经授权且扩大事件范围的恢复可能造成更严重的损失。

前十五分钟应该按流程机械执行

人在压力下会漏记时间戳、争论术语，并以为同事已经完成了某项操作。运行手册需要一套有顺序的初始响应流程，即使原因仍然未知也能执行。

在第零分钟，发现问题的人创建事件记录，并陈述可观察到的事实。写“代理进程向一个无法识别的终端发送了请求”，不要写“代理已被入侵”。事实比早期推测更经得起事后审查。

随后，事件负责人宣布两种状态中的一种：调查或紧急遏制。调查表示团队没有迹象表明权限正在被不安全地使用，可以在不暂停工作的情况下检查。紧急遏制表示团队无法安全确认代理当前拥有的权限或正在执行的操作。第二种状态授权撤销人采取行动。

接下来的十五分钟按顺序完成以下事项：

1. 找到活跃的进程或会话，记录其可见身份、主机、所有者、启动时间和当前任务。
2. 如果它仍在执行，或调度器可能重新启动它，就停止后续执行。
3. 撤销该进程可用的权限，先处理后果最严重的外部操作路径。
4. 通知受影响的服务负责人遏制措施已经生效，并清楚说明运营影响。
5. 在修改无关设置前，保存操作记录和配置上下文。

这一阶段避免进行大范围清理。不要重建主机、删除工作目录、轮换公司所有密钥，也不要因为情况看起来令人担忧就修改部署设置。这些操作之后可能确有必要，但现在会掩盖证据并造成无关中断。

记录员应在一个共享位置维护简单的时间线：

14:07  Observer reported unexpected outbound request from agent run A-184.
14:09  Incident lead declared emergency containment.
14:10  Revoker stopped run A-184 and disabled its action authorization.
14:12  Service owner confirmed order processing may pause.
14:14  Recorder saved action records and configuration digest.
14:18  Team began scope review. No recovery authority granted.

这比事后写的一大段叙述更有用。它显示团队当时知道什么、谁采取了行动，以及权限何时发生变化。观点和假设应放在独立的调查记录中。

审批疲劳是设计失败

当同一个提示同时出现在无害操作和高影响操作面前时，人们会绕过警告。重复审批不会让人更谨慎，只会教会人们点击通过，好让工作继续。

紧急运行手册应明确哪些操作需要人类做出明确决定，哪些操作可以在正常权限内继续。边界必须有实际意义。会改变基础设施、连接新的外部目标、修改账户，或使用预期服务路径之外的凭据的操作，比范围明确的已知只读操作更值得审查。

不要试图用一份充满条件的庞大书面策略解决问题。事件期间，响应人员需要几个清晰选择：拒绝、停止、撤销、授予一次范围明确的紧急操作，或恢复正常运行。如果流程要求解释二十条例外条款，它会对每个响应人员以不同方式失败。

审批界面或记录必须充分识别调用方，让人类能够区分预期运行和意外运行。仅凭进程名称证据很弱，因为名称很容易复制。记录进程来源、操作系统提供时的代码签名身份、启动上下文和会话标识符。这样审批人可以说“这是从该路径启动的预期开发工具”，而不是“这个标签看起来很熟悉”。

一个常见但不好的建议是，每次敏感调用都必须由人审批。它听起来很安全，因为每个环节都有一个人。但当合法任务需要大量调用时，它就会失效：操作员会盲目批准，代理无法完成范围明确的维护工作，团队最终会关闭这一设置。只有当权限具有重要后果时，才使用一次性审批；只有在会话身份清晰且范围可接受时，才使用会话级审批。

Sallyport 通过保险库门禁、默认的逐会话授权，以及可选的逐密钥审批，采用了这种实用的划分。这不能取代运行手册，因为人类仍然需要有权停止工作，并决定是否有理由批准紧急例外。

日志必须回答谁执行了操作，以及谁批准了操作

只写着“代理做的”是不完整的事件记录。代理通过进程、身份、操作通道和人工审批路径运行。证据需要展示其中每个环节。

对每次重要调用，保存代理会话或进程身份、发起调用的人或系统、目标服务或主机、请求的操作、授权状态、结果和可信时间。对于紧急工作，在调用记录旁边写明审批人、撤销人、请求范围、过期时间和移除时间。

将审批记录与操作结果分开保存，再通过事件或请求标识符将两者关联起来。这一区分很重要。审批意味着有人授权了一次范围明确的尝试，但不能证明尝试成功、只触及预期对象，或在过期时停止。

审查时提出以下问题：

• 哪个进程发出了请求，它是如何启动的？
• 当时是哪项权限允许了这个请求？
• 谁批准了紧急工作，批准的具体范围是什么？
• 结果是否符合该范围？
• 独立审查人员能否发现记录被修改或缺失？

NIST Special Publication 800-61 Revision 2《Computer Security Incident Handling Guide》将准备、检测与分析、遏制、根除与恢复，以及事件后活动视为相互关联的工作。它关于记录和保存事件数据的指导仍然有用，但代理操作增加了旧运行手册经常遗漏的一点：你需要记录委托给机器的权限，而不只是记录人类登录。

不要把普通应用日志误认为审计轨迹。应用日志可能遗漏授权上下文，允许广泛的管理变更，或者在机器重建时消失。应保存这些日志，但要说明每条记录能够证明什么，以及不能证明什么。

对于维护加密审计链的系统，应把验证加入演练。Sallyport 通过 sp audit verify 提供离线验证，让审查人员无需保险库密钥即可检查其加密的哈希链审计日志。应在演练期间针对复制的证据集运行该命令，不要等到事件指挥官正在等待答案时才第一次使用。

恢复必须重新赢得权限

恢复服务不等于关闭事件。团队只能恢复能够解释清楚的权限，而且要用足够小的步骤进行，使复发时可以清楚看到边界。

恢复前，事件负责人需要回答三个问题：是什么导致了遏制决策，哪些权限被暴露或使用，以及现在有什么控制措施可以防止重演。你可能无法立即知道完整的根因，但仍然需要足够的把握，说明为什么第一项恢复操作是安全的。

分阶段恢复服务。尽可能先进行只读验证，然后执行一个已知操作，接着进行一次短时间的受监控运行。不要因为某项服务已经恢复，就重新启用所有代理、集成和凭据。在服务负责人和事件负责人同意受影响路径已经得到理解之前，要保留事件边界。

使用与紧急工作审批不同的恢复授权。紧急审批允许在事件期间执行必要操作，恢复审批则确认遏制后可以恢复正常权限。为它单独建立记录：

Recovery authorization
Incident ID:
Cause or remaining uncertainty:
Authority to restore:
Validation performed:
Monitoring owner and review time:
Approved by incident lead and service owner:

这里同样要注意过期时间。如果临时恢复授权在测试成功后仍然可用，它就会变成没有记录的长期访问。撤销人应在恢复记录中确认该权限已经移除。

凭据轮换需要判断，而不是走形式。如果凭据可能已经到达不受信任的进程、目标地址、代码库、日志或人员手中，或者你无法确认它的使用边界，就应进行轮换。如果代理仍然可以通过同一条不安全路径获得新凭据，不要声称轮换已经修复事件。应先修复这条路径。

事件后审查应产出修改，而不仅是观察。不要写“沟通不清”，应改成“记录员将使用事件时间线模板，服务负责人页面将列出一名替补人员”。不要写“访问困难”，应写明缺少的具体权限、将授予权限的负责人，以及下一次演练日期。

演练会暴露无人负责的部分

未经演练的运行手册只是提案。第一次实际使用时，会暴露过期联系人、缺失权限，以及谁可以重启工作的分歧。演练能在风险较低时把这些未知问题变成可修复的缺陷。

先进行桌面推演，再进行受控技术演练。桌面推演时，给参与者一个信息不完整的简短场景，例如代理在部署期间发起意外 SSH 连接。要求他们执行呼叫树，决定是否遏制，填写审批记录，并说明要保留哪些证据。不要让运行手册作者回答所有问题。

技术演练应使用非生产目标，或明确隔离的测试路径。启动一个已知的代理进程，授权一次无害操作，启动遏制措施，确认后续操作失败，保存记录，并执行有限恢复。记录每个操作所用的时间，但不要把演练变成速度竞赛。遗漏撤销的快速响应，比建立清晰边界的较慢响应更糟糕。

使用可观察的检查项为演练评分：

• 观察者能否通过文档中的联系方式联系到事件负责人和撤销人？
• 撤销人是否拥有必要权限，而不需要管理员临时设法授予权限？
• 团队是否区分了停止进程和移除进程权限？
• 审查人员能否将紧急审批与产生的操作记录对应起来？
• 临时访问是否在规定的过期或移除时间消失？

NIST SP 800-61 明确建议测试事件响应能力，理由很实际：演练可以暴露流程、培训和技术控制中的缺口。不要把测试限制在事件响应团队。让运行代理的人、受影响服务的负责人和批准紧急工作的人员都参加。他们的假设通常正是流程失效的地方。

演练结束后立即更新运行手册，此时姓名、延迟和令人困惑的说明还很鲜明。然后安排下一次演练，并把每项修正分配给负责人。如果没有人负责修正，你只是记录了一个缺陷，并选择不去修复它。

把第一步行动卡放在失败无法隐藏的地方

完整的运行手册可以放在受控文档系统中，但响应人员需要一张简短的卡片，在普通工具缓慢或受影响时仍然可用。把它放在团队无需通过代理环境就能访问的位置，并确保卡片指向当前联系人，而不是复制容易过期的详细信息。

卡片应告诉发现问题的人联系谁，告诉事件负责人何时可以宣布遏制，告诉撤销人首先要移除哪项权限，并告诉所有人恢复需要重新决策。卡片还应写明证据记录的位置，以及记录员应在哪里维护时间线。

每当你更换代理运行器、操作通道、负责人或授予访问权限的系统时，都要检查这张卡片。不要等年度审计。团队改变代理连接外部世界的方式后，紧急流程可能立刻变成一纸空文。

一次好的演练结束时，通常会留下一个有些尴尬的遗漏假设清单。保留这份清单。在演练中发现失败的团队，才真正完成了避免在中断期间发现这些失败所需的工作。