Why approval alone fails
A boolean allow decision answers whether a request was approved at one moment. It does not prove the exact same request is what later executes.
Between approval and execution, payloads can drift, retries can replay, and alternate paths can bypass the check entirely. That is why an allow result alone is not enough for high-risk actions.
What the permit adds
The permit binds the approved request to concrete claims: who requested it, what action was approved, what payload hash was accepted, which policy version allowed it, and how long the execution window lasts.
- Signed: the gateway can verify who issued it.
- Short-lived: the approval cannot sit around and be reused later.
- Hash-bound: a changed payload stops matching the approved request.
- Single-use: the first successful execution consumes the permit.
Why the invariant is so strong
No permit, no execution means there is no protected path that works without that artifact. Changed payload? Hash mismatch. Expired permit? Rejected. Reused permit? Rejected.
The phrase sounds simple because it should. Strong security invariants are easiest to trust when they are easy to explain and hard to route around.