一个SQL解析器没法分辨一笔退款是社交工程骗来的，还是正常业务。只要语法合法，它就放行。一个正则表达式也分不清物理USB线和已激活的软件授权。单轮测试套件更抓不住一个智能体集群被跨多轮慢慢抽干。

这是零信任智能体系列第二部分要解决的问题。第一部分里，团队为自主智能体建立了三个确定性控制：用Cloud KMS签名数据库写入、用gVisor做用户态内核隔离、以及由CI单元测试支撑的输入输出网关。

打开网易新闻 查看精彩图片

这些控制有效，但它们共享同一个边界——只能拦住那些你能提前明确写出来的情况。

从语法检查转向意图判断

第二部分的思路是把安全检查移到平台上，让它们去推理意图、适应行为。检查位置一变，归属也跟着变：治理由平台或安全管理员定义和管理，与智能体开发者分离，因为平台是在智能体代码之外强制执行它的。

部署到托管平台后，自托管容器基础设施和显式维护的正则列表被托管运行时治理取代，具体包括三样东西：模型防护、语义治理策略，以及带闭环修复的智能体异常检测。

演示沿用了第一部分的客户支持与退货智能体。它查询订单、计算补货费、对商户账本支付退款。客户要求退货时，智能体用verify_order读取订单，用calculate_restocking_fee确定最终退款金额——这个函数运行在平台为模型生成代码提供的托管沙箱里。如果退款校验通过，它调用issue_refund提交付款，并用智能体自己的Cloud KMS非对称密钥签名请求，这与第一部分是同一套硬件支撑的身份。

一笔订单，两种商品

为了让攻击具体可感，所有攻击都跑在同一笔交易上：订单#99281，总额149.00美元。它包含两个行项目——29.00美元的USB-C Pro扩展坞与线缆，以及120.00美元的年度工作场所用户授权。

物理商品和数字商品之间的这个拆分，正是接下来两种攻击的着力点。

生产环境中，智能体通常通过Model Context Protocol（MCP）暴露的工具或后端API来调用这些能力。为简化配套演示，这里直接把它们实现为本地Python函数。

零信任运行时的前提

零信任运行时假设每一个单独请求看起来都可能合法，同时仍可能是攻击的一部分。它不预先硬编码每一条规则，而是强制执行三个托管控制，全部通过运行时执行点应用——这是拦截并治理交互的位置。

所有代码、策略声明和交互式模拟器都在开源配套演示zero-trust-agents-2中提供。