Network Requirements
Network and firewall configuration required for Azure SRE Agent connectivity.
Required domains
Add the following domains to your firewall allowlist for both HTTP and WebSocket traffic:
| Domain | Purpose |
|---|---|
*.azuresre.ai | Agent portal, API, and real-time chat (WebSocket) |
sre.azure.com | Agent management portal |
portal.azure.com | Azure Portal (for Monitor → Logs and managed identity) |
api.applicationinsights.io | Application Insights query API |
Zscaler and some corporate proxies block *.azuresre.ai by default. If the portal doesn't load or the chat interface is unresponsive:
- Add
*.azuresre.aito your firewall allowlist - Ensure WebSocket connections are not blocked by your proxy
- Try the portal in an incognito/private browser window to rule out extension conflicts
Authentication requirements
| Requirement | Details |
|---|---|
| Azure account | Active Azure subscription |
| RBAC permissions | Microsoft.Authorization/roleAssignments/write — requires Role Based Access Control Administrator or User Access Administrator |
| Browser | Modern browser with JavaScript enabled |
Outbound IP addresses
Your agent uses specific outbound IP addresses when connecting to external services. These platform-assigned IPs are visible in Settings → Basics in the agent portal, with a copy button next to each address.
If your Azure Key Vault or other services have firewall rules enabled, add these IPs to the allowlist. This is required for certificate-based connectors that retrieve certificates from a firewalled Key Vault.
For step-by-step instructions, see Allowlist outbound IPs for Key Vault.
Service tags
Azure SRE Agent does not publish an Azure Service Tag for its outbound traffic, and no per-region egress IP ranges are published. There is no tag you can reference in an NSG rule, a storage account ipRules entry, or an Azure Firewall policy to admit agent traffic specifically.
The only Service Tag that covers agent egress today is AzureCloud.<region>, which admits all Azure traffic originating in that region. It is not a meaningful security boundary — do not design access control around it.
Use one of the following instead, in order of preference:
| Approach | When to use |
|---|---|
| Identity-based authorization | Preferred. Grant the agent's managed identity RBAC on the target resource, and use resource-instance or trusted-service rules. No IP rules needed. |
| Outbound IP allowlist | The target supports IP firewall rules (for example Key Vault or Storage). Use the addresses from Settings → Basics. These are platform-managed and can change when infrastructure is reallocated, so treat them as a pragmatic allowlist rather than a fixed prefix. |
| VNet-injected sandbox | You need a stable source network for sandbox traffic. For public endpoints, configure deterministic egress through a NAT Gateway or Azure Firewall backed by customer-controlled static public IP addresses or prefixes; VNet injection alone does not provide a stable public source IP. For service endpoints or private endpoints, keep traffic on the customer-VNet path. |
| Front the target with your own endpoint | The target cannot be reached any other way. Call it from a Function, Container App, or Logic App running on an address you control. |
Two layers make outbound calls. The sandbox runs terminal commands, the code interpreter, and stdio MCP servers. The runtime runs built-in Azure, Kusto, and incident-platform tools, HTTP-based MCP connectors, and HTTP triggers. VNet injection changes the source of sandbox traffic only — runtime-layer calls continue to egress from platform-managed addresses, so an allowlist sized for a VNet-injected sandbox will not admit them.
When sandbox kubectl routing is enabled, SRE Agent runs kubectl for Microsoft Entra-integrated AKS clusters from the sandbox. For a public cluster that sets apiServerAccessProfile.authorizedIpRanges, the API server sees the sandbox's public egress address rather than the address your operators use, and rejects unlisted sources before authentication. A denial may surface as an HTTP/2 INTERNAL_ERROR, or through kubectl as an error on the server ("") has prevented the request from succeeding. If authorized IP ranges caused the denial, retries, RBAC changes, credential re-issuance, and egress-policy changes that do not route sandbox traffic through an allowed source network cannot fix it. Valid authentication and authorization are still required after network access succeeds.
Allowlisting a single platform-assigned address you observe is neither sufficient nor durable. Sandbox egress is source-NATed across several load balancer frontend addresses, so a /32 built from one observation admits only a fraction of connections, and those addresses are platform-managed, are not service-tagged, and can change when infrastructure is reallocated. For a public cluster, use Azure VNet sandbox mode with deterministic public egress through a NAT Gateway or Azure Firewall backed by customer-controlled static public IP addresses or prefixes. Preserve the cluster's existing authorized ranges when you add those egress addresses or CIDRs. VNet injection without deterministic public egress is not sufficient.
Private-cluster access is a separate routing case because authorized IP ranges apply to public API endpoints. When sandbox kubectl routing is enabled, private Microsoft Entra-integrated clusters still use the sandbox and require a network path from the sandbox to the private API endpoint. Private non-Entra clusters may instead use the AKS ARM RunCommand API. RunCommand is a privileged management-plane execution path that does not require direct caller-to-API-server connectivity; it creates a command pod that remains subject to cluster networking and security controls, and the capability can be disabled. Grant only the required ARM RunCommand and normal cluster-read and credential permissions, scope them to the target AKS resource, and apply least privilege. Do not treat API server authorized IP ranges or private-endpoint access controls as restricting who can invoke RunCommand.
Once a resource is associated with an NSP in Enforced mode, its own firewall and IP rules are superseded by NSP rules — adding outbound IPs to the resource firewall will not resolve a ForbiddenByNsp denial. NSP access rules do include a serviceTags element, but no SRE Agent service tag exists to put in it, and some agent traffic presents no routable source address to NSP (denials show Client address: 0.0.0.0), so IP- and tag-based inbound rules cannot match it. Use a subscription-scoped inbound rule, and run the perimeter in Learning mode with the NspPublicInbound*Denied log categories enabled first to confirm what NSP attributes the call to before writing a rule.
Resources created during agent provisioning
When you create an agent, the following resources are automatically provisioned in your resource group:
| Resource | Purpose |
|---|---|
| Application Insights | Agent telemetry and action logging |
| Log Analytics workspace | Backing store for Application Insights |
| Managed Identity | Agent authentication for Azure resource access |
Region availability
See Supported Regions for the list of Azure regions where SRE Agent is available.
Related
| Resource | Description |
|---|---|
| Supported regions → | Azure regions where SRE Agent is available |
| Data privacy → | How SRE Agent handles your data |