Authority is explicit, bounded and expiring
Nobody “has admin.” Every grant names the action, the resource, the limits and the lifetime, and delegation can only shrink it.
Architecture
Five layers, one authority stack.
Each layer deploys on its own. Their guarantees do not. The card depends on the controller; a proven kernel does not verify the controller’s policy; an interlock enforces exactly one invariant. Saying which needs which is half the work.
The stack
| Layer | Component | What it replaces | Property it restores | Horizon |
|---|---|---|---|---|
| 01 | Effect card | Passwords, sessions, API keys | Presence-gated, challenge-bound delegation | Now |
| 02 | Silicon root | The TPM as an optional feature | Evaluated hardware root; diversity scoped to named exploit classes | Years 1–2 |
| 03 | Vault OS | Linux and Windows on high-consequence machines | Explicit, bounded, expiring authority: no ambient authority at all | Years 2–3 |
| 04 | Dark network | Open reachability of effect interfaces | Bounded admission in front of every protected interface | Year 3 onward |
| 05 | Physical enforcement | Software safety checks in SCADA and weapons | Non-digital limits and an engineered safe fallback | With partners, from year 1 |
The first product is Layer 1 and its controller, protecting one fully specified effect. Everything above it is sequenced by which buyer needs it, not by ambition.
Dependency map
Which guarantee needs which component.
The failure mode of a security architecture is assuming one property implies another. These four do not imply one another, so they are proven separately.
| Guarantee | Requires | Does not follow from |
|---|---|---|
| Authorization No protected effect without an applicable grant | An effect controller with a grant registry, on hardware the host cannot rewrite | A card alone; a proven microkernel alone |
| Accounting No overspend under delegation, concurrency, retry or restart | The controller’s ledger as source of truth, and an executor participating in exactly-once commit | A card balance; a token format |
| Safety Admitted transitions stay inside a modeled envelope | A domain controller with its own sensors, a modeled envelope, and independently provisioned safety authority | Authorization or accounting; a physical interlock alone |
| Presence A remote attacker cannot supply the human step | A card with a physical release and challenge-bound tokens | Non-exportable keys alone: a released token is an ordinary digital object |
| Non-transferability A memory-corruption exploit does not carry across installs | Per-install diversity keyed by the hardware root | Anything at all about logic or authorization errors |
Design principles
Eight commitments the architecture is held to.
01
02
Enforcement lives outside the host
The component that admits an effect runs on hardware the application host cannot rewrite, and trusts nothing the host reports.
03
Disclosure is an effect
Reading public data is free and anonymous. Releasing private data across a trust boundary is consequential, and is gated like any other effect.
04
Presence and scarcity are mechanisms, not proofs
A press proves a person acted. A spent token proves a budget drained. Neither proves the request was legitimate. The grant does.
05
Bounded consumption is not bounded loss
Envelopes are per resource and multidimensional. Operation counts alone bound nothing, and limiting the machines affected does not bound every business consequence of disrupting them.
06
Diversity for specified classes only
Per-machine variation defeats layout- and encoding-dependent exploits. It does nothing against a shared authorization error, which the envelope must catch.
07
Understanding grants nothing
Security survives the attacker holding the full specification and the source. Nothing depends on the attacker staying confused.
08
Honest assurance
Accounting, authorization and safety are three separate claims, each proven or tested under stated assumptions. “Impervious” is never claimed.
The authority model
An effect is not one API call.
This is the research program, and it is the part most easily waved past. A single permitted action may create durable authority, release information, schedule future work, or change the behavior of a system that keeps running. One approved deployment can install a service that then makes thousands of requests. Counting the initiating action once and assuming its consequences are bounded is not defensible.
There are two defensible ways to handle downstream consequences, and we use both:
- Constrain later authority. Every downstream consequential operation passes through enforcement and consumes its own allocation.
- Authorize a bounded continuing activity. The deployment creates an explicit lease (resources, duration, aggregate limits, and termination behavior) rather than a standing permission.
Leases, not kill switches. A capable adversary disables a switch. Here authority expires unless a human renews it, and silence means a defined safe mode. The lease proves that a person renewed it. Nothing more. The grant, not the lease, bounds what may happen while authority is held.
Layers 2 to 5
What the rest of the stack is for.
Layer 02 · silicon root
A hardware root with evaluated properties
Device identity derived on first boot and never shipped; per-install variants that deny exploit transfer within named classes; and offline, split-custody root secrets. The requirement is a specified, evaluated property, not a particular mechanism, and never a blanket claim of unclonability.
Layer 03 · vault OS
The bank already has a website and a vault
This is the vault’s operating system, and the vault grows. Every process is treated as a possibly adversarial contractor with explicit, bounded, expiring authority: a minimal core for isolation and accounting, with small domain controllers above it interpreting consequential operations. Linux keeps running the AI and the legacy applications; root there cannot enlarge what the vault granted it.
Layer 04 · dark network
Can an unauthorized endpoint make us process anything?
One narrow question, answered without replacing the internet: nothing is reachable or visible until introduced, identity replaces location, every packet is signed at its source, and authority accrues with relationship history. An introduced host that is later compromised is already inside; containment after that is the controller’s job, not the network’s.
Layer 05 · physical enforcement
Where software meets the world
Two diverse controllers must agree; final enforcement is non-digital: governors, fuses, relief valves. Safety authority is provisioned independently, so exhausting discretionary budget can never exhaust the ability to enter and hold safe mode. Authority to operate a device never includes authority to change its safety policy.
Precedents throughout: seL4 and Fuchsia for capability-based kernels; SCION, already carrying Swiss interbank traffic, for identity-based routing; unidirectional gateways deployed in nuclear, power and water today; nuclear Permissive Action Links; DARPA’s HACMS, which flew a separation kernel on Boeing’s Unmanned Little Bird and held against a red team given a compromised partition.