Microsoft Foundry Blog: Setting Testable Network Egress Boundaries for Hosted AI Agents

When building AI agents, developers typically focus on "which tools did I give the agent?" However, Muzz Imam of the Microsoft Foundry team argues that the more critical question is "where can this process send a request?" In a blog post about network egress controls in Microsoft Foundry Agent Service, Imam explains a core concept: a tool list is not a network boundary. If an agent is allowed to call an HTTP client, it can access any URL unless there are independent network-layer restrictions.

Imam illustrates this mechanism with an invoice-processing agent example. The agent needs to access a finance API and a vendor API, but if a document contains an unfamiliar upload link, or a helper library follows an unexpected URL, application-level checks alone are insufficient. He proposes moving the destination decision out of the code and onto the hosted-agent definition, controlling it via an explicit Egress Policy.

The article details how to create a JSON policy file containing FQDN rules, specifying allowed domains (such as finance.contoso.example) and defaulting to deny all other traffic. Subsequently, the policy is created via Azure CLI and attached to an agent version using the Python SDK. Imam emphasizes that successful configuration storage does not equal runtime enforcement, necessitating actual testing.

Testing occurs in two stages: first, using "Audit" mode to observe calls and confirm that requests expected to be denied generate "would-deny" evidence; then switching to "Enforced" mode to verify that unapproved destinations truly return 403 errors with no requests reaching the endpoint. This two-step approach ensures policy correctness while avoiding blocking potentially legitimate traffic in production environments directly.