An implant reused a connection-scoped grant to an internal console: with only flow records and the broker's session log, what can you show it carried?

## Read the records for what they each prove This question is really about the direction of claims, and it is where careful candidates separate themselves. **A flow record** — whatever the exporter — carries the five-tuple (source and destination address, source and destination port, protocol), packet and byte counts, and start and end timestamps. It proves that **bytes moved**, between which endpoints, in which direction, in what volume, over what interval. It carries **no payload**. It cannot tell you what an HTTP request asked for, and it cannot tell you whether the traffic was one export or ten thousand page views. **The broker's session log** proves that a **grant was issued**: this identity, on this device, in this posture, was allowed to open a session to this destination at this time, and the session lasted this long. It proves a credential and a device passed policy at that instant. It does not prove a human was at the keyboard, and it does not describe the session's contents. So after a connection-scoped grant to an internal console, the defensible statements are: a session existed between 13:02 and 15:07; it was authorised to a named identity and device; roughly 350 MB returned from the console host; the volume is far above that identity's normal daily console traffic. The statements you cannot make: which resources were opened, whether an export was run, whether anything was modified. ## Why you cannot fix this after the fact The usual instinct is to treat this as a logging gap and ask for more retention or another collector. It is not a retention problem. **Evidence granularity is a property of the unit of decision.** Per-request records come from something that reconstructed requests in order to decide about them. If nothing parsed requests, no per-request record was ever created, and no amount of retention recovers a record that was never written. That is the second half of the price this topic is about. A connection-scoped grant saves a parse and a policy evaluation on every request, and it buys you an incident you cannot bound. ## What is still worth doing - **Go to the application's own log.** An internal console usually records its own requests. The catch is identity: if the connector relayed traffic to the console and the console authenticated the user itself, you have per-request records with a user on them. If the console sits behind a shared service account or trusts the network, its log will show the connector and every session collapses into one actor. - **Bound the incident with volume and timing.** Compare the session's byte counts against that identity's baseline and against the size of plausible data sets. "350 MB returned" is weak evidence of content and strong evidence of scale, and scale is often what a notification decision turns on. - **Establish reachability, not just this session.** What else was inside that grant's destination scope? If the grant named one host and port, your uncertainty is bounded by that host; if it named a range, it is not. - **State the uncertainty explicitly.** "We cannot determine which records were viewed" is a finding. Writing it down is what forces the decision about whether the unit of decision changes for that application. ## Claims to refuse, out loud - **"The flow record shows they exfiltrated data."** It shows bytes moved outbound from the console to the client. Whether that was a bulk export or ordinary browsing is not in the record. - **"The session was authorised, so this was legitimate use."** Authorisation proves the credential and the device passed at setup. The whole premise here is that the process using the session was not the user. - **"There is no evidence of malicious requests."** There is no evidence of requests. Absence of a record from a source that never recorded requests is not evidence of absence. ## The point to land The interviewer wants to hear that you know what each artefact proves and that you attribute the blind spot to the right cause. The blind spot came from the scope of the grant. If the same session had been request-scoped, the connector's decision log would name each resource — which is exactly the record the application team's latency argument traded away.