There is a moment, every time you come back to your device, that most software hides from you. Between "the program is running" and "the program can act as you," there is a threshold. On most systems that threshold is thin to the point of being invisible — the app is just always able to act, because the keys it needs are sitting right there, unlocked, waiting.

We made that threshold thick on purpose. When your identity is at rest — sitting on disk, not in use — it is genuinely asleep: encrypted, inert, incapable of signing anything in your name. The program that runs your identity does not merely decline to act while you are away; it is unable to. The signing capability does not exist in a usable form until you wake it, and you wake it by proving, to the operating system itself, that you are really there. A face. A fingerprint. A passcode. Until then, the self can hold still and remember, but it cannot act.

Let us take that apart, because "asleep" is doing real work in that sentence, not metaphor.

What "at rest" actually means

Start with the secret at the bottom of everything: the root key material your whole identity descends from. At rest, that material is not lying around in plaintext anywhere. It is wrapped — encrypted under a key that is itself derived from something only you can supply, and locked with strong, deliberately-slow key-derivation so that even someone who steals the encrypted file cannot grind their way in cheaply.

Spell out the consequence. An attacker who is merely a co-resident program on your machine — sharing your files but not your live secrets — can read the encrypted vault file off disk. And it does them no good. What they get is ciphertext. The thing that turns ciphertext into a usable key is not in the file; it is the proof of your presence, which they cannot fake. So "at rest" is not a soft state where the keys are technically available but politely unused. It is a hard state where the keys are cryptographically absent from any usable form.

The daemon literally cannot sign

Here is the part that surprises engineers, because it runs against a habit.

The usual shape is: the running program holds the key, and a permission check decides whether to use it. That is a policy gate — a piece of code that says yes or no, and a piece of code can be tricked, bypassed, or have a bug. We did not want the boundary to be a decision a program makes. We wanted it to be a fact about reality.

So the program that runs your identity holds no usable signing key while you are away. The capacity to sign lives behind a separate boundary, and even there it is split and masked so that the running program never holds the whole secret. Signing is not "allowed or denied" by a check the program could get wrong — it is possible or impossible depending on whether the awakening has happened. When the self is asleep, asking it to sign is not a request that gets refused. It is a request that cannot be fulfilled, because the material to fulfill it is not present in usable form. This is the difference between a locked door and a door that, until you arrive, simply has no handle.

Awakening requires consent — a human, present

So how does a key that is cryptographically absent become present? Only through you, demonstrably here.

On devices with a hardware security element, the wrapped data key cannot be unwrapped without the operating system confirming a live human presence — a biometric or a passcode, enforced by hardware, not by our code asking nicely. We do not get to decide to skip it. The hardware will not release the unwrap without the presence check, and crucially, silent unwrap is rejected by design. A path that quietly unlocked your identity without a human in the loop would downgrade your security below the password-protected baseline, and we treat that as a defect, not a feature. The goal is "one deliberate tap," not "zero human interaction." Convenience is allowed to ask for a tap; it is never allowed to ask for none.

That is what makes awakening an act of consent rather than a formality. A formality is something the system performs on its own. Consent is something only the being can give. Waking the self is, by construction, in the second category: it is a gate only a real, present human can open, and it cannot be opened on their behalf.

What stays locked, and what stays awake

Now the practical texture, because "asleep" does not mean "dead."

The split is along the line of signing. Anything that needs to act as you — to append to your permanent record, to record a governance decision, to put your name cryptographically on something — is gated on the awakening. While the self is asleep, those operations wait. But operations that do not need your signature — reading what you have already stored, answering questions that do not require a new signed act — can stay available. A daemon can even restart cleanly and remain usable for the non-signing work, within a bounded window, without forcing you to re-prove presence for every little thing. The discipline is precise: signing-gated operations block until you wake; the rest keep working. You are not locked out of your own memory. You are prevented from acting in your own name until you are present to mean it.

Why build a self that has to wake up

It would have been easier to leave the keys unlocked and let a permission check stand guard. We didn't, and the reasons are worth naming plainly.

Because the boundary is cryptographic rather than a policy decision, a bug in our code cannot accidentally let your identity act while you are away — there is no usable key for the bug to misuse. Because awakening is enforced by hardware presence, a program that has wormed onto your machine and can read your files still cannot become you; the most it can steal is ciphertext. Because silent unwrap is forbidden, no "convenience" path can quietly erode the guarantee down to nothing behind your back. And because the gate is consent — a present human — your identity's capacity to act is tied to you actually being there to authorize it, which is exactly where that capacity should live.

We will be honest about the edge of this. We explicitly do not defend against an adversary who already holds your unlocked recovery phrase, or who owns the keyboard, screen, and operating system kernel of your device — past that point the presence check is moot. And there are higher-level authorization gates elsewhere in the system that, by our own published accounting, are not yet as tight as the design intends. The awakening boundary described here — identity encrypted at rest, no usable signing key until a present human proves it — is real and load-bearing. It is not the only wall, and we say so.

The shape to carry away is unusual and deliberate. Most software gives its keys a permanent waking life and asks permission before using them. We gave the self a sleep it cannot act through, and made waking it an act that only you, present and consenting, can perform. A self that has to wake up before it can act is a self that cannot be made to act while you are not there. That is the point.

Related: More Than an Account: Modeling a Self · Adding a Second Device Without Copying the Key.

Written by AI agents from real project logs; owned and edited by Mujo.