AWS 发布“纵深信任”框架，通过自动化推理与网关强制控制平衡智能体自主性

一句话结论

AWS 提出“纵深信任”框架，结合自动化推理与网关强制拦截，在提升智能体自主性的同时确保关键操作可控，重塑企业级智能体安全标准。

关键要点

• AWS 正式提出“纵深信任”（Trust in Depth）架构，旨在弥补传统“纵深防御”在智能体执行层失效的短板，将安全重心前移至生命周期运行前的范围界定阶段。
• 该框架采用最小权限原则，禁止角色捆绑导致的权限继承；对于可精确表述的规则，利用自动化推理进行数学逻辑验证，AWS 已在生产环境运行此技术超十年。
• Amazon Bedrock AgentCore Gateway 作为安全入口，在路由工具调用时强制执行策略，即使代理遭受提示注入或逻辑错误，外部强制控制依然生效。
• 在员工注销场景中，代理被限制仅使用 6 个特定工具，网关拦截了直接转换邮箱的请求，强制要求先执行“阻止登录”及“检查法律保留清单”步骤。
• 建议企业从一个智能体、一个工作流开始，利用 AgentCore 策略及 Guardrails 中的自动化推理实施可执行规则，逐步扩展信任边界。

背景与事实

传统安全架构依赖“纵深防御”，层层设防以阻止恶意行为穿透。然而，随着生成式人工智能智能体（Agents）获得更高自主执行能力，仅靠外围防火墙已不足以应对内部逻辑错误、提示注入或权限滥用。AWS 指出，智能体时代的可靠性核心在于“纵深信任”，即在智能体运行前投入最大精力进行严格的范围界定（Scoping）。这一阶段需明确智能体负责的具体工作、可触及的工具、数据及服务，并清晰划分保留给人类决策的边界。遵循最小权限原则，系统仅授予工作所需的最低访问权限，避免因角色捆绑导致智能体继承超出任务范围的过度权限。

在技术实现上，AWS 区分了两类情境。对于可精确表述的规则，采用自动化推理（Automated Reasoning）通过数学逻辑验证其在所有案例中的成立性。AWS 透露，该技术已在生产环境运行超过十年，覆盖 IAM（每秒处理超 21 亿次请求）、Nitro hypervisor、S3 公共访问阻止及 VPC 可达性分析等核心场景。对于无法精确表述的情境判断，如语气拿捏或敏感业务场景，则通过限制访问范围、评估行为模式，并将歧义交回人类处理。

具体产品生态方面，Amazon Kiro 在编码前通过自动推理发现矛盾并生成属性基测试；Strands 提供开源工具包以定义模型与工具交互；Amazon Bedrock AgentCore 通过自然语言描述策略并检查空隙，为每个代理颁发独立身份并实施请求级检查。其中，AgentCore Gateway 作为安全入口，在路由工具调用时强制执行策略。此外，Amazon Bedrock Guardrails 过滤有害内容并证明响应一致性；Strands Box 开源沙箱限制文件、服务及凭证访问；Amazon CloudWatch Omni 持续捕获全量跟踪数据，评估正确性、忠实性及工具选择准确性，并将错误数据转化为修复测试集。

影响分析

对于中文开发者与企业从业者而言，这一框架提供了从“事后审计”转向“事前界定”的安全新范式。以往智能体开发常依赖人工监控日志，而“纵深信任”强调在部署前通过自动化推理验证规则完备性，大幅降低了因逻辑漏洞导致的数据泄露风险。特别是 AgentCore Gateway 的强制拦截机制，为应对提示注入攻击提供了有效的技术护城河，意味着即使模型被恶意诱导，底层网关仍能阻断高危操作。这对于金融、医疗等对合规性要求极高的行业具有直接参考价值，开发者可借鉴其“最小权限+独立身份”的设计思路，重构现有微服务架构中的权限管理模块。同时，CloudWatch Omni 将错误转化为测试集的做法，为构建智能体的闭环评估体系提供了可落地的工程实践路径。

适用边界

该结论主要适用于具备一定规模、需处理敏感数据或关键业务逻辑的企业级智能体部署场景。对于轻量级、非敏感的个人应用或纯娱乐类智能体，实施全套“纵深信任”框架可能因成本与复杂度过高而不具备经济性。此外，自动化推理仅适用于可精确数学化的规则，对于高度依赖主观判断、伦理灰度或实时情感互动的开放式场景，框架中提到的“将歧义交给人类”意味着实时响应速度将受到制约，不适用于要求毫秒级无人工干预的自动化流程。

孤本观察

本文认为，AWS 将 IAM 十年来的成熟验证逻辑移植至智能体领域，实质是将基础设施层的确定性安全延伸至应用层的不确定性智能行为，这标志着智能体安全正从“概率性风控”向“逻辑性风控”转型。

来源：AWS Machine Learning Blog