AWS提出“纵深信任”框架:用可验证的分层控制替代人工审批,赋予AI智能体自主权
针对企业担心AI智能体失控的痛点,AWS提出“纵深信任”(Trust in Depth)框架。该框架主张通过范围界定、身份识别、边界约束和观察反馈四个层级,结合自动推理技术,在无需人工逐步审批的情况下确保智能体行为可控,从而解决规模化部署中的审查疲劳问题。
重要性结构性证据E3 可检验写法标准
在企业领导人与AI团队的对话中,一个普遍的矛盾日益凸显:他们希望AI智能体能承担更多工作,却不敢完全信任它们能始终正确执行。这种不信任是合理的,因为赋予智能体的创造力和自主性正是其价值所在,但也使其难以预测。同一个任务运行两次,智能体可能选择完全不同的路径;今天的测试通过并不能保证明天的安全。传统的解决方案是“人在回路”(human-in-the-loop),即由人类批准智能体的每一步操作。然而,随着智能体处理的任务量增加,人工审批迅速堆积,导致审查疲劳。当人们被要求检查一切时,往往反而忽略了真正重要的风险,谨慎变成了瓶颈,使得本可以产生更大价值的智能体闲置。
AWS在博客文章《Trust in Depth: Giving agents more autonomy without losing control》中提出了一个新的思路:让智能体在其行动可以被验证时自主行动,而将人类判断保留给那些真正需要判断的决策。这一方法被称为“纵深信任”(Trust in Depth),借鉴了网络安全领域“纵深防御”(Defense in Depth)的分层理念,但目的从限制错误转变为扩展安全允许的范围。核心在于建立独立且相互强化的信任层级,使组织有信心将重要工作交给AI,确信它即使在无人监督的情况下也能保持在设定的界限内。
“纵深信任”框架围绕智能体生命周期的四个关键问题构建:运行前的“范围”(Scope)、部署时的“知晓”(Know)、运行中的“约束”(Bound)以及运行后的“观察”(Observe)。首先,在智能体运行前,必须明确其用途、所需能力及绝对禁止的行为。这不仅仅是定义目标,更是精确划定权限边界。例如,AWS建议只授予任务所需的工具和数据访问权限,避免继承不必要的管理员角色。其次,每个智能体都需要独立的身份标识,以便追踪其行为及授权来源,防止出现“孤儿智能体”。
在运行过程中,关键在于区分哪些规则可以通过数学逻辑证明,哪些需要人类判断。对于可以精确表述的规则(如“只有经理才能批准访问”),AWS利用其在IAM等系统中已生产运行超过十年的自动推理(Automated Reasoning)技术进行验证。自动推理可以证明规则在所有可能路径下均成立,或找出失败的具体案例。而对于无法精确表述的期望(如“保持友好的语气”),则需限制智能体的访问权限,评估其行为,并将真正的模糊地带交由人类处理。最后,通过CloudWatch Omni等工具记录智能体的每一步操作、调用的工具和应用的策略,不仅用于事后审计,更作为改进模型的数据集。
为了说明这一机制的实际运作,AWS提供了一个员工离职处理的场景。智能体需要移除Sam的访问权限、转移邮箱并释放许可证,但必须遵守严格的顺序规则:先阻止登录再转换邮箱,且在更改许可证前必须检查法律保留要求。在“范围”阶段,团队将这些规则写入AgentCore策略;在“约束”阶段,如果智能体试图在未阻止登录的情况下转换邮箱,网关会直接拦截该调用,因为策略规定前置条件未满足。智能体随后调整步骤,先阻止登录,再转换邮箱,并在发现法律保留要求后放置保留标记,最后才更改许可证类型。整个过程无需人工逐步审批,但每一步都在可验证的策略边界内完成,确保了数据安全和合规性。
这一框架的价值在于它将信任从一种主观感受转化为可验证的工程属性。虽然并非所有业务规则都能被形式化证明,但对于高频率、高风险且规则明确的流程,“纵深信任”提供了一种摆脱人工审批瓶颈的路径。它要求开发者在构建初期投入更多精力定义精确的策略,从而换取后期更大的自主性空间。对于正在探索Agentic AI落地的企业而言,理解如何分层构建这种可验证的信任机制,比单纯追求模型能力的提升更为紧迫。