别信你的代理。信任你的边界：用于 LLM 工具调用的运行时授权层。

如果你的“代理”能做任何真实的事情，比如发放退款、修改生产数据、更新基础设施或给客户发电子邮件，你就越过了一条界限。困难之处不再是模型是否能建议正确的操作。困难之处是你是否能证明在高风险操作执行之前该操作已被授权。代码：https://github.com/lemnk/Sudo-agent

这就是有代理系统中的信任缺口：

• 模型的推理是概率性的。
• 副作用是确定性的且不可逆的。

大多数团队试图通过提示约束、临时允许列表或在代理需要执行多项任务时就会被过度授权的 IAM 角色来弥合这一差距。这些工具有帮助，但它们无法为“意图”和“执行”之间提供一个单一、严格且可审计的边界。

SudoAgent 的使命刻意设定得很窄：为工具和函数调用提供一个运行时授权层，采用确定性控制和可证明的可问责性，通过执行以下规则：

除非能够证明合规性，否则不得执行此动作。

Press enter or click to view image in full size

为什么“记录日志”还不够

安全团队已经在记录日志。但大多数日志是可变的操作性工件，而非证据。

如果你依赖普通的应用日志或数据库审计表，你就隐式地信任了写入它们的机器。如果主机被攻破，有决心的攻击者通常可以在事后更改或删除这些记录。

安全研究几十年来一直把这视为核心问题：如何在不受信任的机器上保存审计记录，同时使对过去条目的篡改在不被发现的情况下变得困难。Schneier 和 Kelsey 关于安全审计日志的经典工作直接阐明了这一点：一旦写入，应该使先前的日志条目不可能被未被发现地修改或销毁。(schneier.com)

所以 SudoAgent 将证据视为一等工件：

• 在执行之前写入决策记录（失败则封闭）
• 在执行之后写入结果记录（尽力而为）
• 使分类账抗篡改（哈希链 + 规范化）
• 可选择添加签名以证明真实性

这也在方向上与监管与治理的发展保持一致。欧盟人工智能法明确要求高风险人工智能系统支持事件的自动记录（日志），并在适当期限内保存日志（第 19 条的摘要至少为六个月）。(ai-act-service-desk.ec.europa.eu)
NIST 的 AI 风险管理框架是自愿性的，但它为可信 AI 风险管理和在治理职能中的操作化建立了共同语言。(nist.gov)

核心思想：确定性的边界

SudoAgent 不是一个代理框架。它不会编排多步骤计划、对工具进行排序或“让代理更聪明”。它围绕着最后一个关键步骤设定边界：会导致副作用的调用。

在运行时，对于每个工具/函数调用，SudoAgent 会执行：

1. 首先进行脱敏处理
   从脱敏后的 args/kwargs 构建上下文（以避免秘密泄露并保持可共享的证据安全）。

2 确定性策略决策
一个策略返回以下之一：

. 允许

• 拒绝
• REQUIRE_APPROVAL

3 可选批准
如果需要批准，SudoAgent 会同步暂停直到被批准/拒绝。批准可以是交互式的（开发者）或被注入的（Slack/UI/HTTP）。批准通过哈希绑定到具体决策。

4.（可选）预算
速率/花费限制采用失败关闭原则。如果无法安全评估预算，则拒绝。

5. 决策依据（失败关闭）
在执行之前将决策条目写入防篡改账本。如果此步骤失败，则该操作不会执行。

6. 执行

7. 结果证据（尽力而为）
在执行后写入一条结果条目；失败不会改变函数的返回结果/异常。

这是一个治理管道，不是提示管道

以代码形式的政策是必要的但不充分

像 Open Policy Agent (OPA) 这样的策略引擎之所以存在，是因为策略太重要，不能埋在应用业务逻辑里。OPA 的 Rego 专为对结构化数据进行策略评估而生。(openpolicyagent.org)
同样，AWS 将 Cedar 开源，聚焦高保障，包括对正确性属性的形式建模与证明。(aws.amazon.com)

SudoAgent 与这种世界观兼容，但目标在不同的层次：

• OPA/Cedar 的回答是：“这应该被允许吗？”
• SudoAgent 回答：“我们能证明允许/拒绝的过程发生在执行之前吗？我们能在事后验证这些证据吗？”

“事后”很重要。审计和事件响应是你系统的下游使用者，他们需要的不止是“相信我”。证据模型：防篡改（可察觉篡改）的分类账本

SudoAgent 的 v2 分类账本是一个仅追加的规范 JSON 对象链：

• 每条条目都包含 entry_hash。
• 每条记录还包含 prev_entry_hash。
• 如果有人修改、删除、插入或重新排序记录，验证将失败。

这与透明日志（例如 Certificate Transparency）背后的思想是一脉相承的：面向公开审计的追加式数据结构。(datatracker.ietf.org)

SudoAgent 使用直接的哈希链（不是默克尔树），因为 v2 优化了：

• 简单性
• 可检查性
• 正确性
• 单主机部署

账本可随时使用 sudoagent verify 进行验证，该命令会检查：

• 规范的 JSON 结构
• 模式/账本 版本
• 哈希链的连续性
• 决策/结果参考完整性
• 可选签名有效性

示例操作：高额退款

设想这条规则：“超过500美元的退款需要批准。”

用 SudoAgent 的术语来表述：

• 策略只看到已遮蔽的上下文
• 如果金额 > 500，要求审批
• 审批仅适用于这一具体决策
• 决策记录在退款执行之前就已写入

简化的账本决策条目如下所示：

{
“schema_version”: “2.0”,
“ledger_version”: “2.0”,
“created_at”: “2026-01-26T10:00:00.000000Z”,
“event”: “decision”,
“request_id”: “req-123”,
“action”: “payments.refund_user”,
“agent_id”: “payments:refund-bot:prod-01”,
“decision”: {
“effect”: “allow”,
“reason”: “批准通过”,
“reason_code”: “POLICY_REQUIRE_APPROVAL_HIGH_VALUE”,
“policy_id”: “RefundPolicy:v2”,
“policy_hash”: “…”,
“decision_hash”: “…”
},
“approval”：{
“binding”：{
“request_id”：“req-123”,
“policy_hash”：“…”,
“decision_hash”：“…”
},
“approved”：true，
“approver_id”：“alice@example.com”
},
“prev_entry_hash”：“…”
“entry_hash”: “…”
}

然后该结果条目会引用相同的 decision_hash 和 request_id。如果有人试图将某个结果“混合搭配”到不同的决策中，核实将失败。