微软Foundry博客:为托管AI智能体设置可测试的网络出口边界
微软Foundry团队Muzz Imam解释了为何工具列表不等于网络边界,并演示了如何通过RAI策略定义、附加和测试托管智能体的出站目的地规则,区分审计与强制模式。
重要性实质性证据E3 可检验写法快讯
在构建AI智能体时,开发者通常关注“我给了它哪些工具”,但微软Foundry团队的Muzz Imam指出,更关键的问题是“这个进程可以向哪里发送请求”。在一篇关于Microsoft Foundry Agent Service网络出口控制的博客中,Imam解释了一个核心概念:工具列表不是网络边界。如果智能体被允许调用一个HTTP客户端,它就可以访问任何URL,除非有独立的网络层限制。
Imam通过一个发票处理智能体的例子说明了这一机制。该智能体需要访问财务API和供应商API,但如果文档中包含一个未知的上传链接,或者辅助库跟随了一个意外的URL,仅靠应用内的检查是不够的。他提出将目的地决策从代码中分离出来,放在托管智能体的定义上,通过显式的出口策略(Egress Policy)来控制。
文章详细演示了如何创建一个包含FQDN规则的JSON策略文件,指定允许的域名(如finance.contoso.example)并默认拒绝其他所有流量。随后,通过Azure CLI创建策略,并使用Python SDK将其附加到智能体版本。Imam强调,配置存储成功并不等于运行时执行成功,因此必须进行实际测试。
测试分为两个阶段:首先使用“Audit”模式观察调用,确认预期被拒绝的请求确实产生了“would-deny”证据;然后切换到“Enforced”模式,验证未批准的目的地是否真正返回403错误且无请求到达端点。这种两步法确保了策略的正确性,同时避免了在生产环境中直接阻断可能存在的合法流量。
然而,Imam也明确了这一方法的边界。目前该功能处于预览阶段,没有SLA,不建议用于生产环境。此外,出口策略只回答“这是正确的目的地吗?”这个问题,而不解决“调用者在该目的地是否有权限?”或“发送的数据是否合适?”。应用层的身份验证和数据校验仍然不可或缺。