Trust in Depth：企业 Agent 不该靠“每一步都人工审批”获得安全感
2026 年 10 月 15 日，AWS 提出面向 Agent 自主性的 Trust in Depth：运行前明确 Scope，部署时 Know 身份与授权，运行中 Bound 动作边界，运行后 Observe 并重建过程，对精确定义的规则进一步 Prove。它试图解决“能力越强，审批越多”的反比例困境。
让人批准每次工具调用在小规模演示中很安全，进入企业后却会制造审批疲劳。用户最终只看按钮颜色，不再理解风险。更合理的架构是让可验证的低风险动作自动通过，把不可逆、含糊或超出政策的动作升级给人。
人类审批不是安全层的替代品；它应该位于规则无法完整表达的边界。
Scope：把任务变成能力清单
“处理客户退款”过于宽泛。部署声明应列出允许读取的资源、可调用工具、金额和时间窗、禁止目的地及成功条件：
purpose: customer_refund
read:
- orders:tenant/*
write:
- refunds:create
limits:
amount_cny: 500
tool_calls: 12
deny:
- export_customer_pii
- change_bank_account
approval:
required_if: "amount_cny > 200 or policy_exception"
这份声明由平台编译为策略，不作为一段容易被覆盖的 system prompt。Prompt 可以提醒模型，执行网关必须再次判定。
Know：Agent 与用户都要有身份
日志里只有“assistant 调用了 refund”无法问责。每个部署实例拥有 workload identity，每次运行绑定发起用户或服务主体、授权来源、版本和租户。子代理委托时产生新的 delegation，而不是转发父 Agent 的完整 token。
{
"principal": "agent:refund-v12",
"on_behalf_of": "user:3182",
"audience": "tool:refund-api",
"scope": ["refund:create"],
"run_id": "run_7fc",
"expires_in": 300
}
这样可以单独撤销某个 Agent、用户或工具授权，并把动作追溯到代码和提示版本。
Bound：在工具之前执行策略
模型输出先转换为结构化动作，再由策略引擎检查参数、资源和运行预算。策略结果应包含 allow、deny 或 require_approval，以及命中规则和策略版本。
decision = policy.evaluate(
principal=ctx.agent_id,
user=ctx.user_id,
action="refund:create",
resource=f"order:{order_id}",
context={"amount": amount, "risk": risk_score},
)
if decision.effect != "allow":
raise PolicyStop(decision)
网络出口、文件系统、沙箱资源和费用也属于 Bound。只控制 API 权限，仍挡不住 Agent 通过浏览器或 shell 绕行。
Observe：证据必须可重放
每次运行保留目标、输入摘要、配置版本、策略决策、工具参数哈希、副作用收据和最终产物。完整敏感内容按需加密保存，不进入普通日志。Trace 要贯穿父子 Agent，才能看到一次上游错误如何污染最终结果。
观察不是“记录了就算完成”。平台需要从拒绝率、人工升级率、撤销动作、重复副作用和异常工具路径中生成回归样本，进入发布门禁。
Prove：精确规则可以做更强验证
对“非经理永远不能共享邮箱”“Agent 无论走哪条路径都不能访问其他租户”这类规则，样例测试无法覆盖所有状态。可把策略、角色关系和资源模型交给 SMT/模型检查或自动推理工具，搜索反例。
形式化证明也有边界：它只能证明模型和假设内的性质。业务资源映射错误、代码绕过网关或策略未部署，证明仍可能与现实脱节。因此需要策略即代码、部署证明和运行审计共同闭环。
企业平台应为动作定义风险等级：可验证的只读操作自动执行，可逆写操作带幂等与补偿，高风险动作进入人工，禁止动作永不开放。Trust in Depth 的目标不是让 Agent 少做事，而是让每一层都提供独立证据，使它在没有人盯着时仍只能在可接受边界内做事。