Network Controls
- Azure VNet mode routes SRE Agent egress through your VNet so it can reach data plane endpoints (such as Log Analytics and Application Insights behind private link) and comply with enterprise network policies
- Connector traffic (Jira, ServiceNow, GitHub, etc.) routes over the public internet during preview, regardless of egress mode
- You control whether public services (package registries, code repos, MCP servers) route through your VNet or the managed path
- VNet integration controls outbound (egress) traffic only
- VNet is optional — the agent works fully without it. See FAQ.
Virtual network (VNet) integration controls where the SRE Agent can send outbound traffic. Without it, outbound calls flow over the public internet. With it, traffic routes through your Azure Virtual Network. This gives you the same network-level controls you use for other Azure workloads: integration with firewalls, communication with resources behind private endpoints, and visibility in your network logs.
Network control modes
| Mode | Description | Best for |
|---|---|---|
| Unrestricted | No network restrictions. The agent can reach any internet endpoint. | Development, test, and non-sensitive workloads |
| Limited | Wildcard-based URL allowlist controls which endpoints the agent can call. | Host-level control without full VNet routing |
| Azure VNet | Non-platform outbound traffic routes through your VNet with your DNS and firewall rules applied. Connector traffic routes over the public internet during preview. Categories with infra network toggles enabled bypass the VNet intentionally. | Production deployments requiring egress control and audit compliance |
To select a mode, open your agent in the portal and navigate to Settings > Workspace configuration. You can switch between modes on a running agent — settings persist across mode changes.
How Azure VNet mode works
In Azure VNet mode, outbound traffic takes one of two paths.
Your VNet. By default, non-platform outbound traffic goes through a delegated subnet in your virtual network. Your NSG rules, firewall policies, custom DNS, and network logs all apply. The agent is subject to the same controls as any other workload on that subnet.
The agent can reach data plane endpoints behind private link (such as Log Analytics workspaces and Application Insights resources with public access disabled), internal services, and on-premises systems connected via ExpressRoute or VPN, as long as your network routes and rules allow it.
Azure SRE Agent infra network. Platform services the agent depends on (orchestration, model endpoints, telemetry) always route through Microsoft's managed infrastructure. These are not configurable. Some agent capabilities such as package installation, code repository access, and remote MCP servers require reaching public services. To use these capabilities in Azure VNet mode, enable the corresponding toggle. If a toggle is off, that capability is unavailable unless your VNet can route to those services directly (for example, through FQDN-based firewall rules).
Traffic routing summary
Platform traffic never enters your VNet. Public service categories on the managed path skip your NSG rules and firewall. Each enabled toggle is a category of traffic your network does not inspect.
| Traffic type | Path | Configurable? |
|---|---|---|
| Your Azure infrastructure (Log Analytics, App Insights, AKS, databases, Key Vaults) | Your VNet | Yes. Routed through your VNet by default. Hosts added to "Additional hosts" bypass the VNet. |
| On-premises systems (ExpressRoute / VPN) | Your VNet | Yes. Accessible if your network routes allow it. |
| Platform services (orchestration, model endpoints, telemetry) | Azure SRE Agent infra network | No. Always routed through managed infrastructure. |
| Package registries (PyPI, npm, NuGet, apt) | Infra network (toggle on) or your VNet (FQDN rule) | Yes. Per-registry toggle or preinstall packages. |
| Code repositories (GitHub, GHE, Azure DevOps) | Infra network (toggle on) or your VNet (FQDN rule) | Yes. Per-provider toggle. |
| Remote MCP servers | Infra network (toggle on) or your VNet (FQDN rule) | Yes. Single toggle. |
| Additional hostnames | Infra network (for hosts in the list) | Yes. Custom list. |
| Connector traffic | Public internet | No. Not routed through VNet in this preview. |
| Inbound (private endpoint) | Not supported | No. Egress only in this preview. |
Configure Azure VNet mode
Subnet requirements
Azure VNet mode requires a dedicated subnet in your virtual network:
- Size: /28 or larger. A /28 supports a single agent's concurrent sessions. Size up to /26 for larger fleets or burst capacity.
- Delegation: The subnet must be delegated to
Microsoft.App/environments. - Region: The subnet must be in the same region as your SRE Agent resource.
- Dedicated: The subnet can't be shared with other services.
For step-by-step setup instructions, see Configure Network Controls.
Azure SRE Agent infra network
Some agent capabilities depend on public services that are difficult to allowlist by IP address. In Azure VNet mode, these capabilities require either an infra network toggle (which routes that category through the managed infra network) or FQDN-based firewall rules in your VNet that allow the traffic directly.
If a toggle is off and your VNet can't reach the service, that capability is unavailable.
You can apply an Azure Policy to restrict or disable infra network toggles, ensuring that no operator can route traffic outside the VNet.
Package registries: toggle vs preinstall
For package registries, you have two options:
- Enable the infra network toggle — the agent reaches PyPI, npm, NuGet, or apt at runtime through the managed infra network.
- Preinstall packages — bake packages into the sandbox base image so they're available without any network call at runtime. This is the stricter option: no outbound traffic to registries at all.
To preinstall packages, navigate to Settings > Workspace configuration > Packages tab, enter the package name, select the package manager (pip or NuGet), optionally specify a version, and select + Add package.
NuGet entries must be .NET CLI tools (for example, dotnet-ef). You can't install library packages globally.
When the network blocks a call
If an outbound request is denied by an NSG rule or has no route, the agent sees the same network error any workload on that subnet would see. The agent reports the failure in its investigation output (for example, "Failed to reach Log Analytics workspace — connection timed out") and continues with the tools and data it can reach. If a critical data source is unreachable, the investigation will be incomplete, and the agent will say so.
Limitations
The following limitations apply during preview.
| Limitation | Details |
|---|---|
| Connector traffic | Connector traffic (Jira, ServiceNow, GitHub, etc.) routes over the public internet rather than through the VNet during preview. |
Get started
→ Configure Network Controls — step-by-step setup for Azure VNet mode, managed path toggles, and verification.
Related capabilities
| Capability | What it adds |
|---|---|
| Security Overview → | Overall security architecture and trust boundaries |
| Agent Identity → | How managed identity and RBAC control what the agent can do |
| Audit Agent Actions → | Track and review all actions the agent takes |
| Network Requirements → | Firewall allowlist and required domains |
| FAQ → | Common questions about VNet and network controls |