A compromised laptop fails posture mid-session: what can the broker kill, what can only the tunnel client kill, and what breaks?

## Two enforcement positions, two different blind spots When a device stops qualifying mid-session, "tear it down" is not one action. It is two actions in two places, and knowing which one reaches which traffic is the whole substance of this question. **The broker's session table.** The access broker holds a record per live session: which principal, which device, which application, when it was admitted. That table is what makes a revocation executable at all — you can only kill what you can identify. For sessions the broker terminates or proxies, it can close them immediately and refuse the next attempt. What it cannot do is act on traffic it never carried. If the deployment excludes some destinations from the tunnel, or the laptop talks to a printer, a NAS or a peer on its own home subnet, those flows are invisible to the broker and survive the revocation untouched. **The tunnel client on the endpoint.** This is the only thing standing where that traffic passes. It can drop the tunnel, and if it does local enforcement it can block flows that never left the host. It is also the position with the ugliest property in the whole design: it runs on the device you have just declared non-compliant. If the posture failure is because someone has code execution on that laptop, the agent is not a trusted narrator — it can be stopped, starved of its signal, or made to keep reporting a healthy verdict. An enforcement decision that depends entirely on the cooperation of a compromised endpoint has assumed away the thing it was meant to defend against. ## The gap between "decided" and "enforced" The decision changes at one instant; the client notices at another. Between them sit the delivery mechanism (a push the client must be online to receive, or a poll whose interval is your floor), the device's power state (a laptop asleep in a bag learns nothing until it wakes), and the network it is on. For a workforce that is entirely remote — home broadband, hotel wifi, a tethered phone — that gap is neither small nor uniform, and the honest way to describe your teardown is a distribution, not a number. This is also why the broker-side kill matters even when the client-side one exists: the broker acts on its own state, immediately, without asking anything of the endpoint. It is the half you control. ## What a teardown costs the user A session teardown is not a graceful thing. Whatever was in flight is lost or must restart: a large upload, a video call, a report query that had run for eight minutes, an editor with unsaved state in a remote session. Multiply by the number of sessions the predicate matched. For a posture rule flipped across a large population, the visible consequence is not a security event — it is a wave of identical support tickets, and the frustration lands on the team that pushed the rule. The design responses are all trade-offs rather than fixes: narrow the predicate and you may miss the adversary; stage the rollout by cohort and you slow containment; warn people first and you have told an insider what is coming. ## What the interviewer is listening for A weak answer says "we tear down the session" and stops. A strong one is explicit about coverage: *this* traffic dies at the broker, *that* traffic dies only if the client acts, and here is the traffic that dies at neither. It is honest about trusting an agent on an untrusted host. And it names the cost — the interrupted work and the ticket queue — because that cost is what determines whether the control gets used in anger or quietly narrowed until it is decorative.