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

Microsoft: AI Red Teaming Agent, November 2025

A daily operations brief is straightforward until the agent misses a run, receives the same work twice, or reports on the wrong reporting window. The challenge is no longer generating a useful answer on demand. It is deciding what one unattended run is allowed to do and how to establish that the work is complete.

A schedule supplies a starting condition. The application needs a run contract that defines inputs, authority, time boundaries, outputs, recovery, and ownership. Establish that contract before enabling recurring execution.

Choose a task with a verifiable end

Microsoft introduced Routines in public preview in the June Build recap. The July 7 Foundry digest continued to describe Routines as preview for scheduled and triggered execution. Treat that as the maturity basis for an evaluation at this stage, rather than assuming a production service commitment.

Begin with a task whose outcome is easy to inspect. A report summarizing completed maintenance work is a better initial candidate than an agent that can independently change maintenance schedules and notify customers. The first produces evidence for review; the second creates several external commitments.

For a hypothetical maintenance-reporting agent, define the approved data sources, business unit, reporting period, output location, and recipients. Make those application configuration. The model can summarize the permitted records without choosing a broader scope or a new audience.

Give the run an explicit result type: completed, completed with declared gaps, awaiting review, failed, or superseded. A fluent report should not be the only success signal. The operator needs to distinguish “nothing happened” from “the agent could not retrieve the records.”

Define time as business data

Choose a business timezone and use explicit period boundaries. “Yesterday” is ambiguous when the service, database, and users operate in different zones. Persist the intended window with the run so a retry uses the same interval.

Decide whether records are selected by event time, completion time, or last modification. A maintenance job completed late but entered the following morning can otherwise disappear between reports. Consider a correction or reconciliation policy for late-arriving data.

Keep the reporting window independent from the actual start time. If the task begins late, it should still process the intended period unless the run policy explicitly says otherwise. Moving the window during recovery makes successive reports difficult to compare.

A catch-up decision also belongs in the contract. After an outage, should the application create each missed report, produce a consolidated report, or notify an operator? None is universally correct. Choose according to the consumer’s needs and record the choice.

Make repetition safe

Assign a stable business key to each intended result, such as business unit, report type, and reporting window. A retry should reconcile that key before producing another externally visible result.

The February durable-orchestration description provides background on workflows that wait and resume. Persistence helps coordinate execution, but the application still needs to establish whether an external write completed. Resuming a workflow is not proof that its effects occurred only once.

For the reporting example, write an internal versioned artifact before delivery. Mark which artifact is approved for distribution. If delivery times out, inspect its authoritative result before resending. Avoid letting a language-model explanation substitute for delivery evidence.

The 2024 τ-bench study assesses task outcomes through final database state and repeated trials. That evaluation principle transfers well to unattended runs: inspect the report and delivery state after retries, rather than judging only the agent’s final message.

Repeated execution can also produce a different summary from the same records. Keep the source snapshot or record versions needed to explain the difference. If a corrected report supersedes an earlier one, preserve that relationship rather than pretending both are independent daily results.

Bound authority and failure handling

Use a dedicated identity with only the access required by the recurring task. Revalidate permission at execution time. A schedule created by an authorized person should not become permanent permission to read data after access changes.

Restrict destinations through application configuration. A malicious instruction in a service record must not redirect the report or add a recipient. Treat retrieved text as information about the task, not authority to redefine it.

Set resource and retry bounds. Decide how long a run may continue, how many recoverable attempts are permitted, and when an operator receives an actionable failure. An agent should not keep searching indefinitely because a source system is unavailable.

Give incomplete data an explicit handling rule. If one approved source fails, the application may permit a report that clearly identifies the missing section, or it may require withholding the report. The business owner should make that decision before a live failure forces an improvised answer.

For any write-capable extension, separate proposal from execution and preserve the required approval. A timer can authorize starting analysis without authorizing the agent to make every change it recommends.

Prove useful unattended operation

Test duplicate invocation, a delayed start, a restart after artifact creation, a timeout after delivery, revoked access, and late-arriving records. Verify both the intended output and the absence of duplicate external effects.

Add a failure rehearsal for operators. They should be able to find the relevant run, identify the missing or uncertain step, and recover it without manually rebuilding the whole conversation. Keep source and output identifiers in the operational record.

Measure useful completed runs, incomplete reports, delivery errors, duplicate results, correction effort, and the time required to resolve failures. Track total cost per accepted report, including review and operation. A higher run count is not automatically a better outcome.

For the pilot, compare the generated brief with the existing manual report over equivalent periods. Ask the report’s consumers whether it changes a decision or saves meaningful effort. If they must reconstruct the source analysis every day, the automation has not yet earned its operating cost.

Keep the preview evaluation separate from the production commitment. Once the task boundary, recovery path, and value are established, the team can reassess the service’s release status and deployment requirements. A reliable recurring agent begins with a precise definition of one successful run.

References

Microsoft: Foundry Build Edition, June 2, 2026

Microsoft: June digest, published July 7, 2026

Microsoft: Durable agent orchestration, February 2026

Yao and colleagues: τ-bench, 2024