Egress control for AI agents on Azure means enforcing what an autonomous agent is allowed to reach on the network before its outbound request leaves your VNet. On Azure you combine NSGs, Azure Firewall, and IMDS hardening with an inline agent proxy that inspects tool-call intent, so a compromised or prompt-injected agent cannot exfiltrate data or reach unapproved hosts.
Why native Azure controls miss AI agent traffic
Azure gives you real network primitives, but none of them were designed for agents that decide their own outbound destinations at runtime. An LLM agent running in an Azure Container App, an AKS pod, or a VM makes HTTP, DNS, and WebSocket calls chosen by a model, not by a static config. The gap is not that Azure lacks filtering, it is that Azure filters at the wrong layer for agent intent.
- NSGs operate on IP ranges, ports, and service tags. They cannot see that an agent is POSTing your customer database to a webhook, because the destination is a legitimate
*.azurewebsites.netor a broad service tag. - Azure Firewall supports FQDN filtering and application rules, which is closer, but it does not parse tool-call arguments, MCP payloads, or inspect for encoded secrets in the request body.
- Azure OpenAI content filters govern the model input and output, not the agent's subsequent outbound actions on the wire.
The result: your Azure OpenAI agent security posture can look complete on paper while the actual outbound action path stays unmonitored.
The Azure IMDS lockdown for agents you cannot skip
The Instance Metadata Service at 169.254.169.254 is the highest-value target for a prompt-injected agent on Azure. A single SSRF-style tool call to the IMDS token endpoint can hand an attacker a managed identity access token scoped to your subscription resources. An azure imds lockdown agent policy is non-negotiable.
Concrete controls to layer:
- Set
Metadata: trueenforcement is not a defense by itself, so block169.254.169.254at the egress proxy for every agent workload that does not legitimately need managed identity bootstrap. - Where the workload does need IMDS, restrict it to the specific token audiences the agent requires and log every access.
- Prefer workload identity federation over broad managed identity assignments so a leaked token is narrowly scoped.
- Deny the IMDS route in your NSG for agent subnets where the SDK can be configured to use an alternate credential path.
A layered azure agent egress proxy architecture
The reliable pattern is defense in depth: coarse network controls from Azure, application-aware enforcement from an inline proxy. Route all agent outbound traffic through a proxy in the VNet, then use NSGs and Azure Firewall to guarantee the agent cannot bypass it.
| Layer | Azure control | What it sees | What it misses |
|---|---|---|---|
| Subnet | NSG rules | IP, port, service tag | Agent intent, request body |
| Perimeter | Azure Firewall FQDN rules | Destination hostname | Tool arguments, encoded exfil |
| Application | Inline agent proxy (Agent G) | Tool call, args, MCP payload, secrets | Nothing on the egress path |
| Model | Azure OpenAI filters | Prompt and completion text | Outbound network actions |
Deploying default-deny egress control ai agents azure teams can trust
The enforcement goal is default-deny: every outbound destination is blocked unless explicitly allowed. Agent G runs as the inline proxy in your VNet and becomes the single egress choke point for agent traffic.
- Place the proxy in a dedicated subnet. Deploy Agent G into a hub or shared services subnet reachable by every agent workload subnet.
- Force traffic through it. Set NSG rules on agent subnets to deny direct internet egress and allow outbound only to the proxy. Use a route table (UDR) so all
0.0.0.0/0traffic transits the proxy or Azure Firewall behind it. - Configure TLS interception. Agent G terminates and inspects encrypted egress so it can read tool arguments and MCP calls without breaking the agent SDK.
- Write an allowlist policy-as-code. Define approved FQDNs, MCP servers, and tool argument constraints in a versioned policy that ships through your existing Azure DevOps or GitHub pipeline.
- Gate risky actions with human-in-the-loop. Route irreversible or high-value operations to an approval step instead of auto-allowing them.
- Stream logs. Send wire-level egress records to Microsoft Sentinel or your SIEM for detection and audit evidence.
Concrete threats this stops on Azure
An egress control ai agents azure deployment closes vectors that NSGs and content filters never see:
- PHI or customer data exfiltration via a legitimate-looking POST to an attacker webhook, caught by inspecting the request body for sensitive patterns.
- Managed identity token theft through IMDS, blocked at the proxy before the token endpoint is reached.
- Encoded secret leakage where an agent base64-encodes an Azure connection string, normalized and detected on the wire.
- Shadow MCP calls to unapproved servers that a poisoned tool description tries to introduce.
- DNS-based exfiltration that tunnels data through hostname lookups the NSG happily forwards.
Operational notes for platform teams
Two practical concerns dominate Azure rollouts. First, latency: an inline proxy adds a hop, so it must add negligible overhead to keep agent loops responsive. Second, bypass prevention: the enforcement is only as strong as your inability to route around it. Lock down the UDR and NSG rules so no agent workload can open a direct socket to the internet, and disable public IP assignment on agent compute. Combine this with private endpoints for Azure OpenAI so the model traffic itself stays on the Microsoft backbone.
Frequently Asked Questions
Does Azure Firewall provide egress control for AI agents?
Azure Firewall enforces FQDN and application rules, which restrict which hostnames an agent can reach. It does not inspect tool-call arguments, MCP payloads, or encoded secrets in request bodies, so pair it with an inline agent proxy that reads egress content and enforces default-deny action policy.
How do I stop an Azure agent from stealing a managed identity token?
Block the IMDS endpoint at 169.254.169.254 for agent workloads that do not need bootstrap credentials, restrict token audiences where IMDS is required, prefer workload identity federation, and log every metadata access so token theft attempts surface immediately in your SIEM.
Can I run an egress proxy without breaking my agent's HTTPS calls?
Yes. An inline proxy like Agent G performs TLS interception by terminating and re-establishing the connection with a trusted internal CA, so it inspects encrypted tool calls while the agent SDK continues to see valid HTTPS. Distribute the CA cert to your agent images.
Where does the proxy sit in an Azure VNet?
Deploy it in a dedicated hub or shared services subnet, then use NSG rules and user-defined routes to force all agent subnet egress through it. Disable public IPs on agent compute so no workload can bypass the choke point and reach the internet directly.
For adjacent hardening, see how Agent G handles SSRF in AI agents, the default-deny egress allowlist playbook, and DNS exfiltration prevention. Compare approaches on our alternatives page or explore the MCP gateway.
Agent G is the zero-trust egress proxy that gives platform and DevSecOps teams real egress control for AI agents on Azure. Request access to the Agent G private beta and lock down your agent VNet before an autonomous action leaves without your approval.