Microsoft announced the general availability of Azure SRE Agent virtual network integration on August 25, 2026.

The feature routes non-platform outbound agent traffic through a customer's Azure Virtual Network. That lets the agent reach databases, Azure Container Apps environments, Azure Kubernetes Service API servers, internal services, and other resources behind private endpoints while applying the organization's existing routes, firewalls, network security groups, private DNS, and network logging.

General availability adds an important production control for an agent that can query telemetry, inspect code, run diagnostics, and perform approved changes. It does not put every byte of agent traffic inside the VNet, create a private inbound endpoint, or replace identity and tool authorization.

The architecture is strongest when network, identity, and action policy are treated as three separate boundaries.

Network Reach Is Part of Agent Authority

An operational agent needs to reach the systems it investigates.

That may include:

• Azure Monitor and Log Analytics

• Application Insights

• AKS control planes

• Databases and caches

• Key Vault

• Azure Container Apps

• Internal APIs

• On-premises systems reached through ExpressRoute or VPN

• Source-control and incident platforms

• Package registries and MCP servers

Without network controls, an identity can be tightly scoped while the runtime still has broad outbound reach. With VNet integration, the agent's sandbox becomes subject to familiar enterprise egress controls.

The subnet can reach only what routing, DNS, firewall rules, security groups, proxies, and private endpoints permit.

That is valuable for regulated workloads and private application estates. It also means a network change can break an investigation. Connectivity becomes an explicit production dependency that needs ownership and monitoring.

Azure SRE Agent Has Three Network Modes

Microsoft documents three outbound network modes.

Unrestricted allows the agent to reach internet endpoints without host restrictions. It is the default and fits development, testing, and non-sensitive experiments.

Limited applies a wildcard-based URL allowlist without sending all traffic through a customer VNet. It offers host-level restriction with less network infrastructure.

Azure VNet sends non-platform outbound traffic through a delegated subnet in the customer's VNet. Network security groups, custom routes, Azure Firewall or another network virtual appliance, private DNS, and network logs apply.

Choose the mode according to the workload, not convenience.

A short-lived sandbox exploring public documentation may not need a VNet. An agent investigating private production databases or regulated data usually does.

Document the reason for the selected mode and prevent unauthorized downgrades.

VNet Integration Is Outbound Only

The GA feature controls egress from the agent.

It does not expose the SRE Agent through a private inbound endpoint. User access to the portal and agent service still follows the documented service endpoints and authentication path.

This distinction matters in architecture reviews. A diagram labeled private SRE Agent can be misleading if it suggests both ingress and egress are private.

Label each flow separately:

• Operator browser to Azure SRE Agent service

• Platform orchestration and model traffic

• Agent sandbox to customer Azure resources

• Agent sandbox to on-premises services

• Agent to code repositories and package registries

• Connector traffic to external systems

• Telemetry and audit export

Apply the control that actually covers each path.

Not All Traffic Uses the Customer VNet

Microsoft splits traffic between the customer VNet and the Azure SRE Agent infrastructure network.

By default in Azure VNet mode, non-platform outbound traffic uses the delegated subnet. That includes customer Azure infrastructure and on-premises systems reachable through configured private routes.

Platform dependencies such as orchestration, model endpoints, and service telemetry always use Microsoft's managed infrastructure. Customers cannot route those platform flows through their VNet.

Some capabilities need public services whose IP ranges change frequently. Code repositories, package registries, and remote MCP servers can use an SRE Agent infrastructure-network toggle, or the customer VNet can allow them through hostname-aware firewall rules.

The current Learn documentation also states that managed connector traffic uses the public internet and is not routed through the VNet.

This is not full traffic capture. Build the compliance assessment from the documented routing table, not from the feature name.

A Dedicated Delegated Subnet Is Required

The current GA guidance requires an empty, dedicated subnet that:

• Uses a `/27` or larger address range

• Exists in the same Azure region as the SRE Agent

• Is delegated to `Microsoft.App/environments`

• Is not shared with other services

The Microsoft Learn network-integration page and GA announcement are the current sources to follow. Validate requirements at deployment time because older setup guidance may show different minimum sizes.

Plan the subnet through the normal IP address management process. Reserve capacity for service behavior and future scale rather than placing the agent in the last small fragment of a production VNet.

Apply:

• A meaningful subnet name and ownership tags

• Network security groups

• User-defined routes where required

• Firewall or proxy routing

• Diagnostic settings

• Private DNS links

• Azure Policy for delegation and configuration

Do not reuse an application subnet simply because it already reaches the right resources.

Private DNS Determines Whether Private Endpoints Work

Routing traffic through a VNet is insufficient when resource hostnames still resolve incorrectly.

Private endpoint access depends on the relevant Azure Private DNS zones being linked to the VNet or on a custom DNS resolver forwarding those zones correctly.

The agent may need to resolve private names for Log Analytics, Key Vault, databases, storage, container environments, AKS, and internal services.

Test name resolution from the SRE Agent workspace, not just from another VM in the VNet. The two runtimes may use different DNS paths or policies.

For each private target, validate:

• The public hostname resolves to the intended private address

• The route reaches the private endpoint subnet

• Network security rules allow the flow

• The service firewall denies unintended public access

• TLS validation succeeds for the service hostname

• The agent's identity is authorized after the network connection succeeds

Network success and application authorization are separate test results.

Bypass Toggles Need Governance

Public developer services such as GitHub, PyPI, npm, NuGet, apt repositories, and remote MCP endpoints often do not provide stable Azure service tags.

Azure SRE Agent therefore exposes infrastructure-network controls that can route selected categories outside the customer VNet.

The available controls cover areas such as:

• Remote MCP server access

• Individual package registries

• GitHub, GitHub Enterprise, and Azure DevOps

• Additional hostnames or wildcard patterns

These toggles solve a practical bootstrap problem. They can also become an unmanaged bypass around enterprise inspection.

Microsoft recommends treating them as a transition rather than a permanent substitute for hostname-aware egress filtering. Azure Policy can restrict or disable the toggles.

For production:

• Disable every category the agent does not use

• Document each enabled provider

• Prefer FQDN-aware inspection where policy requires it

• Monitor configuration changes

• Review wildcard host entries

• Pin and preinstall packages where possible

• Reassess the bypass after firewall capabilities improve

An Allow Internet switch is not a dependency-management strategy.

Preinstalled Packages Reduce Runtime Egress

The network integration documentation describes preinstalling packages into the sandbox base disk image.

This helps when tools depend on Python or .NET CLI packages that are not already present. A preinstalled dependency avoids downloading the package each time the agent runs and can allow the corresponding public registry path to remain disabled.

Pin package versions and use an approved inventory. Preinstallation improves repeatability, but it also creates a software supply-chain responsibility.

Track:

• Package name and exact version

• Source repository

• License

• Vulnerability status

• Business owner

• Update and rollback procedure

• Which tools depend on it

Do not preinstall an unreviewed package merely to make an investigation prompt succeed.

Inspect and Network Audit Improve Troubleshooting

The GA announcement highlights new inspection capabilities in the Azure SRE Agent portal.

Administrators can open Settings > Workspace configuration > Inspect, run commands in the workspace shell, and test whether a destination is reachable.

Network audit shows allowed and denied outbound requests together with their egress-policy decisions.

That is valuable for answering questions such as:

• Was a hostname blocked by agent policy?

• Did the request use the expected path?

• Is a repository category disabled?

• Did the agent attempt a destination no one approved?

Microsoft is clear that Network audit is not a complete network audit trail. It does not replace Azure Firewall, DNS, proxy, NSG flow, private endpoint, or service-side logs.

Correlate the agent's view with the network infrastructure's view. Preserve both under the required retention policy.

A Denied Call Must Fail Clearly

When the network blocks a call, the agent should not silently behave as though the target returned no data.

Test visible failure for:

• DNS resolution denial

• Firewall deny

• Missing route

• Private endpoint misconfiguration

• Disabled package registry

• Disabled repository path

• Blocked remote MCP server

• Expired connector authorization

The operator should see which target failed, which control blocked it, and how that affects the conclusion.

An incident summary built from partial telemetry must say that its evidence is incomplete.

Create alerts for repeated denied calls and unexpected destinations. A sudden deny pattern can indicate configuration drift, a new dependency, or suspicious tool behavior.

Identity Still Decides What the Agent Can Do

VNet integration answers where traffic may go. Managed identity and Azure RBAC answer what the agent may access.

Reaching a private Key Vault endpoint does not grant secret access. Reaching an AKS API server does not grant cluster authority. Reaching Log Analytics does not grant query permission.

Scope the SRE Agent's managed identity to the smallest resource groups and roles necessary. Prefer read-only access for investigation and add separate, narrow write paths for approved remediation.

Audit role assignments and on-behalf-of flows. Network placement must never be used as a substitute for authorization.

A trusted subnet is not a trusted identity.

Tool Policies Still Decide Which Operations Run

Network and RBAC can both allow a request while the operation is still too risky for autonomous use.

Azure SRE Agent tool policies, run modes, hooks, connector controls, and approvals determine whether a proposed tool call is allowed, denied, or held for human review.

Use all three layers together:

• Network: Can the runtime reach the destination?

• Identity: Is the runtime authorized by the destination?

• Tool governance: Is this operation permitted in this context?

For example, the agent may reach a private AKS cluster and hold a role that permits changes. A global tool policy can still deny delete commands or require approval for a deployment.

Design failure at one layer as an intentional control, not an exception that another layer should bypass.

Switching Modes Is an Operational Change

After a VNet is connected, the agent remains in Azure VNet mode. Microsoft says the VNet must be disconnected before switching to Limited or Unrestricted.

Treat that action as a security-sensitive configuration change.

Require an approved change record, capture the before-and-after settings, and alert when a production agent disconnects from its VNet.

Use Azure Policy where available to prevent a regulated agent from enabling unmanaged infrastructure-network paths or reverting to unrestricted egress.

Test whether infrastructure-as-code can detect and correct drift without disrupting active investigations.

Roll Out with a Connectivity Matrix

Before moving a production agent into Azure VNet mode, list every required destination.

For each one, record:

• Hostname and port

• Private or public path

• DNS zone and resolver

• Route and firewall rule

• Agent identity and role

• Tool that uses the destination

• Whether an infrastructure-network toggle is enabled

• Expected audit source

• Business owner

Test reads, writes, approvals, and failure behavior for representative incidents.

Move in phases. Start with read-only Azure telemetry, then private application resources, then source control, packages, MCP servers, and approved remediation tools.

Do not enable every bypass in advance to avoid troubleshooting. That defeats the purpose of controlled egress.

Who Should Care?

Site reliability teams should care because the agent can investigate private production systems without opening them to public access.

Network teams should care because a dedicated delegated subnet, DNS, routing, firewall policy, and logging become part of the agent platform.

Security teams should care because some platform and connector traffic remains outside the customer VNet and bypass toggles need policy.

Platform teams should care because network failures can interrupt diagnostics, packages, repositories, and MCP tools.

Compliance teams should care because the agent's Network audit is useful but not a replacement for the full network evidence chain.

Practical Cloud Engineer Takeaway

Create a non-production SRE Agent in the same region as a dedicated `/27` subnet delegated to `Microsoft.App/environments`.

Connect the VNet with all infrastructure-network bypasses disabled. Test access to one private Log Analytics workspace, one private Key Vault, and one internal service.

Validate DNS, routes, firewall decisions, the agent's Network audit, and service-side authorization separately.

Then enable only the repository or package path required for a real diagnostic tool. Compare the managed infrastructure path with an FQDN-filtered path through your own firewall.

Remove one DNS link and deny one destination deliberately. Confirm the agent exposes partial evidence instead of presenting a confident but incomplete diagnosis.

Finally, apply Azure Policy, alert on mode or bypass changes, and store a connectivity matrix beside the agent's IaC definition.

Bottom Line

Azure SRE Agent VNet integration is now generally available, giving production teams control over non-platform outbound agent traffic.

The agent can reach private Azure and on-premises resources through a dedicated delegated subnet while inheriting the VNet's DNS, routes, network security groups, firewall policies, and logs.

The feature is egress-only. Platform dependencies stay on Microsoft-managed infrastructure, connector traffic is not routed through the VNet, and selected public services may use explicit infrastructure-network toggles.

VNet integration does not replace managed identity, RBAC, tool policies, approvals, or full network logging. It complements them.

Adopt the GA feature with a destination inventory, private DNS validation, narrow bypass settings, policy-enforced mode controls, failure testing, and correlated audit data.

An operational agent should see exactly the systems it needs, through paths the organization can explain and govern—and nothing more.

Sources

Microsoft Apps on Azure GA announcement, published August 25, 2026: https://techcommunity.microsoft.com/blog/appsonazureblog/azure-sre-agent-vnet-integration-is-now-generally-available/4549774

Azure SRE Agent network integration: https://learn.microsoft.com/en-us/azure/sre-agent/network-integration

Azure SRE Agent security overview: https://learn.microsoft.com/en-us/azure/sre-agent/security-overview

Azure SRE Agent tool access policies: https://learn.microsoft.com/en-us/azure/sre-agent/tool-access-policies

Azure SRE Agent network requirements: https://learn.microsoft.com/en-us/azure/sre-agent/network-requirements

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz