The Case for Negative Capabilities
Why Deny is safer than Allow in real systems.
This note describes a structural safety property. It is not a tutorial, not best practice, and not integration guidance.
Claim
Systems are safer when they model explicit denial instead of implicit permission.
A negative capability answers a single question:
“Is there a reason this action must not occur?”
The failure mode of allow-lists
Allow-based systems usually encode logic like:
> User is allowed if condition A, B, and C are true
This approach fails quietly when:
- State is missing
- Inputs are stale
- A new case is added but not wired everywhere
Absence of information becomes interpreted as permission.
Negative capability framing
A deny-first system asks a different question:
- Is there an explicit denial signal present?
If the answer is yes, the system stops.
If the answer is no, the system continues — but only because no prohibition is known, not because permission was granted.
Invariants
- Not denied ≠ permitted
- Absence of a deny signal is not an allow-list
- Denial signals override all other state
Negative capabilities preserve uncertainty instead of collapsing it into false confidence.
Failure modes
- Stale reads cause denial to persist longer than intended
- Clock skew delays deny expiration
- Operators forget to remove denial records
These failures are visible and conservative. They fail closed, not silently open.
Relation to SimpleStates
DenySignal emits whether a denial exists at read time. It does not block execution.
Your system decides how to react to that fact — immediately, partially, or not at all.