微软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，不建议用于生产环境。此外，出口策略只回答“这是正确的目的地吗？”这个问题，而不解决“调用者在该目的地是否有权限？”或“发送的数据是否合适？”。应用层的身份验证和数据校验仍然不可或缺。