The airport-recovery demo: losing your laptop and recovering in two minutes

I ran the lose-the-laptop scenario deliberately against the live AgentKMS cluster yesterday — Linux laptop as the existing machine, an Apple Silicon Mac as the new one. The Mac had never connected to AgentKMS. No keys, no certs, not even the kpm binary. The point was not to validate a unit test. The point was to see whether the design actually held when a real browser had to talk to a real biometric authenticator and the new machine had to mint its first cert from a private key the server would never see.

Here is exactly what happened.

What you do before you lose the laptop

On initial setup, you register a passkey — Touch ID on macOS, a YubiKey, whatever satisfies your WebAuthn authenticator:

kpm webauthn register --type passkey

That ceremony ties a credential to your device’s secure enclave. From that point forward, your device cert and your biometric are the two factors the system knows you by. This is the one-time setup that makes the recovery path possible. Skip it and your recovery options narrow to out-of-band support.

On the existing machine

Two commands on the laptop you still have, while you still have it:

kpm login --step-up                      # Touch ID / passkey ceremony
kpm device add bert-desktop --ttl 30m   # mints a single-use bootstrap token

kpm device add calls POST /auth/bootstrap/issue on the AgentKMS cluster and gets back a short-lived bootstrap token. That token encodes permission for exactly one thing: mint a device cert for user=bert, device=bert-desktop. Nothing else. The --ttl 30m means it expires in thirty minutes whether it is used or not.

The token is a string. You can copy it anywhere — a note, a text message to yourself, a shared doc. It is not a credential that grants access to your secrets. It is a credential that grants access to the ability to present yourself as bert on bert-desktop — and only for half an hour.

On the new machine, fresh out of the box:

# Install kpm, configure the server endpoint
kpm enroll --user bert --device bert-desktop <token>
kpm login
kpm list   # ← same secret stash, different device cert, portable identity

kpm enroll calls POST /auth/cert/issue, which verifies the bootstrap token against the cluster’s token store and, if it is valid and unexpired, issues a fresh device cert keyed to a private key generated on the new machine. The new machine’s private key never leaves that machine. The server never sees it — only the CSR.

After that, kpm login is a normal certificate-based auth flow. kpm list shows the same secrets the Linux laptop already holds, because the secrets are indexed to my user_id, not to any particular device.

Why this works: identity is split

The interesting design point is not the token. It is the identity model underneath it.

Every cert AgentKMS issues encodes a SPIFFE URI:

spiffe://catalyst9.local/tenant/<t>/user/<u>/device/<d>

The user_id is my logical identity — portable, durable, the thing secrets are indexed to. The device_id is this specific machine — scoped, revocable, and tied to a private key that lives only on that device’s disk. They are two separate axes.

If my laptop were stolen, I could revoke the device cert for that machine without touching my user identity or my secrets. The audit trail for every secret access that laptop ever made would stay in place, tagged to its device ID. The replacement machine gets a new device cert with a new key. The user_id bridge is continuous.

The bootstrap token is what makes the initial enrollment safe: it grants authority to mint a cert for user=bert, device=bert-desktop and nothing else. The server validates that the token’s user and device fields match what the enrolling machine requested. A stolen token cannot be used to impersonate a different user or claim a different device name.

The real limit

There is an edge case and it is worth being direct about it.

Minting a bootstrap token requires kpm login --step-up, which requires WebAuthn on the originating device — the device that already holds a registered passkey. If the laptop is already gone and it was the only device you ever registered a passkey on, you cannot self-serve a recovery token. You need a backup factor — a second registered device, a recovery code stored somewhere offline, or a support escalation to your cluster admin.

The design does not pretend this problem away. A passkey on a single device is a single point of failure. The mitigation is to register at least one backup authenticator — a YubiKey, a second machine — before you need it. Most people do not do this until the first time they need it.

What comes next

Part 10 covers the full four-principal identity model that this demo is the first slice of — human, device, workload, and agent — and what it means to have a single audit schema across all of them.

Part 11 covers what actually happened when I tried to ship the WebAuthn flow. Five bugs cascaded out across three layers of the stack. Every single one of them had passing unit tests.