A zero trust connector decides per request for an internal HTTP console but not for a database listener: why, and what does an implant gain?

## Why parseability decides granularity Policy can only constrain what the enforcement point can name. To deny "POST to /admin/entitlements" the connector must first turn a stream of bytes into that statement: find request boundaries, decode the method and target, and know when the request ends and the response begins. That is protocol implementation work, and it exists per protocol. For request/response application protocols with well-known framing this is routine, and the connector can offer a genuinely request-scoped grant. For other protocols it is not: - **Database wire protocols** are stateful and vendor-specific: session setup, prepared statements, cursors, multiplexed result streaming, extension messages. A connector that does not implement the dialect sees an opaque conversation. - **Remote-desktop protocols** carry input events, display updates, clipboard and device redirection inside one long-lived multiplexed channel. There is no natural "request" to decide about at all. - **Vendor binary protocols** — a management channel, a message bus, an appliance's own protocol — are often undocumented. When the connector cannot parse, the decision has to be bound to the only axes it can still see: **who, from what device, to which destination, at what time, for how long**. Everything after that is inside one grant. ## What the adversary gets from the difference This is the part interviews are actually testing. The systems that resist parsing are disproportionately the ones worth most: the database holding customer records, the jump path to production, the administrative channel of an appliance. So the coarse grants land exactly where a fine grant would have been worth the most. An implant on an authorised endpoint does not have to break the broker. It waits for the session the user legitimately opens and uses it. Behind an opaque grant there is nothing left between it and the service except the service's own authorisation — the database's own roles and privileges, the appliance's own account model — which in many estates is one shared, broadly privileged account precisely because access was assumed to be controlled at the network layer. ## The four things you can actually do, and what each costs 1. **Put a parseable service in front.** Build or adopt an internal application that performs the privileged operations over a protocol the connector understands, and make the raw listener unreachable. This is the only option that genuinely restores per-request decisions. It costs a service somebody must build, own and keep in step with what operators need — and every gap in it produces a request for the raw path back. 2. **Narrow along the axes you can still see.** One destination rather than a subnet, a specific device state, a time window, a named group. This shrinks who can open the pipe. It does not constrain anything inside it, and each narrowing generates exceptions that someone must handle. 3. **Push the boundary to the far side.** Make the service's own authorisation real: distinct accounts per person, least-privilege roles, and the service's own audit trail as the record of what happened. This works, and it costs you coverage — you now depend on a system you may not own, and its logs become primary evidence. 4. **Say it plainly.** Write down which applications are all-or-nothing and what one grant to each covers. An architecture document that claims per-request enforcement while three critical systems are coarse is worse than one that names them. ## The wrong answer to aim at A competent engineer will often say the connector can "just inspect the traffic" and apply policy. Visibility is not the constraint being described here — the constraint is **semantics**. Even with the plaintext in hand, a connector that does not implement the dialect cannot reliably tell one operation from the next inside a multiplexed, stateful conversation, and a policy engine that guesses at operation boundaries fails in the worst way: it denies legitimate work intermittently while a determined adversary shapes traffic to avoid the pattern it happens to recognise. The second wrong answer is that the coarse grant is acceptable "because it is still better than a flat network". It is better — but the correct framing is that you have moved the authorisation boundary onto the target system, and you now owe an answer about whether that system's own permissions and audit are good enough to be the only boundary.