Everyone who has put a proxy in front of a real workload has the same scar. It went in, it worked for the traffic it understood, and then something unrelated stopped working. A database connection. A message queue. A long-lived stream. Something that was not web traffic at all, handed to something that only speaks web, producing an error nobody could read.
That experience is why platform teams are slow to adopt anything that sits in the path. Not because they doubt the value. Because they have been burned by scope, and scope is the thing vendors are least willing to talk about.
So make them talk about it. Three questions do the work, and they are more revealing than any feature list.
"What do you not touch, and how do I verify it?"
Out of scope usually means "we have not got to it yet", which quietly means "we may break it". It should mean something firmer: this is not ours, we will not inspect it, and we will not damage it.
That is a design commitment with teeth. Interception applies to the ports where web traffic actually lives; a connection that is not that is accepted and passed straight through. Your Postgres session on 5432 behaves exactly as it did before, because nothing tried to be clever with it.
The negative requirement is the load-bearing one, and it is worth being blunt: an outbound connection that is not governed must arrive at its destination unharmed. Not refused. Not garbled. Not held while something inspects it and gives up.
A real answer names the boundary and then tells you how to watch the pass-through happen. If you cannot verify it, it is a promise rather than a property.
"What is your control on a connection you cannot read?"
This is the subtler one, and it is where a scope claim usually gets stretched.
Governing a request means reading it. Some connections cannot be read — the client pins the destination's certificate, so anything that opens the connection breaks it, and the honest thing is not to. What remains visible is the destination and nothing else.
Concretely: for an ordinary web API you can allow one specific action to one specific path and refuse the rest. For a pinned client talking to the same vendor, the only two answers available are this destination, yes and this destination, no. Both are real controls. They are not the same control, and an operator who believes per-action rules are being applied to a connection where only the destination is visible has a false picture that they built from a product page.
Squidder reads the connections it can and passes through the ones it cannot, and it tells you which of the two you are getting for a given destination.
If the answer you get does not distinguish between destination-level and action-level, keep asking until it does. And if a destination genuinely needs the finer control and it cannot be provided there, the honest response is to say so rather than to apply the coarse one and let the label imply the fine one.
"What happens to a protocol you have never seen?"
"Passed through" is the answer you want. "It should work" is not.
But there is a version of pass-through that is too generous, and it is where a governance product quietly becomes decorative. If out of scope also means unobserved, then out of scope is a channel. Anything that wants to move data without being looked at simply moves it over something you do not govern, and your control plane reports a clean picture of a subset of reality.
So the answer has two halves: passed through, and counted. You should be able to see that a workload is opening connections you are not governing, and to which destinations. Not the contents, which you have committed not to read. The fact of it. And where a deployment is locked down enough to want it, refusing them wholesale should be available. Most organisations will never turn that on. Being able to is what makes the counting mean anything.
The vendors worth your time will be relieved to be asked all three, because they have thought about it and nobody ever lets them say so. The rest will talk about coverage.