Network context, claim by claim

WIN-DLP-EPIC-017 asks to enrich decisions with network context and to evaluate whether network blocking is worth its cost, because the same file to the same destination means different things on a corporate LAN and on an airport network.

Network context does not exist. Nothing in EvaluationContext says where the endpoint is.

The spike is answered (SPIKE-012, DLP-185), and it moved two things:

• Enrichment needs no driver and survives QUIC - the opposite of the risk the ticket was filed against, because the enrichment is scoped to what the OS says about this machine rather than to what can be inferred from traffic. INetworkListManager's DOMAIN_AUTHENTICATED versus PUBLIC is the ticket's own corporate-LAN-versus-airport example, answered by one call.
• Blocking by destination and application needs no driver either. User-mode WFP filters do it. Only content-aware network blocking needs a callout driver, which ADR-0004 refused and which this spike declines to reopen: it would buy visibility the browser extension already has, at the price of a kernel component whose failure mode is a bugcheck.

The caveat the design rests on: a socket table is a snapshot and attribution is racy, so network context is best-effort context on an event and never a fact a policy decides alone on. VPN state in particular cannot be answered honestly - the event will say a tunnel adapter is up, not the corporate VPN is connected.

What this audit is for is the distinction underneath, because three different things in this codebase sound like "network context" and only one of them is missing.

---

1. Three things that sound alike

Signal	What it answers	State
Server reachability - EvaluationContext::online	Can I reach my management server?	Built, and used well
Network share identity - agent/core/src/network_share.rs	Is this path on a file server, and which one?	Built (DLP-227)
Network location - agent/core/src/network_location.rs	Am I on the corporate LAN, over a VPN, or somewhere else?	Reported, not yet a condition (DLP-1147). Decided on the endpoint from each connected network's category and each adapter's DNS suffix and tunnel type, against the indicators the tenant set, and reported in health at every check-in. A policy cannot use it until DLP-1148

The first two are real and useful. The third is new and deliberately narrow:

• It reads no SSID, gateway, address or traffic.
• It says unknown when the tenant has set no indicators or the endpoint could not read its networks, and unknown never counts as corporate.
• "VPN" means a tunnel adapter carries a corporate DNS suffix, not that the corporate VPN routes the traffic.
• The Windows reader is compiled and not yet run on a host, and the frozen Linux build reports unknown.

The risk is that the first gets used as the third. online means the server answered, which on a corporate LAN with a broken server is false and on an airport wifi with an internet-facing server is true. A policy that treated online as "on the corporate network" would be wrong in both directions. Nothing does today, and the field's own documentation is precise - "false when the agent cannot reach the server" - which is why it is worth writing down before somebody reaches for it.

2. What server reachability does buy

It is not network context, and it is not nothing: a policy can carry a different action for when the endpoint is offline.

Claim	Proved by
A disconnected endpoint uses the policy's offline response	evaluate::tests::offline_response_is_used_when_disconnected
…and the decision says which action applied and why	evaluate.rs: "Endpoint is offline; the policy's offline action '…' applies instead of '…'"
Every event records whether it was evaluated offline	EndpointEvent::evaluated_offline

That last one is the property that makes an offline decision defensible after the fact: an analyst reading an incident can see the endpoint was deciding on its own, with a cached bundle, and which action that selected.

3. What network-share identity does buy

NetworkShare carries the mount point, the server as the mount names it, the share path, the filesystem and whether it is read-only.

Claim	Proved by
A read-only share is marked as one	network_share::tests::a_read_only_share_is_marked_as_one
Options that merely start with ro are not read-only	network_share::tests::options_that_merely_start_with_ro_are_not_read_only
Scanning a real host does not panic	network_share::tests::scanning_this_host_does_not_panic

A read-only share cannot be a destination, so reporting it as a monitored egress channel would be noise - which is the same instinct as everywhere else in this matrix, applied one level down.

There is latent network context here. The server name is captured and reaches the event. "This file went to \\\\fileserver01\\finance" is a statement about where the endpoint is as well as about where the file went, and a policy that could key on it would answer part of this epic without any new collection. It cannot today: PolicyScope::destinations matches domain-suffix semantics for upload destinations, not share servers.

4. What is absent, and what it would cost

DLP-185 is the spike. Recorded here so it starts from the trade rather than from an implementation.

Signal	What it is worth	What it costs
SSID / connected network name	Cheap, and the thing people mean by "on the office wifi"	Trivially spoofed - an attacker who wants to look like they are in the office names their hotspot after the office. Fine as an enrichment, dangerous as a control
Default gateway MAC	Harder to spoof casually, still local	Needs a per-site inventory somebody maintains, which decays
Domain controller reachability	A real signal: it means the machine is on a network that can see corporate infrastructure	A probe per evaluation is too expensive; cached, it is stale exactly when a laptop moves
VPN interface present and up	Real, and the one most organisations actually key policies on	Per-vendor detection, and "connected" is not "routing your traffic"

The honest shape is probably: collect several, report them as enrichment on the event, and be cautious about making any of them a condition - because every one of them is under the control of the person the policy is about.

The blocking half of the epic - whether the agent should refuse network traffic rather than file operations - is the larger question and is the same one ADR-0004 answered for the filesystem. A network filter on Windows is a WFP callout driver: kernel-mode, signed, and carrying the distribution and recovery burden SPIKE-004 priced. The answer is likely to be the same, for the same reasons, and DLP-185 should say so explicitly rather than leave it implied.

---

5. What is not covered

• No network code exists to test. The epic's criterion is met by absence: documented, with DLP-185 open.
• The latent signal in NetworkShare is not wired to policy and is not ticketed separately; it belongs in DLP-185's scope and is noted there rather than filed as a duplicate.
• online is not network location, and §1 exists so that stays true.