An invoice-processing agent needs access to the supplier registry and finance API. Then a document includes an upload link, and the agent attempts to follow it. Reviewing the agent’s approved tool names does not answer whether its runtime can send data to that destination.
Outbound connectivity is a separate architectural boundary. It deserves a policy and a test of its own, alongside tool permissions, identity, and validation of the information being sent.
Evaluate the preview within its documented scope
Microsoft’s September 24 egress walkthrough introduces a preview for hosted-agent network controls. The article explicitly states that it has no preview SLA and is intended for development and evaluation rather than production use. Keep that limitation visible when assessing it.
The walkthrough describes separate Audit and Enforced modes for destination policy. It also warns that Transform and Rewrite actions still operate in Audit. Use non-sensitive test values and review action behaviour before treating an Audit trial as harmless observation.
Scope conclusions to the documented hosted-agent HTTP and HTTPS path. A successful experiment should not be generalized to other protocols, unrelated agent types, or every possible route out of an enterprise environment.
The July hosted-agent GA announcement describes the runtime milestone. That does not promote this later egress preview to GA. Runtime availability and network-control maturity are distinct facts in the architecture decision.
Explain what an outbound rule can establish
Consider a hypothetical invoice agent that checks approved finance records. A destination policy can constrain where its HTTP requests go. It does not establish that an allowed request contains the correct invoice or that the recipient should receive every field.
Separate destination permission, caller authorization, and payload validity. The identity used for the finance API needs appropriate access. The application also needs to validate the customer, invoice, and requested operation.
This separation makes investigation clearer. If a permitted endpoint receives another customer’s document, the problem is not solved by adding more hostnames to a deny list. The application failed to bind the payload to the authorized business task.
Treat redirection and helper behaviour as part of the test plan. An apparently simple request can cause a library or remote endpoint to initiate another request. Identify what the selected runtime and policy actually observe and control rather than assuming the first URL describes the whole operation.
Build a controlled experiment with endpoint evidence
Use one approved test endpoint and one deliberately unapproved endpoint under the team’s control. Neither should receive production data. Record requests at the destination so the test has independent evidence of receipt.
Attach an explicit test policy to a defined agent version and preserve its identifier. Record the runtime version, policy version, and test input together. A policy document in configuration storage is evidence of intent, not proof of enforcement.
In Audit, inspect the policy decision evidence and compare it with what both endpoints received. In Enforced, repeat the same calls and verify the approved path still works while the unapproved destination receives nothing.
Do not infer a successful policy denial from an arbitrary error. DNS failure, an expired certificate, or an endpoint’s own access rejection can all prevent a request for unrelated reasons. Correlate runtime policy evidence with the destination log before calling the experiment successful.
Keep TLS verification enabled and follow the platform’s documented certificate handling. Disabling verification to make a test work changes the security conditions and can hide a separate configuration problem.
These are recommended test steps. They are not results from a test performed for this article. Publish measured outcomes only after the team has captured them in its own environment.
Pair network controls with agent security tests
The 2024 AgentDojo evaluation demonstrates why utility and security need separate measurement. In its GPT-4o defense comparison, a tool filter reduced targeted attack success from 57.69% without defense to 6.84%, while benign utility was 69.0% and 73.13% respectively. Those are historical benchmark results under the paper’s tested attacks, not egress-control results or estimates for Foundry.
A filtered tool set and a destination boundary address different parts of the problem. The research supports testing both legitimate work and attacker goals after adding a control. Blocking everything can look secure while making the application unusable.
Microsoft’s AI Red Teaming Agent announcement describes preview assessment for prohibited actions and sensitive-data leakage. Use application-specific scenarios alongside those capabilities: an invoice containing a malicious URL, a misleading tool response, or a request to send data to an unrelated account.
Include allowed endpoints that receive invalid payloads. An attacker may not need an unapproved destination if a legitimate integration can be misused. Business authorization and output validation remain necessary.
Turn the experiment into an operating decision
Assign an owner for policy changes, an owner for application validation, and an operator for failed connections. The runbook should distinguish an expected denial from a service outage and a certificate problem.
Before changing a policy, replay required business calls and deliberate negative tests. Check each active agent version that is expected to use the change. Do not assume that editing a policy instantaneously changes every running session.
Retain a record of why each destination is needed and what data the agent is permitted to send there. Periodically remove unused destinations through the normal review process. An allow list that grows without ownership eventually loses much of its value.
For the current preview, keep the experiment in a development environment and continue using the enterprise’s established production network controls. Evaluate the capability’s maturity again before making it a production dependency.
The desired evidence is concrete: required finance lookups complete, unapproved test destinations receive no request under enforcement, and allowed calls still obey identity and payload rules. That is a useful architecture result. A statement from the agent that it followed policy is not equivalent evidence.
References
Microsoft: Hosted-agent egress preview walkthrough, September 24, 2026
Microsoft: Hosted-agent GA announcement, July 9, 2026
Debenedetti and colleagues: AgentDojo, 2024, defense comparison Table 5
