Azure News - 2026-09-03

We are excited to announce the general availability of explicit proxy in Azure Firewall. This capability brings the familiar explicit proxy configuration model natively to Azure Firewall, enabling applications and browsers to send outbound HTTP and HTTPS traffic directly to the firewall through standard proxy settings. Customers can now gain centralized policy enforcement and visibility while reducing their dependence on self-managed forward proxy appliances. 

Proxy the traffic you choose—not the entire subnet 

Traditional route-based steering can require all traffic from a subnet to traverse a firewall. Explicit proxy offers a more targeted model: configure selected applications or browsers to use the Azure Firewall private IP and proxy port, while other traffic continues on its existing route. This application-level control can simplify migrations, reduce unnecessary routing changes, and help teams apply inspection where it matters most. 

What’s new for general availability 

• A simpler single-port experience: Serve both HTTP and HTTPS destinations through one HTTP explicit proxy endpoint port, reducing client configuration complexity. 

• More secure PAC file access: Retrieve customer-owned proxy auto-configuration files from Azure Blob Storage using a managed identity. PAC files can be up to 256 KB. 

• A streamlined portal workflow: Enable Explicit proxy when creating a Firewall Policy, with added guidance and validation to help prevent common configuration errors. 

Built for real-world modernization 

Modernize legacy proxy infrastructure. Use Azure Firewall as the forward proxy endpoint while retaining the explicit proxy model already configured in applications and browsers. This can help organizations consolidate infrastructure and reduce operational overhead associated with self-hosted proxy appliances. 

Apply selective application-level steering. Direct only the workloads that require centralized inspection through Azure Firewall, without forcing every flow on a subnet through the same path. 

Secure Azure Arc connectivity in hybrid environments. Organizations using ExpressRoute or VPN can configure Azure Firewall as a forward proxy for Azure Arc-enabled servers, providing an inspected, policy-controlled outbound path to required Azure services without opening direct internet access from corporate networks. 

How it works 

1. Enable explicit proxy in the Azure Firewall Policy and choose the HTTP proxy port used for both HTTP and HTTPS destinations.
   
   
2. Configure applications manually with the firewall’s private IP and proxy port or enable proxy auto-configuration. 
   
   
3. If you use a PAC file, store it in Azure Blob Storage and configure the required managed identity and access permissions. 
   
   
4. Create an application rule in the Firewall Policy to allow the intended outbound destinations. 
   

Get started today

Ready to simplify outbound web traffic steering? Explore the Azure Firewall explicit proxy documentation for prerequisites, portal and API configuration steps, PAC file guidance, and supported scenarios. 

With explicit proxy now generally available, Azure Firewall gives organizations another flexible path to modernize secure egress—combining a familiar proxy model with the simplicity, scale, and centralized management of a cloud-native service. 

A ServiceNow connection tells Azure SRE Agent which incidents it can see. Advanced filtering narrows that further, so each response plan handles only the incidents it should.

Advanced filters let a plan express the rule your on-call team already follows:

Send High-priority production network incidents owned by the Network group to our network specialist, and require approval for its proposed actions.

The response plan defines the incident criteria, response subagent, and autonomy level. The selected subagent uses the connectors, source code, telemetry, and Azure access already configured on the agent. If you are still building that foundation, see What It Takes to Give SRE Agent a Useful Starting Point.

Match the incidents your team owns

A plan can specify one or more assignment groups. Search by display name or sys_id, then choose the group from the list. The plan keeps the group's stable identity, so renaming it in ServiceNow does not break the scope.

If you leave the plan's assignment group empty, it inherits the group selected under Generate insights when ServiceNow was connected. If no group was selected there, priority, title, and the plan's other filters define the match.

You can narrow the match on fields your team already uses: priority, configuration item, category and subcategory, caller/requestor, location, state, impact, urgency, and severity. Title contains and title does not contain catch patterns those fields miss.

For fields specific to your ServiceNow instance, add up to 20 custom incident fields whose technical names start with u_. Custom fields use exact equality against the stored value. Reference fields normally use the record's sys_id.

If the integration account can read ServiceNow field metadata, the form suggests friendly labels and technical names. Manual entry remains available when discovery is unavailable.

All populated filters use AND matching. Within a multi-select field, an incident can match any selected value. A plan for the Network group, High priority, category network, and u_environment = production runs only when all four conditions match.

Configure the responder

Each plan can use the Meta Agent, when its ServiceNow skill is enabled, or a custom agent with focused instructions, skills, tools, and hooks. Custom agents share the parent SRE Agent's identity, Azure resource scope, and RBAC permissions.

The built-in ServiceNow skill covers common incident actions. For more control, create a skill with your team's procedure and add search, retrieval, or other tools when the workflow needs them.

Then set how far the responder can go on its own:

• Autonomous is the default. The agent investigates and acts within its configured permissions.
• Review lets the agent investigate and propose actions for approval before it changes resources.

Preview and tune the match

Before saving or enabling a plan, preview recent ServiceNow incidents against the filter. Adjust the criteria or time range until the results reflect the incidents you intend to route.

This example intentionally uses a filter with no recent matches.

Start a new plan in Review mode. Move to Autonomous once the team has seen the filter select the right incidents and agrees with the actions the agent proposes.

Get started

Create or open your Azure SRE Agent.

Open Incidents, select Triggers & response plans, and turn on Advanced filters. You can then use the preview in new or existing response plans.

Product documentation:

• Configure ServiceNow response plans for the new filters and preview flow.
• Connect ServiceNow if the incident platform is not configured yet.
• Create a response plan for the end-to-end workflow.
• Create a custom agent to define focused instructions, skills, tools, and hooks.
• Create a skill to add a reusable procedure and its tools.
• Configure agent permissions to set Azure resource access.