VNet integration for Azure SRE Agent now generally available

VNet integration for Azure SRE Agent is now generally available, routing the agent's outbound traffic through a customer's virtual network. This allows the agent to reach resources behind private endpoints—databases, Azure Container Apps, Azure Kubernetes Service API servers, and others—without exposing them to the public internet.

The feature sends agent egress through existing network infrastructure, so traffic is subject to the same route tables, network security group rules, firewall policies, private DNS configuration, and network logging already in place. Microsoft describes this as one of three complementary controls for enterprise workloads: VNet integration governs where outbound traffic can go, identity and permissions determine which resources the agent can access, and tool policies/approvals control which operations it can run and when human review is required.

Administrators can inspect agent network activity from the portal under Settings > Workspace configuration > Inspect. From there, they can run commands in the workspace shell to test which destinations the agent can reach, and use a Network audit view to review allowed and denied outbound requests along with the policy decisions behind them.

The audit view has a limitation: it covers only agent egress-policy decisions. Microsoft is explicit that it is not a complete network audit trail and does not replace logs from firewalls, DNS, proxy servers, or other network infrastructure. Teams expecting a single pane of glass for all network activity will need to correlate the agent's audit output with their existing network logging.

Setup requires a dedicated subnet that is empty, at least /27, in the same region as the agent, and delegated to Microsoft.App/environments. After configuration, administrators can review the "On the infra network" settings. If the agent needs a code repository, its provider must be enabled or the VNet must allow outbound access to the repository host—a detail that could otherwise surface as a failed integration after deployment.

Once a VNet is connected, the agent remains in Azure VNet mode. Switching to Limited or Unrestricted mode requires disconnecting the VNet first, so configuration changes must follow that sequence.

The feature has been in preview, and an architecture overview covering design decisions is available, along with current requirements, routing details, limitations, and troubleshooting guidance. For enterprises that need agent traffic to stay inside managed network boundaries, the GA release provides a path forward, but the constraints around subnet delegation, repository access, mode switching, and audit scope mean the integration still requires planning.