An app's accept log shows connections from the node network, not the ingress gateway — what does that prove and what does it not?

## The record, and what it can carry An application's own accepted-connection log is the strongest evidence available about where enforcement actually lands, because it is written by the thing you are trying to protect rather than by the control you hope is protecting it. What it holds is a source address, a time, the resource asked for, and whatever identity the request carried. What it does not hold is intent. Given a window of lines where some sources are in the gateway's address pool and some are in the platform's node network, three separate conclusions are available at three different strengths: **Proven.** The application accepted connections whose source is not the enforcement point. Therefore the enforcement point is not unavoidable, and any statement of the form *all access to this application is authorised at the gateway* is false as written. This conclusion is solid and it is the finding. **Not proven.** That anything malicious happened. On a shared container platform, the node network is the source address of the platform's own health probes, of a metrics scrape, of a service-to-service call from a peer workload, and of an operator who opened a shell somewhere and used a tool. A line with no identity field is not a line with a hostile actor behind it; it is a line the enforcement point never got to annotate. Treating each of these as an incident is how a coverage finding gets discredited on the first pass. **Not answered at all.** Who or what was behind any of these requests. If identity is attached at the enforcement point and these connections did not pass it, they are anonymous by construction. That absence is itself the point: the bypass path costs you attribution, not merely policy. **Not bounded.** The complete set of paths. A record shows what was used in the window. A legacy client that runs monthly, a break-glass path used twice a year, and an operator route nobody touched this week all produce nothing. So the absence of a suspicious source in this log is not evidence that no other path exists. ## Working the finding The useful move is classification before remediation: 1. **Separate benign true positives from unknowns.** A health endpoint hit from a node address at a regular cadence is almost certainly the platform doing its job. That is a true observation of a real bypass path *and* legitimately benign — both statements hold at once, and saying so keeps the finding credible. 2. **Name an owner for each benign path.** Health probing and metrics collection are paths around the deny. They stay, and they become documented exceptions with owners rather than untracked holes. 3. **Investigate the unknowns as coverage, not as intrusion.** A node-network source hitting the same business endpoints that authenticated users hit is worth chasing, but chase it as *which component is this and why does it not go through the front door*, escalating to incident handling only if no owner claims it. 4. **Close the path, then re-measure.** Make the application accept connections only from the enforcement point's sources, or place enforcement in its own network path so there is no non-enforcement route. Then re-read the same log: an accept log with a single source class is the evidence that the deny is unavoidable, and it is far better evidence than a diagram. ## What this costs Closing the path is not free and the price lands on other people. Restricting accepted sources breaks the health probe and the metrics scrape on the day you turn it on unless those are enumerated first, and the outage looks like the application's fault. Every legitimate path you preserve becomes an entry on an exception list that somebody owns and someone must review; the list grows faster than it shrinks, because each entry has an advocate and removal has none. And the moment enforcement becomes unavoidable, the operator path becomes the pressure point: whoever needed the direct route at 3am now needs a route that works, or they will build a new one and you will find it in this same log next quarter. ## The interview signal What is being tested is discipline about the direction of a claim. A weak answer reads these lines as an intrusion. A strong answer says: this is proof of a coverage gap, not of an attack; here is what each source probably is; here is what I would have to do to make the deny unavoidable; and here is what breaks when I do.