Pull the architecture diagram for any Azure environment and you are looking at a hypothesis. It shows the subnets someone drew, the firewall someone placed in the middle, the connections someone meant to allow. It is a clean story about how traffic is supposed to move.

The network actually running underneath that diagram is a different thing. Azure provisions connectivity by default, in places you never touched, using mechanisms that appear in nothing you wrote. Routes you never created. Paths to managed services that skip your inspection entirely. Name resolution that returns a different answer depending on where the question is asked. We call it the shadow network: the implicit connectivity every VNet ships with, and the part of your attack surface your diagram is least equipped to show.

Here are the four implicit paths we keep finding, why each one is invisible to the tools most teams trust, and where Act fits.

1. The routes you never wrote

Every subnet in Azure comes with a route table you did not create. Azure injects system routes the moment the subnet exists: traffic stays local inside the VNet and finds its way out to the internet, all without a single line of configuration from you. Most of the time that is convenient. It is also the first place the diagram and the network part ways.

The trouble starts when you add an inspection layer. You stand up a firewall or a network virtual appliance, you draw the arrow that sends everything through it, and you assume that is what happens. But system routes cannot be deleted, only overridden, and the only thing that overrides them is a user-defined route. Miss the route for a slice of traffic and the platform default wins for exactly that slice, quietly, around your appliance. The effective route table is the union of what Azure ships and what you declared, and the parts you did not declare are the parts you never see. An NVA in the middle of a diagram is not the same as an NVA in the middle of the path.

Where Act fits. Act calculates effective access from the resource configuration itself, so the route that exists in practice shows up even when it lives nowhere in your Terraform, and it shows up without waiting on a single observed packet. The default path the platform created and the inspection path you intended both land in the same model, and the gap between them, the drift, is the first thing you see.

2. Service endpoints: a side door to your managed data

Azure service endpoints are sold as a security feature, and used well they are one. They extend a subnet’s identity to a managed service like Storage, SQL, or Key Vault and let that service trust traffic from the subnet directly. The catch lives in that word, directly. Once the endpoint is on, Azure automatically adds its own route and sends traffic to that service across the Microsoft backbone, straight from the subnet to the resource. Nothing is deliberately dodging your firewall: the platform just installed a more specific route, and the result is a hole in the traffic you assumed was all funneling through inspection, because as far as Azure is concerned this is not egress at all. Microsoft documents this plainly: when service endpoints are in play, that traffic is not force-tunneled through your appliance.

So an inspection stack you built to watch everything leaving the subnet now has a clean blind spot shaped exactly like your most sensitive managed data. A workload that should only reach one storage account can often reach others, in other accounts, over the same kind of path, and none of it looks like a connection on your diagram. The service endpoint is an access enabler, not a line on the map.

Where Act fits. Act surfaces the service endpoint as the access enabler behind an access path and shows the managed resources a workload can actually reach through it, not only the ones your firewall would have logged. It gets there from the configuration alone, calculating the effective routes that actually resolve and the rejected routes that do not, so you get the real reachable set without depending on flow logs that never saw the traffic. A path that skips inspection is still a path, and it counts toward blast radius like any other.

3. Private Link DNS: the answer depends on who is asking

Private Link gives a managed service a private address inside your network, and it works by quietly making DNS the thing that decides where you go. The public hostname for the service is redirected to a private link name, and that name resolves to a private address only when the right private DNS zone is linked to the network asking the question. Link the zone and the workload takes the private path. Miss the link, or link a different zone, and the same hostname resolves somewhere else entirely.

That means the path a workload takes to a resource is a property of DNS state, not of anything you can read off the topology. The same name resolves to a private IP from one VNet, a public IP from another, and a stale answer from a third, and each of those is a different security posture wearing the same label. Resolution becomes the access decision, and resolution is the layer your diagram never draws.

Where Act fits. Act resolves effective access including the DNS-dependent hop, so you see what a workload actually connects to rather than what the portal implies it should. When one hostname means three different paths, Act shows you the three paths.

4. Observability that goes blind where it matters most

Here is the pattern underneath the first three. Every one of these paths is built from platform defaults, not from configuration, and almost every tool that draws your network reads configuration. Your CNAPP ingests the portal, the API, and the Terraform state, and even where it pulls flow logs, the shadow network barely registers: the platform never wrote these routes as config, it shipped them as behavior, and the traffic that rides them skips the very chokepoints those flow logs depend on. The map is drawn from the one layer that cannot see the territory.

The inspection appliances have the matching problem from the other side. Traffic that rides a service endpoint or a private link never crosses the chokepoint they sit on, so it never lands in what they record. Flow logs and inline inspection were built on the assumption that the interesting traffic passes through a place you control, and the whole point of the shadow network is that it does not. Detection that assumes you can see the packet has already lost at the boundaries where these paths live.

Where Act fits. Act computes effective access from the full resource model, including the platform routes your own configuration never spelled out, then layers observed access on top where you have it. That single model includes the paths your Terraform never declared and the chokepoint never caught, and it gets there from configuration even when no appliance ever recorded the traffic. You cannot shrink a blast radius you cannot see, and this is not one you can see from config alone unless something is actually computing the paths the platform left implicit.

The bottom line

An Azure diagram tells you what someone intended. The platform shipped a network underneath it, and every implicit path in that network is part of your blast radius whether or not anyone drew it. The routes you did not write, the service endpoints that skip your firewall, the DNS that answers differently depending on who asks: none of them are exotic, and all of them are connectivity an attacker already inside your environment gets to use for free.

The fix is not another appliance in the middle of the diagram. It is to stop trusting the diagram. Map the access that actually exists, configured and observed together, then shrink it: deny the classes of cross-environment movement these paths enable, ring-fence the crown-jewel workloads, and turn the implicit into something explicit enough to reason about.

Start with the paths you never configured. Most teams are surprised by what their workloads are actually connected to.

Adapted from “Azure Networking Dark Arts: The Implicit Paths Your Diagrams Don’t Show,” presented by Achia Rosenfeld, Kobi Rubin and Tamir Asfa at fwd:cloudsec North America 2026, Bellevue, WA.