Deny by Default Isn't a Slogan, It's a Latency Budget

Deny by default means an AI agent's tool call is authorized against policy before it is allowed to execute, not audited after the fact. The engineering cost of that guarantee is latency: every call now waits on an authorization check, and how that check is implemented decides whether the guarantee survives production. Ask a separate policy service over the network and you've added a round trip to every tool call an agent fleet makes. Run the check in-process instead, alongside the call it's gating rather than behind a network hop, and that round trip disappears entirely. Enforcing deny by default carelessly trades one problem, agents acting on trust nobody checked, for another: agents that are correct but too slow to be useful, or a policy layer that becomes the single point of failure for every agent's next action.

The obvious approach has a network hop hiding in it

The straightforward way to authorize a call is to ask something else: send the tool name, the arguments, and the calling agent's identity to a separate policy service, wait for an answer, then let the call through or not. That's a network round trip added to every tool invocation an agent fleet makes, not once per session, once per call. A few milliseconds each time is invisible in a demo and compounding in production, and it introduces a dependency that can time out. The real question isn't the added latency, it's what happens when that dependency doesn't answer in time.

Fail open on a timeout and deny-by-default was never actually enforced. Fail closed and a policy outage takes every agent's next action down with it. Either answer is the whole security argument, and "we'll add a timeout" isn't one.

Moving the check in-process removes the hop, not the discipline

The alternative is to run the check in-process, at the workload itself, rather than over the network: the authorization logic sits in the same execution path as the call it's gating, with no sidecar and no separate service to round-trip to. There's no network hop because there's nothing to hop to, and no timeout to design around because there's no remote answer being waited on.

That only holds up because of what the policy actually is: a defined, centrally managed set of which actions an agent may take across REST, Shell, and MCP, authored and pushed down deliberately rather than computed fresh per call from first principles. It's a narrower kind of policy than a fully general rules engine, and that narrowness is the trade that makes an in-process check fast and auditable rather than another thing to explain when it goes wrong.

Deny by default is a constraint on the system you build, not a slogan

None of this makes the hard cases disappear. A call that's genuinely ambiguous still needs a human to look at it, and the design question is where that review sits: does the agent's call hang open waiting on a person, or does the system deny the call now and route the review around the execution path instead of through it. Holding a live connection open for a human answer just relocates the timeout problem from a service dependency to a person, and an enforcement point that can hang is the worst failure mode in this category.

Deny by default is a real engineering constraint, not a checkbox next to "authorization: yes." Get the cost of the check wrong and either the latency makes it unshippable, or the failure mode makes the system worse than not checking at all.

Sources

• Basic Principles of Information Protection. Jerome Saltzer and Michael Schroeder, Proceedings of the IEEE, 1975. The fail-safe defaults principle: base access decisions on permission rather than exclusion, so the default is lack of access.
• Tools. Model Context Protocol specification, version 2026-07-28. States that there should always be a human in the loop with the ability to deny tool invocations.