Network Controls

TL;DR

• Azure VNet mode routes non-platform outbound traffic through your VNet so the agent can reach private endpoints, internal services, and on-premises systems
• Platform dependencies and connector traffic use Microsoft-managed infrastructure and don't enter your VNet
• You control whether package manager, code repository, remote MCP, and additional-host traffic uses your VNet or the Azure SRE Agent infra network
• VNet integration controls outbound traffic only; inbound private endpoint access isn't supported
• 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 network integration 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 by default, except connector traffic and categories intentionally routed through the Azure SRE Agent infra network.	Production deployments requiring VNet-level egress control and audit visibility

Choose a network control mode for your workload

• Azure VNet: Choose this mode if the workload handles sensitive or regulated data or requires VNet-level control and audit visibility for traffic routed through your VNet. For complete coverage, also review the relevant connector and platform telemetry and your firewall, DNS, and proxy logs.
• Limited: Choose this mode to restrict specific external destinations without routing all traffic through a virtual network.
• Unrestricted: Choose this default mode for short-term development or test environments with no access to sensitive data.

To select a mode, open your agent in the portal and select Settings > Workspace configuration. You can switch modes on a running agent, and 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, except connector traffic and categories intentionally routed through the Azure SRE Agent infra network. Your NSG rules, firewall policies, custom DNS, and network logs apply to traffic on the VNet path. The agent can reach what the subnet can reach, and nothing more.

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, including orchestration, model endpoints, and telemetry, always route through Microsoft's managed infrastructure. Some capabilities such as package installation, code repository access, and remote MCP servers also require public services. Enable the corresponding toggle or allow the service through your VNet with FQDN-based firewall rules.

Traffic routing summary

For security teams

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.
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.
Inbound (private endpoint)	Not supported	No. Egress only.

Configure Azure VNet mode

Subnet requirements

Azure VNet mode requires a dedicated subnet in your virtual network:

• Size: /27 or larger. Azure reserves 5 addresses in every subnet, and Azure SRE Agent requires at least 27 usable addresses, so a /27 (32 addresses) is the smallest subnet that validates. A smaller subnet, such as /28, is rejected when you save the configuration. 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.

note

The portal continues to report the subnet as fully available. The platform joins the delegated subnet through a service association link and allocates addresses through the delegated-subnet data path, so no network interface objects are created in your subscription. Azure Portal derives a subnet's Available IPs count from network interfaces and private endpoints, so it does not decrement for Azure SRE Agent, and you can't enumerate the addresses in use. This is expected for delegated subnets and is not an indication that Azure VNet mode is inactive.

To confirm the subnet has a service association link, run:

az network vnet subnet show \
  --ids <subnet-resource-id> \
  --query "{delegations: delegations[].serviceName, sal: serviceAssociationLinks[].name}"

Expected output shows Microsoft.App/environments in delegations and at least one service association link name in sal.

Because Azure SRE Agent allocations do not decrement the portal's Available IPs count, don't use that count for capacity planning. Size the subnet from the requirements above and keep it dedicated to the agent.

Set up Azure VNet mode

1. Go to Settings > Workspace configuration > Network.
2. Select Azure VNet as the egress mode.
3. Select Browse subnets.
4. Select the subscription, resource group, virtual network, and subnet that meets the requirements.
5. Select Save.
6. Test the agent with a representative incident.

Azure SRE Agent infra network

Capabilities that depend on public services require either an infra network toggle or FQDN-based firewall rules in your VNet. If a toggle is off and your VNet can't reach the service, that capability is unavailable.

Control	Behavior
Remote MCP server access	Routes supported remote MCP traffic through the managed path.
Package registries	Routes each enabled package registry through the managed path.
Code repositories	Routes each selected repository provider through the managed path.
Additional hosts	Routes configured hostnames or supported wildcard patterns through the managed path.

note

You can apply an Azure Policy to restrict or disable infra network toggles, ensuring that no operator can route traffic outside the VNet.

Preinstalled packages

Preinstall packages in the sandbox base disk image so they're available every time the agent runs. In Settings > Workspace configuration > Packages, enter the package name, select pip or NuGet, optionally specify a version, and select + Add package.

note

NuGet entries must be .NET CLI tools (for example, dotnet-ef). You can't install library packages globally.

Virtual network bypass controls

The On the infra network controls route remote MCP, package manager, code repository, and configured additional-host traffic outside your VNet. Use them as a transitional measure while adopting hostname-aware egress filtering.

Access to these controls requires the SRE Agent Administrator role. The controls complement managed identity, on-behalf-of credentials, and RBAC: permissions govern what the agent can do, while network configuration governs where traffic goes.

What happens when the network blocks a call

If an outbound request is denied by an NSG rule or has no route, the agent reports the network failure and continues with the tools and data it can reach. If a critical data source is unreachable, the investigation is incomplete and the agent reports that condition.

Inspect network activity

Administrators can open Settings > Workspace configuration > Inspect and use Network audit to review filtered allowed and denied outbound requests from the agent. Use the host, method, path, and decision to identify destinations blocked by Limited or Azure VNet policy.

Network audit covers agent egress-policy decisions only. It isn't a complete network audit trail and doesn't include every runtime, connector, platform, firewall, DNS, or proxy event.

Limitations

The following limitations apply:

• Egress only: VNet integration controls outbound traffic only. Inbound connections to the agent from inside a private network aren't supported.
• Connectors don't route through the VNet: Connector traffic routes over the public internet.

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