An application team wants a connection-scoped grant on its busiest internal service to protect p99: how do you weigh that against the open pipe?

## Turn a slogan fight into two measurements The request as stated — "give us a connection-scoped grant, per-request checking costs us p99" — is usually made before anyone measured. Two numbers settle most of the argument. **Where does the cost come from?** Per-request enforcement has several possible shapes with wildly different costs: | Shape | Typical cost per request | |---|---| | Parse plus in-process evaluation of a small policy at a connector next to the workload | Sub-millisecond to low milliseconds | | Parse, then a network call to a remote decision service, per request | A full round trip, plus its failure modes | | Re-establishing a session or re-authenticating per request | Far worse, and usually a design error | If the team is quoting the second or third and you can deliver the first, the disagreement is about implementation, not about the unit of decision. **What is actually behind the endpoint?** "The busiest internal service" is not one thing. Ninety-plus percent of the volume is usually a small number of read paths. The dangerous surface is a handful of state-changing and administrative operations that carry almost no traffic. The trade you are being offered is stated at service granularity; the answer is at endpoint granularity. ## The shape of a defensible compromise - **Keep the unit of decision, cheapen the decision.** A per-request grant does not require a complicated rule. A broad allow for a path prefix is trivial to evaluate and still yields a decision record naming identity, device and resource for every call. You keep attribution and bounded scope while paying almost nothing for the high-volume paths. - **Spend the real rules where the volume is not.** Administrative and write paths get specific policy. They are rare, so their cost is invisible in the aggregate. - **Concede where there is nothing to concede.** Protocols the connector cannot parse are already all-or-nothing. Saying so builds credibility, and it moves that conversation to where it belongs: the target system's own accounts, permissions and audit trail. - **Refuse the blanket version.** A connection-scoped grant covering the administrative surface as well as the read paths is the version to push back on, because that is where an implant on an authorised device converts one session into every action the account can perform. ## What you owe the team in return Be explicit about the failure posture you are introducing, because it is the team's outage as much as yours. A decision on every request is a dependency on every request: if the policy path is unavailable, does the connector fail closed and take the service down, or fail open and stop being a control? That choice belongs in the same conversation as the latency number, and it is the one an application team will remember. Also be explicit about the maintenance burden you are asking them to carry. Per-request rules track the application's own surface. When they add a path, a stale rule denies real users. If nobody on their side will own that, a per-request grant degrades into a broad allow anyway — better to plan for the broad allow deliberately than to discover it during an incident. ## Say the consequence in one sentence When you do grant connection scope, put the consequence in writing in language the team will recognise: *"Any process running on an authorised laptop that can reach the local tunnel endpoint gets everything this account can do on your service, for as long as the session is open, and your application's own log is then the only record of what it did."* That sentence does more than any policy document, because it converts an abstract control into a description of their service on a bad day. ## The wrong answers to aim at The first is refusing on principle — insisting on per-request enforcement everywhere, which gets the control removed entirely the first time it appears in an incident review for latency. The second is conceding at service granularity because the team quoted a number, without checking which shape produced it or which endpoints the concession actually covers. Both are common; the difference between them and a good answer is that a good answer arrives with a measurement and an endpoint-level proposal.