When should infrastructure say no?

Most infrastructure is built to say yes by default — the request is valid, so it executes. That default makes sense when the requester is a careful human who already decided the action was warranted. It’s less obviously correct when the requester is an automated system acting on a decision nobody directly reviewed.

Looking at where existing systems actually push back, the honest answer is: rarely, and usually only for clearly malformed requests, not for requests that are well-formed but unwise. A script that requests something destructive, correctly formatted, inside its stated permissions, will almost always be allowed to proceed — because the infrastructure has no concept of “allowed but worth questioning,” only “allowed” or “not allowed.”

That binary is worth examining. Some actions are reversible and low-stakes, and for those, defaulting to yes is fine — asking for confirmation on every harmless operation just adds friction. Other actions are difficult or impossible to undo, and for those, “technically permitted” isn’t the same bar as “should proceed without another check.” Infrastructure that treats every permitted action identically is applying the wrong amount of caution to both ends of that range.

We don’t think the answer is adding friction everywhere. It’s identifying the smaller set of actions where the cost of being wrong is high enough that a second check — even a lightweight one — is worth the delay. Defining that set clearly, ahead of time, is the actual engineering problem; “infrastructure should sometimes say no” is easy to agree with and hard to implement precisely.