A zero trust broker authorises a connection once at setup: what can an implant on that laptop then do, and what does per-request checking cost?
answer
- What object did the decision authorise?
- A pipe, or one message?
- The tunnel is local to the device
- Implant needs no credential to reuse it
- Per-request means parse plus lookup each time
basics
~20 sA connection-scoped grant authorises the pipe, not the messages inside it: an implant on that laptop can send anything the protocol allows down it, uncredentialed. Deciding per request closes that, at a parse and a lookup per request.
solid answer
~50 sThe unit of the decision is the whole point. If the broker decides once, at connection setup, the thing it authorised is a byte pipe to a workload; every message inside that pipe is unexamined by the enforcement point. An implant running as the same user on the same device does not need to steal a credential to use it — the pipe is already open locally, and it inherits everything the account can do on the far side. A per-request grant means the connector reconstructs each request and asks policy about *that* request, so the implant now has to produce requests that pass, and each one leaves a decision record. What you pay is real and it lands on the hot path: a parse plus a policy evaluation on every single request, a connector that must understand the protocol, and a per-request rule set somebody has to write and keep current as the application changes.
go deeper
Be ready to say what one grant covers — a connection or a request — and to name the consequence of the first in one sentence: anything on that device that can reach the open pipe inherits it.
Explain the mechanics: the connector must reconstruct requests before it can decide about them, and each decision costs a parse and an evaluation on the request path.
Show you can decide per application which unit you can afford, and say plainly which systems in an estate can only ever be connection-scoped.
Own the framing that scope of a grant is an architectural property with a running cost, and that promising per-request enforcement estate-wide commits people to writing and maintaining per-request policy for every application.
## What a "grant" is, and why its scope is the question In a zero trust design the enforcement point issues a **grant**: a decision that this identity, on this device, in this posture, may reach this thing. Interviews almost always probe *whether* the decision is made. The better question, and the one this topic is about, is **what one decision covers** — because that, not the existence of the decision, sets what an adversary gets once it is made. There are two units in practice. **Connection-scoped.** The broker evaluates identity, device and policy when a connection is being set up, allows it, and from then on relays bytes between the client and the workload. The authorised object is a pipe. **Request-scoped.** The connector parses the byte stream back into discrete requests — for HTTP, a method, a path, a host, headers — and asks policy about each one before relaying it. The authorised object is a single request. ## What an implant gains from the first The common wrong answer is that a connection-scoped grant is fine because the adversary would still need the user's credential. It would not. Once the pipe exists it is a **local object on the device** — a listening socket, a loopback endpoint, a tunnel interface — and any process that can reach it rides it. Malware running as the signed-in user, a malicious browser extension, a compromised build agent on the same host: none of them re-authenticate, because the authentication already happened and the enforcement point is not being asked again. So the blast radius of one connection-scoped grant is *everything the account can do on the far side of that pipe*, for as long as the pipe is up. If the destination is an internal administrative console, that is the console's whole surface. The only remaining boundary is the far side's own authorisation. A per-request grant does not make the implant harmless — a request the user is legitimately allowed to make still passes — but it narrows the set to requests policy permits and it attributes each one. ## The price, stated honestly | Unit of decision | What it can deny | What it costs | |---|---|---| | One connection | Who may open a pipe, from what device, to which destination | One decision per session; nothing on the hot path | | One request | Which methods, paths and resources inside the session | A parse plus a policy evaluation on every request | The cost is not only latency, and this is what a good answer adds: - **Hot-path work.** Every request pays a parse and an evaluation at the connector. On a chatty internal application that is thousands of evaluations a second that did not exist before. - **Protocol understanding.** The connector must implement the protocol well enough to find request boundaries — framing, streaming responses, long-lived requests, multiplexing. It cannot decide per request on a protocol it cannot take apart. - **A rule surface someone owns.** Per-request policy means rules about paths and methods, and applications change. A stale rule here does not annoy an analyst; it returns a denial to a real user and breaks a business flow. - **Failure posture.** A per-request decision is a dependency on every request. What the connector does when policy is unreachable becomes a design decision with a visible consequence either way. ## Getting the direction of the claim right A grant proves that **a credential and a device passed policy at that instant**. It does not prove a human was driving, and it does not keep proving anything a second later. Per-request decisions narrow what a non-human process can do with the session; they do not establish that a person is present. Candidates who say "per-request means we know it is really them" have the direction wrong. ## The sentence to have ready "A connection-scoped grant authorises reachability plus whatever the account can do behind it; a request-scoped grant authorises one call. The first is cheap and the second is not, and the difference is paid on every request." That sentence, plus a named example of a system in your estate that can only ever have the first, is a complete answer at this level.
- If the implant only issues requests the user is allowed to make, what has the per-request grant bought you?Attribution and bounds, not prevention. Every request now has a decision record naming the identity, device and resource, so the incident is reconstructable and unusual sequences are visible. And the set of possible actions is bounded by policy rather than by whatever the account can do on the far side. A per-request grant narrows and records; it never proves who typed.
- Where does the parse and decision actually happen, and why does that placement change the cost?At the connector next to the workload, or at a broker in front of it. The expensive shapes are a network round trip to a remote decision service on every request, or re-establishing a session per request. Evaluating a small local policy in-process after parsing is far cheaper. Before conceding on latency, measure which shape you actually have.
- Does a shorter session make a connection-scoped grant equivalent to a per-request one?No. It shortens the window but not the scope: inside the window the implant still has everything the account can do behind that pipe, and you still have no per-request record of what it did. Shortening sessions is a different lever with a different price, and it does not turn one decision into many.
A connection-scoped grant is a door badge that unlocks the room; a request-scoped grant is a clerk who checks each item you ask for. The clerk is slower, and the badge lets anyone who follows you in take anything.
saying these in an interview costs you the question
- Says the attacker would still need the user's credential
- Treats per-request decisions as free
- Calls a connection-scoped grant zero trust because a decision was made
- Claims a per-request grant proves a human is present