Capability is not authorization

Why a system should treat the ability to act and the permission to act as two separate things — and how a conjunctive, fail-closed gate enforces that separation.

Most security incidents are not caused by a system that could not do something. They are caused by a system that could, and did, without anyone having decided it should. The lesson is old, and it has a compact statement: a technical capability is never an authorization.

The two things people conflate

"Can this run?" and "May this run?" are different questions with different owners. The first is a fact about the software. The second is a decision that belongs to a person or a policy. When a design lets the first answer stand in for the second, it has quietly handed authority to whatever component happens to be able to act — a model, an agent, an imported result, a plugin.

A gate, not a checkbox

Separating the two means every consequential action must pass an explicit chain of controls before it runs: an authenticated identity, the exact permission for the action, a valid signed usage right, an authorized scope, a risk classification, the human approval that risk demands, and control over where the action may reach on the network. The chain is conjunctive — all of it must pass — and fail-closed — a control that is missing or unreadable is a denial, not a default allow.

Why fail-closed is the whole point

A gate that fails open is not a gate; it is a speed bump. The value of the design is precisely in what it refuses when something is ambiguous. An action whose risk cannot be classified is treated as high risk and denied. A finding whose evidence cannot be re-verified stays a lead. The system's honesty lives in the cases where it declines to proceed.