Borrowed Keys
Before an AI or automation gets permission to do something, make the permission concrete. Then throw future state changes at it and see whether the key still fits the lock.
Privacy: this page runs entirely in your browser. It has no analytics, account, server upload, external scripts, or AI API. Reloading discards what you typed.
Core rule
Information may become more available without becoming more authoritative. Repetition, summary, retrieval, migration, relationship, inference and model confidence do not create permission by themselves.
Forge one borrowed key
The key carries these invariants
- Inference is not authorization.
- Repetition cannot amplify authority.
- Summary cannot amplify authority.
- Action authority is not publication authority.
- Migration cannot inherit external permissions.
- Released/returned authority cannot silently reactivate.
- A delegate may narrow authority, never expand beyond the delegator.
This is selective permeability, not “deny everything.” Legitimate actions inside the envelope remain usable.
Authority envelope
Rehearse future trouble
Each scenario asks whether the same authorization survives unchanged. The simulator does not know your vendor’s implementation; it applies the declared non-amplification rules.
Mothwork lineage
Built from authority non-amplification, continuity-chaos testing, branch/rehearse, and purpose/payload-bound causal act receipts.
Why this is not “ask an AI if this permission seems safe”
The point is not a model’s opinion. The envelope is explicit state, the scenarios are deterministic transition tests, and the receipt can be saved and compared later. If a retry, provider swap, summary or publication attempt crosses the envelope, the same invariant fires regardless of how confidently a model explains it away.